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

Robert Rottermann robert@redcor.ch
Tue, 3 Jul 2001 07:32:49 +0200


Sounds as if I have to look at ZBabel more closely.
The test whether it is up to its task will be whether it can translate pages
like the metadata_edit_form to a couple of European languages without
touching the dtml-code.
Your idea of  adding a translate modifier to the translate tag appeals to
me. This can be done with search and replace!

But then again. I rather go for a solution that is not to perfect but has
the support from our friends living across the big water.

Robert

----- Original Message -----
From: "Joachim Werner" <joe@iuveno-net.de>
To: "Robert Rottermann" <robert@redcor.ch>; <zope-cmf@zope.org>; "Juan David
Ibáñez Palomar" <palomar@sg.uji.es>
Cc: "Stephan Richter" <stephan@iuveno-net.de>
Sent: Tuesday, July 03, 2001 1:39 AM
Subject: Re: [Zope-CMF] How to translate CMF, first summary


> > 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.
>
> You really should have a look at ZBabel. It CAN translate the above
because
> you can use placeholders in your translations. It looks like that:
>
> de: "Der Status des Elementes ist: <<<1>>>"
> en: "This item is in <<<1>>> state"
>
> > 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 ZBabel you translate a screen only once (into an
> internationalized/tagged version). Later, you just have to fix bugs in the
> internationalized DTML or Python code. The translation is kept untouched
as
> long as you don't have to change the actual phrases.
>
> > 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.
>
> That's a good point. But it can be solved by providing a good front-end to
> the translator that maybe displays the context with the string to be
> translated.
>
> > 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.
>
> Again, that is what ZBabel (and also the gettext-based Localizer) are
doing
> already ...
>
> > 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.
>
> We even put the ZBabel translation engine into the var tag. The only
problem
> with that was that virtually everything was translated, sometimes a couple
> of times, as <dtml-var> might call methods that call methods etc. ZBabel
> even started translating its variables, which leads to recursion problems.
> But the code is there, and the only thing needed to make it really cool
> would be adding some additional attribute like this:
>
> <dtml-var variablename translate>
>
> But such a syntax is not any better than using ZBabel's own tags as long
as
> the syntax is not officially accepted. It would break all existing code
when
> it is used with a Zope instance that does not have ZBabel installed.
>
> Joachim
>
>