[Pharo-project] Gettext package?
Hi guys, What is the future of the Gettext package in the PharoNonCorePackages repository? Is the intention to include it in Pharo core? Should that package become a separate project? Something else? I am asking this because I am using it for internationalization support in our Seaside apps (together with the Gettext-Seaside package by Philippe Marschall). Hence, I created a port of the relevant parts to GemStone, following the "develop in Pharo, deploy in GemStone" philosophy. Now, the ported package is a complete duplicate + appropriate changes, but it's better if we create a common package and separate the platform-specific parts out. But I would not want to interfere with anyone's plans, specifically Hilaire Fernandes' plans, probably (who seems to be the author of the package). So, I would like to get in touch with the stakeholders of the package and discuss where it's going. cheers Johan (see more info below -- mails Begin forwarded message:
From: Johan Brichau <johan@inceptive.be> Date: 24 May 2011 08:26:33 GMT+02:00 To: Philippe Marschall <philippe.marschall@gmail.com> Cc: GemStone Seaside beta discussion <beta@seaside.gemstone.com> Subject: Re: [GS/SS Beta] Gettext (for use by Gettext-Seaside) ported to Gemstone Reply-To: GemStone Seaside beta discussion <beta@seaside.gemstone.com>
Hi Philippe,
Yes, those are classes I left out (but they don't have the WA prefix).
I also prefer that there is a shared common package for both platforms but there are more differences spread over several methods. Off the top of my head, most differences are located in the MOFile class. Also, the 'startup' methods that are used to trigger a locale refresh when starting the Pharo image are not applicable in Gemstone.
I'm willing to work towards a common package + platform-specific packages. Probably, we have to hear what the Pharo people (and specifically Hilaire Fernandes) think about it.
cheers Johan
On 23 May 2011, at 20:08, Philippe Marschall wrote:
2011/5/23 Johan Brichau <johan@inceptive.be>:
Hi all,
The Gettext [1] implementation of Pharo has now been ported to Gemstone, such that we can use it for internationalization in web applications together with Gettext-Seaside. More precisely, the Gettext package is a prerequisite for Gettext-Seaside.
With the "develop in Pharo, deploy in Gemstone" philosophy, I ported only those parts that are required to deploy the translation files in the Seaside web apps. The implementation that generates translation files from the codebase is a bit more entrenched into platform-specific libraries. So, one has to generate the translation catalogs to disk in Pharo, edit them with a tool like poedit, and deploy the locale with the Gemstone deployment.
Clever. I guess WAGetTextExporter and WATranslatedArgumentsFinder are the classes that don't work in Gemstone. If so I could split the package into a portable part and a Pharo part so you don't need to load them im GemSonte.
Cheers Philippe
On 24.05.2011 11:11, Johan Brichau wrote:
Hi guys,
What is the future of the Gettext package in the PharoNonCorePackages repository? Is the intention to include it in Pharo core? Should that package become a separate project? Something else?
I am asking this because I am using it for internationalization support in our Seaside apps (together with the Gettext-Seaside package by Philippe Marschall). Hence, I created a port of the relevant parts to GemStone, following the "develop in Pharo, deploy in GemStone" philosophy.
Now, the ported package is a complete duplicate + appropriate changes, but it's better if we create a common package and separate the platform-specific parts out. But I would not want to interfere with anyone's plans, specifically Hilaire Fernandes' plans, probably (who seems to be the author of the package).
So, I would like to get in touch with the stakeholders of the package and discuss where it's going.
cheers Johan
Hilaire is the major stakeholder yes. I had a cursory glance at the code when helping with the file-reading portion in Pharo, for a split aimed at cross-platform, I think 3 packages would be good: 1 ) Core - Providing the translation functionality itself, and parsing of a gettext stream. 2) In/Out - Platform-specific methods to provide streams to read from. 3) System Integration - Detecting locale to use, hooking into/ replacing existing translation engines etc. 1 should be able to do cross-platform. 2 should either have dialect-specific implementation, or a default implementation using Grease. 3 should be optional, and probably can't be provided only using Grease, so needs dialect-specific version. I'm not up to speed on what Grease offers atm though, so this might be wrong :) For platforms where you'd want to use it with seaside, I assume 1 + 2 would be enough? And you'd rarely need a dialect-specific implementation of 2, since Seaside depends on Grease anyways? In any case, I'd vote for moving it out of NonCore and into it's own, proper repository :) Cheers, Henry
I do not have enough experience so I'm all earing what you have to say. Hilaire?
What is the future of the Gettext package in the PharoNonCorePackages repository? Is the intention to include it in Pharo core? Should that package become a separate project? Something else?
I am asking this because I am using it for internationalization support in our Seaside apps (together with the Gettext-Seaside package by Philippe Marschall). Hence, I created a port of the relevant parts to GemStone, following the "develop in Pharo, deploy in GemStone" philosophy.
Now, the ported package is a complete duplicate + appropriate changes, but it's better if we create a common package and separate the platform-specific parts out. But I would not want to interfere with anyone's plans, specifically Hilaire Fernandes' plans, probably (who seems to be the author of the package).
So, I would like to get in touch with the stakeholders of the package and discuss where it's going.
cheers Johan
I ported the gettext package from Etoys to Pharo with help of other (Henrik). I have to admit I mostly forgot about its internal, even if I amn using it for DrGeo. In between, some part of the gettext package in Etoys was improved, I forgot which part exactly. Bert may remember a bit more. Do whatever you think is appropriate with the package. As you hacked the package recently you are definitely in a better position to split it in different component. Hilaire Le 24/05/2011 11:11, Johan Brichau a écrit :
Hi guys,
What is the future of the Gettext package in the PharoNonCorePackages repository? Is the intention to include it in Pharo core? Should that package become a separate project? Something else?
I am asking this because I am using it for internationalization support in our Seaside apps (together with the Gettext-Seaside package by Philippe Marschall). Hence, I created a port of the relevant parts to GemStone, following the "develop in Pharo, deploy in GemStone" philosophy.
Now, the ported package is a complete duplicate + appropriate changes, but it's better if we create a common package and separate the platform-specific parts out. But I would not want to interfere with anyone's plans, specifically Hilaire Fernandes' plans, probably (who seems to be the author of the package).
So, I would like to get in touch with the stakeholders of the package and discuss where it's going.
cheers Johan
(see more info below -- mails
Begin forwarded message:
From: Johan Brichau <johan@inceptive.be> Date: 24 May 2011 08:26:33 GMT+02:00 To: Philippe Marschall <philippe.marschall@gmail.com> Cc: GemStone Seaside beta discussion <beta@seaside.gemstone.com> Subject: Re: [GS/SS Beta] Gettext (for use by Gettext-Seaside) ported to Gemstone Reply-To: GemStone Seaside beta discussion <beta@seaside.gemstone.com>
Hi Philippe,
Yes, those are classes I left out (but they don't have the WA prefix).
I also prefer that there is a shared common package for both platforms but there are more differences spread over several methods. Off the top of my head, most differences are located in the MOFile class. Also, the 'startup' methods that are used to trigger a locale refresh when starting the Pharo image are not applicable in Gemstone.
I'm willing to work towards a common package + platform-specific packages. Probably, we have to hear what the Pharo people (and specifically Hilaire Fernandes) think about it.
cheers Johan
On 23 May 2011, at 20:08, Philippe Marschall wrote:
2011/5/23 Johan Brichau <johan@inceptive.be>:
Hi all,
The Gettext [1] implementation of Pharo has now been ported to Gemstone, such that we can use it for internationalization in web applications together with Gettext-Seaside. More precisely, the Gettext package is a prerequisite for Gettext-Seaside.
With the "develop in Pharo, deploy in Gemstone" philosophy, I ported only those parts that are required to deploy the translation files in the Seaside web apps. The implementation that generates translation files from the codebase is a bit more entrenched into platform-specific libraries. So, one has to generate the translation catalogs to disk in Pharo, edit them with a tool like poedit, and deploy the locale with the Gemstone deployment.
Clever. I guess WAGetTextExporter and WATranslatedArgumentsFinder are the classes that don't work in Gemstone. If so I could split the package into a portable part and a Pharo part so you don't need to load them im GemSonte.
Cheers Philippe
-- Education 0.2 -- http://blog.ofset.org/hilaire
Ok thanks Hilaire. I will take a look at the current state of the package in etoys and split up the code as I mentioned. I'm new to this kind of internationalization stuff, so I will do some work as part of internationalizing our web apps. On 24 May 2011, at 23:13, Hilaire Fernandes wrote:
I ported the gettext package from Etoys to Pharo with help of other (Henrik). I have to admit I mostly forgot about its internal, even if I amn using it for DrGeo. In between, some part of the gettext package in Etoys was improved, I forgot which part exactly. Bert may remember a bit more.
Do whatever you think is appropriate with the package. As you hacked the package recently you are definitely in a better position to split it in different component.
Hilaire
Le 24/05/2011 11:11, Johan Brichau a écrit :
Hi guys,
What is the future of the Gettext package in the PharoNonCorePackages repository? Is the intention to include it in Pharo core? Should that package become a separate project? Something else?
I am asking this because I am using it for internationalization support in our Seaside apps (together with the Gettext-Seaside package by Philippe Marschall). Hence, I created a port of the relevant parts to GemStone, following the "develop in Pharo, deploy in GemStone" philosophy.
Now, the ported package is a complete duplicate + appropriate changes, but it's better if we create a common package and separate the platform-specific parts out. But I would not want to interfere with anyone's plans, specifically Hilaire Fernandes' plans, probably (who seems to be the author of the package).
So, I would like to get in touch with the stakeholders of the package and discuss where it's going.
cheers Johan
(see more info below -- mails
Begin forwarded message:
From: Johan Brichau <johan@inceptive.be> Date: 24 May 2011 08:26:33 GMT+02:00 To: Philippe Marschall <philippe.marschall@gmail.com> Cc: GemStone Seaside beta discussion <beta@seaside.gemstone.com> Subject: Re: [GS/SS Beta] Gettext (for use by Gettext-Seaside) ported to Gemstone Reply-To: GemStone Seaside beta discussion <beta@seaside.gemstone.com>
Hi Philippe,
Yes, those are classes I left out (but they don't have the WA prefix).
I also prefer that there is a shared common package for both platforms but there are more differences spread over several methods. Off the top of my head, most differences are located in the MOFile class. Also, the 'startup' methods that are used to trigger a locale refresh when starting the Pharo image are not applicable in Gemstone.
I'm willing to work towards a common package + platform-specific packages. Probably, we have to hear what the Pharo people (and specifically Hilaire Fernandes) think about it.
cheers Johan
On 23 May 2011, at 20:08, Philippe Marschall wrote:
2011/5/23 Johan Brichau <johan@inceptive.be>:
Hi all,
The Gettext [1] implementation of Pharo has now been ported to Gemstone, such that we can use it for internationalization in web applications together with Gettext-Seaside. More precisely, the Gettext package is a prerequisite for Gettext-Seaside.
With the "develop in Pharo, deploy in Gemstone" philosophy, I ported only those parts that are required to deploy the translation files in the Seaside web apps. The implementation that generates translation files from the codebase is a bit more entrenched into platform-specific libraries. So, one has to generate the translation catalogs to disk in Pharo, edit them with a tool like poedit, and deploy the locale with the Gemstone deployment.
Clever. I guess WAGetTextExporter and WATranslatedArgumentsFinder are the classes that don't work in Gemstone. If so I could split the package into a portable part and a Pharo part so you don't need to load them im GemSonte.
Cheers Philippe
-- Education 0.2 -- http://blog.ofset.org/hilaire
participants (4)
-
Henrik Sperre Johansen -
Hilaire Fernandes -
Johan Brichau -
Stéphane Ducasse