Seaside vs I18N/L10N

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.

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 th
is up with Seaside would be appreciated.

Thanks,

Martin
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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.

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.

Colin
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

At this point my expectation is that in VW we'll be able to use the UserMessage mechanisms for the rendering part, as long as they can resolve in the correct Locale context. So when you need to put a bit of text into the page you do the usual:

        (#CatalogKeyX << MyAppCatalog >> 'This is the default, usually english string') asString

I don't expect other dialects to be too eager to adopt this particular approach, but the advantages are

1) It's the same as what you're expected to use to internationalize usual GUI apps.
2) It's fairly well isolated, i.e. it doesn't need much support from Seaside. All I really need is being able to fetch the Locale information from the session object before I execute the incoming request, so that I can stuff the Locale into the Process beforehand.

As far as performance concerns go, going through the Processor activeProcess shouldn't be too bad. We're currently using the environment associated with the Process to store the Locale, but if that's not fast enough, we still have the option of just making locale a dedicated inst var of Process.

I have yet to figure out how to get to the Seaside session associated with particular connection/request before I execute the request, but once that's clear, the main missing bit is figuring out where/how to manage the associated Locale. That's my main concern at this point. Do you have any thoughts there ? Do you want to start with just storing the Locale id 'en_US' and such or some sort of WALocale object ? How should that be managed within the session context ?

Of course if there are additional, Seaside specific, localization mechanisms, we'd certainly like to have those work as well.

Martin

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/8/16, Martin Kobetic <[hidden email]>:
Why not just put it in the session?

> Do you want to start with just storing the Locale id 'en_US' and such or some sort of WALocale object ?

I always prefer objects over strings (yeah I know technically Strings
are objects but ..)

Cheers
Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside