Bring the new I18NMatcher in line with LocaleAction [Bug 30046]

[Vadim Gritsenko]

Upayavira wrote:
[EMAIL PROTECTED] wrote:
<http://issues.apache.org/bugzilla/show_bug.cgi?id=30046>.
>>
------- Additional Comments From [EMAIL PROTECTED]  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