Add DefaultLocale to the telemetry environment
Categories
(Core :: Internationalization, enhancement, P3)
Tracking
()
People
(Reporter: flod, Unassigned)
Details
Currently our telemetry has a locale
field in environment.
https://probes.telemetry.mozilla.org/?view=detail&probeId=environment%2Fsettings.locale
This field changes depending on the locale currently selected: if you install a language pack, e.g. fr
, on a en-US
build, the value reported will be fr
.
It would be useful to have the build locale (or update locale) reported as a separate field.
One of the benefits would be being able to understand how many users are actually using a language pack (there would be a mismatch between these values).
Reporter | ||
Comment 1•5 years ago
|
||
We added a few intl fields when we introduced the language switcher in Firefox, what I don't understand is if the language build can be safely inferred from them.
For example, Italian build, with installed French and English, French selected.
intl.requestedLocales [fr, it, en-US]
intl.availableLocales [it, en-US, fr]
intl.appLocales [fr, it, en-US]
If I switch back to Italian as current language
intl.requestedLocales [it, fr, en-US]
intl.availableLocales [it, en-US, fr]
intl.appLocales [it, fr, en-US]
it
always stays as the first locale in intl.availableLocales
. Does it mean that the first locale is always the locale of the build?
Comment 2•5 years ago
|
||
For single locale repacks, Services.locale.packagedLocales
has the build language as first one.
For multi-locale builds, it should have something like an alphabetical list. For snaps, probably just has en-US, as they package langpacks (might not be good perf).
The update locale is interesting business, looking at https://searchfox.org/mozilla-central/rev/446160560bf32ebf4cb7c4e25d7386ee22667255/toolkit/modules/UpdateUtils.jsm#137
Comment 3•5 years ago
|
||
https://firefox-source-docs.mozilla.org/intl/locale.html#default-and-last-fallback-locales
Are you looking for defaultLocale
or packagedLocales
?
I.e., what would you like to get in the future when we deploy Swiss Firefox
with 4 locales packaged into it by "bundling" (in some way) Firefox + 4 langpacks?
In such reality we may not have it update by asking for "ch" update bits, but rather it'll ask for FIrefox update bits, plus update 4 language packages.
Reporter | ||
Comment 4•5 years ago
|
||
(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #3)
https://firefox-source-docs.mozilla.org/intl/locale.html#default-and-last-fallback-locales
Are you looking for
defaultLocale
orpackagedLocales
?
What would defaultLocale
be in the examples above (it
build)? Based on the doc, I would assume it's always en-US
.
I.e., what would you like to get in the future when we deploy
Swiss Firefox
with 4 locales packaged into it by "bundling" (in some way) Firefox + 4 langpacks?
My assumption is that this would still be a build with one language (likely en-US), and four additional languages that would be listed as available locales together with the base language of the build.
The reality is that we are nowhere near to change the build system, and given the current resource constraints, it seems unlikely that we will have drastic changes for the time being.
In the meantime, this data would help us prioritize things like bug 1566084, since we can only try to infer language pack installation by proxy (and not necessarily reliable ones).
Comment 5•5 years ago
|
||
What would defaultLocale be in the examples above (it build)? Based on the doc, I would assume it's always en-US.
If you download an italian repack of Firefox, it'll be it
.
My assumption is that this would still be a build with one language (likely en-US), and four additional languages that would be listed as available locales together with the base language of the build.
Correct.
In the meantime, this data would help us prioritize things like bug 1566084, since we can only try to infer language pack installation by proxy (and not necessarily reliable ones).
I understand that. I'm not suggesting blocking this bug on such remodels, I'm just curious what data are you actually asking about :)
We have two bits - the locale we consider "the one Firefox was built with" (which in your comment 1 example would be "it", but in my Swiss example would become "en-US"), or the locales we ship with (which in your comment 1 example would be "it", and in my Swiss example would become the 4 locales "packaged" with the release).
I'd like to suggest a solution that will work long term if possible.
Reporter | ||
Comment 6•5 years ago
|
||
(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #5)
I understand that. I'm not suggesting blocking this bug on such remodels, I'm just curious what data are you actually asking about :)
I want a reliable way to understand what is the language of the build, and if it's different from the locale currently selected (i.e. first in requestedLocales). That would help me understand how many users we have with language packs in use (Linux, for example, install language packs, but they're not necessarily in use).
Reporter | ||
Updated•5 years ago
|
Comment 7•5 years ago
|
||
Synced with Flod and Pike on Matrix. We want to capture Services.locale.defaultLocale
.
Reporter | ||
Updated•4 years ago
|
Updated•4 years ago
|
Description
•