"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
