Closed Bug 674253 Opened 9 years ago Closed 9 years ago

Add mobile strings to API for language packs

Categories

(addons.mozilla.org Graveyard :: API, defect)

defect
Not set

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: clouserw, Assigned: andy+bugzilla)

Details

Attachments

(2 files)

Our current language pack API:  https://addons.mozilla.org/en-US/mobile/api/1.5/get_language_packs

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/localepicker.properties [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: http://mxr.mozilla.org/mozilla-central/source/mobile/locales/en-US/chrome/localepicker.properties
See Also: → 674345
See Also: 674345
https://github.com/jbalogh/zamboni/commit/94e49
Status: NEW → RESOLVED
Closed: 9 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/localepicker.properties inside the chrome/de.jar inside http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/latest-mozilla-central-linux-l10n/linux-i686/xpi/fennec-8.0a1.de.langpack.xpi.

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 localepicker.properties 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 "localepicker.properties" 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 localepicker.properties
> 
> 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 localepicker.properties 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 localepicker.properties, 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.
Status: RESOLVED → REOPENED
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.

http://github.com/jbalogh/zamboni/commit/b35d9c

Krupa: we should upload some of these mobile language packs on preview to test.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 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 (https://addons.allizom.org/en-US/mobile/addon/%D8%A7%D9%84%D8%B9%D8%B1%D8%A8%D9%8A%D8%A9-language-pack1/) which is fully reviewed.

This is not getting listed at https://addons.allizom.org/en-US/mobile/api/1.5/get_language_packs

Am I doing something wrong?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
That addon is an extension.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 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 http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/latest-mozilla-central-linux-l10n/linux-i686/xpi/

It shows up at https://addons.allizom.org/en-US/mobile/api/1.5/get_language_packs as expected. However, the content of localepicker.properties is not shown.

Reopening..
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached file test add-on
What encoding are the files, utf-8, utf-16 or something else?
utf8
http://github.com/jbalogh/zamboni/commit/1c6088

Thanks Axel.
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
verified that contents of localepicker.properties is shown at https://addons.allizom.org/en-US/mobile/api/1.5/get_language_packs

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