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 <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 16, 2001 6:23 AM
Subject: quick comparison of localization tools
> "[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.
>
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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
