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.
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.
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.
-- Olivier
Upayavira wrote:
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]
