cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: one more sitemap idea
Date Thu, 08 Jun 2000 15:12:00 GMT

Neeme Praks wrote:

> I have been thinking about total website/webapp localization...
> including content and URLs.
> Content is pretty straightforward, just a matter of choosing the most
> appropriate implementation.
> However, what is more tricky, is localizing the URL.
> What I would like to have is the following URL's to be equivalent
> /user/add (english)
> /kasutaja/lisa (estonian)
> Why would I want this in the first place? I want to give users the
> possibility of having "friendly" URLs, instead of URLs like
> uses that don't mean anything for most humans.
> What would be the best way to achieve this with Cocoon2 sitemap? One way
> would be to add duplicate <process> tags for each language. This would
> be messy, however. Could we instead allow to have more than one URI
> specified for one <process> tag? Something like this:
> <process uri="user/add" uri="kasutaja/lisa">
> or
> <process>
>     <uri>user/add</uri>
>     <uri>kasutaja/lisa</uri>
> </process>
> Last one would actually be better, then I could also do:
> <process>
>     <uri xml:lang="en">user/add</uri>
>     <uri xml:lang="ee">kasutaja/lisa</uri>
> </process>
> (Not sure of the syntax of xml:lang attribute)
> Comments?
> Neeme

We could also go hog wild with a complete i18n and l10n implementation...
But, if we want to keep it simple (+500000 on that), your second suggestion
will probably be the best.  I'm not sure what the advantage of using the
xml:lang attribute would be here.  It adds unnecessary verbosity and doesn't

add any known benefit.

If your purpose was to pass the attribute to your stylesheet, then we
ought to have a way to add parameters to the request.  Something like:
<request-parameter name="xml:lang" value="en"/>, but you could also do that
in the URL itself.

Here's a crazy thought--feel free to shout it down--XSLT has a mechanism
to create attribute groups that you can apply in multiple spots in your
If Sitemap had a way of specifing an <process> inheritance heirarchy, your
example would be restated like this:

<process uri="user/add" name="add-user">
  <!-- your processing tree here -->
<process uri="kasutaja/lisa" extends="add-user">
  <!-- Anything specified here overrides the root description -->
<!-- for simple aliases, you would have an entry like this: -->
<process uri="usador/insertar" extends="add-user"/>

Will this be insane or what?

View raw message