Bricolage: Impressive

First, a brief introduction, since I started working off-list: I expressed
some interest in helping work with the web site some months ago to Josh
Berkus, and was directed to Dave, and possibly Robert. I think an E-Mail got
lost somewhere, however, so I didn't get further involved at that point.

Last week, roughly around the same time as all the other new folks signed on
to this list, I sent a message to Robert, Dave, and Marc asking if I could
help, and was directed to try out Bricolage as a possible way of powering the
Techdocs site.

My background is in Linguistics, with a fair bit of work and credit in
evaluating web sites for usability. I'm employed with the job title of
"Database Developer & Administrator", which involves maintaining our
PostgreSQL installation and writing most of the interface programs that are
used by the company's employees. This is done using Apache + Perl + Mason,
and I'm very familiar with the last two in particular.

</end introduction>

I now have a working installation of Bricolage installed, and have a better
understanding of how it works. In a word, it's impressive. Unless our
requirements for multilingualism (see previous message) prevent us from using
it, I think it's a very good candidate for generating/unifying all of the
PostgreSQL sites.

It was designed for daily use by journalists, who are not interested in
learning any form of markup, and who in most cases are not *allowed* to do any
form of markup, since this is handled by the site. They write their articles
using plain text, generally as a sequence of paragraphs, though it's possible
to intersperse other user-definable "elements" such as headings, quotes, etc.
For instance, we could have an element called "SQL Code" that would be used
for examples. Josh Berkus' "Adventures in SQL" would then be a series of
"Paragraph" blocks interspersed with "SQL Code" blocks.

[This is not a complicated process, either. By the look of it, I could easily
move one of Josh's articles into Bricolage in under five minutes, just using
copy and paste from my browser.]

Each type of contribution has a workflow associated with it. By default, an
article would go through the Edit Desk, Review Desk, Legal Desk, and Publish
Desk. The workflow is completely customizable, so we could remove the Legal
Desk, add a Translator's Desk, for example. It contains a complete audit
trail, and you can easily revert to an older version, if necessary.

Once an article gets to the Publish Desk, it gets "burned" into HTML by going
through a Mason template (default) or an HTML::Template template (alternate).
This template provides all of the markup and site layout functions, and
results in a plain HTML file, which can be automatically sent to any number of
locations by a variety of means (FTP and File System are available by default;
there may be others, and a simple cron job could fill in the gaps).

The Bricolage server can be run from anywhere -- it need not (and arguably
should not) be at www.postgresql.org:80. The result is that a web server need
only serve plain HTML files, for maximum efficiency and ease of installation
and maintenance.

Based on what I understand of Plone and Bricolage, and of what we want, it
looks like Bricolage is the far better candidate, at least once you get around
the barrier of getting it set up. This is purely my opinion, however.

I'll keep working on it, and see if I can get a simulation of the current
TechDocs site going.

Steve Simms
Database Developer & Administrator
Medical Media Systems, Inc.

I'm also voted for Bricolade, because it's based on Mason, which I
personally have use a lot on many projects.
Multilingual support could be implemented on top of Mason, see
for example www.pgsql.ru

We use custom tag
<* ru=>'something in russian', en=>'the same in english' *>

If you need function call we have i18n(ru=>'...', en=>'....');

Of course, our approach doesn't limited by 2 languages.
We found it's much easier and maitainable for small evolving projects to
use that approach (inline), than gettext, because it's easy just edit
component. But, for stable project, gettext would be better.

Oleg
On Sat, 17 Jan 2004, Steve Simms wrote:

