1471786 - Improve l10n notes and fix translations for form autofill address-level strings

Status: NEW

(Toolkit :: Form Autofill, enhancement, P3)

Description

[Matthew N. [:MattN]]

Form autofill supports showing address field labels that are appropriate for the country they're shown in but it seems like localizers have incorrectly adjusted translations to match their own locale instead, probably because there were no l10n notes.

e.g. we have a string for ZIP Code and Postal Code. The former is mostly used for the U.S. and it's affiliated countries (there are over a half-dozen of them) but some locales (e.g. en-UK and now en-CA) have translated Zip Code back to Postal Code which is incorrect when a U.S. address is being edited.

zip: https://transvision.mozfr.org/string/?entity=browser/extensions/formautofill/formautofill.properties:zip&repo=gecko_strings

Some localizers also assume that Zip is only used in the U.S. but that's isn't really correct:
https://transvision.mozfr.org/string/?entity=browser/extensions/formautofill/formautofill.properties:zip&repo=gecko_strings#an See an, fr, hu, it, oc, rm, etc. where a referenced to the U.S. was added. 

A similar issue applies to "State" vs. "Province". State should translate to what you call a state in countries that use the word state e.g. USA and likewise for Province but the en-US (and now en-CA) translation changes the meaning to match the UK address-level1 which is "county" and that is incorrect when a en-UK/en-CA user tries to add/edit an address in the US.

state => county: https://transvision.mozfr.org/string/?entity=browser/extensions/formautofill/formautofill.properties:state&repo=gecko_strings#en-CA

:flod, what's the best way to get this corrected? Probably some combination of:
a) Add l10n notes to explain that these strings are used in countries where it's the appropriate term.
b) Fix the translations for the known issues of en-UK and others linked above.
c) Send an email to the l10n mailing list asking localizers to review the specific address field related strings.

Comment 1

[Francesco Lodolo [:flod]]

en-CA might be explained with the fact that we used en-GB as a base, but the problem is much larger.

If you look at Japanese, they left all strings in English, because they don't make sense for Japanese
https://hg.mozilla.org/l10n-central/ja/file/default/browser/extensions/formautofill/formautofill.properties

I suggested them to file a bug to investigate, but I don't think it ever happened.

> In Japan:
> * Name order is "family name" to "given name". We don't use middle name.
> * Our address basis is not "street".
> * We use "country" (= Japan), "province", "city", "address1", "address2" (= name of building) and "postal code".
> * If I localize "province" in Japanese, it is "都道府県". However, if it is US address, it will be "州".
> * If I localize "city" in Japanese, it is "市区町村". However, if it is US address, it will be "都市". 

Adding comments and email dev-l10n are good steps, but first we need to figure out how internationalization works for this feature. 

Are those strings supposed to work for "local addresses"? If so, how do you deal, for example, with a en-US build used in Japan? Or the other way around? What about locales that are used in multiple countries, possibly with different fields (Spanish)?

Comment 2

[Francesco Lodolo [:flod]]

(In reply to Francesco Lodolo [:flod] from comment #1)
> Adding comments and email dev-l10n are good steps, but first we need to
> figure out how internationalization works for this feature.

Maybe we need two sets of strings: XXXX.US and XXXX.local. The first is always US, the second is assumed to be local for the language. 

And we might need additional fields for some locales, but they'll need to be exposed to all languages nonetheless.

Side question: in my Italian build, there's no "Country" selected, and it assumed the US structure. Is the default structure locale-dependent?

Comment 3

[Matthew N. [:MattN]]

(In reply to Francesco Lodolo [:flod] from comment #1)
> en-CA might be explained with the fact that we used en-GB as a base, but the
> problem is much larger.

Right, I understand that.

> If you look at Japanese, they left all strings in English, because they
> don't make sense for Japanese
> https://hg.mozilla.org/l10n-central/ja/file/default/browser/extensions/
> formautofill/formautofill.properties
> 
> I suggested them to file a bug to investigate, but I don't think it ever
> happened.
> 
> > In Japan:
> > * Name order is "family name" to "given name". We don't use middle name.
> > * Our address basis is not "street".
> > * We use "country" (= Japan), "province", "city", "address1", "address2" (= name of building) and "postal code".

The above issues are simply that we intentionally don't support Japanese addresses yet, only the three countries in the country picker. The locale checks were removed from Nightly to allow more locales to test the feature (not my choice) but maybe that's a mistake and confuses Nightly testers outside of the three supported countries. We only actually ship autofill in the US currently but CA and DE were ready for release before the project was put on hold. 

> > * If I localize "province" in Japanese, it is "都道府県". However, if it is US address, it will be "州".
> > * If I localize "city" in Japanese, it is "市区町村". However, if it is US address, it will be "都市". 

Unfortunately I don't know Japanese to understand if this is a real problem or not. We would never use the `province` string for a US address (we would use `state`) so I'm not sure whether that line is relevant or not. For a Japanese address the state/province field would be labelled as `prefecture` (not yet in the string file) instead of province or state. We would not show a city field at all.

> Adding comments and email dev-l10n are good steps, but first we need to
> figure out how internationalization works for this feature. 

Sorry, I should have explained better that the field labels should always be correct for the chosen country in the country picker. We use Google's libaddressinput data to do this, it's the same data they use in Chromium for the same purpose. The library tells us which fields to show for a given country and also what to call a "state"/"province" and what to call a "city". We then lookup the translation for that in formautofill.properties.

e.g. to lookup the label for state/province:

1) look at the chosen country (defaults to the user's country, if supported) in the dropdown
2) get the libaddressinput data for the country from https://dxr.mozilla.org/mozilla-central/source/browser/extensions/formautofill/addressmetadata/addressReferences.js
3) Look for a `state_name_type` key in the object, and use it as the l10n ID. Default to "province" if not found.
4) Use the l10n ID from step 3 to get the translation from formautofill.properties.

