Olivier Lange wrote:
Interesting. I was going to have Apache do that for me. But (especially with the LocaleMatcher) I could have Cocoon do it and be done with it.Perhaps one point to take into account to help deciding:
The idea behind the URI scheme I used is that *every* page of the site is available in *each* language (even if it is not translated, I derive the text from another language). Once a user choosed a language, say "fr/", he safely navigates thru pages which are all in the fr/* URI space for instance.
The only issue that gives me is how to deal with legacy URLs for the currently English site, which doesn't have /en/ in the URL.
For me, it implied that I generate the message catalogs from a little database (Access in that case), which contains all texts. And some text can be marked as being derived from the one in another language, and I resolve them when exporting the catalogs.
I have my own linkmap system (inspired by the Forrest one), and with the LocaleMatcher, it has been pretty easy to base the site around source XML (actually, HTML) files, with the LocaleMatcher offering the pipeline the correct source file for further processing. With the information in my linkmap, and the different translated source files (stored, for example in /xml/<lang>/foo.html), I have got a translated site working.
With the index.html.fr|en|es|de approach, I believe Apache can fallback on a default language if one is not available for the locale.
And there is only one URI space, am I right? You access /description/index.html, not /description/index.html.fr? This is completely transparent to the user, but he cannot put an explicit link on the french page for instance. It depends on the locale he defined in the browser.
You are right. What I've been thinking of is using both. One version that uses the browsers locale, on the default URI space, and one with the locale provided as a part of the URI. I'm starting to wonder about that - is it really necessary...
(I will read your other message on link rewriting - I would really like to understand how the LinkRewriter helps in these scenarios.)
Regards, Upayavira
Olivier Lange wrote:
> Interesting. But if I set my browser's locale to French, that isn't taken into account, is it?
Indeed, it is a static publication, all done with the CLI (many thanks Upayavira!), there are no locale matchers.
:-)
It is my intention to change the CLI so that you can say:
<uri type="append" src-prefix="" src="index.html" dest="build/dest/" locales="en,fr,es,de"/>
and it will create: index.html.en index.html.de index.html.fr index.html.es
This is the format that Apache server expects files in if it is to use its own I18n functionality.
But, yours is pretty simple, and works. Hmm.
I let the user themselves choose the language on the very homepage (a Flash animation). Then there is a homepage for each language.As I say, it is simple, and works. And I could get my site working much quicker if I followed this approach.
Regards, Upayavira
Upayavira wrote:
Olivier Lange wrote:
Hi Joose
I used option 2 for a large site, with a complete user request space available in all langages. If some content is not available in some language, I put an explicit mention about the missing translation on that page, plus a text in some other langage.
For instance: this page is available in french, german, italian and english, but not rumantsch; so there's a mention:
http://www.gallerie-ph.ch/rm/events/construct-sonor/klanginstall/index.html
All this handled thru Linkrewriter and i18n message catalogs, so there is no link manipulation needed in the XSLT. By the way: the linkmap gets translated in each language also, of course. The message catalogs are generated.
Interesting. But if I set my browser's locale to French, that isn't taken into account, is it?
I must look into the link rewriter, maybe it'll be helpful here.
I'm working on an i18n site at the moment, and have created the I18nMatcher (soon to become the LocaleMatcher) for just this purpose. I also intend to get the Command Line Interface to be able to handle the creation of pages in different languages.
Maybe just the homepage could respond to a browser locale, and the rest are served as en/page.html, fr/page.html, etc.
Hmm.
Upayavira, who is a complete newbie when it comes to i18n.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