> First, a brief introduction, since I started working off-list: I expressed
> some interest in helping work with the web site some months ago to Josh
> Berkus, and was directed to Dave, and possibly Robert. I think an E-Mail got
> lost somewhere, however, so I didn't get further involved at that point.
>
> Last week, roughly around the same time as all the other new folks signed on
> to this list, I sent a message to Robert, Dave, and Marc asking if I could
> help, and was directed to try out Bricolage as a possible way of powering the
> Techdocs site.
>
> My background is in Linguistics, with a fair bit of work and credit in
> evaluating web sites for usability. I'm employed with the job title of
> "Database Developer & Administrator", which involves maintaining our
> PostgreSQL installation and writing most of the interface programs that are
> used by the company's employees. This is done using Apache + Perl + Mason,
> and I'm very familiar with the last two in particular.
>
> </end introduction>
>
> I now have a working installation of Bricolage installed, and have a better
> understanding of how it works. In a word, it's impressive. Unless our
> requirements for multilingualism (see previous message) prevent us from using
> it, I think it's a very good candidate for generating/unifying all of the
> PostgreSQL sites.
>
> It was designed for daily use by journalists, who are not interested in
> learning any form of markup, and who in most cases are not *allowed* to do any
> form of markup, since this is handled by the site. They write their articles
> using plain text, generally as a sequence of paragraphs, though it's possible
> to intersperse other user-definable "elements" such as headings, quotes, etc.
> For instance, we could have an element called "SQL Code" that would be used
> for examples. Josh Berkus' "Adventures in SQL" would then be a series of
> "Paragraph" blocks interspersed with "SQL Code" blocks.
>
> [This is not a complicated process, either. By the look of it, I could easily
> move one of Josh's articles into Bricolage in under five minutes, just using
> copy and paste from my browser.]
>
> Each type of contribution has a workflow associated with it. By default, an
> article would go through the Edit Desk, Review Desk, Legal Desk, and Publish
> Desk. The workflow is completely customizable, so we could remove the Legal
> Desk, add a Translator's Desk, for example. It contains a complete audit
> trail, and you can easily revert to an older version, if necessary.
>
> Once an article gets to the Publish Desk, it gets "burned" into HTML by going
> through a Mason template (default) or an HTML::Template template (alternate).
> This template provides all of the markup and site layout functions, and
> results in a plain HTML file, which can be automatically sent to any number of
> locations by a variety of means (FTP and File System are available by default;
> there may be others, and a simple cron job could fill in the gaps).
>
> The Bricolage server can be run from anywhere -- it need not (and arguably
> should not) be at www.postgresql.org:80. The result is that a web server need
> only serve plain HTML files, for maximum efficiency and ease of installation
> and maintenance.
>
>
> Based on what I understand of Plone and Bricolage, and of what we want, it
> looks like Bricolage is the far better candidate, at least once you get around
> the barrier of getting it set up. This is purely my opinion, however.
>
> I'll keep working on it, and see if I can get a simulation of the current
> TechDocs site going.
>
> Steve Simms
> Database Developer & Administrator
> Medical Media Systems, Inc.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>

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

'k, we have one vote from someone that has only started to play with it
... and one vote from someone who has used the base technology ...

do we have anyone that is against using this? Steve seems to indicate
that this could be used for not just techdocs, but for the other sites as
well ... do we want to look at this too, since Oleg seems to indicate the
whole internationalization stuff shouldn't be an issue using it?

Steve, is this something that, if I install it on the root server,
everything is maintained through web interfaces, or is there shell access
required for maintaining?

On Sat, 17 Jan 2004, Oleg Bartunov wrote:

