674253 - Add mobile strings to API for language packs

Status: VERIFIED FIXED

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

Description

[Wil Clouser [:clouserw]]

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

Comment 1

[Andy McKay]

https://github.com/jbalogh/zamboni/commit/94e49

Comment 2

[Axel Hecht [:Pike]]

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.

Comment 3

[Andy McKay]

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?

Comment 4

[Axel Hecht [:Pike]]

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.

Comment 5

[Wil Clouser [:clouserw]]

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...?

Comment 6

[Axel Hecht [:Pike]]

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.

Comment 7

[Wil Clouser [:clouserw]]

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. :-/

Comment 8

[Andy McKay]

Cool, will do.

Comment 9

[Wesley Johnston (:wesj)]

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.

Comment 10

[Andy McKay]

Second pass.

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

Krupa: we should upload some of these mobile language packs on preview to test.

Comment 11

[Axel Hecht [:Pike]]

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.

Comment 12

[krupa raj[:krupa]]

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?

Comment 13

[Jeff Balogh (:jbalogh)]

That addon is an extension.

Comment 14

[krupa raj[:krupa]]

(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..

Comment 15

[krupa raj[:krupa]]

Attachment: test add-on

Comment 16

[Andy McKay]

What encoding are the files, utf-8, utf-16 or something else?

Comment 17

[Axel Hecht [:Pike]]

utf8

Comment 18

[Andy McKay]

http://github.com/jbalogh/zamboni/commit/1c6088

Thanks Axel.

Comment 19

[krupa raj[:krupa]]

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.

Comment 20

[krupa raj[:krupa]]

Attachment: post-fix screenshot