> Are those strings supposed to work for "local addresses"?

yes, but currently only between US, CA, and DE on Nightly.

> If so, how do you
> deal, for example, with a en-US build used in Japan?

For a Japanese address: the library tells us to use a `prefecture`[1] string for the state field so the en-US build would likely show "Prefecture". It also tells us to hide the city field.

For a US address: the usual city/state/ZIP Code labels would apply.

> Or the other way
> around?

For a Japanese address: same as above but translated into Japanese

For a US address: city/state/Zip Code fields translated into Japanese if it makes sense to. The translation shouldn't assume that the `zip` or `state` translation is only used in the U.S.A though since the Google data source tells us that it's also used in places like Puerto Rico, Guam, etc.

> What about locales that are used in multiple countries, possibly
> with different fields (Spanish)?

Again, it's all based upon the chosen country.

In general, we should be handling all of the above the same way Chrome does. To be explicit, we have one translation of each word (e.g. `state`) that needs to apply to all countries where that concept is used. It seems like Chrome does fine with this model but if we really need to we could have overrides for specific countries e.g. look for a `state-US` string ID and used that if the string exists, otherwise fallback to using `state`.

[1] https://www.gstatic.com/chrome/autofill/libaddressinput/chromium-i18n/ssl-aggregate-address/data/JP

(In reply to Francesco Lodolo [:flod] from comment #2)
> (In reply to Francesco Lodolo [:flod] from comment #1)
> > Adding comments and email dev-l10n are good steps, but first we need to
> > figure out how internationalization works for this feature.
> 
> Maybe we need two sets of strings: XXXX.US and XXXX.local. The first is
> always US, the second is assumed to be local for the language. 

I think being based upon the country is better than a "local" concept.

> And we might need additional fields for some locales, but they'll need to be
> exposed to all languages nonetheless.

Right, our libaddressinput data handles this.

> Side question: in my Italian build, there's no "Country" selected, and it
> assumed the US structure. Is the default structure locale-dependent?

Not exactly, what happens is that we use IP geolocation (the same data from the search service) to select a default `country` in the picker (which is independent of the UI locale). If you were in Italy when the profile first ran then we would default to Italy in the country picker but we don't currently support Italy so it defaults to empty… then we default to "U.S." in that case.

For Web Payments we will be "supporting" every country using the same Google data and profile UI so Italy will be in the list of countries by the end of the year. Form autofill will still not be offered in Italy though, this is just to support a en-US build needing to buy something to ship to Italy.

Comment 4

[Francesco Lodolo [:flod]]

Actually, let's try to pick Kohei's brain, since he's helping maintaining en-CA and speaks Japanese.

@Matt
I've accepted your changes to en-CA, they'll be in the next beta.

@Kohei
Can you comment on "comment 1" (the portion about Japanese)? Do you think having one field, e.g. "City" or "Street", that is potentially used for both US and Japanese addresses could be a problem?

Comment 5

[Matthew N. [:MattN]]

(In reply to Francesco Lodolo [:flod] from comment #4)
> Actually, let's try to pick Kohei's brain, since he's helping maintaining
> en-CA and speaks Japanese.
> 
> @Matt
> I've accepted your changes to en-CA, they'll be in the next beta.

Thanks.

> @Kohei
> Can you comment on "comment 1" (the portion about Japanese)? Do you think
> having one field, e.g. "City" or "Street", that is potentially used for both
> US and Japanese addresses could be a problem?

And please compare to what Chrome does please.

Comment 6

[Kohei Yoshino [:kohei]]

Dunno why these fields are not localized into Japanese yet. I think :marsf can answer better that question.

Comment 7

[Francesco Lodolo [:flod]]

I should have clarified that comment 1 is coming from an email conversation with :marsf

Comment 8

[Masahiko Imanaka [:marsf]]

MattN:
You are right that the "prefecture" is appropriate term.
https://en.wikipedia.org/wiki/Prefectures_of_Japan

And, I agree with following comments.

(PM if requests are blocking you) from comment #3)
> (In reply to Francesco Lodolo [:flod] from comment #2)
> > (In reply to Francesco Lodolo [:flod] from comment #1)
> > > Adding comments and email dev-l10n are good steps, but first we need to
> > > figure out how internationalization works for this feature.
> > 
> > Maybe we need two sets of strings: XXXX.US and XXXX.local. The first is
> > always US, the second is assumed to be local for the language. 
> 
> I think being based upon the country is better than a "local" concept.
> 
> > And we might need additional fields for some locales, but they'll need to be
> > exposed to all languages nonetheless.
> 
> Right, our libaddressinput data handles this.