Thanks Syllant. Please feel free to post your patch here or send to us directly. We like to see if we can apply the patch to the trunk.
Thanks, Jian On Oct 30, 11:13 am, syllant <[email protected]> wrote: > 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 > (seehttp://code.google.com/p/aost/source/browse/trunk/core/src/main/groov...). > 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/...) > > 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 -~----------~----~----~----~------~----~------~--~---
