1760694 - [meta] Create a multi-locale stub installer in automation

Status: NEW

(Firefox Build System :: General, enhancement, P3)

Description

[Nick Alexander :nalexander [he/him]]

My goal is to produce a stub installer .exe that includes strings for N > 1 locales and is multi-locale aware in two senses:

1. the display language is determined by the OS language
2. the full installer downloaded is determined by the OS language

There's a chain of dependencies here that I will flesh out shortly.

Comment 1

[Nick Alexander :nalexander [he/him]]

Here is how I propose to do this:

1. First, we need to expose relevant locales to the build system for both multi-locale builds and single-locale repacks. This will allow the build system to produce locale-aware artifacts at build-time rather than only at package-time. This will be Bug 1465901 (somewhat repurposed).
2. Then we fix Bug 1571112 by converting the NSIS full/stub/un- installer process to moz.build and making it locale-aware.
3. We teach the NSIS process to package strings for multiple locales, and we make the stub installer use the OS locale (determined at runtime) rather than hard-coding AB_CD: Bug 1715615. It may be that we require the strings for all locales at this point, which will require the following point (point 4) to come before this point (point 3).
4. Finally, we make Desktop shippable builds produce both an en-US and a multi-locale package, or we add new multi-locale build jobs. Bug 1760701.

Comment 2

[Mike Hommey [:glandium]]

Why not move the creation of the stub installer to a separate build?

Comment 3

[Nick Alexander :nalexander [he/him]]

(In reply to Mike Hommey [:glandium] from comment #2)

Why not move the creation of the stub installer to a separate build?

Interpreting "separate build" as "separate TC kind", maybe we can! I have not considered it. I have been positioning this work as charting a path toward multi-locale builds and specifically toward growing multi-locale auxiliary program capabilities: installers, uninstaller, crash reporter, and eventually early-startup -- stuff not covered by langpacks (and that will never be covered by langpacks). A separate TC kind does not help with those, but the installers could be produced by separate jobs.

Or did you intend "separate build" to mean "separate TC build-... job"? This is, I think, the most plausible version of my point 4 in #c1: a second multi-locale build. At first we take the multi-locale stub installer, but eventually we can figure out what a multi-locale crashreporter looks like, how to make a multi-locale omnijar with only the early-startup strings, etc.