cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Neeme Praks" <ne...@one.lv>
Subject RE: one more sitemap idea
Date Fri, 09 Jun 2000 14:27:26 GMT

> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Friday, June 09, 2000 1:44 AM

<snip/>

> 3) the current sitemap WD doesn't have any special feature for this,
> being totally URI and language abstracted. Berin suggests 
> this might be
> common need and the sitemap _should_ incorporate localization 
> features.
> 
> I won't vote on this for now.
> 
> Currently, the sitemap allows you to do
> 
>  <process uri="user/add">
>   <resource name="add user"/>
>  </process>
> 
>  <process uri="kasutaja/lisa">
>   <resource name="add user"/>
>  </process>
> 
> where the "resource" will look for the localization 
> information sent by
> the browser to understand what file to map. 

ok, this could almost solve the problem... this is similar to the
inheritance model proposed before, but less powerful (and less
dangerous?). However, for the problem at hand, I think it would work.
Only thing, though... still I would like to add request parameters in
the sitemap, as proposed before. Something like this then:
 <process uri="user/add">
  <request-parameter name="lang" value="en"/>
  <resource name="add user"/>
 </process>

 <process uri="kasutaja/lisa">
  <request-parameter name="lang" value="ee"/>
  <resource name="add user"/>
 </process>

When encountered, it would add a parameter to the request...
Or another form:

 <process uri="user/add">
  <resource name="add user">
    <request-parameter name="lang" value="en"/>
  </resource>
 </process>

 <process uri="kasutaja/lisa">
  <resource name="add user">
    <request-parameter name="lang" value="ee"/>
  </resource>
 </process>

Here it is a little bit more expressive: redirect processing to the "add
user" resource, _with_ the "lang" parameter. This would mean that you
could do this:

 <process uri="kasutaja/lisa">
  <resource name="add user">
    <request-parameter name="lang" value="ee"/>
  </resource>
  <resource name="confirm user"/>
 </process>

where the "add user" resource has a parameter "lang", while "confirm
user" resource doesn't have this parameter... I don't know if it is
useful, but could be.

> (this creates a problem with
> localizing xlinks too.... hmmmm, not an easy thing)

well, yes... didn't think very much about xlinks... however, if I would
like to use URL rewriting to do session tracking, then I would anyway
use some sort of java class for writing out the inner-site URIs... So I
could also rewrite the URIs in proper language...

> But this assumes the browser sends the correct localization 
> information (which is normally the case, BTW).

By "localization information" you mean the accept-language header? Well,
in the case of some less well-known languages (for example Estonian),
this is normally _not_ the case. Meaning that the browsers are in very
rare cases configured to send accept-language: "ee"...

So, what i would do to determine the language to be served is following:
1. check the machine name that sent the request, if belongs to *.ee
domain then send estonian
2. if machine name unavailable (IP address not resolvable) then check
the accept-language header, if "ee" accepted, send estonian
3. if "ee" not accepted, try to match any other accepted language and
available language. If none matched, send default (ee).

> On the other hand, the proposed tag inheritance is a very 
> dangerous path
> to follow, even if I agree that it's a very powerful model...

Can you be more specific about the dangers in this?

> Hmmm, I need to think a little more about l10n... sure is 
> something very
> important and tuning the sitemap to support it would not only be
> beneficial to web masters but to site users also.

yep, couldn't agree more ;-)
I especially care about this since localization capabilities will be
really important for my sites (that I plan to build with cocoon).

Neeme

Mime
View raw message