> I'm also voted for Bricolade, because it's based on Mason, which I
> personally have use a lot on many projects.
> Multilingual support could be implemented on top of Mason, see
> for example www.pgsql.ru
>
> We use custom tag
> <* ru=>'something in russian', en=>'the same in english' *>
>
> If you need function call we have i18n(ru=>'...', en=>'....');
>
> Of course, our approach doesn't limited by 2 languages.
> We found it's much easier and maitainable for small evolving projects to
> use that approach (inline), than gettext, because it's easy just edit
> component. But, for stable project, gettext would be better.
>
>
> Oleg
> On Sat, 17 Jan 2004, Steve Simms wrote:
>
> > First, a brief introduction, since I started working off-list: I expressed
> > some interest in helping work with the web site some months ago to Josh
> > Berkus, and was directed to Dave, and possibly Robert. I think an E-Mail got
> > lost somewhere, however, so I didn't get further involved at that point.
> >
> > Last week, roughly around the same time as all the other new folks signed on
> > to this list, I sent a message to Robert, Dave, and Marc asking if I could
> > help, and was directed to try out Bricolage as a possible way of powering the
> > Techdocs site.
> >
> > My background is in Linguistics, with a fair bit of work and credit in
> > evaluating web sites for usability. I'm employed with the job title of
> > "Database Developer & Administrator", which involves maintaining our
> > PostgreSQL installation and writing most of the interface programs that are
> > used by the company's employees. This is done using Apache + Perl + Mason,
> > and I'm very familiar with the last two in particular.
> >
> > </end introduction>
> >
> > I now have a working installation of Bricolage installed, and have a better
> > understanding of how it works. In a word, it's impressive. Unless our
> > requirements for multilingualism (see previous message) prevent us from using
> > it, I think it's a very good candidate for generating/unifying all of the
> > PostgreSQL sites.
> >
> > It was designed for daily use by journalists, who are not interested in
> > learning any form of markup, and who in most cases are not *allowed* to do any
> > form of markup, since this is handled by the site. They write their articles
> > using plain text, generally as a sequence of paragraphs, though it's possible
> > to intersperse other user-definable "elements" such as headings, quotes, etc.
> > For instance, we could have an element called "SQL Code" that would be used
> > for examples. Josh Berkus' "Adventures in SQL" would then be a series of
> > "Paragraph" blocks interspersed with "SQL Code" blocks.
> >
> > [This is not a complicated process, either. By the look of it, I could easily
> > move one of Josh's articles into Bricolage in under five minutes, just using
> > copy and paste from my browser.]
> >
> > Each type of contribution has a workflow associated with it. By default, an
> > article would go through the Edit Desk, Review Desk, Legal Desk, and Publish
> > Desk. The workflow is completely customizable, so we could remove the Legal
> > Desk, add a Translator's Desk, for example. It contains a complete audit
> > trail, and you can easily revert to an older version, if necessary.
> >
> > Once an article gets to the Publish Desk, it gets "burned" into HTML by going
> > through a Mason template (default) or an HTML::Template template (alternate).
> > This template provides all of the markup and site layout functions, and
> > results in a plain HTML file, which can be automatically sent to any number of
> > locations by a variety of means (FTP and File System are available by default;
> > there may be others, and a simple cron job could fill in the gaps).
> >
> > The Bricolage server can be run from anywhere -- it need not (and arguably
> > should not) be at www.postgresql.org:80. The result is that a web server need
> > only serve plain HTML files, for maximum efficiency and ease of installation
> > and maintenance.
> >
> >
> > Based on what I understand of Plone and Bricolage, and of what we want, it
> > looks like Bricolage is the far better candidate, at least once you get around
> > the barrier of getting it set up. This is purely my opinion, however.
> >
> > I'll keep working on it, and see if I can get a simulation of the current
> > TechDocs site going.
> >
> > Steve Simms
> > Database Developer & Administrator
> > Medical Media Systems, Inc.
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: Have you searched our list archives?
> >
> > http://archives.postgresql.org
> >
>
> Regards,
> Oleg
> _____________________________________________________________
> Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
> Sternberg Astronomical Institute, Moscow University (Russia)
> Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
> phone: +007(095)939-16-83, +007(095)939-23-83
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Marc G. Fournier wrote:
> do we have anyone that is against using this? Steve seems to
> indicate that this could be used for not just techdocs, but for the
> other sites as well ... do we want to look at this too, since Oleg
> seems to indicate the whole internationalization stuff shouldn't be
> an issue using it?

I read that he indicated that internationalization *is* an issue if you
have lots of languages and frequent, irregular updates. To me, keeping
the translations inline seems OK for a couple of languages and small
sites, but for what we're talking about here it seems shortsighted.

