+----[ 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|