[Zope-CMF] How to translate CMF, first summary

Mon, 2 Jul 2001 00:23:25 +0200

Juan,
I agree with you that each "profession" the designer the programmer and the
translator has to be able to work independently of the rest of the bunch.
This is easy where the visual appearance of the output is of low importance
and only the
message put forward to the user counts. Such is the case where a message is
risen to indicate an error condition or where we use one word menu entries.

But as soon text to display and html code is intermingled things become
tricky.

The following sentence has to be rearranged when translated to German:

<p>This item is in <b>&dtml-review_state;</b> state.</p>
becomes:
<p>Der Status des Elementes ist : <b>&dtml-review_state;</b></p>

This only works when I translate Text and html code together. I can not
separate the two.
This is what I call to translate screen wise.(not all situations are that
straightforward the code might be some paragraphs long)
(is tere an other way to do it ??)

With former translations I was involved with we applied two different
strategies to the solution of this problem. The first one was to tag all
text that was eventually displayed to the user, and batch translated it.
This we used where dynamic translation was not possible.
The other one was to wrap the text in a function call and translate it at
run time.
This of course is "sentence wise translating".  However, the situation was
different in that we did not translate HTML-code but C++ and VB where any
formatting is separated from the text.
And more importantly: It was VERY! hard for the translator to do his job
when he got a couple of thousand pieces of text of which he did not know the
context.
You must know the context to translate. So we are back to translate screen
wise.

The only translating support I can imagine is wrapping "candidates to
translate" into function that render the text translated. (I do not yet
grasp the workings of your approach (building on pythons gettext facility)
but I understand it also wrapps sentences in function calls.)

So the question is who does such wrapping and more importantly will it pay
off.

Will DC do it?
We know their enthusiasm towards such maters. It does not exist.
This is understandable for two reasons. First with making Zope easy
translatable DC does not gain anything with their customers. And secondly DC
is an American company. I believe Americans just have a poor approach
towards such matter. I do not mean that in any way cynical it is just a
question of why should they. Understandably American companies only start to
worry about translation when a significant part of their business comes from
non English speaking countries. And since DC does not ...

Second question: Is it worthwhile to have everything the user eventually
sees wrapped in function calls.
My opinion is no!
I do not mean we should not have any help by DC. However it is enough to
wrap DTML-calls that render a text to display in a function call that
translates them. So instead of  <dtml-var review_state> <dtml-var
"translate(review_state)">. Furthermore all raise statements that render a
displayable text should also be wrapped in such a function. There are a
couple of more things to do but for CMF it would sum up to work for about a
day.

Which I believe they would invest happily.

What would we gain?
To translate CMF did cost us only a few days. This includes translating all
dtml-files and writing functions to translate the action box entries and
similar things.(I will still find some things that are not yet perfect.) A
significant part of the time went into hunting for things we missed or
misinterpreted. The actual translating was less than a day.
I believe that with that little help from our DC friends I can reduce the
time needed to do an adaptation of CMF 1.1 to CMF 1.2 within less than a
day.
This might not include new things. But no matter what translating facility I
have I need to do the first translation anyhow.
The time needed I mentioned above does not include testing. However this
task amounts to about the same what method we might use.

Conclusion:
We need to persuade DC to add translation hooks as I mentioned, and do the
dtml translation by hand.

Robert

----- Original Message -----
From: "Juan David Ibáñez Palomar" <palomar@sg.uji.es>
To: <zope-cmf@zope.org>
Sent: Sunday, July 01, 2001 10:45 AM
Subject: Re: [Zope-CMF] How to translate CMF, first summary

> >
> > There were also some statements regarding the advantage of translating
> > sentences versus translating screens. The main argument was that
translating
> > sentences helps to avoid translating the same sentence more than once.
> > My points against this reasoning (stemming from my experience with
preparing
> > the translation of many non Zope programs) is that not so many sentences
are
> > repeated.
> >
>
> No, in my opinion the main advantage of sentence by sentence translation
> is that the logic/presentation and the translations are separated. This
> has two benefits: the programmer writes the code, the designer builds
> the user interfaces and the translator translates; all of them use
familiar
> tools, the translator could use the same tools to translate for example
> a GNOME application or a Zope product (if Zope supported the same de facto
> standard of course) and don't needs to know anything about the technology
> (DTML, ZPT, Python, ...).
>
> The other advantage is that the update of the translation to a new
> version of the software is easier since usually most of the senteces
> remain unchanged.
>
> Some time ago there was an important effort to translate Zope using
> zzLocale, a product that follows the approach to translate screens.
> It was Zope 2.2, but then Zope 2.3 was released which made important
> changes in the web interfaces, and the work was lost.
>
> Sentence by sentence translation should be used in the web interfaces
> and in the messages returned by Python code.
>
> But other parts, for example the on-line help system, should use a
> different approach, one file per language.
>
>
> Best regards,
> jdavid
>
> _______________________________________________
> Zope-CMF maillist  -  Zope-CMF@zope.org
> http://lists.zope.org/mailman/listinfo/zope-cmf
>
> See http://www.zope.org/Products/PTK/Tracker for bug reports and feature
requests
>