[Seaside] Re: [Pharo-users] i18n tools

Panu Suominen panu.j.m.suominen at gmail.com
Sun Sep 12 05:58:00 UTC 2010

2010/9/11 Philippe Marschall <philippe.marschall at gmail.com>:
>> Does it seem good idea to create class that is going to be translated
>> (but not yet is) and the translation
>> is resolved later.
> I don't quite follow.

Ok. I try to explain my idea better. With magritte you have to spell
out the error messages before you know anything about the locale of
the user who is going to see the messages. One can of course write
those error messages as plain strings and then write alternative
seaside component to translate the string later. However with this
kind of aproach there is no way to extract the translations for .pot

This problem (and the need for special translate: -seside method)
would go away if the String translate method would return object that
translates itself when the actual translated version is needed
(basically printOn: and renderOn: methods).

The main parts of the effective code would be something like this:

"answer the receiver translated to the default language"
	^LazyTranslation fromString: self.

LazyTranslation>>renderOn: html
	html text: (self translate: WACurrentLocalizationContext value localeID).

LazyTranslation>>printOn: aStream
	^self translate.

	^(NaturalLanguageTranslator translate: msgid).

LazyTranslation>>translate: localeID
	^(NaturalLanguageTranslator translate: msgid to: localeID).

Of course LazyTranslation should have to fake it string nature with
additional methods. The goal of this approach is simply decouple the
creation of translation and printing it using some locale. I hope this
made more sense.


More information about the seaside mailing list