Consider supporting retrieval of the language preference list from the system

[hsivonen]

Consider providing functionality (with std, not with no_std) for retrieving the user's system-level preference list of languages as ICU4X locales.

On Windows, Gecko prefers https://learn.microsoft.com/en-us/uwp/api/windows.system.userprofile.globalizationpreferences.languages?view=winrt-22621#windows-system-userprofile-globalizationpreferences-languages and adds region with likely subtags if the system gives a language only.

On Mac, Gecko uses https://developer.apple.com/documentation/corefoundation/1542887-cflocalecopypreferredlanguages

On Android, Gecko prefers https://developer.android.com/reference/android/os/LocaleList#getDefault() . Not sure if it's practical to call a Java method, even a static one, deep within Rust code when the Rust code isn't responsible for the whole app's JNI setup.

On Gtk, Gecko delegates to ICU4C, which AFAICT, calls setlocale(LC_MESSAGES, NULL); and performs fixup. It appears (note the author of the answer) that it's OK to call glibc setlocale to read get (not actually set) a value, and nothing else in the process actually sets the value, either, so that it's constant for the lifetime of the process. Obviously, this code path retrieving only one locale.

(Note: Gecko already has non-ICU4C C++ code for this (except on Gtk), so whereas #3059 is deliberately U-gecko-tagged, I'm filing this as a general U-ecma402 courtesy without the usual implication that everything U-ecma402 is implicitly U-gecko.)

(Note 2: ECMA-402 default locale isn't a preference list and is implied to have data available for it across all the ECMA-402 objects, so implementing ECMA-402 on top of what's suggested above would involve further filtering.)

[robertbastian]

Related: #3059

[sffc]

Is this in scope? Seeking feedback from:

• @Manishearth
• @sffc
• @zbraniecki

[Manishearth]

I think this is in scope as a utils crate we publish separately, perhaps with icu_locid integration. I don't consider this priority.

[zbraniecki]

I would like to consider this out of scope of ICU. I would name such create env_i18n or something similar and I'd be happy to suggest we maintain it and ensure that it uses ICU primitives but I don't like that ICU right now has hooks into env/os. I think separation of concerns is valuable.

[sffc]

Based on feedback from the i18n unconference at RustConf, devs want libraries that "just work" and integrating nicely with the operating system is part of that. We are in a decent position to write this type of code. I don't know where exactly this code lands, but if it lands in the icu4x repository, it should probably be under utils.

[zbraniecki]

Ok, I'm comfortable with this as long as it's explicit.

[sffc]

This is likely a "good first issue" because the API surface is small, mostly a function that returns the system locale as a icu::locid::Locale, which works on all platforms according to what @hsivonen posted above.