Announce: ZBabel a Translation Assistant for Zope
Some people have been bugging me to release this so here we go:- http://www.zope.org/Members/TheJester/ZBabel/ The doco is shambolic to say the least, and there are no examples at the moment and no list of what hooks are available. It does not automatically translate for you, it assists you to build a multi-lingual site once, and then maintain it in different languages, rather than building it once for every language (or rebuilding the same thing over and over). It does however make it pretty easy to get things going fairly cheaply. There is a trade off between resuable phrase lengths and making phrases unambiguous that you have to deal with. If it breaks, you get to keep both bits. Readme Excerpt: ------------------------------------------------------------------------ This is the ZBabel Translation System for ZOPE, the Z Object Publishing Environment (http://www.zope.org/) This is a phrase by phrase translation system, it allows you to translate key parts of your site, and the content if you desire. With this you don't need to maintain seperate source for each supported language, or mix different languages in your source. You can do your entire site in one language and then translate it without re-editing the source code. This system also automatically creates the catalogs as you go, you do not need to manually insert text strings into databases for translation. ZBabel comes as a two part kit, to help you with translating your ZOPE Content. The first part is the tag <dtml-babel> which allows you to register and translate your phrases. The second part is a the ZBabel Tower Product. This is a Folderish Object that does most of the legwork. You will need a ZBabel Tower Product installed somewhere that your documents can acquire it if you want translations to occur. If you do not install the product, the <dtml-babel> tag will simply return the existing text. -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068 |akm@theinternet.com.au|
Thanks for "ZBabel". I've only just downloaded it and haven't played with it yet, but from just reading through, it looks like it will be a great approach! http://www.zope.org/Members/TheJester/ZBabel/ One thing I'm not clear on, which you might want to deal with in future releases, either by documenting what wasn't obvious to me, or by adding a separate layer, is how to deal with "Composite Strings". Often a "phrase" that will need translation is a concatenation of more than one text string with embedded dynamically generated parameters, such as a date, name, price etc. In different languages the actual ordering of the concatenated elements may differ and the structure of the destination language may even result in a different number of text strings to translate than for the source language. Often the original author of a dynamically generated web page will be tempted to use a repeated string for common parts of different UI strings, which cannot in fact be translated that way for other languages. Unless there is some provision for that in the management interface for translation, and the documentation, page authors are very likely to assume they have internationalized something when they haven't, because they may concatenate ZBabelized strings themselves. See for example: http://msdn.microsoft.com/library/default.asp?URL=/library/books/techlang/de vintl/D3/S24AA.HTM I would imagine that Zope is ideally suited to using some sort of class for each composite, with properties for the phrase identifier and the constituent dynamically generated parameters, and leaving it to the specific translation to determine the number and positioning of the elements required. Is that already taken into account somehow by allowing the embedding of DTML within the text phrase to be translated? Also worth thinking about for a future release, is the integration of this with layout considerations. Other languages often require 50% more space than english when translated and this results in layout problems after translation. Reasonably precise formulae are available for what to expect, depending on the length of the string and the source and destination languages. I would imagine that Zope would also be ideal for automatically generating the maximum of this for the acquired set of expected future translations and returning it as a parameter that could be used with dynamic layout. 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 about DTML at all, yet still make it easier for scripters to integrate their translatable content with DTML as well as integrating with HTML layout).
+----[ Albert Langer ]--------------------------------------------- | | Thanks for "ZBabel". I've only just downloaded it and haven't played with it | yet, but from just reading through, it looks like it will be a great | approach! Ta. | One thing I'm not clear on, which you might want to deal with in future | releases, either by documenting what wasn't obvious to me, or by adding a | separate layer, is how to deal with "Composite Strings". Often a "phrase" | that will need translation is a concatenation of more than one text string | with embedded dynamically generated parameters, such as a date, name, price | etc. In different languages the actual ordering of the concatenated elements | may differ and the structure of the destination language may even result in | a different number of text strings to translate than for the source | language. I'm not a linguist nor do I play one on TV d8). This system is obviously not ideal for very dynamic content, what it is useful for is as you describe below, UI elements. Dates, and currency, time etc are usually best handled by fixed catalogs (usually provided by the operating system) where sort orders etc are already well defined and well handled. You can usually change your locale on the fly before calling the routines that require a known locale to function correctly. | Often the original author of a dynamically generated web page will be | tempted to use a repeated string for common parts of different UI strings, | which cannot in fact be translated that way for other languages. You must be disciplined and try to include as much context as possible, especially when your source language is going to be something as crappy as English is. Generally it pays not to be lazy when it comes to translating, and it also pays to have a good thesaurus on hand for replacing really common words with multiple meanings like 'bank' which annoying for having three common meanings. | I would imagine that Zope is ideally suited to using some sort of class for | each composite, with properties for the phrase identifier and the | constituent dynamically generated parameters, and leaving it to the specific | translation to determine the number and positioning of the elements | required. | | Is that already taken into account somehow by allowing the embedding of DTML | within the text phrase to be translated? 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. | 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 about | 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. -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068 |akm@theinternet.com.au|
[Andrew] 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. [Albert] 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 someVar: '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>, please' 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 about | DTML at all, yet still make it easier for scripters to integrate their | translatable content with DTML as well as integrating with HTML layout). [Andrew] 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. [Albert] 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 translator. 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
+----[ Albert Langer ]--------------------------------------------- [Charset iso-8859-1 unsupported, filtering to ASCII...] | [Andrew] | 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. | | [Albert] | 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 | someVar: | | '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' Aha! This is not translation d8) This is re-wording and then translating, which is a bit of fine hair splitting I know. If you reached a point where something couldn't be translated, you would have to revisit the source. | 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>, | please' | | depending on the particular value of someVar at the time. | | Does ZBabel allow this? If so, that's *exactly* what I was hoping for. I think it does what you want to do... <dtml-babel src="langA" dst="langX"><dtml-var GreetAndLink></dtml-babel> GreetAndLink... Click <a href="&dtml-langXUrl;"> For <dtml-var AJollyRogering> You would end up with the following to be translated:- Click <a href="the.langx.url"> For a good langX clicking So you would end up with a phrase that would be partially translated ready for translating because your langXUrl and AJollyRogering already do some localisation. However if langXUrl and AJollyRogering are dynamic you should probably not wrap them in <dtml-babel> tags. | [Andrew] | 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. | | [Albert] | 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 | translator. You can do this by nesting <dtml-babel> calls... <dtml-babel><dtml-babel>Click here</dtml-babel> <dtml-babel>for Zope</dtml-babel></dtml-babel> Would yield the following to be translated:- o Click here o for Zope o Click here for Zope | 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. This is another project... d8) -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068 |akm@theinternet.com.au|
participants (2)
-
Albert Langer -
Andrew Kenneth Milton