Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#25709 closed Bug (worksforme)

Template tag get_available_languages si doing unwanted translation

Reported by: azurit Owned by: nobody
Component: Template system Version: 1.8
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I have this defined in my settings.py:

LANGUAGES = (
    ('sk', u'Slovenčina'),
    ('en', u'English'),
)

I don't want the language names to be translated and this is why i don't used _(). While using template tag get_available_languages to get list of available langauges, the language names are getting translated anyway.

Attachments (1)

patchfile (417 bytes ) - added by azurit 8 years ago.

Download all attachments as: .zip

Change History (12)

by azurit, 8 years ago

Attachment: patchfile added

comment:1 by azurit, 8 years ago

Has patch: set

comment:2 by Ilja Maas, 8 years ago

Triage Stage: UnreviewedAccepted

comment:3 by azurit, 8 years ago

Can i ask which Django version will include this fix and approximately when it will be released? Thank you.

comment:4 by Claude Paroz, 8 years ago

Resolution: worksforme
Status: newclosed

The fact that the language name is translated is documented: https://docs.djangoproject.com/en/1.8/topics/i18n/translation/#get-available-languages

If you want to get the untranslated language name, you can access it through get_language_info: https://docs.djangoproject.com/en/1.8/topics/i18n/translation/#get-language-info

comment:5 by azurit, 8 years ago

Using get_language_info is not the solution as it is NOT reading langauge names from settings.py - it is simply not using my own names but some kind of Django defined names (which it generates based on country code). I don't understand why get_available_languages is translating langauge names, if someone wants translated names, he/she can use _() in settings.py (which also documentation suggests).

comment:6 by azurit, 8 years ago

What is the point in translating language names into current language? Language names should always be in the local translation so everyone will understand them. This seems to me like an old Nokia mobile joke where you just switched a language of friends phone to Chinese and Nokia was displaying also language names in Chinese so he/she was unable to switch it back without trying all languages and finding the correct one.

comment:7 by Claude Paroz, 8 years ago

In the use case of a user having to switch into her own language, you are right. But there are also other valid use cases where you want to present language names with the current language. That's why Django offers both possibilities either through get_available_languages or get_language_info.

comment:8 by azurit, 8 years ago

As i stated before, get_language_info is NOT reading language names from settings.py so it won't fix my problem. Currently, i workarounded the unwanted translation by suffixing language names with a space, which is REALLY ugly hack but there's no other simple solution :(

comment:9 by Claude Paroz, 8 years ago

Note that language names in the default settings.LANGUAGES are in English. get_language_info uses the django.conf.locale.LANG_INFO dictionary which already contains untranslated language name for all supported locales.

If you have specific needs not covered by the utilities from Django, it should not be hard to provide your own piece of code for that (view context if this is for a specific page, context processor or custom tag if you need it more globally).

comment:10 by azurit, 8 years ago

I know there are lots of other solutions but i wanted a simple and nice one - for a gods sake, i just want to show untranslated langauge name of my choice! :) By the way, slovak local language name returned by get_language_info is grammatically incorrect.

in reply to:  10 comment:11 by Claude Paroz, 8 years ago

Replying to azurit:

By the way, slovak local language name returned by get_language_info is grammatically incorrect.

Could you please open a separate ticket for that?

Note: See TracTickets for help on using tickets.
Back to Top