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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
