#32737: get_language_info replaces requested language code with the one found in
django.conf.locale.LANG_INFO
-------------------------------------+-------------------------------------
Reporter: ruffni | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: | Version: dev
Internationalization |
Severity: Normal | Resolution:
Keywords: i18n, | Triage Stage: Accepted
get_language_info, language code, |
LANG_INFO, documentation |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by ruffni):
Replying to [comment:5 Claude Paroz]:
> Thanks a lot for the sample project. I'm reopening at least for the
missing documentation which should tell that `get_language_info` and
`get_language_info_list` only return information for languages included in
Django.
yeah, still not completely sure whether this can be sold as intended
behavior (to replace a given language code from settings with the code for
the language present in the django admin). "languages included in Django"
is what irritates imho. this implies languages defined in settings.py are
not included?
> In your specific use case, I would simply rewrite your language selector
as:
> {{{
> <select name="language" class="custom-select" id="lang_selection">
> {% get_current_language as LANGUAGE_CODE %}
> {% get_available_languages as LANGUAGES %}
> {% for code,lang_name in LANGUAGES %}
> <option value="{{ code }}" {% if code == LANGUAGE_CODE %}
selected{% endif%}>
> {{ lang_name }} ({{code}})</option>
> {% endfor %}
> </select>
> }}}
thanks for the snippet!
now though, the language selection gets displayed in the currently active
language (which is fine in my case where there's only 3 languages).
assuming there were a website with dozens of languages with different
alphabets and reading directions and whatnot, this would definitely be a
deal breaker for usability. imagine trying to find the arabic string for
the word "english" in a drop-down menu full of arabic strings -> mission
impossible.
> If we wanted custom languages data entering Django's `LANG_INFO`, it
would require some deeper refactoring with language data embedded
somewhere inside the locale folders (maybe in `__init__.py`?). Don't know
if it's really worth the effort…
i guess some re-working will have to be done to resolve the issue in a
nice way.
either defining country-specific translations to be second-class citizens
(which django may or may not fall back to if there is no translation for
the standard-language; i.e. selecting translations from 'fr-ch' if French
is requested but code 'fr' is not found) or completely differentiating
between pre-existing languages (the ones you called "included" above) and
ignoring them as soon as LANGUAGES is defined in settings.py.
--
Ticket URL: <https://code.djangoproject.com/ticket/32737#comment:6>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.c90738bac3a1f7823143a3bb38cf2dfb%40djangoproject.com.
