cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira>
Subject Re: Bring the new I18NMatcher in line with LocaleAction [Bug 30046]
Date Thu, 12 Aug 2004 20:55:37 GMT
Vadim Gritsenko wrote:

> Upayavira wrote:
>> Vadim Gritsenko wrote:
>>> What I would like to do is to come up with approach which will unify 
>>> these two together, by making I18nMatcher closer to LocaleAction, 
>>> or, if you have suggestion, by enhancing LocaleAction.
>> It would be good to see them unified, but I can't yet see how - as, 
>> at least at the moment, their use cases are quite different. And at 
>> the mo, I'm okay with the difference.
> >
>> The thing is, I have a site that has maybe 100 pages. We are trying 
>> to get people to translate it - we've got Polish now, Chinese and 
>> Hindi are probably on the way (why not French and German first :-(   
>> ), but the translators will not translate everything. So the site has 
>> to be able to gracefully downgrade to the next best language when a 
>> page hasn't been translated (in most cases English).
> Hmmm. Idea: How about implementing advanced mode for LocaleAction 
> which would negotiate locale based on client request and i18n 
> catalogue you have? This would bring it step closer to I18nMatcher. :-)
Sounds fine :-)

>> I guess we could add a configuration parameter to the definition of 
>> the matcher, to change the way it searches for sources, and to store 
>> the result in the session, for compatibility with LocaleAction. I'd 
>> be okay with that, so long as the other approach is available too!
> Ok, let's then implement two modes:
>  (a) Same as in LocaleAction.
>  (b) Same as now.
> And, optionally, results can be saved into session/cookie/etc.

Fine by me too!

If it helps to make them work more similarly, I'd be happy for the
current behaviour of the i18nmatcher to be the 'advanced' mode, as it
would be on the locale action. Does that help?

Regards, Upayavira

View raw message