#13726 closed (fixed)
Javascript translated string catalog is empty when settings.LANGUAGE_CODE is "fr" and session variable language_code is "en"
| Reported by: | Mike | Owned by: | nobody |
|---|---|---|---|
| Component: | Internationalization | Version: | 1.1 |
| Severity: | 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 LANGUAGE_CODE set to "fr" in settings.py. If the session variable "language_code" is also set to "fr", my javascript catalog correctly contains all of my French strings.
If I then change the session variable "language_code" to "en" and reload my page, the javascript catalog is empty and my string IDs are displayed instead.
If I change LANGUAGE_CODE to "en" in settings.py, the javascript catalog is correct when the session variable "language_code" is "en" and "fr", and my translated strings are all displayed correctly.
This definitely seems to be a bug in Django 1.1.2.
Attachments (1)
Change History (6)
comment:1 by , 14 years ago
| Component: | Uncategorized → Internationalization |
|---|
comment:2 by , 14 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
by , 14 years ago
| Attachment: | 13726.diff added |
|---|
Patch for this issue, includes tests. See notes in ticket comment below about .mo file generation
comment:3 by , 14 years ago
| Has patch: | set |
|---|
The patch added makes the following changes in the jsi18n view code to consider the use case presented in this ticket:
- Toggles the logic to decide the English translation is missing. Currently if any of the packages listed as providing JS translations has no English translation then it is decided that no English translation is available at all. The patch changes that to flag there is an English translation if at least one of the packages provides one. *
- Separates the tracking of such flag from the fact that English is the language selected by the user via preferences. This way we can properly handle the scenario of a non-English original language with the user asking for English translation and handle it just like any other translation provided the relevant .po/.mo files exist.
This could be considered a further refinement to r12384 and r13069. No previous regression tests get broken by it.
Should this patch be applied, the tests/regressiontests/views/app0/locale/en/LC_MESSAGES/djangojs.mo file needs to be previously generated and included as part of the commit.
- Maybe we should consider tracking this
'en'translation availability status per-package?
comment:4 by , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
This is actually an intended behavior as of now. See the test for this: http://code.djangoproject.com/browser/django/trunk/tests/regressiontests/views/tests/i18n.py?rev=13250#L72
The dostring of that tests says: Check if the Javascript i18n view returns an empty language catalog if the default language is non-English but the selected language is English. See #13388 and #3594 for more details.
See r12384 and r13069.
I suspect the OP has at least one of the packages listed ad providing JS translatable literals has no
'en'catalog. Could you please confirm this?It seems we have contradicting requirements between these tickets. The use case described by the OP seems like a valid one.