forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sjur Moshagen <sju...@mac.com>
Subject Re: Dispatcher i18n update + three more issues
Date Wed, 27 Sep 2006 08:09:41 GMT
[WARNING - long e-mail]

Den 26. sep. 2006 kl. 12.37 skrev Ross Gardler:

> This brings me back to the idea of using the locationmap for locale  
> matching rather than Cocoons components, which have their problems  
> in our use case. Something like (be warned, I've not fully thought  
> this through and do not have any i18n sites, I'm not at all sure  
> this will work in the real world):
>
> <match pattern="**.xml">
>     <location src="{project:xdocs}/{1}.{2}.xml/>
> </location>
>
> <match pattern="**.*.xml">
>   <select>
>     <location src="{project:xdocs}/{1}.{2}.xml/>
>     <location src="{project:xdocs}/{1}.{project:locale.default}.xml/>
>   </select>
> </location>

I have been thinking about the LM solution a bit, and here are some  
thoughts (some of these may be unneeded, but I do not understand or  
know the LM, thus this is as well a way for me to clear my thoughts):

Goal: change the localised URL from the 'index.html?locale=XY'  
pattern to something along 'index.XY.html when overriding browser  
locale settings.

I see no point in removing the present i18n processing, replacing it  
completely with LM; instead I hope we can use the LM to overcome the  
URL problem above. Thus, the Cocoon components and the LM should be  
able to coexist. They both have their use cases (see discussion below).

There are four possible combinations of URLs and files:

1 - URL is localised - file is localised
2 - URL is localised - file is not
3 - URL is not localised - file is
4 - URL is not localised - file is not

1 - URL is localised - file is localised
========================================

Use case: the user has selected a language override from a list, or  
has manually edited the URL to try other languages

Assumption: there is a match between requested locale and available  
locale (non-match is covered by case 2)

Actions:
* return the corresponding localised file, using LM
* use the identified locale for all i18n processing of menus, tabs  
and messages
* make sure the non-localised URL is given the menu and tab  
processing (otherwise the menu system breaks down)
* store the identified locale in the session (such that the next page  
requested will be given in the same locale, if available) (this might  
be dependent upon configuration)

2 - URL is localised - file is not
==================================

Use cases:
1 - the user has selected a language override from a list
2 - the user has manually edited the URL to try other languages

In the first use case it means that the localised URL corresponds to  
the fallback file.
In the second case it most often means that there is no corresponding  
localised file - we need to gracefully handle this situation

Actions:
* check the content of the fall-back file for @xml:lang
** if the fallback document corresponds to the requested locale,  
return it
** if not, fall back to regular negotiation using the browser  
settings - optionally throw an error saying that the document isn't  
available in the requested language (which one to use could depend on  
a setting)
* use the identified locale for all i18n processing of menus, tabs  
and messages
* make sure the non-localised URL is given the menu and tab  
processing (otherwise the menu system breaks down)
* store the identified locale in the session (such that the next page  
requested will be given in the same locale, if available) (this might  
be dependent upon configuration)

3 - URL is not localised - file is
==================================

Use cases:
1 - the user is entering the site - traditional negotiation should apply
2 - the user is entering a new page after a locale selection - the  
locale should be picked from the session if available

1) is what we do today with the Cocoon modules, 2) is just a  
variation of 1.

Actions:
* return the corresponding localised file (Cocoon i18n components)
* use the identified locale for all i18n processing of menus, tabs  
and messages
* store the identified locale in the session (such that the next page  
requested will be given in the same locale, if available) (this might  
be dependent upon configuration)

4 - URL is not localised - file is not
======================================

Use case: this is the fallback case - no match found, return the  
default/fallback.

Actions:
* return the fallback file (Cocoon i18n components)
* use the fallback locale for all i18n processing of menus, tabs and  
messages, to give a consistent view of the page (all elements in the  
same language) (should this be depending on a setting, thus allowing  
menus etc to be in the user's preferred language, even though the  
document is not?)
* do NOT store the document locale in the session - the next time the  
user returns to a page in the preferred locale, that one should be used

It is combinations 1 & 2 that are problematic from a URL POV, and  
this is where we will need the LM.

Work to be done:
- figure out whether the solution sketched here will actually work,  
or whether another approach should be taken
- enhance all document lookups with a locationmap variant for cases  
where the URL is of pattern **.*.* ({0} = document ref, {1} = locale,  
{2} = extension) - this will likely collide with existing patterns  
for internal matches, and needs thorough consideration
- figure out how to set the session locale from a LM/i18n match
- adapt the menu and tab processing (this is probably a subset of the  
first task)

This is a lot of work, and I will not be able to do all of this, both  
in terms of time and knowledge. The first question is easy enough  
though:

WDYT?

Sjur


Mime
View raw message