Skip site navigation (1) Skip section navigation (2)

Re: Bricolage: Impressive

From: David Wheeler <david(at)kineticode(dot)com>
To: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
Cc: Steve Simms <steve(at)deefs(dot)net>,Peter Eisentraut <peter_e(at)gmx(dot)net>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>,PostgreSQL Web Development Mailing List <pgsql-www(at)postgresql(dot)org>
Subject: Re: Bricolage: Impressive
Date: 2004-01-18 17:51:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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:

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, 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 






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:

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.

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.



David Wheeler                                     AIM: dwTheory
david(at)kineticode(dot)com                              ICQ: 15726394                     Yahoo!: dew7e
                                                Jabber: Theory(at)jabber(dot)org
Kineticode. Setting knowledge in motion.[sm]

In response to


pgsql-www by date

Next:From: Marc G. FournierDate: 2004-01-18 18:51:00
Subject: Re: Bricolage: Impressive
Previous:From: Robert TreatDate: 2004-01-18 17:06:26
Subject: Re: Bricolage: Impressive

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group