cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: Bring the new I18NMatcher in line with LocaleAction [Bug 30046]
Date Thu, 12 Aug 2004 18:19:38 GMT
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. :-)


> 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.

Vadim


Mime
View raw message