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 Wed, 11 Aug 2004 09:36:11 GMT
Vadim Gritsenko wrote:

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

Correct. The LocaleAction, in my mind, is good for sites where you have 
_everything_ translated into all of your languages. The I18nMatcher 
handles situations (as does httpd) where you don't necessarily.

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

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

Well, I wouldn't use it like that! I'd do:
<map:match pattern="source/*/foo.xml">
  <map:generate src="{source}"/>
  <map:transform src="add-images-to-your-page.xsl">
    <map:parameter name="locale" value="{locale}"/>
  <map:serialize type="html"/>

So you use the locale found by the i18n matcher to view resources on 
that page.

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

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). Actually, ideally, in such a 
situation, it would say, e.g. in Polish "Sorry, this page wasn't 
available in Polish. Here is the English version instead".

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!

Can you say more about your concerns and how the i18nmatcher doesn't 
work for you?

Regards, Upayavira

View raw message