Shane F. Carr

Discuss with: - @sffc - @robertbastian - @younies - @Manishearth

Another possible solution: 4. Add a data key that contains a unique entry for each locale. For example, `supported@1/en-GB` which contains a single string "en-GB" so it doesn't get deduplicated....

What crate should this go into? I lean toward putting it with the rest of the fallback-type code in `icu_locid_transform`.

How does this look? ```rust #[icu_provider::data_struct(SupportedLocaleV1Marker)] pub struct SupportedLocaleV1, } pub struct SupportedLocale { data: DataPayload, } impl SupportedLocale { pub fn load_unstable( provider: &P, locale: &DataLocale ) -> Result...

@robertbastian to make a counter-proposal.

I'm concerned about relying on `response.metadata.locale` because 1. We have a [tutorial example](https://github.com/unicode-org/icu4x/blob/main/docs/tutorials/data_provider.md#accessing-the-resolved-locale) that suggests it is okay to remove the locale from the response metadata 2. The resolved locale...

@zbraniecki The latest thinking (exact API shape yet to be decided) is that the supported locales list is based on the locales for which data was generated. So even if...

A crucial question here is whether it is important to discriminante the list of supported locales based on data key. I proposed several solutions that relax this constraint but give...

From talking with @zbraniecki about this extensively today, here is my understanding: In general, locales could be supported in three ways: (a) fully supported, (b) supported via an approximate fallback,...

Here's a low-cost proposal that might be "close enough" to get the job done and be spec-compliant. We add a new fallback mode called `--fallback thin` which is the same...