From: "Enke, Michael" <[EMAIL PROTECTED]> > 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?
Yes, I remember your request, it is even listed in the ToDo list somewhere in docs. I'll take a look at it too. In the new implementation there should be no trim(), because XMLResourceBundle returns Nodes and not Strings. Hope that empty translations should now be possible. Another minor addition is: allowed CDATA sections, though I've tried them only for attribute translations. The work is not finished yet, but I'll commit it, so interested parties could try it and patch if needed. Regards, Konstantin > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
