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

Re: Bricolage: Impressive

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

what I'd like to see is a built in search facility, so once document
has approved for publication, it could be searchable. It's nice feature
and we use it in our CMS (also, Mason based) and PostgreSQL has
contrib/tsearch2 (I'm one of the authors) and OpenFTS as a middleware,
so I don't see any problem to add search to Bricolade.

This will solve problem with search engine if -www
will decide to go with Bricolade.

On Sun, 18 Jan 2004, David Wheeler wrote:

> 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
> 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:
> 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.
> HTH,
> David

Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg(at)sai(dot)msu(dot)su,
phone: +007(095)939-16-83, +007(095)939-23-83

In response to


pgsql-www by date

Next:From: Dave PageDate: 2004-01-19 12:06:02
Subject: Re: Bricolage: Impressive
Previous:From: Devrim GUNDUZDate: 2004-01-19 09:28:50
Subject: Re: New News Entry

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