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?
Regards,
Michael
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org