6 May
2009
6 May
'09
5:42 p.m.
2009/5/6 Miguel Enrique Cobá Martínez <miguel.coba(a)gmail.com>
Lukas Renggli wrote:
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
I need to internationalize Pier components. I am
doing a site with Pier
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.
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...".
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
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
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 ?