Re: [Pharo-users] i18n tools

On Fri, Sep 10, 2010 at 2:41 PM, Panu Suominen <[hidden email]> wrote:

2010/9/10 Stanislav Paskalev <[hidden email]>:

> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

Forwarded conversation
Subject: i18n tools
------------------------

From: Panu Suominen <[hidden email]>
Date: 2010/9/9
To: [hidden email]


I am researching wether out team could start using Pharo. I have tried to locate
some tools to do user interface translations but I did not find
anything in time so I had
to develop some rudimentary key-based translation tools my self. I would like
to know is this lack of translation tools reality and if others are having same
kind of problems?

--
Panu

----------
From: Stéphane Ducasse <[hidden email]>
Date: 2010/9/9
To: [hidden email], A friendly place where any question about pharo is welcome <[hidden email]>
Cc: Hilaire Fernandes <[hidden email]>


hilaire

can you provide some pointers because you did a lot of translations.

Stef
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users


----------
From: Panu Suominen <[hidden email]>
Date: 2010/9/10
To: Stéphane Ducasse <[hidden email]>
Cc: A friendly place where any question about pharo is welcome <[hidden email]>, Hilaire Fernandes <[hidden email]>


To stimulate little more.. I have done rudimentary translation support
for magritte and seaside.
Should I publish them or are there already working options?

--
Panu

----------
From: Stanislav Paskalev <[hidden email]>
Date: 2010/9/10
To: [hidden email], A friendly place where any question about pharo is welcome <[hidden email]>


Seaside had none the last time I asked. Please do so.

Stanislav Paskalev

----------
From: Panu Suominen <[hidden email]>
Date: 2010/9/10
To: Stanislav Paskalev <[hidden email]>
Cc: A friendly place where any question about pharo is welcome <[hidden email]>


2010/9/10 Stanislav Paskalev <[hidden email]>:
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

----------
From: Mariano Martinez Peck <[hidden email]>
Date: 2010/9/10
To: [hidden email], A friendly place where any question about pharo is welcome <[hidden email]>
Cc: Seaside - general discussion <[hidden email]>


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