I have written my own one, I was just pointing out that this might be a
common use case.
Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 10.05.2013 02:04, schrieb Gerhard Petracek:
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*
