Panu, maybe you may want to cc seaside mailing list too ;) On Fri, Sep 10, 2010 at 2:41 PM, Panu Suominen <[email protected]>wrote:
> 2010/9/10 Stanislav Paskalev <[email protected]>: > > 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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >
_______________________________________________ Pharo-users mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
