818306 - Remove all other languages that are not being supported

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia, defect, P1)

Description

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

First run experience as well as settings -> language is showing arabic, English (US), French and Chinese.

We should be showing English, Brazilian Portuguese, and Latin America Spanish at the very least.

Note: I can't seem to find a bug for this so I am creating one and marking as a basecamp blocker because we can't ship with the current language selections.

Comment 1

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Actually the addition of the languages were bug 809253.  Changing the title to the removal of non supported languages.  At the very least we should remove RTL languages (arabic) as it causes layout issues.

Comment 2

[David Scravaglieri [:scravag]]

Maria, could you check what are the expected supported languages ?

Comment 3

[Daniel Coloma:dcoloma]

The languages commented by Naoki are the ones to be shipped in the product:

English, Brazilian Portuguese, and Latin America Spanish

Adding Stas to the loop as he is working in a way to decouple languages and configure during build time.

Comment 4

[Alex Keybl [:akeybl]]

Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.

Comment 5

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Naoki Hirata :nhirata from comment #1)
> Actually the addition of the languages were bug 809253.  Changing the title
> to the removal of non supported languages.  At the very least we should
> remove RTL languages (arabic) as it causes layout issues.

The current language selection as been done for a few reasons. French is a very long languages so strings are likely to not fit in the UI. Arabic is a RTL language and localizers can not fix all Gaia issues related to RTL support (an additional difficulty couple with translation), and zh-TW because this is a fun language with complicate IME.

That said I have no issue to remove them as long as those can be accessed easily for developers / translators (which is the case).

So here is done my useless comment.

Comment 6

[Staś Małolepszy :stas]

We shouldn't remove these locales for the nightly builds.  They're useful for everyone when it comes to testing.  In fact, I intend to add even more in bug 823478.

For production builds, we should have additional languages-*.json files with the proper selection of locales.

Comment 7

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

This bug is for production as the other languages should not be included for shipping.

Comment 9

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

For further explanation on reopening the bug:
- I would rather not include languages for final production such as RTL and double byte characters as we do not support RTL languages well (you can find the RTL bugs) and the double byte (asian languages) keyboard crashes the phone.

- Also I would prefer not to have incomplete languages and would rather concentrate on the languages that are required.

Comment 10

[Staś Małolepszy :stas]

Naoki:  I agree with you, but they way we're going to solve this is discussed in bug 822440. In short, we're adding languages-basecamp.json with en-US, es and pt-BR only.

Comment 11

[Tony Chung [:tchung]]

reopening this bug, so we can track this bug as primary action on removing the unreleased locales.   It was a request by releng so they can track the work seperately from bug 822440.

This bug will be marked blocking-b2g:tef+, as this is for final v1.0 release.

Comment 12

[Staś Małolepszy :stas]

Tony -- I dont' understand why this bug need to be open?  See my comment 10.  By using languages-basecamp.json from bug 822440 we will be setting the list of available locales to (en-US, es, pt-BR).  Arabic, French and Chinese will not be available.

The only thing that we might want to fix in this bug is that *.{ar, fr, zh-TW}.properties files are not zipped in the profile, as they are right now.

This should be a build time fix, and should not involve removing these files from the git repository.  They need to stay in git for testing purposes.

Comment 13

[Justin Wood (:Callek)]

(In reply to Staś Małolepszy :stas from comment #12)
> Tony -- I dont' understand why this bug need to be open?

I'll comment here as I was the releng person that asked tony to move the issue to a new bug instead of 822440. I'm of a mindset of "one bug per issue" and even if the other bug is intended to be or have a solution to one issue, the fact that 822440 is about, specifically, mirroring l10n repos to git.m.o adding on other issues to it is just cumbersome/troublesome/problematic in terms of tracking and understanding what is going on.

So in order to keep my sanity in terms of the work there, tony reopened this bug for the tracking:tef+ choice and the specific issue of "don't ship these other locales", lets chat on IRC if there is a reason you still don't agree after the above explanation

Comment 14

[Alex Keybl [:akeybl]]

This doesn't blocking-b2g:tef+, because we can notify partners to build with less locales as part of their own configuration.

Comment 15

[Binyamin]

I agree that the unstable features are not relevant for stable release. Anyway I think for Nightly version must be enabled all languages for a better testing case https://bugzilla.mozilla.org/show_bug.cgi?id=947700

Comment 16

[Staś Małolepszy :stas]

This was fixed a long time ago by introducing the LOCALES_FILE make flag which can point to any JSON file similar to shared/resources/languages.json.