On Wed, May 6, 2009 at 5:26 AM, Lukas Renggli <renggli@gmail.com> 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...".

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

Ok. I will do. When I have a beta I will let you know :)
 

> 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>.

Thanks. That's all I wanted.
 


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.

Good to know :)
 

> 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 ;-)

Yes. I know hahaha
 


> 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'

I didn't understand this. I should do this for all (if not all, which ones ?) the descriptions? I mean, that was just an example, wasn't it ? 

 

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.

You mean I can subclass String ? I didn't get it :(
 

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?

A friend of mine, Esteban Lorenzano,  did this approach so he can give a hand with it.

However, what I will do is to wait until last moment to put int18. Perhaps at that moment the issue is done :) And if not, I do one of these approaches.

Thanks for all!

Mariano

 

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

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