[Zope3-dev] translation in ZPT

Wed Sep 29 12:52:21 EDT 2004

Hey,

I've moved this into a separate thread. The old thread became unmanageable.

[I said, but then I didn't. So now I will anyway, with a small edit as 
Jim evidently does not think we're done talking yet either, just wants 
to reorganize the discussion.]

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
_______________________________________________
Zope3-dev mailing list
Zope3-dev at zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/faassen%40infrae.com