Marc G. Fournier said:
> do we have anyone that is against using this? Steve seems to indicate
> that this could be used for not just techdocs, but for the other sites as
> well ... do we want to look at this too, since Oleg seems to indicate the
> whole internationalization stuff shouldn't be an issue using it?

For my part, I'm not sure how well internationalization will work. I tried
searching through the Bricolage mailing list archives, but SourceForge seems
to be acting up, and returns "no results" for any set of keywords. I'll try
again later.

I think it will depend on what kind of internationalization we decide we need.
Bricolage *is* being used for highly multilingual sites based on what I've
seen, though I'm not sure yet how they do it.

> Steve, is this something that, if I install it on the root server,
> everything is maintained through web interfaces, or is there shell access
> required for maintaining?

For normal purposes and most administration, yes. I'm not yet sure about
things like adding/updating CSS files -- I'll let you know when I find out.
Other layout can definitely be done entirely through the web interface, so I
think it's safe to say that 90%+ of site administration can be done through
the web.

Steve Simms
Database Developer & Administrator
Medical Media Systems, Inc.

David, can you add some input into this? The thread starts:

http://archives.postgresql.org/pgsql-www/2004-01/msg00188.php

On Sat, 17 Jan 2004, Peter Eisentraut wrote:

> Marc G. Fournier wrote:
> > do we have anyone that is against using this? Steve seems to
> > indicate that this could be used for not just techdocs, but for the
> > other sites as well ... do we want to look at this too, since Oleg
> > seems to indicate the whole internationalization stuff shouldn't be
> > an issue using it?
>
> I read that he indicated that internationalization *is* an issue if you
> have lots of languages and frequent, irregular updates. To me, keeping
> the translations inline seems OK for a couple of languages and small
> sites, but for what we're talking about here it seems shortsighted.
>
>

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

On Sat, 17 Jan 2004, Peter Eisentraut wrote:

> Marc G. Fournier wrote:
> > do we have anyone that is against using this? Steve seems to
> > indicate that this could be used for not just techdocs, but for the
> > other sites as well ... do we want to look at this too, since Oleg
> > seems to indicate the whole internationalization stuff shouldn't be
> > an issue using it?
>
> I read that he indicated that internationalization *is* an issue if you
> have lots of languages and frequent, irregular updates. To me, keeping
> the translations inline seems OK for a couple of languages and small
> sites, but for what we're talking about here it seems shortsighted.
>

You're right. The more I'm thinking about .postgresq.org sites, the more I
inclined to regular approach with Locale::Maketext::Lexicon.
http://www.autrijus.org/webl10n/webl10n.html - nice paper

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

On Saturday 17 January 2004 13:29, Steve Simms wrote:
> I now have a working installation of Bricolage installed, and have a better
> understanding of how it works. In a word, it's impressive. Unless our
> requirements for multilingualism (see previous message) prevent us from
> using it, I think it's a very good candidate for generating/unifying all of
> the PostgreSQL sites.
>

Initially there isn't a requirement that techdocs and the main website use the
same backend, as long as they can be given some type of unified look/feel
with the main site. AFAICR no one has ever clamored to translate the
articles up on the techdocs website (though we're certainly not opposed to
it, just no one has really wanted to) So multilingualism shouldn't be a
stumbling block for techdocs. One thing that we do need is the ablility for
users comments on articles, is there any provision for that? Another thing
that could come up would be user articles submitted in pdf form (I just added
one yesterday), is there a provision for that?

>
> Based on what I understand of Plone and Bricolage, and of what we want, it
> looks like Bricolage is the far better candidate, at least once you get
> around the barrier of getting it set up. This is purely my opinion,
> however.
>
> I'll keep working on it, and see if I can get a simulation of the current
> TechDocs site going.
>

OK, if you can send us (or me at least) a url I'd be interested in browsing
around and adding an article or two.

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

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(at)kineticode(dot)com ICQ: 15726394
http://www.kineticode.com/ Yahoo!: dew7e
Jabber: Theory(at)jabber(dot)org
Kineticode. Setting knowledge in motion.[sm]

David, could you comment to Robert's questions below?

