2009/5/6 Miguel Enrique Cobá Martínez <miguel.coba@gmail.com>
Lukas Renggli wrote:
I need to internationalize Pier components. I am doing a site with Pier for
Spanish people. The final user has access to Pier components. For example,
it can leave comments or even post. But pier components have the html
outputs in English. For example when you are going to create a post you have
"author, publish, tags, ..." and I want "autor, publicacion, etiquetas...".

This is how I do it:

First I added a new class, suppose it is call MyLocale
in the class side you add a method for each message you want to translate to other languages. For example:

MyLocale class >> helloWorld
 ^ "Hello World!"

Then, add a subclass for each language, overriding each message in the corresponding language.

MyLocaleESMX class >> helloWorld
 ^ "Hola mundo!"

Then in your application, be sure to include this in the session, so that each user has his own language:

MySession >> locale
       ^ locale ifNil: [ locale := MyLocale ]

MySession >> locale: anObject
       locale := anObject

MySession >> l10n
       self isLoggedIn ifTrue: [ ^ self user preferences l10n ].
       ^ self locale

Then, each user has in the preferences the name of the class he wants for the locale, MyLocale or MyLocaleESMX.
This way each user use the class he wants.
Now, for use it, for example, in a login component:

MyLogin >> renderMessageOn: html
       html label with: self session l10n helloWorld

This will have your component always use the class associated with the user to output messages or, if the user is not logged in, to use a default language.


First of all thanks for your time writing the email. Your solution can be easily applied for the components I make but it cannot for Pier components. I am right or I am not understanding something ? I mean, I don't want to touch Pier components because then I wont be able to update anymore. Or I will start doing merge all the time. Another thing is that something like this is in the core on Pier.

Greetings,

Mariano
 

If you need more details, let me know.

Miguel Cobá


Sounds like a really interesting project. Keep us posted on the progress.

Ok, after said that, I want to add int18 to my website but I don't want to
touch Pier code. So, the solution I thought is this:

That would be a goal for the next big release then. I created an
issue: <http://code.google.com/p/pier/issues/detail?id=95>.

We were sort of thinking of providing an internationalization package
as part of Seaside 2.9, because this is something quite a lot of
people want. Especially in the context of web applications. However we
didn't do anything yet.

override String #printOn: or Object #printString     (which one could be
better?)  to something like this:
(suppose I override printOn:)

Uhh, that sounds scary, but I guess you are discussing this already on
the Pharo list ;-)

Could this be a good idea? Any other solution ?

That's certainly an approach.

For Magritte strings (in fact Magritte has already been used in fully
localized applications) it would be easy just to change the
descriptions. If there is the description:

PRStructure>>descriptionTitle (in package Pier-Model)
 ^ MAStringDescription new
       accessor: #title;
       label: 'Title';
       yourself

You can add the method:

PRStructure>>descriptionTitleSpanish: aDescription (in package
Pier-Localized-Spanish)
  ^ aDescription label: 'título'

Instead of using a hardcoded string you could also use your own "smart
string implementation" that knows how to translate to different
languages. At least this is what I've done in various commercial
projects.

Now that doesn't solve the problems of the Strings in Pier itself.
Maybe it is the easiest if you just make a package that overrides the
respective methods that you always load after updating to Pier?

Cheers,
Lukas


_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki