895006 - Enable all locales that are currently shipping Firefox desktop

Status: RESOLVED WONTFIX

(developer.mozilla.org Graveyard :: Localization, defect)

Description

[Jeff Beatty [:gueroJeff]]

What feature should be changed? Please provide the URL of the feature if possible.
==================================================================================
The number of enabled locales on MDN.

What problems would this solve?
===============================
This will allow a greater breadth of locales to translate and create developer documentation on MDN. Additionally, this will pave the way for l10n teams to transalte and localize their own style guides for their l10n work.

Who would use this?
===================
Mozilla localizers

What would users see?
=====================
More locales in the list of supported locales (see "Other Languages" dropdown menu).

These would be the locales added to the list:

Acholi (ach)
Afrikaans (af)
Armenian (hy-AM)
Indian Bengali (bn-IN)
Assamese (as)
Asturian (ast)
Basque (eu)
Belarusian (be)
Bosnian (bs)
Breton (bre)
Bulgarian (bg)
Danish (da)
English (en-GB)
English (en-ZA)
Esperanto (eo)
Estonian (et)
Fulah (fu)
Scottish Gaelic (gd)
Galician (ga)
Gujarati (gu-IN)
Hindi (hi-IN)
Icelandic (is)
Kannada (kn)
Kashubian (csb)
Kazakh (kk)
Khmer (km)
Latvian (lv)
Ligurian (lij)
Lithuanian (lt)
Macedonian (mk)
Maithili (mai)
Marathi (mr)
Malayalam (ml)
Northern Sotho (nso)
Norwegian Bokmal (nb-NO)
Norwegian Nnynorsk (nn-NO)
Oriya (or)
Punjabi (pa-IN)
Romansh (rm)
Serbian (sr)
Sinhala (si)
Slovak (sk)
Slovenian (sl)
Songhai (son)
Argentine Spanish (es-AR)
Chilean Spanish (es-CL)
Mexican Spanish (es-MX)
European Spanish (es-ES)
Swedish (sv-SE)
Tamil (ta)
Telugu (te)
Ukranian (uk)
Welsh (cy)
Zulu (zu)

What would users do? What would happen as a result?
===================================================
They would be able to select documentation in their language. 

Is there anything else we should know?
======================================
The l10n drivers are creating a style guide that will be rolled out to shipping l10n teams to translate and localize. We would like MDN to host the style guide because of how accessible the wiki is and how easy it is to create and localize documents on MDN.

Comment 1

[Florian Scholz (Open Web Docs)]

Jeff, if I see it correctly, not even SUMO has support for all these locales:
https://support.mozilla.org/en-US/locales

Does it really make sense to enable all of them?

Also, I really see no need for English (en-GB), English (en-ZA) and so on.

Comment 2

[Jeff Beatty [:gueroJeff]]

Hi Florian,

The primary use for this is internal: l10n teams need a place to author and maintain their own translated style guides for their l10n work. Being that we store Mozilla l10n doc on MDN, and that Kuma is much better authoring platform (not to mention properly internationalized) than mediawiki, I'd hoped that we could encourage l10n teams to use MDN for this purpose.

The existing style guide is here: https://developer.mozilla.org/en-US/docs/L10n_Style_Guide The goal is that l10n teams will translate the first page and localize the second according to their own language's particular needs.

Currently, Axel and I are re-evaluating the l10n doc strategy. It would be good to organize a discussion with you about the role and future of the Mozilla l10n doc on MDN.

Comment 3

[Luke Crouch [:groovecoder]]

That makes sense to me.

The only concern I have is the effect on the rest of MDN content and user experience. E.g., will we confuse users with so many language choices into the various language drop-downs and lists? And will they be frustrated if the L10n style guide is the only thing actually translated into their language?

Comment 4

[Jeff Beatty [:gueroJeff]]

Does enabling a language on MDN require that it be added to the drop-down or lists? Since enabling the locale is primarily for internal purposes, keeping it off of those lists once enabled would minimize user impact, while allowing us to pursue our needs for the style guide.

Conversly, is it possible that enabling these locales and having users comment on not enough doc being available in their language provide an opportunity for MDN to expand their language coverage by involving these people in the MDN translation efforts? Janet forwards me many requests from the "Get Involved" page where people have selected their interest as "Documentation" and they mention translation in their comments. It's likely that these people could be motivated to translate for MDN if their language were already available.

Comment 5

[Jean-Yves Perrier [:teoli]]

(In reply to Jeff Beatty [:gueroJeff] from comment #4)
> Does enabling a language on MDN require that it be added to the drop-down or
> lists? 
If this is possible, I'm quite interested. Feedbacking Luke :-) .

Comment 6

[Luke Crouch [:groovecoder]]

Currently, yes - enabling a language on MDN automatically:

* Adds it to places where we list all languages (language selector drop-down)
* Enables an "untranslated" view of every article on MDN, with a Call-to-Translate link at the top [1]

The problem with enabling languages that aren't active:

1. A translator translates an article [2]
2. English article is updated [3]
3. Translator doesn't update translation
4. Visitor to the article receives out-dated information

That's the experience problem we need to fix before we add 55 new languages in bulk. A couple other bugs/features would help:

* bug 665719 for better review-and-approve workflow
* bug 899665 to notify translators when the English articles are updated

So, I'm making this bug depend on the latter.

[1] https://developer.mozilla.org/de/docs/Web/JavaScript/Getting_Started
[2] https://developer.mozilla.org/el/docs/Mozilla/Firefox_OS/Developer_phone_guide/Geeksphone
[3] https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/Geeksphone

Comment 7

[Jeff Beatty [:gueroJeff]]

Luke, so then it's currently not possible to enable a language and keep it from being added to the language selector?

Comment 8

[Julien G]

My 2 cents: the language list that I use the most is the one from the 'Languages' button of an article (not the one for the language selection of the whole site) 
(L1) which is the list of the currently available locales for one page. If L1 has N elements, the dropdown list will show N+1 elements (the locales + "Add a translation" option) and the user will see the dropdown list when clicking on "Languages")

