commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Florey" <daniel.flo...@web.de>
Subject AW: [i18n] Providers behave different
Date Sun, 24 Apr 2005 10:05:44 GMT
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: commons-dev-return-70528-daniel.florey=web.de@jakarta.apache.org
> [mailto:commons-dev-return-70528-daniel.florey=web.de@jakarta.apache.org]
> Im Auftrag von Mattias J
> Gesendet: Donnerstag, 21. April 2005 15:41
> An: commons-dev@jakarta.apache.org
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message