On Sun, 18 Jan 2004, Robert Treat wrote:

> stumbling block for techdocs. One thing that we do need is the ablility
> for users comments on articles, is there any provision for that?
> Another thing that could come up would be user articles submitted in pdf
> form (I just added one yesterday), is there a provision for that?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Guys,

As you know, I've always favored Bricolage for Techdocs. It covers what I
want for acquiring writers who are not HTML-jockeys (like me), and is
immensely scalable, and I am already lightly involved in the Bric community
so I feel more able to troubleshoot issues.

However, there is a labor-intensive "templating" process in the initial Bric
set-up, which requires a good knowledge of HTML and Bric and a light
knowledge of Perl and Mason. Elein was going to set this up initially but
became tied up in her start-up and hasn't had time. I don't feel skilled
enough to do the templating.

If Steve is up to templating, I will happily work on porting articles. In
addition to Steve's server, David Fetter set up a Bric server for
development, which may be still connected to the internet.

Robert: since what Bric does is build HTML pages, it is entirely possible to
"plug in" PHP applications as blocks of HTML text. Comments could be
supported this way, as well as a Wiki (which I also believe we should have).

--
-Josh Berkus
Aglio Database Solutions
San Francisco

Guys,

Oh, and the other reason to use Bric is political; Bric is one of PostgreSQL's
few "killer apps" that really give companies a compelling reason to use
PostgreSQL if they are not already database-saavy. Us using it would benefit
both projects.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

I'm still following lightly all of these threads and am
still very interested in setting up templates
in Bricolage for techdocs.

Collaboration with someone else might ease
my time commitment pain, though.

Steve?

elein

