[Seaside] Seaside vs I18N/L10N
philippe.marschall at gmail.com
Thu Aug 16 21:16:52 UTC 2007
2007/8/16, Martin Kobetic <mkobetic at cincom.com>:
> 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 ?
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 ..)
> 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.
> > 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
> > Seaside at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
More information about the seaside