You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm working on a proposal for ICU4X 2.0 for unified model of handling resolution between four sources of locale preferences:
Explicit Unicode Extension in a selected locale
Explicit preferences listed in the options bag passed to the constructor
Implicit defaults for a given locale
Explicit preferences set in the host environment (Operating System)
This is a long standing battle over how to provide good defaults for negotiation of preferences between user and developer (see tc39/ecma402#109 for an old attempt) in a privacy respectful way, in a multi-level (app settings, browser settings, OS settings) environment.
I've been modelling the relation between 1., 2. and 3. for quite some time, and have always wanted to incorporate scalable solution that includes 4.
The gist is that I'm rethinking Locale to be a type of a Preference Bag, that can be "merged" with another. In ICU4X we want to do this explicitly outside of the constructor, allowing developers to build their own wrappers that perform the merging in any direction and with any of the 4 involved.
Since the goal of ICU4X is to supply the needs of ECMA-402, I'd like to suggest we collaborate on the design of this proposal and icu_preferences API, since ICU4X will want to make implementing this proposal easy.
My only early feedback is that you seem to follow UTS35 in naming it Extensions. I'd like to suggest renaming it to Locale Preferences - the term extensions in UTS makes sense since its an extension to Language Identifier, but in context of this API it overcommunicates that. We really are talking about regional preferences, or internationalization preferences.
Here's a sample of how the current API in ICU4X is intended to work, for reference:
// 1. Explicit Unicode Extension in a selected localelet loc = locale!("en-US-u-hc-h11");// 2. Explicit preferences listed in the options bag passed to the constructorletmut bag = DateTimeFormatPreferences{hour_cycle:Some(HourCycle::H24),
..Default::default()};// 3. Resolved defaults for a given language identifierlet li_defaults = get_li_defaults();// for `en-US` it is `H12`// 4. Optional preferences set in the host environment (Operating System)let os_prefs = get_os_dtf_preferences(&loc.id);// In this example user set OS Regional Preference for `en-US` to `H23`.// Step 1 - Take the Language Identifier defaultsletmut preferences = li_defaults;// Step 2 - Extend with OS PreferencesifletSome(os_pefs) = os_prefs {
preferences.extend(os_prefs);}// Step 3 - Extend with Locale Unicode Extensions
preferences.extend(loc);// Step 4 - Extend with Preferences Bag
preferences.extend(bag);let dtf = DateTimeFormat::new(preferences,Default::default());assert_eq!(dtf.resolved_options().hour_cycle,HourCycle::H24);
The text was updated successfully, but these errors were encountered:
Hi there,
I'm working on a proposal for ICU4X 2.0 for unified model of handling resolution between four sources of locale preferences:
This is a long standing battle over how to provide good defaults for negotiation of preferences between user and developer (see tc39/ecma402#109 for an old attempt) in a privacy respectful way, in a multi-level (app settings, browser settings, OS settings) environment.
I've been modelling the relation between 1., 2. and 3. for quite some time, and have always wanted to incorporate scalable solution that includes 4.
You can find my current API proposal here: unicode-org/icu4x#1833
The gist is that I'm rethinking
Locale
to be a type of a Preference Bag, that can be "merged" with another. In ICU4X we want to do this explicitly outside of the constructor, allowing developers to build their own wrappers that perform the merging in any direction and with any of the 4 involved.Since the goal of ICU4X is to supply the needs of ECMA-402, I'd like to suggest we collaborate on the design of this proposal and
icu_preferences
API, since ICU4X will want to make implementing this proposal easy.My only early feedback is that you seem to follow UTS35 in naming it
Extensions
. I'd like to suggest renaming it toLocale Preferences
- the termextensions
in UTS makes sense since its an extension to Language Identifier, but in context of this API it overcommunicates that. We really are talking about regional preferences, or internationalization preferences.Here's a sample of how the current API in ICU4X is intended to work, for reference:
The text was updated successfully, but these errors were encountered: