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