You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Dean West <de...@petlynx.net> on 2004/05/10 21:55:41 UTC
Cocoon and Internationalization
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).
Thanks for help,
DW
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon and Internationalization
Posted by Askild Aaberg Olsen <as...@xangeli.com>.
Upayavira wrote:
> Askild Aaberg Olsen wrote:
> >This is actually my current approach, but implemented with sitemap
> >parameters, a stylesheet and cinclude.
> >
> ><map:match pattern="**/*.*">
> > <map:generate type="directory" src="{1}">
> > <map:parameter name="include" value="{2}_?(.*).{3}"/>
> > </map:generate>
> > <map:transform type="xslt" src="match.lang.xslt">
> > <map:parameter name="lang"
> value="{request-param:lang}"/>
> > <map:parameter name="path" value="{1}"/>
> > </map:transform>
> > <map:transform type="cinclude"/>
> > <map:serialize type="xml"/>
> ></map:match>
> >
> >The stylesheet implements the selection logic to find the
> correct file,
> >and if it doesn't find it, serves the closest match.
> >
> >
> Now that is interesting. If you instead did:
>
> <map:act type="locale">
> <map:transform type="xslt" src="match.lang.xslt">
> <map:parameter name="request-lang"
> value="{request-param:lang}"/>
> <map:parameter name="locale-lang"
> value="{locale:lang}"/>
> <map:parameter name="path" value="{1}"/>
> </map:transform>
> </map:act>
>
> You would be able to code your stylesheet to handle the
> locale provided
> by the user's browser, not just a request parameter.
Nice one, but in my case this sitemap is actually called from another
pipeline, that provides the actual lang request-parameter. I have a separate
piece logic to work out the right locale (not only based on the users
locale).
> Would you be willing to post (or send me privately) your stylesheet as it
currently stands?
Of course!
I rely on your and the Cocoon community's work all day long, so it's just
decent to give something back.
The filename pattern is <filename>_<lang>.<ext>, and the idea is to take the
file with the longest <lang>-string that matches the complete or partial
language.
If no match is found, just produce the last one (wich is also the default
language, usually english or norwegian (!) for norwegian only sites.
> >It works, but it's not rock-solid.
> >
> It looks good to me, so far.
Thanks, but you haven't seen the stylesheet yet ;)
That's the weak link, since it's not able to compute the 100% correct
language.
But it's still good enough for me, event if it doesn't work for all cases.
> >A cocoon component that implements this
> >would be really useful!
> >
> >
> Yea. But there's also something to be said for the simple component
> approach that you've taken. I'll mull on this more.
>
> Regards, Upayavira
Regards, Askild
Re: Cocoon and Internationalization
Posted by Upayavira <uv...@upaya.co.uk>.
Askild Aaberg Olsen wrote:
>Upayavira wrote:
>
>
>>>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
>>
>>
>
>This is actually my current approach, but implemented with sitemap
>parameters, a stylesheet and cinclude.
>
><map:match pattern="**/*.*">
> <map:generate type="directory" src="{1}">
> <map:parameter name="include" value="{2}_?(.*).{3}"/>
> </map:generate>
> <map:transform type="xslt" src="match.lang.xslt">
> <map:parameter name="lang" value="{request-param:lang}"/>
> <map:parameter name="path" value="{1}"/>
> </map:transform>
> <map:transform type="cinclude"/>
> <map:serialize type="xml"/>
></map:match>
>
>The stylesheet implements the selection logic to find the correct file, and
>if it doesn't find it, serves the closest match.
>
>
Now that is interesting. If you instead did:
<map:act type="locale">
<map:transform type="xslt" src="match.lang.xslt">
<map:parameter name="request-lang" value="{request-param:lang}"/>
<map:parameter name="locale-lang" value="{locale:lang}"/>
<map:parameter name="path" value="{1}"/>
</map:transform>
</map:act>
You would be able to code your stylesheet to handle the locale provided
by the user's browser, not just a request parameter. Would you be
willing to post (or send me privately) your stylesheet as it currently
stands?
>It works, but it's not rock-solid.
>
It looks good to me, so far.
>A cocoon component that implements this
>would be really useful!
>
>
Yea. But there's also something to be said for the simple component
approach that you've taken. I'll mull on this more.
Regards, Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon and Internationalization
Posted by Askild Aaberg Olsen <as...@xangeli.com>.
Upayavira wrote:
> > 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
This is actually my current approach, but implemented with sitemap
parameters, a stylesheet and cinclude.
<map:match pattern="**/*.*">
<map:generate type="directory" src="{1}">
<map:parameter name="include" value="{2}_?(.*).{3}"/>
</map:generate>
<map:transform type="xslt" src="match.lang.xslt">
<map:parameter name="lang" value="{request-param:lang}"/>
<map:parameter name="path" value="{1}"/>
</map:transform>
<map:transform type="cinclude"/>
<map:serialize type="xml"/>
</map:match>
The stylesheet implements the selection logic to find the correct file, and
if it doesn't find it, serves the closest match.
It works, but it's not rock-solid. A cocoon component that implements this
would be really useful!
Askild
-
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon and Internationalization
Posted by Upayavira <uv...@upaya.co.uk>.
Darren Petrie wrote:
> 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: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon and Internationalization
Posted by Tomasz Nowak <tn...@netventure.pl>.
Darren Petrie <dp...@anteon.com> wrote:
>
> 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 do almost exactly the same, with one difference that we put
translated content xml files into {$lang} directories, ex:
content/en/somePageContent.xml
content/de/somePageContent.xml
content/ru/somePageContent.xml
etc..
This is of course all about simple sites with no db-based
CMS which handles language version of content itself.
--
Tomasz Nowak
Netventure, http://www.netventure.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon and Internationalization
Posted by Darren Petrie <dp...@anteon.com>.
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.
Darren
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: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon and Internationalization
Posted by Sjur Nørstebø Moshagen <sj...@kolumbus.fi>.
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon and Internationalization
Posted by Joerg Heinicke <jo...@gmx.de>.
On 17.05.2004 17:00, Dean West wrote:
> then add it to pipeline:
>
> <map:match pattern="*">
> <map:generate src="blah/{1}.xml"/>
> <map:transform type="i18n"/>
> <map:serialize/>
> </map:match>
AFAIK this would obtain the server's default locale.
> In this book it's stated that adding the request parameter of
> "?locale=fr_ca" should display the appropriate translation automatically,
> but it does not function this way as far as i can see. (and yes - I do have
> the correct xmlns in my source doc, and messages/translations set up
> correctly)
Pass a parameter like in some of the samples
<map:transform type="i18n">
<map:parameter name="locale" value="en-US"/>
</map:transform>
(taken from forms block). Instead of hard-coding en-US choose your
request param. But IIRC there is even a smarter version using a locale
input module or action?
... searching for a sample ...
Locale action:
http://cocoon.apache.org/2.1/howto/howto-i18n-xmlform.html#5.+Create+a+Sitemap+match+element
Locale input module
http://wiki.cocoondev.org/Wiki.jsp?page=WorkingWithLocales, third blue box
I would prefer the input module, less to type.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon and Internationalization
Posted by Dean West <de...@petlynx.net>.
The i18n Transformer looks good for dealing with internationalization,
however...
I am very confused regarding HOW i get the appropriate country_locale
parameters passed dynamically?
I am reading the "Cocoon developers handbook" which samples do not seem to
work with cocoon 2.1.4.
I configure sitemap with:
<map:transformer name="i18n"
src="org.apache.cocoon.transformation.I18nTransformer">
<catalogue-name>messages</catalogue-name>
<catalogue-location>translations</catalogue-location>
<untranslated-text>untranslated</untranslated-text>
<cache-at-startup>true</cache-at-startup>
</map:transformer>
then add it to pipeline:
<map:match pattern="*">
<map:generate src="blah/{1}.xml"/>
<map:transform type="i18n"/>
<map:serialize/>
</map:match>
In this book it's stated that adding the request parameter of
"?locale=fr_ca" should display the appropriate translation automatically,
but it does not function this way as far as i can see. (and yes - I do have
the correct xmlns in my source doc, and messages/translations set up
correctly)
I do not see anything here that deals with sending through the locale /
country based on the users browser setting or OS settings... Help!
Thank You all Cocoon users for your feedback.
Dean West
----- Original Message -----
From: "Joerg Heinicke" <jo...@gmx.de>
To: <us...@cocoon.apache.org>
Sent: Monday, May 10, 2004 5:07 PM
Subject: Re: Cocoon and Internationalization
> 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
>
> Joerg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon and Internationalization
Posted by Joerg Heinicke <jo...@gmx.de>.
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
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
AW: Cocoon and Internationalization
Posted by Nils <co...@lolili.de>.
Hi,
i'm internationalizing my website as well, currently german and english.
I didn't use i18n becuase it seemed to be as complex as solving the problem
myself. I have session-management and authentication and that seemed a
little to complex to combine with i18n, but don't blame on me: I didn't try
it!
I chose to have both languages in one XML-File. Every entry has it's
lang="en" or lang="de" attribute. I handle the language switch with a
requestparam which can be set on every request. The current language is then
stored in the session and available in a global variable called $lang. With
that I can also handle to load different Images for different languages.
If you're interessted I can provide you more informations!
regards,
Nils
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon and Internationalization
Posted by "John L. Webber" <Jo...@jentro.com>.
We're internationalizing in English and German (for now -- more
languages may come later); we generally use the practices recommended in
the Cocoon docs (master dictionary), but in addition, we split the
master dictionary into several parts, a main dictionary and a
subdictionary for each semantic area. The subdictionaries are
referenced in the main dictionary as entities. Splitting it up helps
keep things manageable if you have more than a couple of dozen
translation keys.
I also recommend writing tests to make sure you don't have any duplicate
keys, and if you use i18n parameters checking for mismatched brackets
(cost me 2 hours recently when this happened, Tomcat crashed every time
with an OutOfMemoryError without giving a clue where the actual problem
was).
I find it's hard after a while to keep the dictionaries up to date - old
translations that aren't used any more as the webapp evolves tend to
hang around. Anyone have any experience dealing with that?
John
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).
>
>
--
---------------------------------------------------------
Jentro Technologies GmbH
John L. Webber, Software Development
---------------------------------------------------------
Rosenheimer Str. 145e 81671 München
Tel. +49 89 189 169 80 mailto:John.Webber@jentro.com
Fax +49 89 189 169 99 http://www.jentro.com
---------------------------------------------------------
NOTICE: The information contained in this e-mail is confidential or may otherwise be legally privileged. It is intended for the named recipient only. If you have received it in error, please notify us immediately by reply or by calling the telephone number above and delete this message and all its attachments without any use or further distribution of its contents. Please note that any unauthorised review, copying, disclosing or otherwise making use of the information is strictly prohibited. Thank you.
---------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org