Making IterableResourceProvider return Locales instead of ResourceOptions
#2175
Conversation
|
|
||
| /// A [`DynProvider`] that can iterate over all supported [`ResourceOptions`] for a certain key. | ||
| /// A [`DynProvider`] that can iterate over all supported [`Locale`]s for a certain key. |
There was a problem hiding this comment.
Issue: I am not aligned on the motivation for this change (trying to remove ResourceOptions from public APIs).
| key: ResourceKey, | ||
| ) -> Result<Vec<ResourceOptions>, DataError>; | ||
| /// Given a [`ResourceKey`], returns a list of [`Locale`]s. | ||
| fn supported_locales_for_key(&self, key: ResourceKey) -> Result<Vec<Locale>, DataError>; |
There was a problem hiding this comment.
Issue: We may want to use the name supported_locales_for_key for the actual supported-locales logic proposed in #58 (comment) in the post-1.x timeframe. I would like this trait to remain datagen-specific for the time being.
The other issue here is that I think we may want to retire this mechanism in the data exporter entirely, and instead use a declarative list of locales combined with locale fallback. At least when reading CLDR data, we only need to load the list of CLDR locales one time, and then use the same list for all of the data keys. See #834 for further discussion.
Implementors usually have
Locales and should just be able to return those without depending on the representation insideDataRequest. This allows us to makeResourceOptionsprivate (see discussion in #1995).