cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Bring the new I18NMatcher in line with LocaleAction [Bug 30046]
Date Wed, 11 Aug 2004 01:44:03 GMT
Upayavira wrote:

> bugzilla@apache.org wrote:
> 
>> <http://issues.apache.org/bugzilla/show_bug.cgi?id=30046>.
 >>
>> ------- Additional Comments From vgritsenko@apache.org  2004-08-09 
>> 14:34 -------
>> Added code for checking locale stored in session and in cookie. Full 
>> locale
>> checking order now is:
>> * request parameter
>> * session attribute
>> * cookie
>> * sitemap parameter
>> * request locale(s) - optional, depends on use-locale(s) config 
>> parameters.
>> * default
>> * blank
>>
>> LocaleAction supports same order but has no sitemap parameter, and has no
>> default locale, and blank locale (because request locale checking is not
>> optional - and will always return some non null locale).
>>
>> Now, about setting locale into the request/session/cookie: this is not 
>> as simple
>> as it looks. Problem is that LocaleAction selects first available 
>> locale, but
>> I18nMatcher goes through *all* available locales till it finds matching
>> resource. Thus, for one resource it can result in one locale, and for 
>> other
>> resource - in other locale, so locale returned by I18nMatcher can not 
>> be used
>> for setting into session/cookie.
>>
>> I18nMatcher can be changed to be two-step procedure, (1) select 
>> locale, (2)
>> using selected locale search for resource in this locale (with variant ->
>> country -> language -> blank degradation). This modified I18nMatcher 
>> will be
>> more compatible with LocaleAction, and then it can be modified to set 
>> chosen
>> locale into session/cookie.
>>  
>>
> (on train - can't reply through Bugzilla)

It's Ok as long as you reply :-)


> I don't quite understand how your two stage procedure would work. As the 
> selection of the locale is fundamentally connected with the available 
> resources.

I understand what you mean.


> As you work through each method for selecting a locale, you 
> look for a resource using that method, if found, you exit. Otherwise, 
> you try the next method, and if necessary, you degrade from 
> variant/country/language, etc. How could this be done as separate select 
> locale/select resource stages?

The problem I'm trying to communicate is disconnect between LocaleAction 
and I18nMatcher. LocaleAction chooses a locale with disregard to the 
availability of the resources. Originally I thought that I18nMatcher is 
a nice shortcut combining LocaleAction and resource selection:

   <map:act type="locale">
     <map:select type="resource-exist">
       <map:when test="{../1}_{language}_{country}-{variant}.xml">
         <map:generate src="{../1}_{language}_{country}-{variant}.xml"/>
       </map:when>
       <map:when test="{../1}_{language}_{country}.xml">
         <map:generate src="{../1}_{language}_{country}.xml"/>
       </map:when>
       <map:when test="{../1}_{language}.xml">
         <map:generate src="{../1}_{language}.xml"/>
       </map:when>
       <map:otherwise>
         <map:generate src="{../1}.xml"/>
       </map:otherwise>
     </map:select>
   </map:act>

As you see, here locale selection step and resource selection steps are 
well separated: first you select locale, and only for this locale you go 
and try to locate a matching resource using (up to) 3 variations of this 
locale.

In I18nMatcher as it is implemented now, it goes through all locales, 
and within each locale, through three variations of locale, and tries to 
locate a matching resource. Thus, due to this difference in 
implementation, following is not possible:

  * Implementing "set locale" functionality in the I18nMatcher.
    (because request for another resource can result in another locale)
  * Mix and match LocaleAction and I18nMatcher in same application.
    (LocaleAction remembers selected locale, I18nMatcher does not. And,
     selection algorithm does not match)

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.


However, I have trouble understanding how I18nMatcher suppose to work in 
practice when it mixes different locales for the same user. Let's go 
through simple use case:
  * Browser has configuration:
     Accept-Language: en, fr
  * Site has resources:
     image/en/a.gif
     image/fr/a.gif
     image/fr/b.gif
     image/b.gif
  * Site has page:
     <html><img src="a.gif"/><img src="b.gif"/></html>

Now, question: What would you expect to see? What would your graphics 
designer expect to see (especially if he uses text - in - graphics)?

Vadim


Mime
View raw message