Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a mechanism to list available locales for a given data key. #1092

Open
gregtatum opened this issue Sep 23, 2021 · 3 comments
Open

Provide a mechanism to list available locales for a given data key. #1092

gregtatum opened this issue Sep 23, 2021 · 3 comments
Assignees
Labels
C-data-infra Component: provider, datagen, fallback, adapters S-medium Size: Less than a week (larger bug fix or enhancement) T-core Type: Required functionality

Comments

@gregtatum
Copy link
Member

In SpiderMonkey we are asserting in debug builds that our generated locale data are consistent by checking the locales available for different components. ICU supports this through functions like udat_getAvailable. It would be nice to have generic support of this through the provider. I did a quick look through the code and didn't see existing support for it, but I might have missed it.

It seems like with the modularity of the project, finding this out would be useful, especially if using data from different sources.

@gregtatum gregtatum added the C-data-infra Component: provider, datagen, fallback, adapters label Sep 23, 2021
@sffc
Copy link
Member

sffc commented Oct 21, 2021

Action: implement iterable data provider on runtime providers.

@sffc sffc self-assigned this Oct 21, 2021
@sffc sffc added S-small Size: One afternoon (small bug fix or enhancement) T-core Type: Required functionality labels Oct 21, 2021
@sffc sffc added this to the ICU4X 0.5 milestone Oct 21, 2021
@sffc sffc modified the milestones: ICU4X 0.5, ICU4X 0.6 Jan 27, 2022
@sffc
Copy link
Member

sffc commented Feb 17, 2022

Related: #211

I think we need a way for providers to declare what set of languages they support, not at a key level as we currently have, but at the overall provider level.

pub trait LocaleProvider {
    fn iter_locales(&self) -> impl Iterator<LanguageIdentifier>;

    fn supports_locale(&self, &LanguageIdentifier) -> bool;
}

Meanwhile, IterableProvider is and should continue to be a low-level trait with one purpose, to drive the data exporter.

This model means that providers implementing this trait must support the same set of locales for all keys. I think this is an okay and perhaps beneficial constraint. ForkByKeyProvider will not be able to implement this trait, which is fine.

@sffc
Copy link
Member

sffc commented Jul 25, 2022

Mostly a duplicate of #58, which is marked as 1.x

@sffc sffc added S-medium Size: Less than a week (larger bug fix or enhancement) and removed S-small Size: One afternoon (small bug fix or enhancement) labels Jan 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-data-infra Component: provider, datagen, fallback, adapters S-medium Size: Less than a week (larger bug fix or enhancement) T-core Type: Required functionality
Projects
None yet
Development

No branches or pull requests

2 participants