[Zope3-dev] translation in ZPT

[Martijn Faassen]

Hey,

I've moved this into a separate thread, as I think (unlike Jim) we're 
not done talking yet. The old thread became unmanageable. Let's reframe 
the discussion entirely and get some concepts and positions spelled out 
at least.

First, an attempt to summarize the previous discussion. I hope I don't 
get people's positions all wrong, of course:

Godefroid: message ids can now be indicated for python strings. We 
should automatically translate those when they enter page templates. 
This way we have to do less work.

Jim: no, the request to translate should be part of page templates, 
while the message id information can be either in the page template or 
in the Python string. Making translation happen automatically as soon as 
a message id is encountered can lead to problems.

I think those positions are both interesting, and I'm not convinced they 
are mutually exclusive. I'll go into why later on.

I'll use Jim's statements in the original thread to hang some of my own 
discussion on.

Jim Fulton wrote:
[snip]
> 1. Avioding typing is not an important goal

Hm, I am confused. I thought avoiding typing is an important goal. Dead 
chickens are typing, we want to avoid those, right? One important reason 
to do abstractions in programming at all is to avoid typing the same 
stuff over and over again. You could type out all functions inline, too, 
right? Typing is failure prone and slows us down. I'm speaking at 
someone who types pretty quickly here. :)

Avoiding doing the same thing twice is an important goal in programming. 
Your point in this discussion is that you're not doing the same thing 
twice. Godefroid is of the opinion that is it doing the same thing 
twice. I think we can resolve this by giving you both what you want.

So, if we can make the framework help us do less stuff, and the 
framework doesn't break down unexpectedly too often, then that may be a 
useful change to the framework, right?

> 2. You are mixing 2 different bits of information: message id data, and the
>    desire to translate on a string operation.

I think I can explain where this mixing comes from. It's quite natural 
if we look at i18n in ZPT as it is in Zope 2:

Traditionally, message_id information could *only* be in the ZPT. A 
*single* statement was used to indicate message id and the request to 
translate. It's hardly surprising people think that since the message id 
is now in Python, the indication that we want to translate can also be 
there. One could be arguing that you're splitting up a single bit of 
information: the desire to translate from the information on how to 
actually do it.

I however think it's useful in the discussion to separately identify 
such concepts. I think Godefroid understands this separation just fine 
as well, anyway.

Let's accept that the situation concerning i18n has changed quite a lot 
in Zope 3: suddenly, we have message id information that isn't in a page 
template, but elsewhere. The statement in ZPT can now have the meaning 
'please translate and use the message id in Python, if it's there' 
besides the original 'please translate and here's a message id'.

So now, we are faced with ZPT message ids, ZPT statements to indicate 
translatable content, Python i18n strings (with message ids included), 
and their interesting interactions. I think the interpretation of an 
i18n string as "translate this and here's some hints" is as valid an 
interpretation as yours, which is "if you're going to be translated, 
here's some hints". One or the other may be the better approach, or a 
third way entirely.

[Godefroid]
>> You have not told me why this was wrong.

[Jim]
> I've told you exactly why this is wrong. I'll repeat:
> 
> - It is implicit wrt translation.

Explicit is better than implicit, *except when it's not*. Godefroid is 
arguing you're already explicit about *that* it is translatable content 
in another place, and *how* to translate it, so why state it again? 
You're arguing that it is separate. As I tried to indicate those are 
both interesting positions.

Avoiding implicitness is a guideline, and one we break very often as we 
aim for avoiding dead chickens and increased convenience. It's good to 
consider the guideline, but it can be consciously broken.

> - It guesses wrong in many cases. For example, I might want
>   to output a message id as a string. With implicit translation,
>   I can't do that without anti-magic.

This surprises me, and now I'm wondering what I am missing: could you 
explain why this will guess wrong in *many cases*? I can imagine *some* 
cases (let's say, message id managers, though I'm not sure of even that 
one), but I can't really come up with many.

In the case in software where most of the time it goes one way, with 
some exceptions, an explicit way to turn *off* the behavior in the 
exceptional case is what is desirable, right?

>> You just gave an example of a very specific case where the comportment 
>> could be of a problem.
> 
> Right. And you haven't given any examples where explicitly requesting
> translation is a problem.

Let's try to talk a bit more about goals:

Godefroid is suggesting a new feature (automatic translation) which he 
believes will make translation easier and more convenient in many cases.

We are hopefully agreed that increased convenience is a worthwhile goal, 
though not at the expense of understandability or expressive power, of 
course.

Jim thinks understandability and expressive power might be at risk in 
the case of automatic translation and gives an example. Godefroid then 
asked for some more cases than this one example?

I agree with Godefroid that this would be useful information to evaluate 
the risk of introducing the convenience feature. Jim however responds in 
wanting cases where not having the convenience feature will stop someone 
from doing something they want, unless I misunderstand that.

A convenience feature however should not be evaluated by the criterion 
of it making things problematic if it's not there. It is evaluated by 
how much easier it makes things, and how by the aforementioned 
possibility of risks.

I think Godefroid's position might be summarized as the following: 
i18n:translate in the face of i18n python strings is a dead chicken; you 
need to scatter them through your ZPTs to request translation 
everywhere, even though the information on how to do it is already 
available anyway. There should be an easier way.

To distract everybody, I also came up with a set of problems concerning 
ambiguity. It's not just explicitly requesting translation that you can 
do in a ZPT; you can also come up with a message id all by yourself. In 
that case in the face of a python-based message_id, which one takes 
priority? In fact explicit message ids in ZPTs is how the translation 
feature is mostly used in Plone as far as I'm aware, so this is not an 
insignificant use case. I believe actually taking the Python message_id 
is the more confusing option of the two; I argued why elsethread.

[snip]
> As long as message ids are strings, we are not going to translate
> implicitly.  I'm open to making them not be strings, but that is a big
> change that won't happen overnight.

I don't think this is an either-or debate; let's not frame it that way. 
I think we have edge cases to discuss and possibilities left unexplored. 
Perhaps personalities got in the way of a useful debate; I know mine 
often does for sure. :)

What about a way, as I mentioned elsewhere, to mark a whole block in a 
ZPT as 'auto-translate this'? Less typing and still explicit enough I'd 
say. When you know it's safe for a whole page template, you'd mark it at 
the top; if not, you mark it for the sections you're sure about. You 
could have another way to mark a block as 'except this part' if it turns 
out you want auto-translation in all those parts except in one 
particular section.

i18n:translate could be the microlevel statement to explicitly invoke 
translation no matter what block we're in, and it could also be a way to 
explicitly supply a message id for static strings in the ZPT, and a way 
where you want to explicitly override whatever goes on on the Python 
level ('no, use *this* message id now').

Surely it's a useful feature to be able to ask for translation of all 
incoming message ids in a whole area of HTML in one go?

Regards,

Martijn