Re: Bricolage: Impressive - Mailing list pgsql-www
From | David Wheeler |
---|---|
Subject | Re: Bricolage: Impressive |
Date | |
Msg-id | E1C136F9-49DE-11D8-8158-000A95972D84@kineticode.com Whole thread Raw |
In response to | Re: Bricolage: Impressive ("Marc G. Fournier" <scrappy@postgresql.org>) |
Responses |
Re: Bricolage: Impressive
|
List | pgsql-www |
On Jan 17, 2004, at 9:47 PM, Marc G. Fournier wrote: > David, can you add some input into this? The thread starts: > > http://archives.postgresql.org/pgsql-www/2004-01/msg00188.php Ah, a new list and a new world. Thank you for alerting me to this, Marc. I agree that Bricolage would be an excellent solution for TechDocs and other Pg sites; Steve's comments are right on target. I also agree that I18N can be tricky. Here's the deal. The World Health Organization uses Bricolage to manage its Web site, www.who.int. The WHO mandates that all of its content be published in five languages: English, Spanish, French, Chinese, and one other I can't remember right now (Russian?). Currently, the Web site is published in English, French, and Spanish only; the other languages will be added later. Here's how they do it. You'll recall that Steve said that you can define fields for Bricolage document types, such as "Paragraph", "Header", or "Code". What WHO does is have three versions of each of these (well, not Code): "English Paragraph", "English Header", "Spanish Paragraph", "Spanish Header", "French Paragraph", and "French Header". The documents are originally authored in one language, say French, and then translators translate them by adding the appropriate fields. The result is something like this: =en_paragrah Hello. =es_paragraph Hola. =fr_paragraph Bon jour. And yes, there is an editing interface that uses this approach--POD-like tags to indicate fields--which makes editing much easier than using discreet textarea fields. The downside to this approach, however, is that the documents can get rather unwieldy. Ordering can also be tricky. And of course, the templates have to know what they're outputting and where. An alternate solution is to clone a document. This creates a completely separate document that can then be translated. So if document was originally written in French, a translator would clone it, and then convert the cloned version's contents into Spanish. A separate clone would be used for English. This approach makes the documents much more wieldy, and the templates don't have to be as intelligent. The disadvantage of course is that the translations are actually independent documents. This may be okay in some environments, but others might prefer that they all stick together. This might be because someone makes a change to the French original, and then wants to send it to the Translation desk to ensure that the English and Spanish translations are likewise updated. OTOH, one might just send it to the Translation desk, and then it's up to the translator to find the right clones and update them. Anyway, these issues are a big raison d'être for Bricolage 2.0, which is currently in the early stages of development. You can read about the design docs here: http://www.bricolage.cc/docs/design/ElementRevision.html One of the major new features of Bricolage 2.0 is "Input Channels". Input channels allow a single document to have different channels for input for its content. So, for example, a document might have "English", "Spanish", and "French" input channels--or more, as many as you define. Then, when a user checks out a document, she can just switch channels to see the different input for those channels. This keeps all of the translations together in a single document, but is far more wieldy than the solution currently used at WHO. Unfortunately, Bricolage 2.0 is probably a good 9-12 months away. Folks who wish to help with the development would be most welcome! Just subscribe to the bricolage-devel mail list and ask how you can help. http://sourceforge.net/mail/?group_id=34789 In the meantime, the approaches I mentioned above may get you where you need to go. For better or for worse, I don't think there are good multi-language document solutions in any CMS. I suspect that Bricolage 2.0 will be first in its class in this respect, all others having solutions similar to the workarounds we use for Bricolage 1.x. HTH, David -- David Wheeler AIM: dwTheory david@kineticode.com ICQ: 15726394 http://www.kineticode.com/ Yahoo!: dew7e Jabber: Theory@jabber.org Kineticode. Setting knowledge in motion.[sm]