#24739 closed Bug (fixed)
Document translation fallback behavior change in 1.8
Reported by: | Nicola | Owned by: | nobody |
---|---|---|---|
Component: | Internationalization | Version: | 1.8 |
Severity: | Release blocker | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I updated from 1.7 to 1.8
in my templates and python code I have string in my native language (italian),
so my po files look likes this:
1) locale en
msgid "original string in italian"
msgstr "english translated string"
2) locale it
msgid "original string in italian"
msgstr ""
now in settings I have:
LANGUAGE_CODE = 'en'
my browser is in italian so request.LANGUAGE_CODE is "it"
in django <1.8 the fallback translation is taken from the it po file, in django 1.8+ en translation is used since my default LANGUAGE_CODE is "en", if I set LANGUAGE_CODE to "it" the fallback string from it po file is used
Change History (8)
comment:1 by , 10 years ago
Severity: | Normal → Release blocker |
---|---|
Summary: | 1.7 => 1.8 i18n behaviour change → Undocumented i18n behavior change in 1.8 (or a regression) |
Triage Stage: | Unreviewed → Accepted |
Type: | Uncategorized → Bug |
comment:2 by , 10 years ago
Apart from the unexpected change, isn't the new behavior the most correct?
Maybe you might check that master keeps this behavior, as [3cf1c02695481900] touched this part of the code. But at first sight, it shouldn't affect the use case you described.
comment:3 by , 10 years ago
New behaviour:
- if a string is not translated for a locale django use the translated string (if any) from the default locale
Old behaviour:
- if a string is not translated for a locale django use the untranslated string for the same locale
what is most correct is an opinion, I like the old behaviour since all untranslated strings should be equals,
your opinion could be that an untranslated string should show the value for the default locale and not the untranslated one
however is easy enouth to use a tool like poedit to copy all the translations from the original string, so if you like more the new behaviour is just a matter to document it
comment:4 by , 9 years ago
Claude, could you propose a patch (docs or otherwise) at your convenience?
comment:5 by , 9 years ago
#24503 was partially related.
What about:
-
docs/releases/1.8.txt
diff --git a/docs/releases/1.8.txt b/docs/releases/1.8.txt index fb0438a..c5f3e72 100644
a b Miscellaneous 1159 1159 * :func:`django.utils.translation.get_language()` now returns ``None`` instead 1160 1160 of :setting:`LANGUAGE_CODE` when translations are temporarily deactivated. 1161 1161 1162 * When a translation doesn't exist for a specific literal, the fallback is now 1163 taken from the :setting:`LANGUAGE_CODE` language (instead of the untranslated 1164 ``msgid`` message). 1165 1162 1166 * The ``name`` field of :class:`django.contrib.contenttypes.models.ContentType` 1163 1167 has been removed by a migration and replaced by a property. That means it's 1164 1168 not possible to query or filter a ``ContentType`` by this field any longer.
comment:6 by , 9 years ago
Has patch: | set |
---|---|
Summary: | Undocumented i18n behavior change in 1.8 (or a regression) → Document translation fallback behavior change in 1.8 |
Triage Stage: | Accepted → Ready for checkin |
I'd suggest "instead of from the" -- otherwise, good!
Reproduced and bisected to a5f6cbce07b5f3ab48d931e3fd1883c757fb9b45.