Thanks for response 1. Concerning aggregation: this is what I've done, I have added some bundles for en/fr locales. But it can't work with current implementation of InternationalizationManager: when you retrieve messages, you call getString() on each bundle (see http://code.google.com/p/aost/source/browse/trunk/core/src/main/groovy/org/tellurium/i18n/InternationalizationManager.groovy#103). But if iterated bundle does not contain key, a MissingResourceException is thrown and you do not continue with other bundles! I think you should catch MissingResourceException during iteration and only throw it if key is not found in all bundles. Otherwise I don't understand the point of aggregating bundles with same keys ?
2. Concerning setLocale(). This does not work dynamically: if bundles where loaded with 'en' locale and you call setLocale(Locale.FRENCH) after, you will not load french bundles. InternationalizationManager has to store bundles by locales. Maybe you could take a look at Spring i18N implementations (e.g. : https://src.springframework.org/svn/spring-maintenance/trunk/src/org/springframework/context/support/ReloadableResourceBundleMessageSource.java) 3. Besides, 'translate' is used for retrieving labels AND for converting date/numbers, which is even more ambiguous I've patched InternationalizationManager so it provides features I need, but I wish I switch back to trunk soon. Feel free to contact me if you want to discuss or test some features :-) Sylvain On 30 oct, 15:34, AJ R <[email protected]> wrote: > Hey Sylvain > > My reply is inline in blue font below > > > > On Fri, Oct 30, 2009 at 5:21 AM, syllant <[email protected]> wrote: > > > Hi all, > > > I had reported a request feature about implementing > > internationalization support (http://code.google.com/p/aost/issues/ > > detail?id=221&q=i18n), I see it's committed and documented for 0.7.0 > > snaphost(http://code.google.com/p/aost/issues/detail?id=221&q=i18n), > > great ;-) > > > However, I have some concerns about implementation: > > > 1. Management of multiple bundles is incorrect: > > InternationalizationManager#translate() methods do not handle case > > when bundle key is not found in some bundles, which makes this feature > > unusable according to me: you can't aggregate distinct messages from > > distinct bundles. This method should handle MissingResourceException. > > Actually you can aggregate distinct messages from different bundles. If you > go to this > linkhttp://code.google.com/p/aost/wiki/InternationalizationSupportTellurium > and scroll down to the section called "Internationalization Extension to > User defined tests" you will find how you can > add your own message bundle (use a function called addResourceBundle). > > The basic idea is that you can add as many distinct message bundles as long > as they are not called the same, and are not named "DefaultMessagesBundle" > since that is the default message bundle used in the core. > > Also if you dont find a key, it should throw a MissingResourceException. > > > > > 2. You don't allow to specify language when asking for a translation. > > It would be useful to be able to pass locale, either by adding > > optional locale parameter in translate method (translate('msgKey', > > Locale.FRENCH)), either by providing one InternationalizationManager > > instance by locale > > Yes this would definitely be a good additional feature to add, which I will > add as soon as I can. Although you can kinda do it right now, if you can > call setLocale() of the InternationalizationManager class. But i will > definitely add this functionality > > > 3. I find term 'translate' not totally relevant: it does not translate > > something, it just provides value for specified key. I think these > > methods should be named with someting like get() > > My intention of using translate was to signify that the English version of > the message was being translated to non english > But now that I think about it, your suggestion makes better sense. Let me > see what I can do about this. > ( translate just sounded cool :-) ) > > > > > 4. method BaseTelluriumJavaTestCase#geti18nManager() does not respect > > Java naming standard, it should be getI18nManager() > > > Yeah i agree, Will update the project soon. > > 5. It would be useful to allow to set a custom implementation of > > InternationalizationManager > > Yep definitely a good idea, will look into it. > > > > > Anyway, I go on with 0.7.0 snapshot, with patched implementation of > > InternationalizationManager for #1 issue. > > Thanks for trying this feature out. Please do let me know if you face any > problems or any of the functionalities are not working as desired. > > > > > Sylvain --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "tellurium-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/tellurium-users?hl=en -~----------~----~----~----~------~----~------~--~---
