538287 - [z] Add the locales AMO supports to django

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Code Quality, defect, P2)

Description

[Wil Clouser [:clouserw]]

Django only supports a subset of the locales that AMO supports and the docs say we need to translate a portion of django as well in order to add the locale.  It doesn't sound like a painless process so -> jbalogh for recommendations and help.  I can help too.

Docs are http://docs.djangoproject.com/en/dev/topics/i18n/

Comment 1

[Jeff Balogh (:jbalogh)]

I asked on the Django list and they'll accept partial translations.  We could start with the strings in http://gist.github.com/272594 to get error messages and technical strings for locales Django doesn't support.

Comment 2

[Wil Clouser [:clouserw]]

I don't think that's too bad.  We can create a fake template with just those strings in it to automatically add those strings to our .po file via the extraction script.  Some of those are going to require developer comments but I can help with that.

Comment 3

[Jeff Balogh (:jbalogh)]

Added all the locales in http://github.com/jbalogh/zamboni/commit/723ab7a6ec39ad41b2f7d1c02178cdc4018c65da

Comment 4

[Jeff Balogh (:jbalogh)]

(In reply to comment #2)
> I don't think that's too bad.  We can create a fake template with just those
> strings in it to automatically add those strings to our .po file via the
> extraction script.  Some of those are going to require developer comments but I
> can help with that.

These strings are already translated in most of the locales we want, in the django source.  We don't want everyone to do this, only the locales Django is missing.  If the missing locales want to translate these, why wouldn't we upstream it to Django as soon as possible?

Comment 5

[Wil Clouser [:clouserw]]

I was trying to figure out a way to manage the flow of localizers translating these.  Emailing the list and saying "here is a pile of strings" and having them email them back sounds like a pain for everyone involved.

I guess we could make a separate, temporary project in SVN and hook up verbatim.  That could move relatively quickly.

Comment 6

[Fred Wenzel [:wenzel]]

(In reply to comment #5)
> I was trying to figure out a way to manage the flow of localizers translating
> these.  Emailing the list and saying "here is a pile of strings" and having
> them email them back sounds like a pain for everyone involved.
> 
> I guess we could make a separate, temporary project in SVN and hook up
> verbatim.  That could move relatively quickly.

Both options work, depending on the amount of locales we need to do that for, we could do either. Do you have a list of affected locales?

Comment 7

[Jeff Balogh (:jbalogh)]

Attachment: locales in amo's /locale dir

Comment 8

[Jeff Balogh (:jbalogh)]

Attachment: locales in django's /locale dir

Comment 9

[Jeff Balogh (:jbalogh)]

What's django missing?

af
en-US (they have en)
es-ES (they have es)
fy-NL
ga-IE (they have ga)
id
mn
pt-BR (they have pt and pt-PT)
sq
sr-Latin (they have sr)
sv-SE (they have sv)
vi

Full diff of the locales:

--- amo-locales.txt	2010-01-21 14:55:37.000000000 -0800
+++ django-locales.txt	2010-01-21 14:55:41.000000000 -0800
@@ -1,39 +1,52 @@
-af
 ar
+bg
+bn
 ca
 cs
 cy
 da
 de
 el
-en_US
-es_ES
+en
+es
+es_AR
+et
 eu
 fa
 fi
 fr
-fy_NL
-ga_IE
+ga
+gl
 he
+hi
+hr
 hu
-id
+is
 it
 ja
+ka
+km
+kn
 ko
-mn
+lt
+lv
+mk
 nl
+no
 pl
+pt
 pt_BR
-pt_PT
 ro
 ru
 sk
-sq
+sl
 sr
-sr-Latn
-sv_SE
+sr_Latn
+sv
+ta
+te
+th
 tr
 uk
-vi
 zh_CN
 zh_TW

Comment 10

[Jeff Balogh (:jbalogh)]

Django has en but we have en-US.  Is that mismatch going to be problem, or does gettext know how to fall back to en?

Comment 11

[Wil Clouser [:clouserw]]

gettext can do en-US -> en.  It can't do stuff like pt-BR -> pt-PT -> en

Comment 12

[Wil Clouser [:clouserw]]

Let's just create django.po files for locales that need them and put them in the remora locale directory to get them localized.  Then we can upstream them manually.

Comment 13

[Wil Clouser [:clouserw]]

Files are in r61111

Comment 14

[Wil Clouser [:clouserw]]

Status Update:

No response:
af, id, mn, sr-Latn:  These locales have been inactive for a while.  I want them to still show up in the L10n dashboard, since that will encourage someone to pick them up.
vi: This locale is active, but I don't think the localizer reads dev-l10n-web.  I'll see what's up.

Done:
> en-US (they have en) - We'll just redirect to en until there is reason not to
> es-ES (they have es) - Need to redirect to es
> fy-NL - added
> ga-IE (they have ga) - We'll redirect to ga
> pt-PT - no response, let's redirect to pt
> sq - added
> sv-SE - no response, let's redirect to sv

Comment 15

[Wil Clouser [:clouserw]]

vi bug has been filed for 2 weeks[1].  I'm waiting on django there.  So, this is mostly done and I'm kicking it to 5.8.

[1] http://code.djangoproject.com/ticket/11463

Comment 16

[Wil Clouser [:clouserw]]

these locales are on django.  The 4 that gave no response are way behind and we'll leave them partially localized, but not support them on the actual site (l10n stats can be done via verbatim).