Closed Bug 674253 Opened 10 years ago Closed 10 years ago

Add mobile strings to API for language packs


( Graveyard :: API, defect)

Not set


(Not tracked)



(Reporter: clouserw, Assigned: andy+bugzilla)



(2 files)

Our current language pack API:

We're interested in adjusting the output so that under <addon> there is a <strings> element with some data in it.  The flow is something like:

1) User uploads new language pack
2) We extract the file chrome/ [1]
3) We take the entire contents of that file and put it somewhere in a cache
4) When the above URL is requested, put it in the output of each add-on, something like:

>    <strings><![CDATA[
>       title=Select a language
>       continueIn=Continue in %S
>    ]]></strings>

[1] example:
See Also: → 674345
See Also: 674345
Closed: 10 years ago
Resolution: --- → FIXED
I can't say that I understand the patch, but the path sounds wrong. Looking at an actual langpack, it's

locale/de/browser/ inside the chrome/de.jar inside

Many of the paths and files depend on the actual locale code here, too. In my example, that's "de", but that changes depending on the actual pack, and can at some point be an arbitrary unicode locale code, I guess. As in, the extension to a bcp47 code.
If the language packs aren't in a consistent place, that makes it a little trickier. Doesn't seem to be mentioned in a manifest either. Is there only going to be one and only one file?
One would hope not more than one for a while at least. Though for the time being, they'll only be there for fennec langpacks, but not for ones for firefox or thunderbird or seamonkey.
I just copied the path from that example URL in comment 0.  Can this file really appear anywhere in the .xpi with no actual pointer to it?  Surely we can require it to be in one spot...?
It can't appear 'anywhere', but we can't move it to 'one' spot either. There's one algorithm to get to it, though:

In the chrome manifest, look up the line that starts with "locale browser",
locale browser de jar:chrome/de.jar!/locale/de/browser/
and resolve "" against that jar url.

That's getting you the path as long as the mobile folks don't move that file around. You'll need a social contract with them on that though.

PS: We can't move the file to exactly one path, as that'd break multi-locale omni.jar's.
Via email from Wesley Johnston:

> For Mozilla built xpis I believe you can do something like:
> Open the .xpi file
> Enter the "chrome" directory
> Open the .jar inside (its exact name will vary based on locale, but should be <localeName>.jar)
> Enter the "locale/<localeName>/browser/" directory
> Open
> I talked to gavin about this right now, and for Mozilla uploaded locales this will always be true. That seems like a fine start for now if you're worried about getting something up and running.
> For locales uploaded by community members, it might not. There should always be a file somewhere in either the xpi or jar file. With the XPCOM nsIZipReader its fairly easy to scan over all the files for one matching, but I imagine you're not using that, and the quickest way to do this may depend on what interfaces are available.

Let's do the method he described then.  Sorry I wasn't aware this file could move around when I filed. :-/
Cool, will do.
Resolution: FIXED → ---
Sorry I wasn't cc'd here. Axel's algorithm looks good to me too though. Probably more robust if you don't mind parsing the chrome.manifest a little bit.
Second pass.

Krupa: we should upload some of these mobile language packs on preview to test.
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
That looks good, the pitfalls that I would have in mind look like they're dealt with. Not a thorough review of mine, but there's nothing that I'd find glancing through the patch. Extra kudos for handling both jar and flat packaging.
I uploaded a language pack for Fennec ( which is fully reviewed.

This is not getting listed at

Am I doing something wrong?
Resolution: FIXED → ---
That addon is an extension.
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
(In reply to comment #13)
> That addon is an extension.

yep. This time I uploaded a valid lang pack(type = 8) from

It shows up at as expected. However, the content of is not shown.

Resolution: FIXED → ---
Attached file test add-on
What encoding are the files, utf-8, utf-16 or something else?

Thanks Axel.
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
verified that contents of is shown at

I will continue to upload more add-ons to catch any edge cases.
Attached image post-fix screenshot
Product: → Graveyard
You need to log in before you can comment on or make changes to this bug.