Hi all!
A couple changes just landed in Gecko that will tighten our handling of
language tags and locales to BCP47 standard.
tl;dr:
- Use mozilla::locale::Locale for any operations on Locale codes in C++
- Expect LocaleService::NegotiateLanguages to return canonicalized BCP47
langauge tags
== Locale ==
We gained mozilla::intl::Locale class [0] which allows any C++ code to
validate, normalize and parse language tags.
Please, start using this code whenever you find yourself having to work
with language tags and analyze them.
For example instead of trying to write `langTag.Substring(0,
2).Equals("en")` which is insanely brittle, use:
```
Locale loc = Locale(langTag);
loc.GetLanguage().Equals("en");
```
You can also compare directly `loc == loc2` or using `.Match` which can
take ranges (to make `en` be treated as `en-*-*-*` and match `en-US`)
For JS code, we just advanced the `Intl.Locale` proposal to Stage 3 [0] at
this weeks TC39 meeting and will implement it in SpiderMonkey soon [1].
The locale class implements a direct subset of BCP47 and will be expanded
over time to handle more (all?) of it.
As we will want to start using Unicode Extension Keys around the codebase,
it becomes important that we can rely on all language tags being correctly
parsed and that means that we don't have DIY code around our codebase that
attempts to parse them on its own.
== Language Negotiation ==
There is also a change to our language negotiation handled by
mozilla::locale::LocaleService::NegotiateLanguages and
`Services.locale.negotiateLanguages`.
We now canonicalize the output (because we use the Locale class mentioned
above). That means that if you pass `ES-es` language tag, we'll return
`es-ES`.
It is important that we conform our codebase to the BCP47 standard and if
you expect to face non-canonicalized code, you can always use Locale class
or `Intl.getCanonicalLocales` ECMA402 API to get the canonicalized version
of any locale list.
If you have any questions, please, let me know!
zb.
p.s. We still support *one* extension to BCP47 which is 3-letter variants,
and we do this exclusively for the `ja-JP-mac` case. There's a conversation
about how to get rid of it [3] as it's the sole reason we have to maintain
both `LocaleService::GetAppLocalesAsLangTags` and
`LocaleService::GetAppLocalesAsBCP47`.
[0]
https://hg.mozilla.org/integration/autoland/file/tip/intl/locale/MozLocale.h#l16
[1] https://github.com/tc39/proposal-intl-locale/
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1433303
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1424953
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
