Closed
Bug 647376
Opened 13 years ago
Closed 13 years ago
L10n problems in settings file
Categories
(Websites Graveyard :: markup.mozilla.org, defect, P2)
Websites Graveyard
markup.mozilla.org
Tracking
(Not tracked)
VERIFIED
FIXED
1.0
People
(Reporter: wenzel, Assigned: wenzel)
Details
(Keywords: l12y)
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•13 years ago
|
Severity: minor → normal
Comment 1•13 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?
Updated•13 years ago
|
Assignee: nobody → adam
Comment 3•13 years ago
|
||
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•13 years ago
|
||
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•13 years ago
|
||
Updates here?
Comment 6•13 years ago
|
||
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.
Assignee | ||
Updated•13 years ago
|
Priority: -- → P2
Comment 7•13 years ago
|
||
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.
Updated•13 years ago
|
Target Milestone: --- → 1.0
Assignee | ||
Comment 8•13 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•13 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment 9•13 years ago
|
||
Wheee! Thanks, Fred.
Comment 10•13 years ago
|
||
Looks good to me. Stas do you see more that needs to be done before we squash this bug?
Comment 11•13 years ago
|
||
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•13 years ago
|
||
I file bug 655875 for the issue described in comment 11. This one is verified.
Status: RESOLVED → VERIFIED
Updated•2 years ago
|
Product: Websites → Websites Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•