Android shippable builds run an extra post-build step: multi-l10n. This checks out locale repositories and then runs mach package-multi-locale, producing a multi-locale GeckoView AAR. This ticket tracks doing the same for Desktop shippable builds.

We may want to lift the pull-locale-source mozharness step before the mach build step, so that the build can consume localized resources from multiple locales; but doing so may open a can of worms that we're not interested in addressing, so I'll settle for running mach package-multi-locale on Desktop builds. We may want to differentiate an en-US package from a multi package so that we can pick-and-choose the artifacts from each as appropriate.

Do we want to produce/ship multi-locale desktop builds? Bug 1760694 doesn't seem to be about that.

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

Do we want to produce/ship multi-locale desktop builds? Bug 1760694 doesn't seem to be about that.

Produce, yes; ship, not immediately. I want to produce a multi-locale stub installer, and I'd prefer to produce it at build-time rather than at package-time. That is, I'd like to chart a course towards more sensible l10n by telling the build system about the set of locales and then producing appropriate artifacts rather than have the package step be the place that knows about the locales in play and have it rebuild certain build artifacts. This was and is hard for Android (we do android-archive-geckoview at package-time, which rebuilds many things) and will be hard for the NSIS process on Desktop. Does that make sense, :glandium?