Philipp von Weitershausen wrote:
Stephan Richter wrote:
On Friday 06 May 2005 10:11, Dmitry Vasiliev wrote:
Opinions?
Dimitry, I am sorry. There was already a papal's edict on the issue:
http://mail.zope.org/pipermail/zope3-dev/2004-September/012186.html
That means, message ids must be translated explicitely using
i18n:translate. So, Dimitry, you can go ahead and deprecate the
implict tranlation of message ids.
Great. I guess that also means backing out most of r30249.
Yes, and I pretty sure that we'll found much more cases of implicit
translation.
Btw, I dug through the thread and found an 'interesting' edge case that
we might want to look into as well. Imagine you have
<span tal:content="view/getMeSomeI18nMessage"
i18n:translate="explicit_message_id"
/>
IMO, this shouldn't happen, meaning it should be a syntax error to use
tal:content and an explicit message id in i18n:translate in the same
tag. Maybe this was already fixed, but I would guess not.
The fix will be trivial anyway.
A note about the edict:
The edict doesn't rule out a change of semantics, provided it was
written out in a proposal. For example, thinking about the above edge
case, it struck me that i18n:translate is really used for two things:
a) Translating a static string in the template
<p i18n:translate="heading-greeting">Greetings, user!</p>
b) Translating a message id coming from Python code:
<p tal:content="view/getAnI18nMessage" i18n:translate="">...</p>
So, i18n:translate has two different semantics, depending whether you're
using it for case a) or b). In case b), for example, stating an explicit
message id is nonsense, as I've stated in the edge case above.
So, here's an idea: Let's limit the use of i18n:translate to case a) and
introduce i18n versions of tal:content and tal:replace that mean "insert
the message id and translate it". It would look like that:
<span i18n:content="view/getAnI18nMessage">...</span>
instead of
<span tal:content="view/getAnI18nMessage" i18n:translate="">...</span>
The latter would be deprecated/forbidden. That would get rid of any
ambiguity regarding i18n:translate and thus also a lot easier for
message id extraction tools. They wouldn't collect false message ids
anymore.
Also, we could even require the input of i18n:content to always be an
i18n message id. So, if view.getAnI18nMessage() return a mere string, it
wouldn't be translated. But maybe there are use cases against this.
It wouldn't be translated anyway since i18n:content will be only translation
phase and we can't define a msgid for dynamic content, we just can pass the
string through or raise an error/warning.
Thoughts?
I like the idea and I'm ready to implement the proposal, but I like to do it
after 3.1 will be released.
--
Dmitry Vasiliev (dima at hlabs.spb.ru)
http://hlabs.spb.ru
_______________________________________________
Zope3-dev mailing list
[email protected]
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
