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