Teach `browser/installer/windows` how to produce multi-locale stub installer
Categories
(Toolkit :: Application Update, enhancement, P3)
Tracking
()
People
(Reporter: nalexander, Unassigned)
References
(Blocks 2 open bugs)
Details
The stub and full installer are written in NSIS and use the MUI (Modern User Interface) module. MUI supports multiple locales: see https://nsis.sourceforge.io/Docs/Modern%20UI/Readme.html. Right now, there is support for a single locale in our build system: see preprocess-locale.py. This ticket tracks supporting a variable set of locales, initially in the stub installer.
The reason to focus on the stub installer is that we don't (yet) produce a multi-locale build of Firefox Desktop. So a multi-locale full installer only has a single-locale build to install, defeating the point. (We might, along the way, start producing a multi-locale build as part of this work.) In contrast, the stub installer can know its language and choose the existing single-locale installer/package to fetch dynamically.
In discussions with the Install/Update team and especially :mhowell, I gather that there is no technical reason this cannot be done. Historically there has been no way to bring the locale definitions together with the build system steps in CI. This is still tricky but there is precedent in the Android fat AAR builds and the multi-l10n mozharness step. It's my belief that this can be generalized, although exactly how I cannot (yet) say.
I expect any work here to break down into a few distinct parts:
- Build system details about ferrying the locales around and getting a set of locales turned into a bunch of NSIS include files or similar;
- NSIS/MUI details about consuming multiple languages and potentially working through how to provide options to switch language.
- CI and build system details for how to do the moral equivalent of the
multi-l10nbuild step.
|
Reporter | |
Updated•4 years ago
|
|
||
Comment 1•4 years ago
|
||
In contrast, the stub installer can know its language and choose the existing single-locale installer/package to fetch dynamically.
Would it be possible for the stub installer to choose and install a langpack?
|
|
Reporter | |
Comment 2•4 years ago
|
||
(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #1)
In contrast, the stub installer can know its language and choose the existing single-locale installer/package to fetch dynamically.
Would it be possible for the stub installer to choose and install a langpack?
Possible? Anything is possible. Right now, I have no obvious way to tell the stub installer where to look for the langpack that corresponds to a particular installer, but it must be possible to figure that out in some manner.
But it's my understanding that an en-US Firefox + a langpack is "not good enough" because there are parts of the browser not covered by langpacks, or not covered early enough. Is that not correct, Zibi?
|
|
||
Comment 3•4 years ago
|
||
We're planning to start assembling requirements to move from repacks to langpacks, and having installer be able to install Firefox+langpack rather than repacked Firefox is something we'll need to tackle as part of it.
Parts of the browser (auxilary binaries like crash reporter) are going to have to be tackled separately, yes, but I'd still appreciate if we architected for langpack future rather than continue building repack-only tools.
If adding langpack support adds a lot of cost, I'd just ask to architect the system in a way that makes it easier to extend to langpack support later.
|
|
Reporter | |
Updated•4 years ago
|
|
||
Updated•4 years ago
|
|
|
Reporter | |
Comment 4•4 years ago
|
||
While doing some preparatory work for this in the form of Bug 1571112, I discovered that all of the NSIS-produced .exe files use MOZ_MUI_* macros that control MUI... except for setup-stub.exe. The introduction of the MOZ_MUI_* system dates all the way back to Bug 340173, which landed ~16 years ago. The stub installer did not use that system from the get go when it was introduced in Bug 322206, which landed ~9 years ago. If I'm understanding the actual sources correctly, this is all a wash: both approaches have a single locale with locale ID 0, all the strings (regardless of locale) identified as that locale 0, and no particular MUI interaction: they just use the NSIS/MUI LangString concept.
mhowell: are you aware of any history around MOZ_MUI_*, MUI more generally, and the stub installer? Is there a reason to not use the same macros that all of the other NSIS .exe artifacts use?
|
||
Comment 5•4 years ago
|
||
The abbreviation MUI refers to "Modern UI", which is what implements the wizard UI that the full installer and the uninstaller use (it's "modern" by comparison to the default NSIS UI, which is... less so). It has to be involved because it's responsible for actually rendering most of the text in those things, but you're right that everything ends up in the same place.
The stub installer never used the MUI framework because it just didn't fit there; that UI was always totally custom (and was a massive pain to work on as a result, prior to it being webified).
|
|
Reporter | |
Comment 6•4 years ago
|
||
(In reply to Molly Howell (she/her) [:mhowell] from comment #5)
The abbreviation MUI refers to "Modern UI", which is what implements the wizard UI that the full installer and the uninstaller use (it's "modern" by comparison to the default NSIS UI, which is... less so). It has to be involved because it's responsible for actually rendering most of the text in those things, but you're right that everything ends up in the same place.
Mmm, I realize that I should have referred specifically to the MOZ_MUI_LANGUAGE* macros that control localization, not to the whole Modern UI system.
The stub installer never used the MUI framework because it just didn't fit there; that UI was always totally custom (and was a massive pain to work on as a result, prior to it being webified).
Aha! This might explain why there's no MOZ_MUI_LANGUAGE* invocations. Thanks for the history lesson, Molly!
|
|
Reporter | |
Comment 7•3 years ago
|
||
I'm going to scope this down to point 2. of #c0: NSIS/MUI details about consuming multiple languages and potentially working through how to provide options to switch language. Further, we're not going to try to have UI for choosing (switching) languages at runtime: the multi-locale stub installer will display in the OS language and will download the full installer corresponding to the OS language.
Description
•