1160467 - [ga-IE] [sv-SE] [bn-IN] Firefox for iOS (build 9): Locale code mapping error due to Mozilla locale codes not adhering to BCP 47

Status: RESOLVED FIXED

(Firefox for iOS :: General, defect)

Description

[Luna Jernberg]

Hello i just installed Firefox iOS Beta that came today on my iPhone 4S thats set to Swedish but the Firefox application from Testflight is in english and did not find any way to set it to Swedish so reporting this bug to see whats up ?

Comment 1

[Francesco Lodolo [:flod]]

I can only confirm that Build 9 from Testflight works fine for me in Italian.
http://viewvc.svn.mozilla.org/vc/projects/l10n-misc/trunk/firefox-ios/sv-SE/firefox-ios.xliff?revision=140496&view=co

Wondering if it doesn't like the target-language as sv-SE.

Comment 2

[Francesco Lodolo [:flod]]

(In reply to Francesco Lodolo [:flod] (UTC+2) from comment #1)
> Wondering if it doesn't like the target-language as sv-SE.

Tested locally in XCode, importing the localization and setting the Simulator to Swedish:
* Current file -> Firefox in English
* Replace "sv-SE" with "sv" for target-language, Firefox is correctly localized

Which means we're probably going to have similar issue with zh-*, pt-PT.

There's still a pending PR to update the script to update localized XLIFF files
https://github.com/mozilla/firefox-ios/pull/340

It would be easy to map a folder to a different locale code, not sure how well it would be digested by Pootle.

Comment 3

[Jeff Beatty [:gueroJeff]]

Xcode should replace the locale code with the one it wants. Martin, have you also tried making sure that your region settings are set to Sweden, as well as your language settings to Swedish?

Another point is that what may have been made available is not the Aurora builds, but a Beta build. Meaning that it's possible no locales have been pushed into Beta. NI flagging Stefan to comment.

Comment 4

[Luna Jernberg]

(In reply to Jeff Beatty [:gueroJeff] from comment #3)
> Xcode should replace the locale code with the one it wants. Martin, have you
> also tried making sure that your region settings are set to Sweden, as well
> as your language settings to Swedish?
> 
> Another point is that what may have been made available is not the Aurora
> builds, but a Beta build. Meaning that it's possible no locales have been
> pushed into Beta. NI flagging Stefan to comment.

Yea everything on my phone is set to Swedish: http://a.pomf.se/imeffb.jpg but as we talking too on irc seems to be some problem, but i am waiting for next beta to try it out thx for all help and stuff for checking this out so far :)

Comment 5

[Jeff Beatty [:gueroJeff]]

Adjusted the summary of the bug. We have three locale codes which do not adhere to BCP 47 where iOS does. In the case mentioned above, sv-SE is too elaborate of a locale code because the region designation is unnecessary, thus it does not adhere to BCP 47. iOS only recognizes sv, as that is recommended according to BCP 47. As flod pointed out above, the locale code doesn't map to what iOS will recognize, and thus doesn't open in Swedish.

bn-IN (should be bn) and ga-IE (should be ga) are also affected by this bug. es-MX, pt-PT, zh-CN, and zh-TW are unaffected.

Comment 6

[Francesco Lodolo [:flod]]

Added the mapping for these 3 locales to the same pull request (separate commit, can squash if needed).

I also updated en-US (r140926) and used the script to update all other locales (r140927) in SVN.

Comment 7

[Stefan [:stefanh]]

(In reply to Jeff Beatty [:gueroJeff] from comment #5)
> Adjusted the summary of the bug. We have three locale codes which do not
> adhere to BCP 47 where iOS does. In the case mentioned above, sv-SE is too
> elaborate of a locale code because the region designation is unnecessary,
> thus it does not adhere to BCP 47. iOS only recognizes sv, as that is
> recommended according to BCP 47.

Jeff, where in BCP 47 does it say that the region designation "SE" is unnecessary and that the "SE" region designator is not valid? That does sounds more like an opinion to me :-) The ISO 3166 country code for Sweden is "SE" (see BCP 47 section 2.2.4 on the usage of country codes).

It looks to me that Apple think the region designator is unnecessary in some cases (which doesn't mean that the region designator in those cases isn't valid) and the problem here is more of a technical nature.

Comment 8

[Jeff Beatty [:gueroJeff]]

I should have used the word redundant rather than unnecessary. It's not that the region designation isn't valid, it's superfluous for the locales mentioned here. Part of BCP 47 emphasizes simplification of locale codes. So for example, why identify the Ireland region when Irish is exlusively spoken in Ireland? It's a redundancy and BCP 47 would prefer using ga as the code, rather than ga-IE. The same is true with Swedish in this case.

bn-IN is more of an Apple opinion issue. Clearly bn is spoken prominently in more countries than India, but they prefer to blur the country lines (as most companies do) and not use the region code. For Bengali, that tends to be the best practice. Besides Mozilla, I haven't found other companies who produce separate localizations for bn-IN and bn-BD.

Comment 9

[Stefan [:stefanh]]

(In reply to Jeff Beatty [:gueroJeff] from comment #8)
> I should have used the word redundant rather than unnecessary. It's not that
> the region designation isn't valid, it's superfluous for the locales
> mentioned here. Part of BCP 47 emphasizes simplification of locale codes. So
> for example, why identify the Ireland region when Irish is exlusively spoken
> in Ireland? It's a redundancy and BCP 47 would prefer using ga as the code,
> rather than ga-IE. The same is true with Swedish in this case.
>
> bn-IN is more of an Apple opinion issue

No, Swedish isn't exclusively spoken in Sweden. Swedish is spoken in Finland (minority language), Åland (100%) and to some extent also in Estonia (very few, though - iirc there is a minority population on the island Ösel which speaks Swedish). So this is more of an opinion issue :-)

Note that I don't have any strong opinion against dropping the existing region designators in this case (my guess is that the regional differences of sv are small, particulary when it comes to a browser UI), but they're currently used everywhere in mozilla-central (see for example http://mxr.mozilla.org/mozilla-central/search?string=sv-SE).

Comment 10

[Jeff Beatty [:gueroJeff]]

When I said the same is true with Swedish in this case, I was referencing the redundancy. I think we're getting distracted here. Please see comment 6 to see the implemented fix for this.

Comment 11

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Couple of quick notes:

Interestingly when submitted Build #9 to TestFlight, the App Store validation only complained about fry-NL. (Frysian is not supported on iOS it seems). Not about any of the locales mentioned in this bug.

The PR at https://github.com/mozilla/firefox-ios/pull/340 looks good. :flod do you have permission to merge that or are you waiting for me? Ping me and I'll merge if needed. Sorry for the delay.

Just to confirm, I don't have to do the same mapping in https://github.com/mozilla/firefox-ios/blob/master/scripts/xliff-to-strings.py because I write out the .lproj files based on the target-language, which your patch updates correctly?

Comment 12

[Francesco Lodolo [:flod]]

(In reply to Stefan Arentz [:st3fan] from comment #11)
> The PR at https://github.com/mozilla/firefox-ios/pull/340 looks good. :flod
> do you have permission to merge that or are you waiting for me? Ping me and
> I'll merge if needed. Sorry for the delay.

Yes, will need someone to merge (also squashed the commits).

> Just to confirm, I don't have to do the same mapping in
> https://github.com/mozilla/firefox-ios/blob/master/scripts/xliff-to-strings.
> py because I write out the .lproj files based on the target-language, which
> your patch updates correctly?

I think so. This works for me:
* Run the script xliff-to-strings.py (it will fail for br, empty targets).
* Run the build in XCode.
* Switch the simulator to Svenska, ignore the crash, restart the simulator and check that the URL placeholder is localized.

Comment 13

[Brian Nicholson (:bnicholson)]

Stefan says this might be resolved already.

Comment 14

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Can we ask the br maintainer to put a target-language in every <file> section? What is the procedure for that? Or can I modify the file in the SVN repository directly?

Marking this bug as resolved.

Comment 15

[Francesco Lodolo [:flod]]

(In reply to Stefan Arentz [:st3fan] from comment #14)
> Can we ask the br maintainer to put a target-language in every <file>
> section? What is the procedure for that? Or can I modify the file in the SVN
> repository directly?

Breton uses Pootle. I think there were issues with the import/export last time, it should be fixed in the next export. Just to be sure I'll clean up the file and see what happens next time.

Comment 16

[Francesco Lodolo [:flod]]

(In reply to Francesco Lodolo [:flod] (UTC+2) from comment #15)
> Just to be sure I'll clean up the file and see what happens next time.

Done in r141083.

Comment 17

[Luna Jernberg]

There is still problem for Swedish in Build 15

Comment 18

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Reopening this because it seems the locale code mapping code that I implemented was not committed or did somehow get lost.

This was reported for sv missing from TestFlight Build #15.

This is also a note to add ga-IE and bn-IN to the same locale mapping list.

Comment 19

[Francesco Lodolo [:flod]]

(In reply to Stefan Arentz [:st3fan] from comment #18)
> Reopening this because it seems the locale code mapping code that I
> implemented was not committed or did somehow get lost.

The problem is that Pootle overwrites the target-language with set with the script. The solution is to run this script before importing the files
https://github.com/mozilla/firefox-ios/blob/master/scripts/update-xliff.py

Comment 20

[Luna Jernberg]

Works now for Swedish in build #16