[Zope3-dev] Re: RFC: undeprecate auto-message id translation

[Philipp von Weitershausen]

Jim Fulton wrote:
> I still don't like the implicit translation of message ids,

I thought like that, too. You really would want implicit translation of
message ids, though, not because implicitness is the right choice here,
but because of general separation of concerns. This is along the same
lines as the domains issue you also mention: The template author has and
should have no control over what he's getting in, the i18n: tags only
affect the ZPT source, like you say.

The i18n domain setting is a good example, another good one is variable
interpolation. The template author might not care about i18n but reuse a
message id from somewhere that uses variable interpolation and has a
mapping with values. Unless translation is turned on, the ${variables}
won't be interpolated with the values from the mapping. So, even though
the template author doesn't care about i18n, he still has to use
i18n:translate="" to trigger variable interpolation.

> If we do this, then it would be tempting to deprecate allowing 
> i18n:translate to be used in combination with tal:content or
> tal:replace, however, it is still appropriate to use i18n:translate
> in combination with tal:content if there is a chance that the default
> would be used.

Good point.

> We need to stop thinking about Zope 3 ZPT vs Zope 2 ZPT and switch to
> having one ZPT used by both.

+10

It is crucial that we switch soon. It's not only a p.i.t.a. to maintain
two different implementations, the gap between the two implementations
also gets wider by the minute. Switching over PageTemplateFile shouldn't
be too hard, it gets trickier with persistent PageTemplate objects and
forward compatibility of the pickles. Of course, everything has to be
switched over at once because of macro incompatabilies between Zope 2
and 3 implementations... Oh boy...

Philipp