På 9. jul. 2004 kl. 13.12 skrev Upayavira:

The way it is currently coded, if de_AU was not found, it wouldn't find de. Which is not ideal. I'll extend it so that for ru_EE-KOI8 it will try:
* ru_EE-KOI8
* ru_EE
* ru
in turn. Is that the correct behaviour?

Yes.

This way it is possible for the subsequent i18n processing to cater for country-(or whatever)-specific requirements in menus etc. without the document itself necessarily being adjusted for such variation.

Then, we can have {matched-locale} being the one that was actually matched, e.g. ru_EE, {full-locale} being the full, original locale that caused the match, e.g. ru_EE-KOI8. That's easy, it is just a question of chosing decent names.

This looks fine, and your suggested names look good as well.

2) What happens if the locale of the returned document is not available in the rest of the i18n chain? There are at least two possible solutions:
- just use the default locale
- provide in {locale} not only the returned locale of the document, but the whole list of preferred locales _from the document match on_. In the example above that would have given:


Making various bits of the locale available would allow the site developer handle this as they please. {lang}, {locale}, {encoding}, etc, etc as well as the above.

I guess the full list would be: {lang}, {country}, {encoding}, {variant}, {full-locale}, {matched-locale}. {locale} could be a shorthand for {full-locale}.


{locale} = de_AU, sv_FI, ru_EE-KOI8

That would be {locales}

Excellent! Do we want/need to also provide the complete, unabbrigded list of request locales, e.g {all-locales}? And further: we need to check that the existing i18n transformer is given what it expects when giving it more than one locale.


Site default locale is defined within the config of the matcher at the top of the sitemap. It could easily be overridden with a <map:parameter name="default-locale" value="xxxx"/> within the matcher itself.

OK.

When I've finished implementing this, I'll go onto extend the CLI to be able to work effectively with this kind on i18n site, enableing it to crawl a site for each of a range of locales. But that's for another time.

Looking forward to it;)))

Let's get this first bit working, first!

Sure;)

Thanks. I'm glad to have got this one off the ground, at last, and to have at last worked out a way that isn't just way too complicated for sitemap developers to understand.

With this in place, Cocoon can finally claim full support for i18n;)

Regards,
Sjur



Reply via email to