Strings containing escape chars are not properly translated #133

Closed
wants to merge 2 commits into
from

Projects

None yet

2 participants

@jinty
Contributor
jinty commented Nov 8, 2012

This currently fails because escaping is applied before translation. Meaning untranslated strings as the msgids in the ,po files don't match what gets sent to the translate function :(

Unfortunately I only have time right now to provide a failing test case, will look for the bug if time allows and no-one gets there first...

@jinty jinty A test for translating strings containing escape chars
This test currently fails because escaping is applied
before translation.
a96d5a7
@malthe
Owner
malthe commented Dec 5, 2012

Sorry, I haven't seen this one before now.

@malthe malthe was assigned Dec 5, 2012
@malthe
Owner
malthe commented Jan 14, 2013

I don't agree: 48868c2.

I could be wrong, but this isn't how i18n:translate works. But note that in your example, ${text} means that whatever string is in text will be escaped. If you wanted this to be different, put ${structure: text}.

But i18n:translate is XML-agnostic. It doesn't know about it.

@jinty
Contributor
jinty commented Jan 14, 2013

I had another look at my test, I guess I wasn't being very clear. I've updated it with one that passes but still shows what I think is an inconsistency.

I had naively expected this template: <tal:tag i18n:translate="">hello <span i18n:name="world" tal:replace="world"/></tal:tag> to be exactly the same as <tal:tag i18n:translate="">hello ${world}</tal:tag>. It appears as if it they are not the same. That makes the second syntax something to avoid as the way it mixes with translations is not very intuitive.

Not sure this is a bug though, so feel free to close this pull request if you aren't going to take any action.

@malthe
Owner
malthe commented May 15, 2013

In the default translation mode (explicit), the fact that your expression ${world} looks like an i18n:name (i.e. an identifier) does not mean that it's automatically turned into one.

But it could be that way. The problem is that e.g. ${world.upper()} isn't an identifier and then you'd have to explicitly assign it an i18n:name (such as "world"). While often times a tal:replace is simply an identifier (or variable), it's also often a non-trivial expression such as item.title.

There's such a thing as implicit translation mode with Chameleon. It's easy to enable:

implicit_i18n_translate = True

With implicit translation, you don't need i18n:translate. But it might make implicit choices you don't agree with.

@jinty
Contributor
jinty commented May 15, 2013

I'm closing this pull as "wontfix" so it doesn't add to the clutter.

I understand the issue now and guess I'll just stick to the verbose tal:name syntax for translation heavy apps. I definitely prefer explicitness :)

Many thanks for taking the time to explain what's happening.

@jinty jinty closed this May 15, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment