647376 - L10n problems in settings file

Status: VERIFIED FIXED

(Websites Graveyard :: markup.mozilla.org, defect, P2)

Description

[Fred Wenzel [:wenzel]]

Stas from the L10n team writes:

"""
Some code looks unfinished:

    https://github.com/mozilla/markup/blob/master/ffdemo/settings.py#L69

    gettext = lambda s: s

This might not work :)

Also, the list of the locale names shouldn't be in the code.  I think 
we usually pull it from the product-details lib?  In either case, we 
have the names localized into all languages for sure.
"""

He's referring to this library:

http://github.com/fwenzel/django-mozilla-product-details

and the way it is used here:

https://github.com/mozilla/playdoh/blob/base/settings.py#L26 ... until line 74

Comment 1

[claudia // barbarian]

However, our question is that it says the list of the locale name shouldn't be in the code, but the example you gave does have it in the code:

KNOWN_LANGUAGES = ('en-US',)

Can you please clarify?

Comment 2

[Adam Miller]

Clarification please.

Comment 3

[Zibi Braniecki [:zbraniecki][:gandalf]]

It's pretty much ok to have KNOWN_LANGUAGES inside settings.py. Let's keep it there for now, and if we'll want to move it to product-details, it'll be easy.

Comment 4

[Staś Małolepszy :stas]

I meant locale names, not codes, actually.

I can still see the following code

# Accepted locales
LANGUAGES = (
    ('de', 'German'),
    ('en', 'English'),
    ('fr', 'French'),
    ('ru', 'Russian'),
)

on github.  I think we should take advantage of the product-details library to get the full names of locales (native and in English).

Comment 5

[Laura Mesa [:lmesa] [:lvmesa]]

Updates here?

Comment 6

[Staś Małolepszy :stas]

Alternatively, it looks like we could use locale data that's built into Django:

    django.utils.translation.get_language_info

See <http://docs.djangoproject.com/en/dev/topics/i18n/internationalization/#localized-names-of-languages> for more information.

Comment 7

[Staś Małolepszy :stas]

Actually, {% get_language_info %} and {% get_language_info_list %} template tags were only introduced in Django 1.3.  Since MarkUp is on 1.2.*, it seems that using product-details would be the best solution.

Comment 8

[Fred Wenzel [:wenzel]]

I used the product-details library for the (translated) locale names:

https://github.com/mozilla/markup/commit/1167240

Please also note that this changed /en to /en-US, which we use everywhere else. I grepped through the source tree and didn't see a reason why this would lead to problems, so off we go.

Comment 9

[Staś Małolepszy :stas]

Wheee!  Thanks, Fred.

Comment 10

[Matt Brandt [:mbrandt]]

Looks good to me. Stas do you see more that needs to be done before we squash this bug?

Comment 11

[Staś Małolepszy :stas]

I'm not sure if this is related to this bug or maybe bug 655305, but I recall seeing the current language name being displayed next to the arrow in the language chooser when it's closed.  Right now I can only see the arrow.

Comment 12

[Staś Małolepszy :stas]

I file bug 655875 for the issue described in comment 11.  This one is verified.