1450107 - Please clone AMO product [e-mail] to [e-mail]

Status: RESOLVED FIXED

(Cloud Services :: Operations: AMO, task)

Description

[Justin Wood (:Callek)]

For production (and ideally stage too) we need the metadata for the japanese language pack duplicated.

New Langpack: `[e-mail]` should be created using the same AMO contents as `[e-mail]`, License, set of users, etc.

See-Also: Bug 1450104 for where releng will get access to admin these.

Background:

Mac japanese locale has a different language pack than linux/windows due to different string translations involved on OSX. These translations have existed as a seperate language pack for years, and is not currently possible to emulate the needs in Firefox as of today.  (There is discussions ongoing to see if that can be rectified with .ftl/fluent)

If we need to populate a language pack on AMO for this to work, we can use one of the 59.x mac langpacks:

https://archive.mozilla.org/pub/firefox/releases/59.0/mac/xpi/ja-JP-mac.xpi
https://archive.mozilla.org/pub/firefox/releases/59.0.1/mac/xpi/ja-JP-mac.xpi
https://archive.mozilla.org/pub/firefox/releases/59.0.2/mac/xpi/ja-JP-mac.xpi

Comment 1

[Justin Wood (:Callek)]

:aswan and :Pike probably have some added context here if there are any questions, I'll be away most of next week of course.

Again this is needed on production, but having someone do this on stage as well would be helpful.

Comment 2

[Jorge Villalobos [:jorgev] (he/him)]

AMO supports uploading different files for different platforms. So, a version of a language pack can have one file for Windows and a different one for macOS. Doing it this way makes it possible for existing users to be updated to the macOS file, rather than staying with the original language pack after the split (we don't have a way to migrate those users to the new listing we would need to create).

This might require changes to the upload API we're providing, but it makes more sense to me. Would it work for you?

Comment 3

[Jorge Villalobos [:jorgev] (he/him)]

From discussion on IRC, my suggestion won't work because the language pack has already existed for years, just not on AMO. I misunderstood that the main language pack was going to be forked. So, back to the original plan, I'll create those new listings.

Comment 4

[Jorge Villalobos [:jorgev] (he/him)]

I uploaded it to stage. Please review how the listing looks:

https://addons.allizom.org/addon/japanese-langpack-mac/

As well as how it looks if you go to the language tools page:

https://addons.allizom.org/ja/firefox/language-tools/

If it all looks good, I can do the same in prod.

Comment 5

[Justin Wood (:Callek)]

Looks good to me, I'm going to leave final-say to :Pike (or I can nab someone else if Axel doesn't respond sooner)

My only comment is that there could/should be some indication I think that this one is for OSX (maybe '(OSX)' or '(mac)') otherwise those users could get confused seeing two entries on that page. "Which one is valid for me"

Comment 6

[Axel Hecht [:Pike]]

We talked a bit more, and there are various caveats around ja-JP-mac, and users getting confused when they download one or the other.

Can we make the ja-JP-mac one unlisted for now? Then we at least have the xpis on ftp signed.

Here's context that bothers me:

- ja-JP-mac isn't a valid locale code (hysterical raisins, bug 1424953)
- we add UI to prefs to change UI locale, and that might come with discoverability and then we need to figure out ja/ja-JP-mac in prefs UI
- we might stop doing ja-JP-mac once we're fully migrated to fluent, and then users would be stuck on a dead langpack


I'm OK with going ahead with the ja-JP-mac langpack for now, but I'd like to keep it off of user's radar as much as possible until we've figured out more of the context, which will likely happen over the next quarter or two. Too late for the signing party, sadly.

Comment 7

[Justin Wood (:Callek)]

(In reply to Axel Hecht [:Pike] from comment #6)
> Can we make the ja-JP-mac one unlisted for now? Then we at least have the
> xpis on ftp signed.

On relengs end, yes we can do this. On the AMO end I'll defer to jorgev.

Comment 8

[Jorge Villalobos [:jorgev] (he/him)]

We can submit those versions as unlisted, yes. For staging, though, I can't resubmit the same version as self-hosted, but you can still download it and use it and I can disable it if needed.

Let me know when you want the self-hosted upload to happen on prod.

Comment 9

[Justin Wood (:Callek)]

Jorgev, I'm hoping for automation to do that self-hosted upload on prod sometime tomorrow. (for the next beta GTB).

If you need an upload of some version of the addon first we can use any of the ones in c#0 as our bed to help populate.

Comment 10

[Andreas Wagner [:TheOne] [use NI]]

I heard this is time-sensitive, so I created the add-on at https://addons.mozilla.org/en-US/developers/addon/japanese-langpack-mac/edit It is self-hosted (unlisted) as requested.

Note that I had initially tried to use the langpack for 59.0.2 (from comment 0), and that file threw an error because the manifest defines

"strict_min_version": "59.0.2"

That version is not known to AMO, based on https://addons.mozilla.org/en-us/firefox/pages/appversions/ .

I am not sure what the proper solution to that would be, maybe we need to start adding dot releases to the list of known versions.
Leaving the need-info for Jorge for this.

Comment 11

[Jorge Villalobos [:jorgev] (he/him)]

I added 59.0.2 as a valid appversion for now, to unblock this. However, the min version shouldn't be a point release unless strictly necessary. Callek, can you clarify this point?

Comment 12

[Justin Wood (:Callek)]

:jorgev, currently the langpack creation code sets the minversion to be the applications version, which on dot releases is stuff like 59.0.2, on beta would be 59.0 and so on.

I can probably coerce this at some point to always be major.minor.* and never include .min, though my memory says there were cases of .min changing l10n in the past (though far from common), and I don't think I could do so in time for 60.0.x (and not sure at this stage how risky an uplift of it to esr60 would be).

:jorgev - will this be a big problem going forward? (knowing releng needs this ahead of GTB time for dot releases, so ideally even if we know 60.0.1 is out, 60.0.2 will be valid even if we know of no 60.0.2 at that time)

:Pike, can you think of any reason we shouldn't do major.minor for min version in all cases, and major.minor.* for max?

Comment 13

[Axel Hecht [:Pike]]

After some back and forth, the way this could break is that en-US removes ... a string, possibly a file, in a dot release. And then users would update the langpack to the one without those strings, but still be on the non-dot release.

Yeah, right. Dropping the .dot version in the minversion sounds OK to me.

Comment 14

[Jorge Villalobos [:jorgev] (he/him)]

Yes, so the problem is that AMO uses a whitelist of valid min/max versions, and that whitelist doesn't include dot releases. They are added on every release cycle, and it's a somewhat manual process. If you can drop that part of the version number, it would be best for us.

I want AMO to stop depending on that whitelist (it's not very useful since the move to WebExtensions), but that's work that hasn't been prioritized yet and isn't trivial to do.

Comment 15

[Justin Wood (:Callek)]

This is done, releng has a TODO item to poke AMO team if we are doing a dot (sec) version of RR 60.0.

I filed Bug 1455337 to track that side of the work to not make that needed anymore.