Closed Bug 1280680 Opened 5 years ago Closed 5 years ago

Build support for l20n in Gecko/Firefox


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



(Not tracked)



(Reporter: Pike, Assigned: Pike)



(Whiteboard: [gecko-l20n])

User Story

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.


(1 file)

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.
Blocks: 1280683
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 and 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). 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?
Flags: needinfo?(mh+mozilla)
Flags: needinfo?(gps)
There's also a thread in!topic/ on the outcome
I mostly defer to glandium.

At this point, is mostly an extension of we parse files as part of reading files. files have an advantage over 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 files for l10n/packaging foo. This is mostly from the era before we had full build system config knowledge ( files). So whatever we do for l20n should get hooked up to somehow so we don't have to do hacky things like code lists of directories in files.
Flags: needinfo?(gps)
Mass change dependency tree for bug 1279002 into a whiteboard keyword.
No longer blocks: gecko-l20n
Whiteboard: [gecko-l20n]
Blocks: 1291693
Got my needinfos from glandium on irc.

We're sticking with, 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.
Flags: needinfo?(mh+mozilla)
Assignee: nobody → l10n
User Story: (updated)
Comment on attachment 8797991 [details]
bug 1280680, build l20n files outside of chrome, in localization,

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., marking FIXED.
Closed: 5 years ago
Resolution: --- → FIXED
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.