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.
On 23 May 2011, at 20:08, Philippe Marschall wrote:
> 2011/5/23 Johan Brichau <[hidden email]
>> Hi all,
>> The Gettext  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.