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