Yes you can embed DTML inside the block and it will resolve all of the
DTML before translating the result. You can turn this behaviour off.
This is why I opted for a container tag, rather than a simple tag.

That is what I am still not clear on. Noticed the container, but still
confused about "literal" and about "before", "after", "off" and "on".

Suppose web site in source language has something like this:

'Click <A href="{fieldX(someVar.A)}">here</A>, for {fieldY(someVar.B)}'

With suitably horrific DTML instead of ' ' and {}.

Rendered english result would be, for some particular dynamic instance of

'Click <A href="http://www.zope.org/">here</A> for Zope'

Translator for language X decides to reverse the positions of fieldA and
fieldB and use 3 separate substrings, because it is too abrupt for that
language, so translates to something like:

'If you would like {fieldY(someVar.B)}, click <A
href="{fieldX(someVar.A)}">this link</A>, please'

There are now 3 substrings in the translation because it would be rude not
to start or end with something like "please" in language X, and it reads
better with the fields reversed in that language.

Final rendered result becomes (in language X):

'If you would like Zope, click <A href="http://www.zope.org/">this link</A>,

depending on the particular value of someVar at the time.

Does ZBabel allow this? If so, that's *exactly* what I was hoping for.

(Naturally it is up to the classes for fieldY and fieldX to do their own
thing, and localize it if its a date or currency etc, not up to ZBabel).

| Finally, is there some way that the "magic" behind Zwicki structured text
| formatting could be used, to allow an author to just write the phrase in
| their own language and automatically generate related DTML tags for
| parameters etc?
|  (Rather vague idea I know, but somehow make it easier for
| people just writing content, like Zwiki contributors, to know nothing
| DTML at all, yet still make it easier for scripters to integrate their
| translatable content with DTML as well as integrating with HTML layout).

I have another project on my TO DO list which is a dynamic components
product which this would integrate well with.

Any "Form Generation" products would probably be able to integrate
the same stuff as well fairly easily.

It is rather intrusive I know, but, there are few if any options that
don't require massive amounts of effort to achieve the same thing.
Especially building the catalogs. I know of another ASP based system
that's pretty much the same as this, but, they have to go through
and change the source code after translating (they have to provide a
dummy 'phrase id' which is then altered). It is really really ugly.

The lack of a dummy "phrase id" is what I thought was really great about
your approach. Thanks!

I regard HTML/DTML as possibly avoidable clutter in the same way that a
"phrase id" is.

If ZBabel already does what I asked above, my question about something
closer to Zwiki structured text might be more clear in terms of wondering
whether anything can be done to hide the HTML/DTML tagging and field coding
from the translator by giving them some sort of template like this:

'Click [here] for {Zope}'

So that they would translate it to:

'If you would like {Zope} click [this link[here]], please'

Note that the two original substrings of ordinary text AND the [bracketed]
text all denote elements to be translated, while the text in {braces} does
not, but is sample data visible in the UI as a prototype example for the

Then the magic which extracted the HTML (and DTML) tagging and field names
etc to give the translator something more understandable, would just stick
it back in, replacing "here" with "this link", but ALSO restoring the
surrounding DTML/HTML for that element and for the {Zope} element, in much
the same way that you already do not need a "phrase id" but work directly
with the text. Translators understand prototypes much more easily than they
understand web pages.

(Also useful for content managers cf HTML/DTML designers and convenient for
HTML/DTML designers too ;-).

Any possibility of doing that automatically? By clicking "generate
template", a web developer might be able to generate simplified template
strings like above for the translator, using a sample prototype from actual
data. Then, when the translator has processed it, a web developer or content
manager could just click "import translation".

Otherwise either the web developer might still need to generate such
prototypes manually to make life easier for translators, or the translators
need to understand some HTML/DTML as well as understanding translation.

Seeya, Albert

Zope maillist  -  [EMAIL PROTECTED]
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-dev )

Reply via email to