Robert Yates wrote:
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 didn't know anything about that, but I do know that the localization
of weblog content is anything but complete right now. I had planned to
work on this a little bit, more specifically in regards to handling
dates, but it's all part of the same problem.
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.
Hmmm, I'm not sure I agree with that. I suppose we need to be clear
about what pages we are talking about though. My feelings on the
situation are pretty straight forward ...
1. For all weblog content the locale used for rendering should be the
locale configured by the weblog owner on the UI. *if* a weblog owner
wants to maintain their blog in multiple languages then they can enable
that and allow for the language specific views of their blog via the
urls that Elias described (/<handle>/<locale>/*). In the event that a
locale is present in the url then that locale is used for all i18n.
2. On the publishing/administration UI we always use the locale set in
the users profile. I am not particularly tied to this approach, but it
makes some sense. Alternatively we can just have the UI make use of the
browser accept-language values.
3. On any pages which don't fall into either 1 or 2 above then we just
use the browser's accept-language values. i.e. for registration or
login pages.
I think we are basically doing all of those things now, but I'm sure we
could be doing it better and more completely.
-- Allen
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
