Smalltalk › Frameworks & Tools › Magritte, Pier and Related Tools

Pier components internationalization

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

Mariano Martinez Peck

Pier components internationalization

Sorry to bother again with this, but I really need it.

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

I think Pier give CMS a new and higher level to CMS. I think there is a field in websites that can start being done with Pier, but they are no "CMS traditional". For example, in my case, I am making a tourism website with Pier. This sounds strange isn't it ? However It give me lots of features:

1) Do a lot with very little time and code
2) Dynamism: I can modify my website at any moment just using a browser.
3) The website can be built with business people. For example my friend (Tourisim graduated). Hi doesn't now anything about computer neither wiki. I explained few things: edit a page, add a page, links and now, he is building the website with me. Ok, not all of it, but parts.
4) I am making the first tourism website I know where the final user can be part of.

I think Pier+Seaside+Magritte has all the power and capabilities to spread about this new field. But, for this, is very important to have int18.

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:

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

printOn: aStream
    "Print inside string quotes, doubling inbedded quotes."
     self size < 100
         ifTrue: [ self localize storeOn: aStream ]
        ifFalse: [ self storeOn: aStream ]

Then I define localize like this:

localize
    ^ WACurrentSession value ifNotNilDo: [ :session | session language localize: self ].

And then the Langauge # localize could be something like this:

localize: aString
    ^self localizationMap at: aString ifAbsent: [ aString ].

Obviously all of this methods will be with category *MiApp (an extension).

Could this be a good idea? Any other solution ?

Thanks in advance,

Mariano

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

Lukas Renggli

Re: Pier components internationalization

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

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

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

Mariano Martinez Peck

Re: Pier components internationalization

On Wed, May 6, 2009 at 5:26 AM, Lukas Renggli <[hidden email]> 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

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

Mariano Martinez Peck

Re: Pier components internationalization

In reply to this post by Lukas Renggli

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

can I add some comments here ?

cheers,

Mariano

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

Miguel Cobá

Re: Pier components internationalization

In reply to this post by Lukas Renggli

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.

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

Mariano Martinez Peck

Re: Pier components internationalization

2009/5/6 Miguel Enrique Cobá Martínez <[hidden email]>

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

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

Lukas Renggli

Re: Pier components internationalization

In reply to this post by Mariano Martinez Peck

Yes. Please go ahead.

On Wednesday, May 6, 2009, Mariano Martinez Peck <[hidden email]> wrote:

>
>
> 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>.
>
>
> can I add some comments here ?
>
> cheers,
>
> Mariano
>

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Mariano Martinez Peck

Re: Pier components internationalization

done.

On Wed, May 6, 2009 at 2:46 PM, Lukas Renggli <[hidden email]> wrote:

Yes. Please go ahead.

On Wednesday, May 6, 2009, Mariano Martinez Peck <[hidden email]> wrote:
>
>
> 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>.
>
>
> can I add some comments here ?
>
> cheers,
>
> Mariano
>

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

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