[Seaside] Localisation of Seaside apps
brent.pinkney at aircom.co.za
Wed Jun 14 00:32:14 UTC 2006
> I just had to submit an offer for a web application with localisation.
> After thinking a bit about it, I must admit that all my solutions so far
> are rather unwieldly.
Our web application is fully localised:
We modifed to signal a notification to return the preferred instance
String >> translated
"answer the receiver translated to the default language"
^ CurrentTranslator signal translate: self
We implemented CurrentTranslator as a subclass of Notification with:
CurrentTranslator >> defaultAction
"Answer the current system-wide NaturalLanguageTranslator."
^ NaturalLanguageTranslator current
So far, the string translation functions as it always has.
The entry point for any Seaside application is either WAMain >> start: for new requests
or WASession >> peformRequest for requests with a valid session key. We overrode our
subclass's implementation to catch the CurrentTranslator signal and answer the appropriate
translator as stored in the WASession, viz:
BpAuthMain >> start:
[ super start: aRequest ]
do: [ :e | e resume: self session translator ]
and similarly for #performRequest:
We then subclasses WASession to include an instance variable for the current LocalID.
This can return the appropriate translator. We use Basic authentication to identify the user and read
the locale ID from our database.
Our solution allows each Seaside session to have its own translator so different users can have the
results rendered in different languages.
Note: We were not sure whether to use a Notification to answer the preferred translator or a DynamicBinding.
So far we have not detected any performance problems with this approach.
Contact me directly if you need more help or sample code. PS. We would really like this functionality to
migrate its way into the offical Seaside distribution and would be willing to modify our implementation accordingly.
More information about the Seaside