[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
