5 May
2009
5 May
'09
10:24 p.m.
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
6 May
6 May
8:26 a.m.
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
5:14 p.m.
On Wed, May 6, 2009 at 5:26 AM, Lukas Renggli <renggli(a)gmail.com> wrote:
Ok. I will do. When I have a beta I will let you know :)
Thanks. That's all I wanted.
Yes. I know hahaha
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 ?
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.
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 ;-) 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.
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
5:46 p.m.
Yes. Please go ahead.
On Wednesday, May 6, 2009, Mariano Martinez Peck <marianopeck(a)gmail.com> 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
7:29 p.m.
done.
On Wed, May 6, 2009 at 2:46 PM, Lukas Renggli <renggli(a)gmail.com> wrote:
Yes. Please go ahead.
On Wednesday, May 6, 2009, Mariano Martinez Peck <marianopeck(a)gmail.com>
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
5:30 p.m.
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
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 ?
5717
days inactive
5718
days old
7 comments
3 participants
participants (3)
-
Lukas Renggli -
Mariano Martinez Peck -
Miguel Enrique Cobá Martínez