PS: I cannot run bricolage on my own server until I
get upgraded to debian from old suse :-(

On Sun, Jan 18, 2004 at 05:35:49PM -0800, Josh Berkus wrote:
> Guys,
>
> As you know, I've always favored Bricolage for Techdocs. It covers what I
> want for acquiring writers who are not HTML-jockeys (like me), and is
> immensely scalable, and I am already lightly involved in the Bric community
> so I feel more able to troubleshoot issues.
>
> However, there is a labor-intensive "templating" process in the initial Bric
> set-up, which requires a good knowledge of HTML and Bric and a light
> knowledge of Perl and Mason. Elein was going to set this up initially but
> became tied up in her start-up and hasn't had time. I don't feel skilled
> enough to do the templating.
>
> If Steve is up to templating, I will happily work on porting articles. In
> addition to Steve's server, David Fetter set up a Bric server for
> development, which may be still connected to the internet.
>
> Robert: since what Bric does is build HTML pages, it is entirely possible to
> "plug in" PHP applications as blocks of HTML text. Comments could be
> supported this way, as well as a Wiki (which I also believe we should have).
>
> --
> -Josh Berkus
> Aglio Database Solutions
> San Francisco
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Oh, and the other reason to use Bric is political; Bric is one of
> PostgreSQL's few "killer apps" that really give companies a compelling
> reason to use PostgreSQL if they are not already database-saavy. Us
> using it would benefit both projects.

Indeed. It looks like you already caught David Wheeler's attention;
perhaps he'd be willing to lend a hand, or at least superintend.

regards, tom lane

David,

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 .postgresql.org problem with search engine if -www
will decide to go with Bricolade.

Oleg
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:
> >
> > 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
>
>

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

On Jan 18, 2004, at 10:51 AM, Marc G. Fournier wrote:

> David, could you comment to Robert's questions below?
>
> On Sun, 18 Jan 2004, Robert Treat wrote:
>
>> stumbling block for techdocs. One thing that we do need is the
>> ablility
>> for users comments on articles, is there any provision for that?
>> Another thing that could come up would be user articles submitted in
>> pdf
>> form (I just added one yesterday), is there a provision for that?

No. Bricolage is entirely a back=end application. For users to comment
on articles, you'd have to do one of two things: Either implement
something for it on the front-end server (I'm sure there are plenty of
simple OSS solutions for this), or create some sort of gateway script
that takes a submitted comment and submits it to the Bricolage SOAP
server to be added to a document, and then triggering the republish of
that document.

For performance reasons, I recommend the former.

HTH,

David

On Sun, 18 Jan 2004, elein wrote:

> PS: I cannot run bricolage on my own server until I
> get upgraded to debian from old suse :-(

That isn't an issue, I just need someone to tell me that this is what we
should be working on and I'll get it setup over here ...

From what Steve said, it shouldn't be run on port 80 of the main site ...
can the port be changed, or does it need to run on a seperate IP
altogether?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Marc,

> That isn't an issue, I just need someone to tell me that this is what we
> should be working on and I'll get it setup over here ...

From my experience, Bricolage needs its own (virtual) server, and preferably
its own machine. It's not set up to share resources.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

On Mon, 19 Jan 2004, Josh Berkus wrote:

> Marc,
>
> > That isn't an issue, I just need someone to tell me that this is what we
> > should be working on and I'll get it setup over here ...
>
> From my experience, Bricolage needs its own (virtual) server, and preferably
> its own machine. It's not set up to share resources.

k, seperate VM isn't an issue ... but what is it doing that it needs its
own machine? God, I thought Java programs were the worst, you are saying
that this needs more then jakarta-tomcat processes?

David?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Marc,

> k, seperate VM isn't an issue ... but what is it doing that it needs its
> own machine? God, I thought Java programs were the worst, you are saying
> that this needs more then jakarta-tomcat processes?

Probably not, no.

It does need a seperate VM because of all the Perl stuff and the static
mod_perl in Apache.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

On Mon, 19 Jan 2004, Josh Berkus wrote:

> Marc,
>
> > k, seperate VM isn't an issue ... but what is it doing that it needs its
> > own machine? God, I thought Java programs were the worst, you are saying
> > that this needs more then jakarta-tomcat processes?
>
> Probably not, no.
>
> It does need a seperate VM because of all the Perl stuff and the static
> mod_perl in Apache.

That's doable with the current VM as well, as mod_perl is already
installed ... the only issue that I could see is the port 80 that Steve
mentioned ...

But, the thing with putting it onto its own VM is that it makes it easier
to provide ppl like Elein and Steve access without having access to the
main servers ...

If we are all in agreement that this is the direction we want to go, then
I can get the VM for this setup tomorrow ... who will/should be given
"root" to that VM? Elein? Steve? Josh? Let me know ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

I would definitely like access. I don't have a postgresql
login, though. Steve--let's coordinate off list?

--elein

On Mon, Jan 19, 2004 at 05:09:09PM -0400, Marc G. Fournier wrote:
> On Mon, 19 Jan 2004, Josh Berkus wrote:
>
> > Marc,
> >
> > > k, seperate VM isn't an issue ... but what is it doing that it needs its
> > > own machine? God, I thought Java programs were the worst, you are saying
> > > that this needs more then jakarta-tomcat processes?
> >
> > Probably not, no.
> >
> > It does need a seperate VM because of all the Perl stuff and the static
> > mod_perl in Apache.
>
> That's doable with the current VM as well, as mod_perl is already
> installed ... the only issue that I could see is the port 80 that Steve
> mentioned ...
>
> But, the thing with putting it onto its own VM is that it makes it easier
> to provide ppl like Elein and Steve access without having access to the
> main servers ...
>
> If we are all in agreement that this is the direction we want to go, then
> I can get the VM for this setup tomorrow ... who will/should be given
> "root" to that VM? Elein? Steve? Josh? Let me know ...
>
> ----
> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
> Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match

Marc G. Fournier said:
>> It does need a seperate VM because of all the Perl stuff and the static
>> mod_perl in Apache.
>
> That's doable with the current VM as well, as mod_perl is already
> installed ... the only issue that I could see is the port 80 that Steve
> mentioned ...

It can be set up to run on a port other than 80 -- that's what I'm doing on my
server.

You might want to try setting it up on a different computer first, though, for
the experience -- when I tried to set it up on mine (I was attempting to do a
virtual host on the same port), I accidentally caused Bricolage to answer all
queries for all virtual hosts, and if my sites had higher traffic, people
might have noticed. :-)

Also, be ready to install a LOT of Perl modules.

The main issue to consider with Bricolage are the memory requirements -- I
think the docs say that it takes something like 25MB per Apache child.
Looking at my server, I see one child at 30MB. So be sure that there's plenty
of RAM available.

> If we are all in agreement that this is the direction we want to go, then
> I can get the VM for this setup tomorrow ... who will/should be given
> "root" to that VM? Elein? Steve? Josh? Let me know ...

The only people who should need direct access to the machine are the people
who will be maintaining any technical aspects of it. All content and
template/layout development and publishing (except deleting files once they're
published) can be done through the interface.

I'd be fine with being the (or one of the) main people doing technical
maintenance on this server, but I wouldn't want to be the only one. I could
help get someone else up to speed, though, if that would help. (Elein?)

Hope this helps,

Steve Simms
Database Developer & Administrator
Medical Media Systems, Inc.

Josh Berkus said:
> If Steve is up to templating, I will happily work on porting articles.

I'd be happy to do the templating -- compared to the Mason code I normally
deal with, this should be simple. My hangup at the moment is coming up with
the structure. If Elein, Josh, etc. could help me come up with a revised set
of categories for the articles, that would be very helpful.

The existing TechDocs site looks like it was modified as articles were added,
with the result that I have a hard time finding things on that page. Now that
we have a fairly large number of articles, it seems like it would be worth
taking the time to take another look at the category structure.

Also, it might be worth moving pre-7.3 articles into their own subcategory --
maybe by having a set of categories for version-specific articles. When I
first visited the PostgreSQL sites, I thought the project was no longer in
active development because of the large number of old articles that were
prominently linked. This would help, as would getting new articles. :-) We
certainly shouldn't remove them altogether, though -- I, for one, was
maintaining a 7.1.1 install of PostgreSQL until a couple of months ago, and
those articles were helpful.

> Robert: since what Bric does is build HTML pages, it is entirely possible to
> "plug in" PHP applications as blocks of HTML text. Comments could be
> supported this way, as well as a Wiki (which I also believe we should have).

Correct. We'd just have the Bricolage "burner" include the relevant code to
fire up the relevant apps. This *will* impact our ability to have mirrors,
though, for the TechDocs site, I don't imagine this is terribly important.

Steve Simms
Database Developer & Administrator
Medical Media Systems, Inc.

On Jan 19, 2004, at 3:54 AM, Oleg Bartunov wrote:

> 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 .postgresql.org problem with search engine if -www
> will decide to go with Bricolade.

Bricolage is a back-office application, not front end. It has SQL-style
search, but it's just for users of the application. Once you publish a
document, it's entirely outside of Bricolage -- it distributes the
XHTML files to your Web server. If you need search on the front end,
it'll have to be a different product.

I hear that SWISH-E works pretty well.

Cheers,

David

On Jan 19, 2004, at 12:44 PM, Marc G. Fournier wrote:

> k, seperate VM isn't an issue ... but what is it doing that it needs
> its
> own machine? God, I thought Java programs were the worst, you are
> saying
> that this needs more then jakarta-tomcat processes?
>
> David?

It typically starts up using around 25MB per process (shared). It's not
uncommon for processes to swell upwards of 50MB or more. Then there are
the PostgreSQL processes.

Hey, you want a lot of functionality, you got to pay for it.

Cheers,

David

On Jan 19, 2004, at 5:34 PM, Steve Simms wrote:

> The only people who should need direct access to the machine are the
> people
> who will be maintaining any technical aspects of it. All content and
> template/layout development and publishing (except deleting files once
> they're
> published) can be done through the interface.

Actually, if you publish a document with an expire date and you have
bric_dist_mon running on a cron job, the files will be deleted from the
Web server. :-)

Regards,

David