You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Scott Eade <se...@backstagetech.com.au> on 2007/06/27 07:01:42 UTC
Localization fun
I know a number of the active developers have localized applications, so
I am hoping to pick your brains for a few hints to help me along my way...
Do you always rely on the Accept-Language header provided by the browser
or do you allow your users to select their own language to override this?
Off-line processing (sending emails, etc.) basically means that I need
access to the user's selected language even when they are not logged in.
Using a language value stored against the user means that I end up with
bunches of Localization.format(Localization.getDefaultBundleName(),
user.getLocale(), key, arg1...) crap in my code. For templates,
LocalizationTool is currently a PITA because init() is declared as
final, so it is not currently possible to extend it to provide a
different means of specifying the locale. In my app I am thinking of
doing all of the localization via my user class where I have access to
the selected locale, I can then go user.getL10n(key, arg1) - a lot less
verbose and the localization implementation is then only invoked from a
few places in this one class. In templates I can either go
$data.User.getL10n(key) or fix LocalizationTool to allow me to extend it
so that it can pull the locale out of the user object. Does this sound
like a reasonable approach?
Are you localizing your intake messages? I assume this is just a matter
of using a l10n bundle key in the error message and processing it
accordingly.
Thanks for any ideas,
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Localization fun
Posted by Scott Eade <se...@backstagetech.com.au>.
Thomas Vandahl wrote:
> Scott Eade wrote:
>
>>> (Just a side note: If you feel tempted to use Localization in your
>>> Java code, think again. There may be places where this is unavoidable
>>> but mostly it isn't.)
>>>
>> I find I need to do this when I:
>>
>> * do some validation in my action class that requires giving
>> feedback to the user
>> * provide a successful operation message to the user from my action
>> class
>>
>
> I usually set data.setMessage(LOCALIZATION_KEY) when to report
> something. If more information needs to be given, I mis-use the
> DebugVariables of RunData. One place where I found the direct
> Localization necessary is a dynamically assembled string like the
> summary of a search forms content (like in: "You were searching for
> Name=foo, Type=bar"
>
Excellent - I can apply the same idea as below to pull the l10n
processing out of the action classes.
Abusing DebugVariables in the manner suggested seems like a valid
approach, but in many cases the space delimited variables approach would
avoid the need to do this I think. In your last example the varying
parameters could be a case where something like that needs to be done -
a specific key prefix could be used to indicate that the variables need
to be retrieved from DebugVariables (or even from the context using a
specific key prefix).
>> So intake.xml can have:
>> <field name="OldPwd" key="opwd" type="String">
>> <rule name="required" value="false">intake.rule.required</rule>
>> <rule name="maxLength" value="16">intake.rule.maxLength 16</rule>
>> </field>
>> with:
>> intake.rule.required=Please enter a value.
>> intake.rule.maxLength=Please enter a maximum of {0} character(s).
>>
>> Simple idea, seems to work.
>>
>
> That looks interesting. I need to check if it would work for us, too.
> Thanks for the hint.
>
The joy of open source collaborative development!
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Localization fun
Posted by Thomas Vandahl <tv...@apache.org>.
Scott Eade wrote:
>> (Just a side note: If you feel tempted to use Localization in your
>> Java code, think again. There may be places where this is unavoidable
>> but mostly it isn't.)
> I find I need to do this when I:
>
> * do some validation in my action class that requires giving
> feedback to the user
> * provide a successful operation message to the user from my action
> class
I usually set data.setMessage(LOCALIZATION_KEY) when to report
something. If more information needs to be given, I mis-use the
DebugVariables of RunData. One place where I found the direct
Localization necessary is a dynamically assembled string like the
summary of a search forms content (like in: "You were searching for
Name=foo, Type=bar"
> So intake.xml can have:
> <field name="OldPwd" key="opwd" type="String">
> <rule name="required" value="false">intake.rule.required</rule>
> <rule name="maxLength" value="16">intake.rule.maxLength 16</rule>
> </field>
> with:
> intake.rule.required=Please enter a value.
> intake.rule.maxLength=Please enter a maximum of {0} character(s).
>
> Simple idea, seems to work.
That looks interesting. I need to check if it would work for us, too.
Thanks for the hint.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Localization fun
Posted by Scott Eade <se...@backstagetech.com.au>.
Thanks for the info Thomas.
Thomas Vandahl wrote:
> In LocalizationTool, init() may be final but locale is protected. So
> my suggestion would be to override the Locale setting
> (refresh(Rundata) comes to mind) in a derived class and to configure
> LocalizationTool as a session tool (which would bypass the
> initialization with the request). Do you think that could be it?
>
> LocalizationTool needs fixing anyway, so go ahead. I do think that
> generally, "final" is not a good modifier for methods in a framework,
> anyway (See Turbine.doGet()).
Easier to get rid of the final, and as a side effect I am now free to
use a different scope.
>
> (Just a side note: If you feel tempted to use Localization in your
> Java code, think again. There may be places where this is unavoidable
> but mostly it isn't.)
I find I need to do this when I:
* do some validation in my action class that requires giving
feedback to the user
* provide a successful operation message to the user from my action
class
> Scott Eade wrote:
>> Are you localizing your intake messages? I assume this is just a
>> matter of using a l10n bundle key in the error message and processing
>> it accordingly.
> Yes. I have INTAKE* message keys which are translated using
> LocalizationTool.
In my new LocalizationTool I have:
/**
* Formats a localized intake value.
*
* @param keyData The identifier for the localized text to retrieve
plus any
* argument data - space separated. This will only be processed if it
* begins with "intake.", otherwise the input value will be returned.
*/
public String formatIntake(String keyData)
{
if (keyData.startsWith("intake."))
{
String key = null;
List args = new ArrayList();
for (Iterator st = new StrTokenizer(keyData); st.hasNext();)
{
String element = (String) st.next();
if (null == key)
{
key = element;
}
else
{
args.add(element);
}
}
return Localization.format(getBundleName(null), getLocale(),
key, args.toArray());
}
// keyData does not contain a l10n key.
return keyData;
}
So intake.xml can have:
<field name="OldPwd" key="opwd" type="String">
<rule name="required" value="false">intake.rule.required</rule>
<rule name="maxLength" value="16">intake.rule.maxLength 16</rule>
</field>
with:
intake.rule.required=Please enter a value.
intake.rule.maxLength=Please enter a maximum of {0} character(s).
Simple idea, seems to work.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: Localization fun
Posted by Thomas Vandahl <th...@tewisoft.de>.
Hi Scott,
Scott Eade wrote:
> Do you always rely on the Accept-Language header provided by the browser
> or do you allow your users to select their own language to override this?
Yes. We always use the Accept-Language header.
> different means of specifying the locale. In my app I am thinking of
> doing all of the localization via my user class where I have access to
> the selected locale, I can then go user.getL10n(key, arg1) - a lot less
> verbose and the localization implementation is then only invoked from a
> few places in this one class. In templates I can either go
> $data.User.getL10n(key) or fix LocalizationTool to allow me to extend it
> so that it can pull the locale out of the user object. Does this sound
> like a reasonable approach?
In LocalizationTool, init() may be final but locale is protected. So my
suggestion would be to override the Locale setting (refresh(Rundata)
comes to mind) in a derived class and to configure LocalizationTool as a
session tool (which would bypass the initialization with the request).
Do you think that could be it?
LocalizationTool needs fixing anyway, so go ahead. I do think that
generally, "final" is not a good modifier for methods in a framework,
anyway (See Turbine.doGet()).
(Just a side note: If you feel tempted to use Localization in your Java
code, think again. There may be places where this is unavoidable but
mostly it isn't.)
> Are you localizing your intake messages? I assume this is just a matter
> of using a l10n bundle key in the error message and processing it
> accordingly.
Yes. I have INTAKE* message keys which are translated using
LocalizationTool.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org