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 #1049 (closed defect: wontfix)

Opened 13 years ago

Last modified 10 years ago

i18n_filter can't translate text with python expressions

Reported by: ulysses Owned by: Chris Arndt
Priority: normal Milestone: 1.1
Component: TurboGears Version: 0.9a6
Severity: normal Keywords: i18n i18n_filter kid

Description (last modified by Chris Arndt) (diff)

Text with Python expressions inside kid template can't get translated by plain_gettext().

Kid example:

  Actual Status: ${actualStatus[0]}.

This string will generate "Actual Status: ${actualStatus![0]}." key in the .pot file, but, after translating and compiling it, it is still untranslated when showing through browser.

Tracking this bug I realize that i18n_filter function calls plain_gettext() using as key the already processed python expression. So the line above will call plain_gettext using "Actual Status: some_value" instead of "Actual Status: ${actualStatus![0]}". I think here is the problem but I can't figure out how to solve yet.

Change History

comment:1 Changed 13 years ago by jorge.vargas

  • Milestone changed from 1.0b1 to 1.0b3

comment:2 Changed 12 years ago by alberto

  • Milestone changed from 1.0b3 to 1.1

comment:3 Changed 12 years ago by alberto

  • Milestone changed from 1.1 to __unclassified__

Batch moved into unclassified from 1.1 to properly track progress on the later

comment:4 Changed 11 years ago by Chris Arndt

  • Status changed from new to assigned
  • Owner changed from anonymous to Chris Arndt
  • Description modified (diff)
  • Milestone changed from __unclassified__ to 1.1

This is actually a pretty annoying bug and I wonder why no more people complained about earlier.

When the messages are compiled by command.i18n Kid is used to parse the kid XML templates but in such a way that it is not possible to detect whether some element text content is normal text or a placeholder. I have not digged deep enough into Kid to find out if there is a proper way to do this. If all fails, we'll have to pare message strings with a regular expression and cut them into small pieces around placeholders.

This should best be fixed together with #1695.

comment:5 Changed 11 years ago by Chris Arndt

  • Component changed from Kid to TurboGears

comment:6 Changed 11 years ago by chrisz

As a workaround and the recommended "kiddy" way of doing things, you can write

 Actual Status: <span py:replace="actualStatus[0]"/>.


 Actual Status: <span py:replace="actualStatus[0]">Placeholder</span>.

comment:7 Changed 10 years ago by chrisz

  • Status changed from assigned to closed
  • Resolution set to wontfix
  • Severity changed from major to normal

As of 2009-02-15 (already since r3558, TG, the issue doesn't exist any more in this form since text containing such Python expressions is not even collected and does not appear in the .pot file anyway.

More precisely, TG has two different ways of collecting strings, namely through the toolbox and through tg-admin i18n. In the former case, the strings are collected with toolbox.admin18n.pygettext, where text containing such expressions is excluded by checking with the __contains_inline_python method. In the latter case, the strings are collected with command.i18n, and here in scan_kid_files text with inline expressions is filtered out and a "Mixed content" warning is printed.

The situation is similar with Genshi, though here in the latter case the method scan_genshi_files is used which does not skip completely over text with expressions, but keeps the non-expression parts.

So what really needs to be done is the following: Merge the two different ways of collecting strings (which both are flawed in different ways) to one way that is implemented correctly. Only then we should solve the issue of translating text with such expressions correctly.

If anybody cares to get this fixed in TG 1.x, please open a new ticket for the 1.x milestone requesting proper string collection first. In TG 2.0, string extraction is delegated to Babel anyway, so for me it does not seem worth wile to spend much time with this any more.

Note: See TracTickets for help on using tickets.