Thee another list (L2) which the list of all possible locales to translate a page (see [a]). L1 can only be a subset of L2.  I don't see L2 on each page. I only see L2 in pages like [a] or the home page!

I think that L2 could be reduced from Jeff's list to the list of locales available for [b] (to avoid having 'en-CA' or "too small" variants like Florian said)

I think expanding L2 is a good idea (reducing the obstacles to have new pages in a new locale). (but remind that we already have the "add a translation" option + the incentive message "help us translate this page" (see [1] of #6) and for me that's great).

[a] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Getting_Started$locales
[b] https://www.mozilla.org

Comment 9

[Luke Crouch [:groovecoder]]

Julien is right about the language selector choices.

So, we're trying to expand our existing "possible locales" [1] to match mozilla.org's locales [2]? That's more reasonable than automatically enabling all Firefox locales.

But we would still need to solve the issues of out-dated translations. madalina - (how) does SUMO display out-dated translations?

[1] https://github.com/mozilla/kuma/blob/master/settings.py#L114-L152
[2] https://github.com/mozilla/bedrock/blob/master/bedrock/settings/base.py#L31-L42

Comment 10

[Jeff Beatty [:gueroJeff]]

The locales on mozilla.org are the same as those we commit to shipping Firefox into. Localizing mozilla.org is part of the official release process for Firefox desktop.

Please know that I appreciate your looking into this for me. I also understand why it wouldn't be in MDN's best interest to enable all of these locales. Although I certainly would prefer that this style guide project take place on MDN, I can also look into alternatives if needed.

Comment 11

[Jean-Yves Perrier [:teoli]]

(In reply to Luke Crouch [:groovecoder] from comment #9)

> So, we're trying to expand our existing "possible locales" [1] to match
> mozilla.org's locales [2]? That's more reasonable than automatically
> enabling all Firefox locales.

No. There are locales there that we don't want _any_ article in. Like en-GB.

Comment 12

[Julien G]

(In reply to Jeff Beatty [:gueroJeff] from comment #10)
> The locales on mozilla.org are the same as those we commit to shipping
> Firefox into. Localizing mozilla.org is part of the official release process
> for Firefox desktop.
> 
> Please know that I appreciate your looking into this for me. I also
> understand why it wouldn't be in MDN's best interest to enable all of these
> locales. Although I certainly would prefer that this style guide project
> take place on MDN, I can also look into alternatives if needed.

Agreed, I am just wondering : how are selected the locales for mozilla.org? 
When I'm exploring the source code I don't find 'en-GB' for example. Please see the attachments, I think it is useful if we want to apply the same "filter" for MDN.

Comment 13

[Julien G]

Attachment: Locales observed in the mozilla.org selector

Comment 14

[Julien G]

Attachment: A diff between mozilla.org and https://github.com/mozilla/bedrock/blob/master/bedrock/settings/base.py#L31-L42

Comment 15

[Jeff Beatty [:gueroJeff]]

I imagine the reason some appear in the prod list is because the span different channels, also because there's no real need for an en-GB, en-ZA, or nn-NO localization of mozilla.org . Following the mozilla.org selector is fine.

Comment 16

[madalina]

(In reply to Luke Crouch [:groovecoder] from comment #9)
> Julien is right about the language selector choices.
>
> But we would still need to solve the issues of out-dated translations.
> madalina - (how) does SUMO display out-dated translations?
> 
> [1] https://github.com/mozilla/kuma/blob/master/settings.py#L114-L152
> [2]
> https://github.com/mozilla/bedrock/blob/master/bedrock/settings/base.py#L31-
> L42

I'm not familiar with this one, maybe Kadir can help

Comment 17

[Kadir Topal [:atopal]]

(In reply to Luke Crouch [:groovecoder] from comment #9)
> But we would still need to solve the issues of out-dated translations.
> madalina - (how) does SUMO display out-dated translations?

We let the reviewers decide what level of change an edit represents. We have

Level 1: spelling and grammar mistakes, no effect on localization. Nobody gets notified

Level 2: Additions, improvements to an article. Localizers gets a message per mail and it goes on the L10n dashboard as "needs update"

Level 3: The previous version is now inaccurate, maybe dangerous to follow. Localizers gets a message per mail and it goes on the L10n dashboard as "needs immediate update". We also put a message on top of the article saying: "This is an outdated version of the article, you may want to read the current version in English" and link to it.

Comment 18

[Jean-Yves Perrier [:teoli]]

So the current proposal is available there:
https://docs.google.com/spreadsheets/d/1E6zGB4x3gQaumsFPiREYZ9lCMWUkwR33v272F-3QifU/edit#gid=0

Adding productwanted for tomorrow's council.

Comment 19

[Jean-Yves Perrier [:teoli]]

Would like to have :robhudson feedback on this :-)

Comment 20

[Rob Hudson [:robhudson]]

I agree with Luke's assessment in comment #6 and the other devs felt similar when I asked. The preference would be to only add new locales if there are active localizer(s) that will be translating UI strings and documents.