[Seaside] Seaside vs I18N/L10N
cputney at wiresong.ca
Wed Aug 15 04:01:24 UTC 2007
On Aug 14, 2007, at 2:30 PM, Martin Kobetic wrote:
> I have a few questions regarding I18N/L10N of Seaside applications.
> I'm not sure what exactly is the difference, but I figured I'd
> mention both :-). What I really want to know is if there is any
> support/hooks in Seaside to allow rendering of pages in different
> (human) languages for different, concurrently connected users. I'm
> interested in any pointers in both 2.7 and 2.8 contexts. If there's
> nothing, that's a useful answer as well. Or any yet to be
> implemented plans are interesting too. I searched the list archives
> some and browsed seaside.st but didn't find much on this.
There's nothing, as far as I know.
> To provide some context where I'm coming from, we expect to handle
> each connection in context of its own dedicated process and we're
> adding support for per-process Locale. So evaluating 'Locale
> current' would return the one associated with the process executing
> the expression. This will allow application text (UserMessages in
> VW) to be translated by the correct set of translation catalogs,
> associated with current Locale's language. Given all this the
> question is how to integrate this best with Seaside. Presumably the
> language choice needs to be associated with and controlled by
> Seaside's session somehow. In fact we need Seaside to tell us in
> the first place which Locale we should set on given connection
> process, since there are many ways in which a web application may
> want to manage this (one may want to just infer it from accept-
> language header, other will have the user pick it from some web doo-
> dads somewhere on first pages, etc). Any hints on what's the best
> way to hook this up with Seaside would be appreciated.
I've been thinking a bit about how to do this as well, and it seems
that we'd need explicit support for it in Seaside. I've found that
localized rendering tends to involve a lot of accesses to the current
locale, so we don't want that to be an expensive call. I thought of
caching the current locale in the rendering context, and adding some
helper methods so that rendering methods can do stuff like:
html localized: #foo.
It's not a big deal really, but there doesn need to be some support
built into Seaside to make it work.
More information about the seaside