[Seaside] Seaside vs I18N/L10N

Colin Putney 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 mailing list