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]


pgsql-www by date:

Previous
From: Jan Wieck
Date:
Subject: Re: [press] UltraSQL for Windows released
Next
From: Justin Clift
Date:
Subject: Entry for the front page?