Parsing system locales

[Finchiedev]

Hello all!

I've been experimenting with integrating icu4x into user-facing applications for a while now, and was very excited to see the progress made by GSoC student @ashu26jha in #5081 and #5358 on retrieving the system locale. If there is interest in doing so, I would be very interested in contributing to the env_preferences crate that came out of this work to make it easier to use out-of-the-box.

This is motivated by my computer (x86_64-unknown-linux-gnu) returning Ok({All: "C"}) from the linux implementation of env_preferences::get_locales. Ideally, env_preferences::get_locales would return Locale instead of String, so I can immediately use the unwrapped result with icu_datetime, icu_plurals etc. I assume parsing these strings into locales is the kind of logic that should be handled by icu4x rather than duplicated across downstream users - but please correct me if I'm wrong!

At least on Linux, I would expect to solve this according to TR35's section on legacy variants. If possible, I'd love feedback on this solution, and if there's interest in such a contribution at all. I am very happy to do the work but don't want to interfere with anyone's existing progress or create an unwanted PR :)

[Manishearth]

Yes, we'd welcome contributions!

I think the legacy variant section is correct, though note that ICU4X doesn't ship any data around these by default.

@sffc to confirm that this is the route we should take.

[sffc]

Thanks for your interest in this area!

CC @robertbastian @zbraniecki to advise on design.

[zbraniecki]

Ideally, env_preferences::get_locales would return Locale instead of String, so I can immediately use the unwrapped result with icu_datetime, icu_plurals etc. I assume parsing these strings into locales is the kind of logic that should be handled by icu4x rather than duplicated across downstream users - but please correct me if I'm wrong!

You are correct, the student that started this crate did not get to this phase, but the intention is to normalize API between env_preferences and anything else use Locales everywhere.

IIRC the original idea is that there should be that you can use per-OS specialization to get an unprocessed response from the OS (so, for example windows::get_raw_locales or some similar name returns Strings), and have universal cross-OS method like env_preferences::get_requested_locales_lossy(options) -> Vec<Locale> which returns parsed locales, omitting ones that could not be resolved and env_preferences::get_requested_locales(options) -> Result<Vec<Locale>, _> failing on errors.

I'd be happy to brainstorm that with you and review your design.