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

Collaboration with ICU4X #8

Open
zbraniecki opened this issue Nov 23, 2023 · 0 comments
Open

Collaboration with ICU4X #8

zbraniecki opened this issue Nov 23, 2023 · 0 comments

Comments

@zbraniecki
Copy link

Hi there,

I'm working on a proposal for ICU4X 2.0 for unified model of handling resolution between four sources of locale preferences:

  1. Explicit Unicode Extension in a selected locale
  2. Explicit preferences listed in the options bag passed to the constructor
  3. Implicit defaults for a given locale
  4. 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.

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 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 locale
let loc = locale!("en-US-u-hc-h11");

// 2. Explicit preferences listed in the options bag passed to the constructor
let mut bag = DateTimeFormatPreferences {
    hour_cycle: Some(HourCycle::H24),
    ..Default::default()
};

// 3. Resolved defaults for a given language identifier
let 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 defaults
let mut preferences = li_defaults;

// Step 2 - Extend with OS Preferences
if let Some(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);
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant