Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #1399 (closed defect: fixed)

Opened 10 years ago

Last modified 9 years ago

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

Reported by: Puck Owned by: 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 Download (421 bytes) - added by gremat 9 years ago.

Change History

comment:1 Changed 10 years ago 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.

comment:2 Changed 10 years ago 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

comment:3 Changed 10 years ago by faide

  • Milestone changed from 1.0.3 to 1.1

Is this issue what Chris implied ?

Changed 9 years ago by gremat

comment:4 Changed 9 years ago 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.

comment:5 Changed 9 years ago 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.

Note: See TracTickets for help on using tickets.