like MessageContext#messageSource(/*list*/), we would need MessageContext#supportedLocale(/*list*/) -> the MessageResolver has to do the correct handling (like it does for message-sources).
that wouldn't solve your use-case (due to >multiple dynamic< fallbacks) -> you would need a custom MessageResolver. regards, gerhard 2013/5/10 Christian Beikov <[email protected]> > If you don't localize your texts properly you will always sooner or later > end up with differently localized messages. > In my application I know for every set of texts, in what languages they > are available. I also have a prioritized set of locale preferrences that > are orderd like: > > 1. user locale > 2. company locale > 3 - (n - 1): locales sent by the browser > n. default locale > > I resolve the locale that should be used by considering these two sets and > returning the best match. When the locales that are supported are not known > it's just not possible to use my resolving algorithm. So probably something > like the following would suite the LocaleResolver interfaces a bit more? > > public Locale getLocale(Collection<Locale> supportedLocales); > > > Mit freundlichen Grüßen, > ------------------------------**------------------------------** > ------------ > *Christian Beikov* > Am 10.05.2013 00:09, schrieb Gerhard Petracek: > >> i've attached a first draft to [1]. >> >> regards, >> gerhard >> >> [1] >> https://issues.apache.org/**jira/browse/DELTASPIKE-360<https://issues.apache.org/jira/browse/DELTASPIKE-360> >> >> >> >> 2013/5/9 Gerhard Petracek <[email protected]> >> >> hi christian, >>> >>> you could end up with a mixture of messages easily. >>> what you would need is a LocalResolver which checks the current locale >>> (based on a list of supported locals + a default locale). >>> >>> regards, >>> gerhard >>> >>> >>> >>> 2013/5/9 Christian Beikov <[email protected]> >>> >>> Hello there, >>>> >>>> I was just about to configure the I18N module for my needs and hit a >>>> limitation. The LocalResolver can only return a single Locale which is >>>> somehow bad. Normally you have various preferences. Are you going to add >>>> something like: >>>> >>>> public Iterable<Locale> getLocales() >>>> >>>> to LocaleResolver or is the current design intended to be kind of final? >>>> -- >>>> >>>> Mit freundlichen Grüßen, >>>> ------------------------------****----------------------------**--** >>>> ------------ >>>> *Christian Beikov* >>>> >>>> >>> >
