forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sjur Nørstebø Moshagen <sjur.mosha...@kolumbus.fi>
Subject Re: Q: Further i18n and ISO 639-2 support
Date Wed, 10 Mar 2004 13:17:13 GMT
På 1. jan. 2002 kl. 16.01 skrev Juan Jose Pablos:

> Sjur Nørstebø Moshagen wrote:
>> Hm, feel strong enough, but I'm lacking the skills :-(
> That's fine, maybe you can help wih the testing & documentation :-)

Any time!

>> There are basically three issues:
> possibly more :-)

For sure;)

>> 0) Defining the site languages
> I am not sure about this one.
>
> IMO, language is another representation of the same "foo". So if you  
> request foo.{format} forrest should look for foo.{lang}.{source}. But  
> this is on resource level not for the whole site.

True, but:

a) we need(?) a consistent way of defining the relationship between  
whatever string {lang} is used, and the display name of the language  
(eg. de = deutsch),
b) if a), then we also should have a standardised place and format for  
this information, and
c) it is nice to be able to do at least a minimal consistency check  
when generating a static site (or dynamic, for that matter), to avoid  
basic errors like typos in file names.

That is, this list is *not* something to be displayed to the user as  
is, but a support file when building a page.

> We can use the directory generator for this:
> <map:match pattern="*.xml">
>   <action type="locale">
>     <map:generate type="directory"  
> src="{project:content.xdocs}{1}_{lang}">
>   </action>
> </map:match>

Thanks.

>> 2) Building a selection list for the user
>> Given 0) and 1), this step should not be too complicated (similar to  
>> building the site menu?), but I'm rather new to both cocoon and  
>> forrest, so any help would be appreciated.
>
> Check on the code used to create the menu.

I will.

>> 3) store the selection/take action
>> There are a couple of options here. The simplest solution is to just  
>> serve the language version "as is": the selection "deutsch" based on  
>> the above list would be a link to the file index_de.html. With this  
>> approach, no info is stored, and no further action is taken. Thus,  
>> the user most likely will have to click on "deutsch" again for the  
>> next page, unless forrest, upon serving index_de.html, appends _de to  
>> all links on that page.
>
> Well, I understand, what you meant about store. Actually this is the  
> first problem to resolve. When you make a request "foo.html" Forrest  
> display the correct content, but the file name is the same so if you  
> saved, it does not containt the language information on the uri.
>
> You need to modify the filename to get apache negociation content  
> support.
>
> Anyone can give a hand on this? I am not sure about the best approach.
>
> 1) move foo.{format} to foo.{format}.{lang}
> 2) move foo.{format} to foo.{land}.{format} and create var files with  
> this info:
>
> URI: foo.{lang}.{format}
> Content-type: text/{format};charset=iso-8859-1
> Content-language: {lang}
>
>
>> A better approach would be to set the session language based on the  
>> user selection, and optionally also a cookie for later perusal. But  
>> I'm clueless (more or less) as to how this should be done. Again, any  
>> help/cooperation would be appreciated;)
>
> But that information get lost when you saved the file. Forrest is used  
> mainly to get static content. Dinamic content is to allow faster  
> development, and it should be consistency.

I definitely want this to work for dynamic sites as well.

I don't understand what you mean by 'saving the file'. Which file? I am  
also a little confused about static vs dynamic, and your mentioning of  
apache. This is what I understand, please correct me where I'm wrong:

_static vs dynamic_ in a Forrest/cocoon context means that a static  
site is pregenerated but still served by Tomcat or a similar container,  
whereas a dynamic site is like a static site with write access, such  
that it can be modified while running. Thus, you don't need apache at  
all.

_Content negotiation_ is not the same in cocoon as in apache, because  
cocoon has a notion of session that apache does not. They also differ  
in how to specify a language version of a file (apache:  
index.html.{lang} / index.{lang}.html, cocoon: index_{lang}.xml).  
Cocoon negotiation goes like this: CGI parameter, session language (but  
how is that set), cookie, content negotiation à la apache. That is, if  
there is a CGI parameter 'locale', that will be used; if not, cocoon  
will look for a defined session locale for a session, and that locale  
will be used when serving pages by cocoon; if not, then cocoon will  
look for a cookie containing a locale parameter, and if found, will use  
its value when serving pages; if not, it will fall back on standard  
content negotiation.

The above understanding is based on the document:
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/acting/ 
LocaleAction.html

The main idea (to me) is that when a language is selected, it is more  
likely that the user would like to keep that language as the preferred  
one, rather than wanting a new language each time he visits a site, or  
goes to a different page on a site. Thus, it is a goal to minimize the  
user interaction when deciding upon language choice, and this can be  
done by storing a cookie and setting the session language if the user  
explicitly chooses a language. The cookie should be available the next  
time the user visits a site, and will thus set the locale  
automatically. If the user is satisfied with what is served, that is,  
relying upon standard content negotiation, that will of course also  
give predictable and stable results for the user.

Sjur


Mime
View raw message