cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enke, Michael" <>
Subject Re: [advice needed] New i18n implementation
Date Wed, 13 Nov 2002 09:25:09 GMT
Hi Konstantin,
nice to hear from you.
Because you asked for advise, I have a desire: Could you include an empty translation please.
At the time a construct like this one:
<message key="any"> </message>
results in a translation "empty translation" (or what is given in sitemap transformator initialization).
I wish to have the output of the transformer just " ", what I put between <message>
and </message>.
Actually I only comment out the trim() in XMLResourceBundle but I didn't found your agreement
to make this public, but maybe with this new version?


Konstantin Piroumian wrote:
> Hi all!
> I am back again from my inactivity caused by job change and Internet provider problems
and going to spend some time on finilizing the new implementation of i18n in Cocoon.
> So, I need an advice on the following points:
> 1. New features - new namespace.
> The new implementation of i18n transformer has several very useful new features but also
some backward incompatibilities, so I am going to change the namespace to use a new
> version number (2.1 instead of 2.0).
> I think, that this new implementation should go only into the 2.1-dev branch (HEAD) and
the question is what to do with the old one? What are the best practices in cases, when
> two namespaces can be present? Is it Ok to warn the users that the namespace has changed
and they should update their content or should I keep separate versions of
> I18nTransformer for each namespace?
> Personally, I'd drop the old one and maintain only the new implementation, but I'd like
to hear some other opinions.
> 2. Cachability.
> Currently, I have two implementations of the new version: cachable and not. As you can
guess the cachable implementation performs much better, cause it is cached after the first
> use, but in cases, when you have a dynamic content like the current date that is generated
by the <i18n:date*/> and <i18n:time/> tags then you'll have problems.
> So, the second questions is: is it a good idea to use a configuration parameter to control
the cachability of a component? Or there are better solutions from Avalon/Excalibur for
> such cases?
> Regards,
>   Konstantin Piroumian

To unsubscribe, e-mail:
For additional commands, email:

View raw message