Proposal: 1280680 - Build support for l20n in Gecko/Firefox

[Axel Hecht]

Hi

I'd like to propose a wanted outcome for
https://bugzilla.mozilla.org/show_bug.cgi?id=1280680.

I think we should claim resource:///locales/ and resource://gre/locales/
for l20n.

I'd like to package whole directories without file path tweaks, and
without preprocessing files.
I.e., foo/bar/locales/en-US/**/*.ftl get's copied to
resource:///locales/en-US/**/*.ftl.

We may want to filter the results to copy from l10n to a path pattern to
make sure we're not shipping files that shouldn't be in there, and
localizers land by mistake?

In particular looking for feedback from gandalf on this one.

Axel

[zbran...@mozilla.com]

Hi,

On Tuesday, July 19, 2016 at 11:27:45 AM UTC-7, Axel Hecht wrote:
> I think we should claim resource:///locales/ and resource://gre/locales/
> for l20n.
>
> I'd like to package whole directories without file path tweaks, and
> without preprocessing files.
> I.e., foo/bar/locales/en-US/**/*.ftl get's copied to
> resource:///locales/en-US/**/*.ftl.
>
> We may want to filter the results to copy from l10n to a path pattern to
> make sure we're not shipping files that shouldn't be in there, and
> localizers land by mistake?
>
> In particular looking for feedback from gandalf on this one.

Sounds great to me!

The question is if we'll want to reuse jar.mn, or use some other syntax to instruct build system which files to package.

zb.

[Axel Hecht]

I'm leaning towards something in moz.build, which triggers all *.ftl
files to be replicated in dist in the same directory structure.

That has two benefits:

- it gives a clear mapping between runtime location and source location.
- it allows us to use the same browser/locales/en-US directory, but with
different packaging.

The wildcard logic in
https://gecko.readthedocs.io/en/latest/build/buildsystem/jar-manifests.html
only works per directory, AFAICT, not exactly what I would hope for.

Axel