We have successfully used Cocoon on several "DOCUMENT oriented" multi-lingual sites. In our experience we have found that i18n is good for internationalizing our application but not our content. The text that is part of the APPLICATION (menu bars, headings, navigation aides etc) is all controlled under the i18n umbrella. The CONTENT however is simply marked up with language identifying tags. We did this for a couple of reasons. One was outlined below in that i18n isn't really designed for whole documents but rather bits and pieces. The second reason was that we wanted to keep our content "pure" separate from any application specific mechanisms. This way our content stands alone and is ready to be used or served by any system. Whether or not the translated content is in a single file per document or individual language files is completely a design choice. We have done it both ways.
This is the sort of thing that is intended to be supported by what I am working on. Unfortunately, contrary to what Sjur says, I haven't finished it - I haven't really started it. It is a spare time task, and spare time has been taken up with other more personal stuff recently.
But, what I want to do, is something like:
<map:match pattern="**/*.html">
<map:generate src="{i18n:content/$locale/{1}/{2}.xml}"/>
...
</map:match>Where $locale is replaced, by this i18n module, with the name of the relevant file, with the appropriate language. It would take into account such things as the locale first, dropping down to the appropriate default until it finds a file, then maybe using a request parameter lang="xxx", etc, until it finds a file, which it then serves up.
Having described it like that, it doesn't actually seem that hard to do! Maybe I'll actually get it done some time soon!
Upayavira
On May 11, 2004, at 2:54 AM, Sjur Nørstebø Moshagen wrote:
På 11. mai. 2004 kl. 02.07 skrev Joerg Heinicke:
On 10.05.2004 21:55, Dean West wrote:
I have been tasked with internationalization for the company I work for, and
since we already use Cocoon in our current appliction - I am thinking that
the "I18n Transformer" should do the job?
I like the concept of the I18n Transformer because it seperates the
different langues into their own source XML documents... this SEEMS to be
way more efficient than having 1 xml source doc with a plethora of
"xml:lang" tags for each language translation.
Can anyone offer their expertise on this subject (best practices)? - it
just seems really heavy on the xml engine to have to parse huge xml files
(containing all language translations).
Yes, you should use multiple files. They offer as additional value the fallback from the language_country_variant to language_country to language to default if a key is missing in the more detailed variant. Did you read the documentation on I18nTransformer? I think it explains the details very well:
http://cocoon.apache.org/2.1/userdocs/transformers/i18n- transformer.html
The documentation on the wiki can probably not add much more, but the URL is: http://wiki.cocoondev.org/Wiki.jsp?page=I18NTransformer
You should be aware that the present i18n support in Cocoon (2.1.4) is missing one major i18n feature: whole-document i18n. The present features are geared towards database-driven sites where you need to translate table headings, menues, and other smaller pieces of texts as part of a generated site. If your site is document-heavy in the sense that you have largeish documents in several languages (each language in a separate file, as you describe it above), there presently is no way to select _documents_ (ie files) based on locale/language, at least I have not been able to find a way of doing it.
BUT: Upayavira has implemented an i18n-ed file selector which does proper fallbacks (lang_country_variant -> lang_country -> lang). I haven't tried it yet myself, but I believe it is available in the latest CVS versions. With it you can also easily select whole documents/files based on locale.
Sjur
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
