You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Joose Vettenranta <jo...@iki.fi> on 2004/08/16 11:06:40 UTC
Good practise for international site (URI-designing)
Hi,
I came to think what would be the best way to make site accessible with
several languages..
Option 1:
Make a localeaction which saves locale information to
session/request/whatever.
/info.html -> language depens on locale
Option 2:
Make locale available from URI:
/en/info.html
/fi/info.html
...
Option 3:
Keep locale in URL:
/info?locale=en
/info?locale=fi
What is best practise (or good) ..
I was thinking Option 1 would be nice, but how does proxys and caches
know that language has changed? so perhaps option 2 would be nice, but
then again, making links in XSLT is not that nice. and option 3 is ugly
=)
What do you think?
- Joose
--
"Always remember that you are unique, just like everyone else!"
* http://iki.fi/joose/ * joose@iki.fi * +358 44 561 0270 *
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Good practise for international site (URI-designing)
Posted by Joose Vettenranta <jo...@iki.fi>.
>
> Option 2:
> Make locale available from URI:
>
> /en/info.html
> /fi/info.html
> ...
>
This has bad thing this:
copy&pasting url's have language information with it. (sometimes good,
sometimes bad).
Hmm.. wonder does RFC say anything to this?
- Joose
--
"Always remember that you are unique, just like everyone else!"
* http://iki.fi/joose/ * joose@iki.fi * +358 44 561 0270 *
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Good practise for international site (URI-designing)
Posted by Olivier Lange <wi...@petit-atelier.ch>.
> I must look into the link rewriter, maybe it'll be helpful here.
I found it very usefull, resulting in no broken links and no link
translation hassle.
Moreover, I found the linkmap being a very useful resource: I used it to
resolve the source content id and templates from the sitemap, thru input
modules (starting from the document URI and retrieving various
attributes in the linkmap).
And I believe the linkmap could be used as input of the CLI... it
provides a complete overview of the site structure.
I had to tweak the LinkTransformer to handle logical links in
Dreamweaver's onClick attributes, which look like this:
MM_swapImage('domdesc','','pict:dom-desc-over',1)
and I wanted them to get translated to:
MM_swapImage('domdesc','','/comx/img/fr/dom-desc-over.gif',1)
I saw that Cocoon 2.1.5 comes with regular expressions for the link patterns. It wonder if it would do it without tweaking the transformer source code.
And here are some details of the linkmap translation I used. Maybe it is
of interest?
The linkmap looks like this:
<linkmap>
<site id="phga" href="/">
<!-- Language independant homepage (users have to choose) -->
<document><page id="intro" href="index.html" /></document>
<!-- Language specific document collections -->
<lang-specific href="{lang}/">
<!-- Homepage in a specific language -->
<document><page id="home" href="index.html" /></document>
<!-- Domain "Project description" -->
<domain id="desc" href="descriptif/">
<document><page id="desc-home" href="index.html"
/></document>
<document><page id="desc-detail(p1)"
href="detail(p1).html" /></document>
<document><page id="desc-detail(p2)"
href="detail(p2).html" /></document>
<document><page id="desc-detail(p3)"
href="detail(p3).html" /></document>
<document><page id="desc-detail(p4)"
href="detail(p4).html" /></document>
</domain>
[...]
In the sitemap, the linkrewriter is used thru <map:call
resource="linkrewriter"> with a parameter 'lang':
<map:resource name="linkrewriter">
<map:transform type="linkrewriter"
src="cocoon:/{lang}/linkmap.abs.xml">
<map:parameter name="link-attrs" value="href src value
content onmouseover onMouseOver onmouseout onMouseOut onload onLoad
onclick onClick"/>
<map:parameter name="schemes" value="phga external"/>
<map:parameter name="exclude-schemes" value="http https
ftp mailto news"/>
<map:parameter name="bad-link-str" value="bad-link"/>
</map:transform>
</map:resource>
The linkmap is translated thru the following pipeline:
<map:match pattern="*/linkmap.abs.xml">
<map:generate type="file" src="linkmap.xml"/>
<map:transform type="xslt"
src="transform/links/linkmap-translation.xsl">
<map:parameter name="lang" value="{1}"/></map:transform>
<map:serialize type="xml"/>
</map:match>
and a request to "cocoon:/fr/linkmap.abs.xml" would return a translated
linkmap like this:
<linkmap>
<site id="phga" href="/">
<!-- Language independant homepage (users have to choose) -->
<document><page id="intro" href="/index.html"/></document>
<!-- Language specific document collections -->
<lang-specific href="/fr/">
<!-- Homepage in a specific language -->
<document><page id="home" href="/fr/index.html"/></document>
<!-- Domain "Project description" -->
<domain id="desc" href="/fr/descriptif/">
<document><page id="desc-home" href="/fr/descriptif/index.html"/></document>
<document><page id="desc-detail(p1)" href="/fr/descriptif/detail(p1).html"/></document>
<document><page id="desc-detail(p2)" href="/fr/descriptif/detail(p2).html"/></document>
<document><page id="desc-detail(p3)" href="/fr/descriptif/detail(p3).html"/></document>
<document><page id="desc-detail(p4)" href="/fr/descriptif/detail(p4).html"/></document>
</domain>
The linkmap-translation.xsl XSL script was adapted from Forrest's absolutize-linkmap.xsl and does actually two things:
1) replaces all {lang} occurrences with a parameter value ("fr" in the example above);
2) absolutizes the href="..." attribute contents.
--
Olivier
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: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Good practise for international site (URI-designing)
Posted by Olivier Lange <wi...@petit-atelier.ch>.
Upayavira wrote:
> Olivier Lange wrote:
>
>> 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.
>>
> 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.
>
> 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.
Yes, in your case, as the source files are already translated, there is
no need of message catalogs I believe.
I used the i18nTransformer to translate all texts (and the Linkrewriter
to translate all links in a language dependant way).
No better solution than yours, it was just to point out why I used
message catalogs. The text database also the users to track the
translations, which was the main problem... Now they handle all the
translation process themselves and send me the text-database with the
translated texts when they're done, without knowing anything about the
XML files. Then I regenerate the i18n message catalogs from the database
and republish the changed pages with Cocoon.
One nice feature of this solution: these two transformers together, the
i18nTransformer+Linkrewriter, allow for the content files and page
templates being language independant (I have one content XML file for
the events for instance, with i18n elements in it; and one page
template, whose links and texts get translated). Both of them are given
an input (message catalog, linkmap) in the desired locale (fr|de|en|es|...).
>
>>
>> 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...
*For what it's worth*: I would go for just one URI scheme. If there are
two URI to the same content, these content will be indexed twice by
search engine I think, and it is twice the "maintenance" if you move a
page for instance.
>
> (I will read your other message on link rewriting - I would really
> like to understand how the LinkRewriter helps in these scenarios.)
It is pretty obvious, but one thing I forgot to state clearly: all links
in my page templates and i18n content are "logical" links, like
"site:description-home" or "pict:dom-desc-over". I have no absolute URIs
anywhere and I had, these would of course not be translated.
>
> 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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Good practise for international site (URI-designing)
Posted by Upayavira <uv...@upaya.co.uk>.
Olivier Lange wrote:
> 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.
>
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.
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: users-unsubscribe@cocoon.apache.org
>>>> For additional commands, e-mail: users-help@cocoon.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>> For additional commands, e-mail: users-help@cocoon.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Good practise for international site (URI-designing)
Posted by Olivier Lange <wi...@petit-atelier.ch>.
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: users-unsubscribe@cocoon.apache.org
>>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Good practise for international site (URI-designing)
Posted by Upayavira <uv...@upaya.co.uk>.
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: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Good practise for international site (URI-designing)
Posted by Olivier Lange <wi...@petit-atelier.ch>.
> 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.
I let the user themselves choose the language on the very homepage (a
Flash animation). Then there is a homepage for each language.
--
Olivier
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: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Good practise for international site (URI-designing)
Posted by Upayavira <uv...@upaya.co.uk>.
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Good practise for international site (URI-designing)
Posted by Olivier Lange <wi...@petit-atelier.ch>.
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.
--
Olivier
Joose Vettenranta wrote:
> Hi,
>
> I came to think what would be the best way to make site accessible
> with several languages..
>
> Option 1:
> Make a localeaction which saves locale information to
> session/request/whatever.
>
> /info.html -> language depens on locale
>
> Option 2:
> Make locale available from URI:
>
> /en/info.html
> /fi/info.html
> ...
>
> Option 3:
> Keep locale in URL:
>
> /info?locale=en
> /info?locale=fi
>
>
> What is best practise (or good) ..
>
> I was thinking Option 1 would be nice, but how does proxys and caches
> know that language has changed? so perhaps option 2 would be nice, but
> then again, making links in XSLT is not that nice. and option 3 is
> ugly =)
>
> What do you think?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org