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 <[email protected]> >> Date: 24 May 2011 08:26:33 GMT+02:00 >> To: Philippe Marschall <[email protected]> >> Cc: GemStone Seaside beta discussion <[email protected]> >> Subject: Re: [GS/SS Beta] Gettext (for use by Gettext-Seaside) ported to >> Gemstone >> Reply-To: GemStone Seaside beta discussion <[email protected]> >> >> 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 <[email protected]>: >>>> 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
