You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Daniel Rall <dl...@finemaltcoding.com> on 2001/10/16 06:23:40 UTC
quick comparison of localization tools
"jaco@libero.it" <ja...@libero.it> writes:
> These are the main features (and concepts) of my localization pull tool:
>
> a) a web application can have the language (Locale) set at four
> different levels:
> 1) user temporary language: a language chosen by the user for the
> current session (setTemp)
> 2) user permanent language: a language chosen by the user as a
> default language (setPerm)
> 3) application (context): usually only the admin can set this level
> 4) default value from the TurbineResources.properties (the one set by
> the standard loc service)
> if the tool finds a temporary language then uses it; if not, try to
> get and use the permanent language; and so on... and this process is
> hidden by the tool: from within a template you has only to call a
> $loc.text("USER")
The request-scoped LocalizationTool (LT) developed for Turbine 3 (now
backported to 2.x) uses the Accept-Language HTTP header supplied by
the client's user agent to automatically negotiate the correct Locale.
LT falls back to the default Locale information specified in the
TurbineResources.properties file if a Locale cannot be automatically
negotiated.
I like your additional Locale negotation hooks, and think that they'd
be a good addition to LT if they can be setup to also automatically
negotiate Locale.
> b) you can set ($loc.setPage("LOGIN")) at template level a prefix for
> the keys searched in the bundle.
That's a nice feature as well. I'll add that one in my copious spare
time.
> c) you can use four different $loc.text(..) methods: some of them
> return specified default values if the keys are not found, some of them
> use a different key prefix.
This requires more effort on the part of the user, effort which I do
not want as part of doing simple text lookups in the view. I much
prefer to keep the context API dead simple, such as $l10n.MY_KEY,
which in turn invokes LT.get("MY_KEY").
> d) if a key is not found a very usefull debug message is provided in
> place of the missing label (no more template errors): the debug message
> can be configured in the TR.properties file and is in the form
> ERROR_MESSAGE(key_not_found)
I took a slightly different approach. If a key value cannot be looked
up, null is returned. With Velocity, this works very well, as the the
markup renders literally (i.e. "$l10n.MY_KEY" renders as exactly that).
There's definitely some value in being able to return alternate error
text. I think I'll add that to LT as well.
Thanks for the great description, Jacopo.
- Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: quick comparison of localization tools
Posted by Daniel Rall <dl...@finemaltcoding.com>.
I've moved this list of TODO items into the source file in the 3.x
tree.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: quick comparison of localization tools
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Daniel Rall <dl...@finemaltcoding.com> writes:
>>> > b) you can set ($loc.setPage("LOGIN")) at template level a prefix for
>>> > the keys searched in the bundle.
>>>
>>> That's a nice feature as well. I'll add that one in my copious spare
>>> time.
>
> I think I can wiggle this in as automatically set in refresh().
Excuse me, init(Object) would be the right place for this. However, I
think this might be done best by subclassing the LT in Turbine. I
added some commentary to this affect in the partial refactoring I just
checked in.
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: quick comparison of localization tools
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Daniel Rall <dl...@finemaltcoding.com> writes:
>>> > c) you can use four different $loc.text(..) methods: some of them
>>> > return specified default values if the keys are not found, some of them
>>> > use a different key prefix.
>>>
>>> This requires more effort on the part of the user, effort which I do
>>> not want as part of doing simple text lookups in the view. I much
>>> prefer to keep the context API dead simple, such as $l10n.MY_KEY,
>>> which in turn invokes LT.get("MY_KEY").
>>
>> You are right!!! This is a great quality of your tool and has to be the MAIN
>> method to retrieve a text...
>> but I think that some of my methods could be useful in some circumstances
>> (e.g. if you have set a page prefix and you want to retrieve a generic text,
>> with a different prefix)
>
> Agreed. There must definitely be a method for retrieving the values
> keyed by prefix-less keys when a key prefix is set.
What's the best interface for such a method? Here's a few
suggestions:
public String get(String key, String prefix)
public String get(String prefix, String key)
public String getWithoutPrefix(String key) // method name open to comment
Note that the default method's signature is as follows:
public String get(String key)
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: quick comparison of localization tools
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Jacopo Cappellato" <ja...@libero.it> writes:
> Hi Daniel,
>
> and thank you for your considerations!
>
> I'm happy to read that you have appreciated some of my ideas: I can send you
> the source siles, if you think this could useful for you... let me know.
You're welcome, Jacopo. It's always nice to to hear about other
approaches. I wouldn't mind looking over your source files.
>> The request-scoped LocalizationTool (LT) developed for Turbine 3 (now
>> backported to 2.x) uses the Accept-Language HTTP header supplied by
>> the client's user agent to automatically negotiate the correct Locale.
>> LT falls back to the default Locale information specified in the
>> TurbineResources.properties file if a Locale cannot be automatically
>> negotiated.
>>
>> I like your additional Locale negotation hooks, and think that they'd
>> be a good addition to LT if they can be setup to also automatically
>> negotiate Locale.
>
> Maybe the best solution is that of adding your automatic language
> negotiation between step 3 and 4, i.e:
> 1) user temporary language
> 2) user permanent language
> 3) application context language
> 4) AUTOMATIC LANGUAGE NEGOTIATION
> 5) default TR locale
> In this way, if a developer is not interested in using my hooks, the tool
> can be used exactly in the same way as the original Turbine 3 localization
> pull tool.
That's the right spot for it. Step 5 is actually part of step 4 in
3.x (not sure whether I backported that to the 2.x module or not).
>> > b) you can set ($loc.setPage("LOGIN")) at template level a prefix for
>> > the keys searched in the bundle.
>>
>> That's a nice feature as well. I'll add that one in my copious spare
>> time.
I think I can wiggle this in as automatically set in refresh().
>> > c) you can use four different $loc.text(..) methods: some of them
>> > return specified default values if the keys are not found, some of them
>> > use a different key prefix.
>>
>> This requires more effort on the part of the user, effort which I do
>> not want as part of doing simple text lookups in the view. I much
>> prefer to keep the context API dead simple, such as $l10n.MY_KEY,
>> which in turn invokes LT.get("MY_KEY").
>
> You are right!!! This is a great quality of your tool and has to be the MAIN
> method to retrieve a text...
> but I think that some of my methods could be useful in some circumstances
> (e.g. if you have set a page prefix and you want to retrieve a generic text,
> with a different prefix)
Agreed. There must definitely be a method for retrieving the values
keyed by prefix-less keys when a key prefix is set.
>> > d) if a key is not found a very usefull debug message is provided in
>> > place of the missing label (no more template errors): the debug message
>> > can be configured in the TR.properties file and is in the form
>> > ERROR_MESSAGE(key_not_found)
>>
>> I took a slightly different approach. If a key value cannot be looked
>> up, null is returned. With Velocity, this works very well, as the the
>> markup renders literally (i.e. "$l10n.MY_KEY" renders as exactly that).
>>
>> There's definitely some value in being able to return alternate error
>> text. I think I'll add that to LT as well.
>
> As you probably have noticed, I'm not a velocity expert at all; I think that
> your approach is better than mine... maybe the (optional) alternate error
> text could be set as a property in TR and, if not present, null could be
> returned for missing keys.
Definitely the most flexible way to configure it, so long as the key
value can be used in the error message configured via TR.props (my
preference), or is supplied in some fashion when the LT error message
from TR.props is used (seems somewhat clunky).
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: quick comparison of localization tools
Posted by Jacopo Cappellato <ja...@libero.it>.
Hi Daniel,
and thank you for your considerations!
I'm happy to read that you have appreciated some of my ideas: I can send you
the source siles, if you think this could useful for you... let me know.
By the way, I've got something to say about your mail:
----- Original Message -----
From: Daniel Rall <dl...@finemaltcoding.com>
To: <tu...@jakarta.apache.org>
Sent: Tuesday, October 16, 2001 6:23 AM
Subject: quick comparison of localization tools
> "jaco@libero.it" <ja...@libero.it> writes:
>
> > These are the main features (and concepts) of my localization pull tool:
> >
> > a) a web application can have the language (Locale) set at four
> > different levels:
> > 1) user temporary language: a language chosen by the user for the
> > current session (setTemp)
> > 2) user permanent language: a language chosen by the user as a
> > default language (setPerm)
> > 3) application (context): usually only the admin can set this level
> > 4) default value from the TurbineResources.properties (the one set by
> > the standard loc service)
> > if the tool finds a temporary language then uses it; if not, try to
> > get and use the permanent language; and so on... and this process is
> > hidden by the tool: from within a template you has only to call a
> > $loc.text("USER")
>
> The request-scoped LocalizationTool (LT) developed for Turbine 3 (now
> backported to 2.x) uses the Accept-Language HTTP header supplied by
> the client's user agent to automatically negotiate the correct Locale.
> LT falls back to the default Locale information specified in the
> TurbineResources.properties file if a Locale cannot be automatically
> negotiated.
>
> I like your additional Locale negotation hooks, and think that they'd
> be a good addition to LT if they can be setup to also automatically
> negotiate Locale.
>
Maybe the best solution is that of adding your automatic language
negotiation between step 3 and 4, i.e:
1) user temporary language
2) user permanent language
3) application context language
4) AUTOMATIC LANGUAGE NEGOTIATION
5) default TR locale
In this way, if a developer is not interested in using my hooks, the tool
can be used exactly in the same way as the original Turbine 3 localization
pull tool.
> > b) you can set ($loc.setPage("LOGIN")) at template level a prefix for
> > the keys searched in the bundle.
>
> That's a nice feature as well. I'll add that one in my copious spare
> time.
>
> > c) you can use four different $loc.text(..) methods: some of them
> > return specified default values if the keys are not found, some of them
> > use a different key prefix.
>
> This requires more effort on the part of the user, effort which I do
> not want as part of doing simple text lookups in the view. I much
> prefer to keep the context API dead simple, such as $l10n.MY_KEY,
> which in turn invokes LT.get("MY_KEY").
>
You are right!!! This is a great quality of your tool and has to be the MAIN
method to retrieve a text...
but I think that some of my methods could be useful in some circumstances
(e.g. if you have set a page prefix and you want to retrieve a generic text,
with a different prefix)
> > d) if a key is not found a very usefull debug message is provided in
> > place of the missing label (no more template errors): the debug message
> > can be configured in the TR.properties file and is in the form
> > ERROR_MESSAGE(key_not_found)
>
> I took a slightly different approach. If a key value cannot be looked
> up, null is returned. With Velocity, this works very well, as the the
> markup renders literally (i.e. "$l10n.MY_KEY" renders as exactly that).
>
> There's definitely some value in being able to return alternate error
> text. I think I'll add that to LT as well.
>
As you probably have noticed, I'm not a velocity expert at all; I think that
your approach is better than mine... maybe the (optional) alternate error
text could be set as a property in TR and, if not present, null could be
returned for missing keys.
>
> Thanks for the great description, Jacopo.
>
Thanks for your suggestions; please let me know what you think about this
message.
Best regards,
Jacopo
> - Daniel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org