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

Mariano Martinez Peck marianopeck at gmail.com
Fri Sep 10 12:47:57 UTC 2010

Panu, maybe you may want to cc seaside mailing list too ;)

On Fri, Sep 10, 2010 at 2:41 PM, Panu Suominen
<panu.j.m.suominen at gmail.com>wrote:

> 2010/9/10 Stanislav Paskalev <kshorg at gmail.com>:
> > Seaside had none the last time I asked. Please do so.
> I am in a bit hurry, but I hope you can still make sense out of this.
> The whole seaside and translation thing is based on the fact that
> Seaside render: method is dispatched to objects renderOn: method where
> we can access session. On the other hand
> we can store language to session. If we implement object that is able
> to answer correctly to translate: -message with language as a
> parameter we have a simple translation framework.
> I created a simple translation framework which is able to return
> translation for certain key. Keys are looked from properly named
> subclass. Names are form of LanguagePackOfProgramX_fi,
> LanguagePackOfProgramX_en. Each containing translations for the given
> language. K3LanguagePack and tests should give better idea.
> Notice that examples below need language -method in session....
> Example to use with seaside:
> renderContentOn: html
>    html render: (LanguegPackOfMyProgram translationFor: #greetingMessge)
> Example with magritte:
> descriptionEmail
>       ^MAStringDescription new
>                accessor: #email;
>                label: (K3CoreLanguagePack translationFor: #email);
>                addCondition: [:value | value includes: $@] labelled:
> (LanguegPackOfMyProgram translationFor: #emailNotValid);
>                beRequired; requiredErrorMessage:
> (LanguegPackOfMyProgram translationFor: #emailIsRequired);
>                priority: 10;
>                yourself.
> The magritte part was builded on top of 2.0.5 magritte-seaside.
> This code enabled me to build seaside application demo that could
> change its user interface on the fly. Meaning that anything else stays
> as it is, only the language changes.
> But I don't know how useful this is for other people.
> Currently the major flaw is that there is no way to set the arguments
> for the translation ('Hello user, your name is {1}'). It is not a big
> addition but haven't needed it in this proof of concept. However it
> should not be very hard to implement.
> Other thing that should be discussed is the way translations are
> stored. I chose to use symbols that points to methods and thus
> translations can be encapsulated in classes. However there seems to be
> NaturalLanguageTranslator and string translate already in existence
> and I am wondering should I change the implementation to use them
> instead.
> I am very open to suggestions.
> --
> Panu
> _______________________________________________
> Pharo-users mailing list
> Pharo-users at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20100910/54d45f6c/attachment.htm

More information about the seaside mailing list