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

[Philippe Marschall]

2010/9/12 Panu Suominen <panu.j.m.suominen at gmail.com>:
> 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.

Nope. The locale is set before the Magritte code even kicks in.

> 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
> file.
>
> 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:
>
> String>>translated
> "answer the receiver translated to the default language"
>        ^LazyTranslation fromString: self.

Override in String, not gonna happen.

> LazyTranslation>>renderOn: html
>        html text: (self translate: WACurrentLocalizationContext value localeID).
>
> LazyTranslation>>printOn: aStream
>        ^self translate.
>
> LazyTranslation>>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.

Cheers
Philippe