Closed Bug 1623587 Opened 5 years ago Closed 5 years ago

glean.py fails to detect locale on Windows

Categories

(Data Platform and Tools :: Glean: SDK, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Dexter, Assigned: mdroettboom)

References

Details

(Whiteboard: [telemetry:glean.rs:m13][glean-py])

When running Glean on Windows in the MozillaBuild tools environment it fails to initialize.

File "c:\mozilla-build\python3\lib\site-packages\glean\glean.py", line 135, in initialize
cls._initialize_core_metrics()
File "c:\mozilla-build\python3\lib\site-packages\glean\glean.py", line 347, in initialize_core_metrics
metrics.glean.baseline.locale.set(util.get_locale_tag())
File "c:\mozilla-build\python3\lib\site-packages\glean\util.py", line 24, in get_locale_tag
value = value.replace("
", "-")
AttributeError: 'NoneType' object has no attribute 'replace'

The problem is that Python fails to detect the locale and breaks the init process.

We should fix this and either gracefully report the problem or make sure it works properly in MozillaBuild (since that's the reccommended way to build Firefox on Windows).

Priority: -- → P3
Whiteboard: [telemetry:glean.rs:m?]
Assignee: nobody → mdroettboom

What should this function provide if we can't determine? I think "C" is the most obvious choice, but ultimately this ends up in a metric in our data, so I wonder if there's precedent for what we do on Desktop when we can't determine the locale?

Flags: needinfo?(alessio.placitelli)

(In reply to Michael Droettboom [:mdroettboom] from comment #2)

What should this function provide if we can't determine? I think "C" is the most obvious choice, but ultimately this ends up in a metric in our data, so I wonder if there's precedent for what we do on Desktop when we can't determine the locale?

This is a great question, took me a long while to figure this out :-)

The product locale we report in the telemetry environment is determined here. Following the chain of calls, it ends up in here, in case the default locale needs to be determined.

As far as I can tell, it attempts to read the locale from a file we ship and, if that fails for some reason, we stick to the last resort fallback of en-US.

Zibi, I saw you worked on this or, at the very least, know much more than me about Firefox locales :) Is the above description of how we determine the default Firefox locale correct?

Flags: needinfo?(alessio.placitelli) → needinfo?(zbraniecki)

Thanks for the investigation.

In the case of the Glean Python bindings, the option to look at a file we ship maybe wouldn't make sense. Many of these apps aren't localized to begin with. I think I'd prefer to say "C" to indicate "unknown" rather than "en-US", since we wouldn't be able to distinguish between actual "en-US" users and when we hit this case.

(In reply to Michael Droettboom [:mdroettboom] from comment #4)

Thanks for the investigation.

In the case of the Glean Python bindings, the option to look at a file we ship maybe wouldn't make sense. Many of these apps aren't localized to begin with. I think I'd prefer to say "C" to indicate "unknown" rather than "en-US", since we wouldn't be able to distinguish between actual "en-US" users and when we hit this case.

Yes, I second using "C" rather than "en-US" :) Of course we should document this in the metric documentation.

Flags: needinfo?(zbraniecki)
See Also: → 1623757
Whiteboard: [telemetry:glean.rs:m?] → [telemetry:glean.rs:m13][glean-py]
Blocks: 1621025
No longer blocks: 1621025

Zibi, I saw you worked on this or, at the very least, know much more than me about Firefox locales :) Is the above description of how we determine the default Firefox locale correct?

Yes. update.locale is the locale we build Firefox for. en-US is the last resort fallback.

Optionally, you could use und as the undefined correct locale identifier. I'd recommend against using C as C is not a correct locale identifier and is just a POSIX trick and the general consensus in the industry is that POSIX is a really back internationalization model :)

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #7)

See https://unicode.org/reports/tr35/#Unknown_or_Invalid_Identifiers for details.

Thank you, Zibi!

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.