My suggestion is that you first have a look at my tests and refactorings and incorporate it into the SVN, after that we discuss my new ideas and then we solve these problems.
At 2005-04-24 12:05, Daniel Florey:
This really needs to be changed. What is the most desirable behaviour for these cases? I'd suggest including the missing entries defined for the default locale if the entries for another language are requested. So the XMLMessageProvider needs to be changed. Or makes it sense to have two different methods for this? For the latter issue I need to have a closer look at the code. Thanks for reporting these important issues! Daniel
BTW: I'm back home. If you want me to add your testcases just mail the zip file to me.
> -----Urspr�ngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Im Auftrag von Mattias J > Gesendet: Donnerstag, 21. April 2005 15:41 > An: [email protected] > Betreff: [i18n] Providers behave different > > It seems that the ResourceBundleMessageProvider and the XMLMessageProvider > behaves differently when an entry does not exist in a non-default > language. > With ResourceBundles, if I have an entry, say > helloWorld.notTranslated=This entry is not translated to any other > languages > that only exists in the default locale file, the entry will be included > when calling getEntries() for *any* locale. > > Whereas for XML, only the entries defined for the given locale will be > returned. > > Furthermore if the id ("parent") exists, but the entry ("child") does not, > the ResourceBundleMessageProvider throws an exception (erroneously > claiming > "No message entries found for bundle with key ..."), while the > XMLMessageProvider returns null. > > Daniel, I assume the first issue is not intended but only a consequence of > the most obvious implementation? > Does either need to be changed? > > Mattias Jiderhamn > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
