L10n problems in settings file

VERIFIED FIXED in 1.0

Status

P2
normal
VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: wenzel, Assigned: wenzel)

Tracking

({l12y})

unspecified

Details

(Assignee)

Description

8 years ago
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
(Assignee)

Updated

8 years ago
Severity: minor → normal

Comment 1

8 years ago
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?
Assignee: nobody → adam

Comment 2

8 years ago
Clarification please.
Assignee: adam → fwenzel
Status: NEW → ASSIGNED
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.
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).
Updates here?
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.
Keywords: l12y
(Assignee)

Updated

8 years ago
Priority: -- → P2
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.
Target Milestone: --- → 1.0
(Assignee)

Comment 8

8 years ago
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.
(Assignee)

Updated

8 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Wheee!  Thanks, Fred.
Looks good to me. Stas do you see more that needs to be done before we squash this bug?
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.
I file bug 655875 for the issue described in comment 11.  This one is verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.