Code

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#13726 closed (fixed)

Javascript translated string catalog is empty when settings.LANGUAGE_CODE is "fr" and session variable language_code is "en"

Reported by: stodge 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: UI/UX:

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)

13726.diff (6.8 KB) - added by ramiro 4 years ago.
Patch for this issue, includes tests. See notes in ticket comment below about .mo file generation

Download all attachments as: .zip

Change History (6)

comment:1 Changed 4 years ago by thejaswi_puthraya

  • Component changed from Uncategorized to Internationalization
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 4 years ago by ramiro

  • Triage Stage changed from Unreviewed to Accepted

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.

Changed 4 years ago by ramiro

Patch for this issue, includes tests. See notes in ticket comment below about .mo file generation

comment:3 Changed 4 years ago by ramiro

  • Has patch set

The patch added makes the following changes in the jsi18n view code to consider the use case presented in this ticket:

  1. 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. *
  2. 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 Changed 4 years ago by jezdez

  • Resolution set to fixed
  • Status changed from new to closed

(In [14901]) Fixed #13726 -- Further refine changes made in r12384 and r13069 for using non-English source languages in JavaScript translation catalogues. Thanks, Ramiro.

comment:5 Changed 4 years ago by jezdez

(In [14911]) [1.2.X] Fixed #13726 -- Further refine changes made in r12384 and r13069 for using non-English source languages in JavaScript translation catalogues. Thanks, Ramiro.

Backport from trunk.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.