In Bug 1720190, we're working on bundling Firefox and multiple langpacks into a single MSIX. Modulo signing issues, this appears to work. Yay!

However, the very first run starts by processing more than 100 langpacks, and it's slow. Very, very slow. We could mitigate this by:

• associating a subset of langpacks with a Windows locale
• packaging each subset of locales into a per-locale resource package
• aggregating all of the packages into a single .msixbundle

That should have Windows install just the langpacks the current OS locale will require, speeding startup. It should improve the user experience, too, because the in-product language picker will expose a targeted subset of languages rather than a massive list.

This ticket tracks trying to do this.

:agashlin suggests that our msix-packaging toolchain probably does not support signing .msixbundle files (yet).

It looks as though the magic words here are ResourcePackage: see https://docs.microsoft.com/en-us/windows/msix/package/packaging-layout.

One thing that I just thought of was that it might even be possible to package locale-specific omni.ja files in these resource package bundles, changing the structure yet further. I doubt this is attractive, but I wanted to make a note for my future self.