Closed Bug 1280680 Opened 5 years ago Closed 5 years ago
Build support for l20n in Gecko/Firefox
L20n needs multiple languages, with multiple install locations. Build system will need to put files in resource:///localizations/ab-CD and resource://gre/localizations/ab-CD.
58 bytes, text/x-review-board-request
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.
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?
There's also a thread in https://groups.google.com/forum/#!topic/mozilla.tools.l10n/fOtvsh8gWNg on the outcome
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.
Mass change dependency tree for bug 1279002 into a whiteboard keyword.
No longer blocks: gecko-l20n
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.
Assignee: nobody → l10n
Status: NEW → ASSIGNED
User Story: (updated)
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.
Attachment #8797991 - Flags: review?(mh+mozilla)
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.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.