You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@deltaspike.apache.org by Christian Beikov <ch...@gmail.com> on 2013/05/09 22:55:02 UTC
I18N Module
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*
Re: I18N Module
Posted by Christian Beikov <ch...@gmail.com>.
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 <ch...@gmail.com>
>
>> 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 <ge...@gmail.com>
>>>
>>> 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 <ch...@gmail.com>
>>>>
>>>> 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*
>>>>>
>>>>>
Re: I18N Module
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <ch...@gmail.com>
> 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 <ge...@gmail.com>
>>
>> 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 <ch...@gmail.com>
>>>
>>> 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*
>>>>
>>>>
>>>
>
Re: I18N Module
Posted by Christian Beikov <ch...@gmail.com>.
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 <ge...@gmail.com>
>
>> 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 <ch...@gmail.com>
>>
>>> 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*
>>>
>>
Re: I18N Module
Posted by Gerhard Petracek <ge...@gmail.com>.
i've attached a first draft to [1].
regards,
gerhard
[1] https://issues.apache.org/jira/browse/DELTASPIKE-360
2013/5/9 Gerhard Petracek <ge...@gmail.com>
> 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 <ch...@gmail.com>
>
>> 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*
>>
>
>
Re: I18N Module
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <ch...@gmail.com>
> 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*
>