Ticket #1399 (closed defect: fixed)

Opened 3 years ago

Last modified 2 years ago

[PATCH] Default behaviour of i18n changed with 1.0.2.2 (for the worse)

Reported by: Puck Assigned to: anonymous
Priority: normal Milestone: 1.5
Component: TurboGears Version: 1.0.2
Severity: normal Keywords:
Cc:

Description

Hi all,

the behaviour of i18n changed (presumably) with 1.0.2.2. Previously, the msgid was used as localized version, if no msgstr was supplied in a .po file, which is a very reasonable behaviour in my eyes.

To reproduce the problem

  • quickstart a new project
  • add 
    session_filter.on = True
i18n.run_template_filter = True
    to your configuration
  • tg-admin toolbox, in toolbox
    • click on link admi18n
    • click on link Collect your strings
    • click on Collect Strings... button
    • click on link Manage your languages
    • add de as language
    • add en as language
    • click on edit de
    • supply an alternative string ("Wilkommen") for the last entry "Welcome to TurboGears", which is the page title
    • click on the little "save" checkmark; your alternative string should appear as german translation
  • do a tg-admin i18n merge
  • do a tg-admin i18n compile
  • start the application
  • fire up your browser, set german as preferred language, browse the start url of the application - "Willkommen" will be shown as browser title
  • change the preferred language, reload the page - the title does not change
  • to show that the en language file is read, you can supply an alternative msgstr in the english messages.po file, do a tg-admin i18n compile

Best regards

Puck

Attachments

msgfmt_patch.diff (421 bytes) - added by gremat on 08/06/08 11:49:58.

Change History

06/08/07 09:25:54 changed by chrisz

I can reproduce that, but it seems the behavior did not change since r2259 (between 0.9a9 and 1.0). Which version did you use before?

I think the problem is that you added an English locale without editing it in the first place. If you just don't add an English locale at all, you should get your expected behavior.

06/10/07 03:06:33 changed by Puck

Hi Chris,

that's kind of strange ... as I'm still very new to python and turbogears, I've only used the "official" downloads 1.0, 1.0.1 and 1.0.2.2. I can't really say when the change in i18n took place, just that it did - we were lazy with supplying German translations for our webapp and were very happy to see the occasional "Benutzer" instead of user. We then had a translation sprint and supplied all the neccessary text blocks. Then we stopped caring about translations and only recently realized that the original English texts were not appearing any more.

I'll try to delete the English locale all together, to see whether that works.

Best regards,

Puck

07/01/07 18:32:03 changed by faide

  • milestone changed from 1.0.3 to 1.1.

Is this issue what Chris implied ?

08/06/08 11:49:58 changed by gremat

  • attachment msgfmt_patch.diff added.

08/06/08 12:09:46 changed by gremat

  • summary changed from Default behaviour of i18n changed with 1.0.2.2 (for the worse) to [PATCH] Default behaviour of i18n changed with 1.0.2.2 (for the worse).

The problem is in the \turbogears\toolbox\admi18n\msgfmt.py file, which is responsible for compiling language catalogs. The module defines a global dict MESSAGES which collects all the msgids and corresponding strings. The dict is never cleared, however, which means that if more than one language catalogs are compiled in succession, key-value pairs of the previous language remain in the dict.

In the ticket description example, the de catalog is compiled first. This leaves the key-value {"Welcome to TurboGears": "Wilkommen"} in the global MESSAGES dict. The en catalog is compiled second. Because it doesn't include a value for the "Welcome to Turbogears" msgid, the "Wilkommen" value is never overridden and it gets compiled into the en .mo file, which of course shouldn't happen.

A simple solution is to clear the MESSAGE dict every time before starting a compilation.

08/06/08 15:12:17 changed by chrisz

  • status changed from new to closed.
  • resolution set to fixed.

Thank you. Patch was applied together with some code clean-up in r5106.