Just to add to this we also found that $text.get wasn't actually doing
any localization in the velocity templates.  We have a fix for this
that we can also check into the branch, but......

I think there is a bigger question here.  As far as I can make out
there are a variety of different approaches used to determine the
locale to render any given page.  In no particular order some of the
things that I have found.

1) The user's Locale
2) The blog's Locale
3) The accept-language header from the browser.

This led to a rather confusing user experience.  To simplify things we
now always utilize the browser's setting and I wondered if this is
something that we should change in Roller.  Again you are welcome to
all our patches.

If we choose to always use the accept-language header then we'd want
to do content negotiation on a given language neutral URL and redirect
to a language specific one as Elias outlines below.  This way we can
get lots of performance boosts from browser and reverse proxy caches.
I blogged about this approach in gory detail a while back [1],

let us know what you think,

Thanks,

Rob

[1] http://robubu.com/?p=13

On 2/21/07, Elias Torres <[EMAIL PROTECTED]> wrote:
Roller Team,

One of the things we focused in our product development for Roller was
support for caching using reverse proxies. Most of the changes are quite
straight-forward and I should be proposing them soon for your approval
if you would like them put in the trunk or 4.0 branch.

There's one issue pending and that's the language translation of blog
messages (meaning which .properties file we load to translate UI for the
user). We can obtain the locale from the request, the problem is in the
reverse proxy and its inability to differentiate from just the URL that
the blog contents are actually different. We could use a Vary header and
set the value to Content-Language or whatever the right header is, but
not all browsers respect the Vary header. One of the solutions is to
simply use a different URL for each language.

/eliast/entry/hello+world

/eliast/es/entry/hello+world

The problem though is that we already use the lang segment in our url
structure but for something a bit different if I understand it
correctly. Basically, we use "es" as a filter to which entries can
appear on that page/feed/etc instead of which language is use to
translate the UI. I'd think it might make more sense to do something
like this:

/eliast/es/entry/hello+world?entry-lang=fr

Meaning to use a query parameter to filter the entries that we want
displayed regardless of the language we are using to render the blog UI.

What do you all think?

-Elias


Reply via email to