1386924 - Document and/or automate the process for copying strings to form autofill's l10n repo

Status: RESOLVED INVALID

(Toolkit :: Form Manager, defect, P3)

Description

[Matthew N. [:MattN]]

In the generic autofill directory docs and/or in the README of https://github.com/mozilla-l10n/formautofill-l10n we should document the process for updating the l10n repo with new strings. Even if it's as simple as copying files to a git repo we should at least make it clear that the github repo is where l10n occurs, not in the hg mozilla-* repos.

If we can automate some process with TaskCluster or some in-tree scripts that may also be useful. The docs should probably mention compare-locales and l10n-merge from bug 1375799 comment 15

Comment 1

[Luke Chang [:lchang] (inactive)]

L10N support is the feature in V2 plan.

Comment 2

[Scott Wu [:scottwu]]

Now that our strings and UI are stable, I wonder what's the recommended mechanism for Form Autofill to enter the l10n process?

My understanding is that we need to update the `formautofill.properties` on the github repository (https://github.com/mozilla-l10n/formautofill-l10n), so that people can work on it on Pontoon. Should we just send a pull request manually every time there's a string change? And once the localized strings are done, I assume we just go grab the localized strings from the github repo and commit it to mc?

Comment 3

[Francesco Lodolo [:flod]]

(In reply to Scott Wu [:scottwu] from comment #2)
> My understanding is that we need to update the `formautofill.properties` on
> the github repository (https://github.com/mozilla-l10n/formautofill-l10n),
> so that people can work on it on Pontoon. Should we just send a pull request
> manually every time there's a string change? 

Maybe we can start with pull requests, and review to make sure we're on the same page when it comes to string changes.
Note that I also need to review the current content for issues.

> And once the localized strings are done, I assume we just go grab the localized strings from the github
> repo and commit it to mc?

Yes, but I'd like a clear schedule on when things are supposed to happen, i.e. the frequency for that happening, how later we can see strings in builds, etc.

Comment 4

[Francesco Lodolo [:flod]]

I have one more question after reading the comment on GitHub
https://github.com/mozilla-l10n/formautofill-l10n/pull/2

> We are currently riding the train, even though can ship with 
> Go Faster if we find compelling reason to do so in the future. 
> So I guess the update frequency is same as regular release cycle.

Is the plan to enable localization only for a few languages (initially the request was for es-MX), or for all the languages that ship in Firefox? 

If it's the latter, it might be a good idea to rethink the localization strategy at this point. 

We use an external repository for system add-ons where development and localization happen outside of m-c (Activity Stream, Screenshots). For Form Autofill, development happens directly in m-c.

Starting from 57, we use a single l10n repository (cross-channel) to build all versions of Firefox (for now Beta 57, Nightly 58). Once translated in this repository for Nightly, strings will also be available for other branches, making uplifts a less painful option if needed.

If the plan is to localize in all languages starting from 58, and mostly ride the trains, I think having localizations directly in m-c makes more sense with cross-channel. 

If the plan is to enable only selected languages, we need to stick with the GH repository. I will also need the list of languages.

Comment 5

[Scott Wu [:scottwu]]

A few languages are what we considered high priority, namely es-MX, and languages for countries like Canada, Germany, France, Japan, and Taiwan. Having all languages localized is great, but not required, because only a subset of our users can see this feature.

Our initial concern was that if we have localizations in m-c, but in the future opt to not riding the train, l10n might break whenever there's a string change. But from what I'm reading, cross-channel would be able to handle this? If this is the case, having localizations in m-c seems like the simpler option.

In terms of efforts from l10n team, would you prefer one way over the other?

Comment 6

[Francesco Lodolo [:flod]]

It's definitely easier to have these translations in mozilla-central. It removes the need to copy .properties outside, then move them back, or having a separate project in Pontoon.

> Our initial concern was that if we have localizations in m-c, but in the
> future opt to not riding the train, l10n might break whenever there's a
> string change. But from what I'm reading, cross-channel would be able to
> handle this? If this is the case, having localizations in m-c seems like the
> simpler option.

Building in mozilla-central ensures that a missing or broken string falls back to English. 

Cross-channel would make uplifts easier, as long as you leave reasonable time for localization, i.e. don't uplift something in Beta and expect to ship in release a week later.

I'm still concerned about the supported languages though. How do you plan to enable them? By UI locale and geolocation?

Listing countries is also not super helpful, we need to identify a list of languages.

Comment 7

[Luke Chang [:lchang] (inactive)]

Sorry to jump in.

I personally think having translations in m-c would be more suitable for Form Autofill because we do intend to ship with all languages if possible. Will discuss it with the team ASAP.

(In reply to Francesco Lodolo [:flod] from comment #6)
> I'm still concerned about the supported languages though. How do you plan to
> enable them? By UI locale and geolocation?

(Not sure if Scott has already mentioned but I can help on clarifying it.)

Currently, Form Autofill add-on will be available by users only when UI locale is detected to be "en-US" and geolocation is "US". Our short-term plan is to ship it with all languages but make it still restricted within "geolocation = US" so that people using zh-TW build but living in US can see the feature as well.

The countries Scott listed is related to our next plan, in which we are going to support more countries (i.e. geolocation = US,CA,DE, etc). For this reason, languages for those countries need to have higher priority if all translations can't be done at once. If, however, it's not the problem, to define supported languages might not be that necessary.

Comment 8

[Francesco Lodolo [:flod]]

Thanks Luke, I agree that enabling translations for all languages in m-c makes sense at this point.

As a side note, a lot of those countries have a very diverse population and a lot of languages spoken thanks to immigration (thinking of Canada, Germany, France), one more reason to enable all locales.

Comment 9

[Scott Wu [:scottwu]]

Thanks Francesco, I'll file a bug to commit the string ID changes and localization notes.

Also, to enable localization on m-c, do I just add our path to the filter.py file? http://searchfox.org/mozilla-central/source/browser/locales/filter.py#11

Comment 10

[Francesco Lodolo [:flod]]

You need to:
* Update filter.py in /browser
http://searchfox.org/mozilla-central/rev/1033bfa26f6d42c1ef48621909f04e734a7ed8a3/browser/locales/filter.py#11-12
* Update l10n.ini and l10n.toml in /browser
http://searchfox.org/mozilla-central/rev/1033bfa26f6d42c1ef48621909f04e734a7ed8a3/browser/locales/l10n.ini#15-16
http://searchfox.org/mozilla-central/rev/1033bfa26f6d42c1ef48621909f04e734a7ed8a3/browser/locales/l10n.toml#122-128

I assume the build part is already in good place
http://searchfox.org/mozilla-central/rev/1033bfa26f6d42c1ef48621909f04e734a7ed8a3/browser/extensions/formautofill/locales/jar.mn

The best reviewer for this kind of patch would be :pike

Comment 11

[Scott Wu [:scottwu]]

I've filed Bug 1407530 for updating the localization notes and Bug 1407528 for enabling localization.

(In reply to Francesco Lodolo [:flod] from comment #6)
> Cross-channel would make uplifts easier, as long as you leave reasonable
> time for localization, i.e. don't uplift something in Beta and expect to
> ship in release a week later.

How much time would you say is reasonable time for localization? Like how many weeks?

Comment 12

[Francesco Lodolo [:flod]]

(In reply to Scott Wu [:scottwu] from comment #11)
> How much time would you say is reasonable time for localization? Like how
> many weeks?

It's really hard to tell, because locales work at different times on the cycles. For example, German and Japanese typically work on Beta, and land late in the cycle. Some might also ship English strings before they manage to catch up.

I guess you're going to have a good percentage of locales done within a couple of weeks from landing (~20), but those might not necessarily be the languages you're interested in.

Comment 13

[Scott Wu [:scottwu]]

Thanks for the clarification. I guess we will just try to land strings as early as we could once they've been reviewed.

With Bug 1407528 landed, I don't think this bug is valid anymore since we're just going by the standard localization process. I'm marking this as invalid.