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
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*
