Gettext package?
Locked
 
|
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 <[hidden email]> > Date: 24 May 2011 08:26:33 GMT+02:00 > To: Philippe Marschall <[hidden email]> > Cc: GemStone Seaside beta discussion <[hidden email]> > Subject: Re: [GS/SS Beta] Gettext (for use by Gettext-Seaside) ported to Gemstone > Reply-To: GemStone Seaside beta discussion <[hidden email]> > > 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 <[hidden email]>: >>> 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 |
|
|
In reply to this post by Johan Brichau-2
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 |
|
In reply to this post by Johan Brichau-2
CONTENTS DELETED
The author has deleted this message.
|
|
|
In reply to this post by Johan Brichau-2
On May 24, 2011, at 11:13 PM, 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. > Right now there is support for internationalisation in the image.... but not really used. Would it make sense to replace that with Gettext? (and make gettecht a core feature?) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
|
|
On 25.05.2011 08:14, Marcus Denker wrote:
> On May 24, 2011, at 11:13 PM, 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. >> > Right now there is support for internationalisation in the image.... but not really used. > Would it make sense to replace that with Gettext? (and make gettecht a core feature?) > > Marcus If you mean String >> #translated, the previous localization functionality in NaturalLanguageTranslator has been replaced by stubs since 1.2. The System Integration part of gettext package I mentioned hooks into this, and is the expected thing to use for those needing it. Personally, I don't think it belongs in Core. Cheers, Henry |
|
|
In reply to this post by Marcus Denker-4
On May 25, 2011, at 11:03 AM, Henrik Sperre Johansen wrote: > On 25.05.2011 08:14, Marcus Denker wrote: >> On May 24, 2011, at 11:13 PM, 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. >>> >> Right now there is support for internationalisation in the image.... but not really used. >> Would it make sense to replace that with Gettext? (and make gettecht a core feature?) >> >> Marcus > > If you mean String >> #translated, the previous localization functionality in NaturalLanguageTranslator has been replaced by stubs since 1.2. > The System Integration part of gettext package I mentioned hooks into this, and is the expected thing to use for those needing it. > > Personally, I don't think it belongs in Core. But does it belong into that what we call Pharo? -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
|
|
> But does it belong into that what we call Pharo?
yes probably. Stef |
|
|
On 25 May 2011, at 11:34, Stéphane Ducasse wrote: >> But does it belong into that what we call Pharo? > > yes probably. If you want to keep and improve the existing "localisation & translation" support, I think it's a good idea to integrate Gettext. It uses a format that is used beyond the Smalltalk community. But I guess the above depends wether the 'core' Pharo tools require some "translation" support. And I don't think they do, i.e: I don't think we want a french version of the system browser ;-) They might require "localisation" without the translation (i.e. date format etc.) but Gettext is not about that. Any internationalization support is more a package to be used by applications developed in Pharo. My use of Gettext, for example, is for translation support in Seaside apps. Hilaire uses it for Dr. Geo. Of course, GemStone and Visualworks also come with an internationalization library integrated in the basic image (not entirely sure about VW). If I do more work using Gettext, I can certainly do something for its integration in Pharo. Johan |
|
|
In reply to this post by 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 <[hidden email]> >>> Date: 24 May 2011 08:26:33 GMT+02:00 >>> To: Philippe Marschall <[hidden email]> >>> Cc: GemStone Seaside beta discussion <[hidden email]> >>> Subject: Re: [GS/SS Beta] Gettext (for use by Gettext-Seaside) ported to Gemstone >>> Reply-To: GemStone Seaside beta discussion <[hidden email]> >>> >>> 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 <[hidden email]>: >>>>> 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 > > |
|
|
In reply to this post by Johan Brichau-2
>>
> > If you want to keep and improve the existing "localisation & translation" support, I think it's a good idea to integrate Gettext. It uses a format that is used beyond the Smalltalk community. yes > > But I guess the above depends wether the 'core' Pharo tools require some "translation" support. And I don't think they do, i.e: I don't think we want a french version of the system browser ;-) :) > They might require "localisation" without the translation (i.e. date format etc.) but Gettext is not about that. Any internationalization support is more a package to be used by applications developed in Pharo. > My use of Gettext, for example, is for translation support in Seaside apps. Hilaire uses it for Dr. Geo. > > Of course, GemStone and Visualworks also come with an internationalization library integrated in the basic image (not entirely sure about VW). > > If I do more work using Gettext, I can certainly do something for its integration in Pharo. excellent so let us know. > > Johan |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |