Multilingual CMS (was Re: The wgo CMS can't wait more)



I'll try to explain why the CMS selection is not that simple and why
localization is so important. And why I don't think such selection can
be simply made based on community enthusiasm or votes. 


If wgo would be planned in just one language the selection of the CMS
would be much more simple and much more based on the human resources
available. I could simply say 'let's choose Drupal because there are
more people around us knowing this tool' and there wouldn't be a strong
argument against that.

However, i18n is an essential piece of the wgo revamp. The i18n team set
some requirements/recommendations -
http://live.gnome.org/GnomeWeb/Localization - almost impossible to
achieve without hacking seriously an existing tool (i.e. translations
managed through PO files). We need to see how to lower those
requirements in order to match existing functionality, or new
functionality the developers of a CMS plan to release in the short term.

The fact that the wgo translations have been dropped from 2.18 leave us
6 months more to tune the right solution, but anyway we need to choose
the platform now.

On Wed, 2006-10-25 at 13:54 -0400, Marc Laporte wrote:

So I repeat my question from August: "Can someone point me to a working 
implementation (in any open source CMS)?"
http://mail.gnome.org/archives/marketing-list/2006-August/msg00108.html

What the i18n team si asking for doesn't exist yet, as far as I know. I
asked them to refine/lower the requirements but I got no response, which
doesn't help much.  :)  However, I think our requirements better don't
go below...

- Full support for multiple locales, including:

        * non-Western and right-to-left (RTL). 

        * all the content users see in English can be translated, including
menus and date formats

        * Different images can be published in different languages and images
(graphic.png in page.html can be substituted by graphic_DE.png in
page_DE.html)

- Automatic session & browser language detection.

- Automatic relation between the translations of a same page.

- Incremental page versioning and diffs.

- Notifications of changes in a page.

- Translatable URL paths.

- Capacity to work on the translation in language X in a non-public
environment and then publish the new translated site at once.

- The i18n team says that native XML content or a good XML import/export
functionality is very important in order to make the wgo translations
compatible with their current workflow. (native XML is probably useful
for other things, although we haven't still evaluated this in the
context of wgo).


Not essential but quite recommendable:

- List of pages of language X with versions and translation status
compared to the English original site. It should be easy to find pages
not translated and outdated translations.

- User permissions to create/edit pages in one language only.

- ? Start a new language translation on top of a copy of the original
English site, so you don't need to create again the pages and its
structure.


As far as I know Tiki is not the candidate matching most of this
features and for me this is a strong reason to dismiss it. But the
Drupal lovers will see that this very popular CMS is not in the best
condition to match the i18n requirements either. eZ, Midgard and Plone
seem to be better equipped.

Of course there are still the other factors I mentioned yesterday
(look&feel, learning curve, security & upgrades, user management and
contributors). But only looking at this one we see that there is not a
clear winner, and also that Drupal will need to sweat to win (thinks a
Drupal admin like me).


PS: I still don't have a clear next candidate to be dismissed. Perhaps
eZ due to the lack of own resources (the tool itself looks good). If you
would lead and complete an eZ implementation let us know. If you have a
better candidate to dismiss next let us know.

Here is the issue revisited recently:
http://drone-alliance.org/wordpress/2006/08/20/i18n-revisited/
You will see it can become very tricky with branches & all! Which type 
of contribution invalidates the translation set, etc

Interesting article. Well, this is the reason why I think it's important
to obey the i18n team: if we are able to give them a translation tool
friendly with their system, then wgo will benefit not only from their
human resources, but also from a set of policies of procedures that have
proven to work over the time, in dozens of languages coordinated and
offering good quality standards.


Back to WGO, I also got confused when someone on the list was insisting 
to use PO files. So does WGO want PO import/export or should 
contributors edit via the web-based interface?

Yeah, nobody has been able to explain how to treat page content as PO
files. This is why I'm lowering the requirement to native XML or good
XML import/export.

-- 
Quim Gil /// http://desdeamericaconamor.org

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]