You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Mattias J <mj...@expertsystem.se> on 2005/04/21 15:40:41 UTC
[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
Re: [i18n] Providers behave different
Posted by Mattias J <mj...@expertsystem.se>.
I have now e-mailed the test cases and the proposed refactoring (to make
each data source have it's own provider instance, in preparation for
qualified entries). I also have some ideas for further refactoring, which
might make it easier to solve the problems below.
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: 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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
AW: [i18n] Providers behave different
Posted by Daniel Florey <da...@web.de>.
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