1280680 - Build support for l20n in Gecko/Firefox

Status: RESOLVED FIXED

(Firefox Build System :: General, defect, P5)

Description

[Axel Hecht [:Pike]]

Filing this to get the build system part of l20n-in-gecko into the buglist.

The details will depend on the actual storage in a registry, which we figure out in bug 1280671.

I suggest to use the user story to describe the actionable details once we have them. P5 until this is actionable, HTH.

Comment 1

[Axel Hecht [:Pike]]

My current thinking is that we want a nice little niche in omni.ja/dist, where we put our files.

resource:///localization and resource://gre/localization sound good to me.

Within those, we'd have a directory for each language, and then a plain copy of the dir structure in en-US.

So browser/locales/en-US/user/feature/file.ftl would end up in resource:///en-US/user/feature/file.ftl.

I'm torn between moz.build and jar.mn. The latter seems to bind us to resource:///chrome and friend, and I'd really like a location that's not accessible via chrome://. Also, it's full of directory/path mangling tradition, which I want to break away from. Being outside of that would also be good for repacks, as we can make an explicit call about "remove en-US (old)" and not (new).
moz.build OTH is blank slate, which is both good and bad.

We'll not do l10n-merge. Fallback strings need to know the language they're in to pick correct plural rules etc. This is an existing bug in l10n-merge today, that we shouldn't replicate, as we don't have to.

gps, glandium, what's your take? In how you want to work on build stuff, what's a good way to tackle this?

Comment 2

[Axel Hecht [:Pike]]

There's also a thread in https://groups.google.com/forum/#!topic/mozilla.tools.l10n/fOtvsh8gWNg on the outcome

Comment 3

[Gregory Szorc [:gps]]

I mostly defer to glandium.

At this point, jar.mn is mostly an extension of moz.build: we parse jar.mn files as part of reading moz.build files. jar.mn files have an advantage over moz.build in that they are a bit less verbose. So where things live doesn't really matter in theory. That being said, we still have a bit of baggage in the build system around the handling of jar.mn files for l10n/packaging foo. This is mostly from the era before we had full build system config knowledge (moz.build files). So whatever we do for l20n should get hooked up to moz.build somehow so we don't have to do hacky things like code lists of directories in Makefile.in files.

Comment 4

[Axel Hecht [:Pike]]

Mass change dependency tree for bug 1279002 into a whiteboard keyword.

Comment 5

[Axel Hecht [:Pike]]

Attachment: bug 1280680, build l20n files outside of chrome, in localization,

Review commit: https://reviewboard.mozilla.org/r/83594/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/83594/

Comment 6

[Axel Hecht [:Pike]]

Comment on attachment 8797991 [details]
bug 1280680, build l20n files outside of chrome, in localization,

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/83594/diff/1-2/

Comment 7

[Axel Hecht [:Pike]]

Got my needinfos from glandium on irc.

We're sticking with jar.mn, and we're using 

[localization] @AB_CD@.jar:
    browser                                        (%browser/**/*.ftl)

in general to copy the directory structure of browser verbatim, but just ftl files.

I tested both unpackaged and packaged builds, and there are no regressions functionally.

Comment 8

[Mike Hommey [:glandium]]

Comment on attachment 8797991 [details]
bug 1280680, build l20n files outside of chrome, in localization,

https://reviewboard.mozilla.org/r/83594/#review82750

LGTM, but I'm not sure why you're asking for review, since this is not a patch against code in mozilla-central or integration branches.

Comment 9

[Axel Hecht [:Pike]]

Yeah, looking at the patch, we probably need to slice-n-dice the fragments in this landing into different patches when we land on central.

But it doesn't hurt that we can point back to this bug once we do so.

Comment 10

[Axel Hecht [:Pike]]

https://hg.mozilla.org/projects/larch/rev/f29da9ed45d1584c0f318d84981a60811586fd1b, marking FIXED.