September 2014 - Pharo-users

Re: [Pharo-users] Gettext with pharo 3 and seaside 3.1.2

by Johan Brichau

On 14 Sep 2014, at 12:59, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Just think about it: Pharo itself should have translated menus. So we need *something* in the system anyway. > Why then not make it good and make it the one that everyone is using? Yes, and actually, Gettext is just about the support for the Gettext format [1]. So, you can see it as an extension of the existing Localization system that is already in the image and itâs probably a good idea to internalize it completely. The LocaleID and NaturalLanguageTranslator classes in the package are the same (and more) as those already in the image. So, why not just internalize it? I think there are a couple of people who are willing to maintain it: Hilaire, Usman and myself (who are the current maintainers of the package). Maybe this discussion should move to pharo-dev ? Thereâs not so much to the Gettext package actually. It just deserves a bit of a cleaning. The hard part is: make your applications use the localization and create translation filesâ¦ Johan [1] http://www.gnu.org/software/gettext/

Sept. 14, 2014

Re: [Pharo-users] Gettext with pharo 3 and seaside 3.1.2

by Johan Brichau

Peter, Gettext works. See DrGeo, for example. Also, the Seaside-Gettext extension works just fine. If I understand correctly, the Pharo IDE (and rest of the system) has not been working with ant localization implementation. Johan On 14 Sep 2014, at 16:18, Peter Schorsch <tralalas(a)freenet.de> wrote: >> Localization is very basic functionality that should be provided by >> the platform itself. We are in the situation that we are in only >> because people see Pharo as something âto build on topâ. >> >> This way everyone does their own I18N stuff, while the right thing >> would be to have *one* that is good and part or Pharo itself. >> >> Just think about it: Pharo itself should have translated menus. So we >> need *something* in the system anyway. Why then not make it good and >> make it the one that everyone is using? > > As a beginner with pharo I TOTALLY agree with that statement. E.g. so > far I understood there are 3 different localization existing: > > * System internal localization > - never seen before, never read about before > * Gettext > - does not work > * QCMagritte > - shall work, did not managed it by myself. Only uses csv > table if I understood correctly. > > Here is my suggestion (keep in mind that I did not fully understood > QCMagritte atm). My wish is a localization that: > > * supports the gettext format for in and output > * has fallback options if a phrase is not translated > * pharo internal interface maybe a Dictionary > * support of different number formats (e.g. date etc.) > * does NOT depend on the env locales - only the IDE of pharo > > Honestly, I am surprised that pharo does not work fully with utf8 > (see MathOntology discussion) and has no well documentated and working > localization. > > If I understood something wrong please correct me - I still want to > learn pharo and seaside :) >

Sept. 14, 2014

Re: [Pharo-users] Gettext with pharo 3 and seaside 3.1.2

by Peter Schorsch

> Localization is very basic functionality that should be provided by > the platform itself. We are in the situation that we are in only > because people see Pharo as something âto build on topâ. > > This way everyone does their own I18N stuff, while the right thing > would be to have *one* that is good and part or Pharo itself. > > Just think about it: Pharo itself should have translated menus. So we > need *something* in the system anyway. Why then not make it good and > make it the one that everyone is using? As a beginner with pharo I TOTALLY agree with that statement. E.g. so far I understood there are 3 different localization existing: * System internal localization - never seen before, never read about before * Gettext - does not work * QCMagritte - shall work, did not managed it by myself. Only uses csv table if I understood correctly. Here is my suggestion (keep in mind that I did not fully understood QCMagritte atm). My wish is a localization that: * supports the gettext format for in and output * has fallback options if a phrase is not translated * pharo internal interface maybe a Dictionary * support of different number formats (e.g. date etc.) * does NOT depend on the env locales - only the IDE of pharo Honestly, I am surprised that pharo does not work fully with utf8 (see MathOntology discussion) and has no well documentated and working localization. If I understood something wrong please correct me - I still want to learn pharo and seaside :)

Sept. 14, 2014

Re: [Pharo-users] Gettext with pharo 3 and seaside 3.1.2

by Johan Brichau

On 13 Sep 2014, at 19:54, stepharo <stepharo(a)free.fr> wrote: > > On 13/9/14 15:57, Hilaire wrote: >> Hello, >> >> I guess the gettext package on the seaside repo depends on the gettext package at PharoExtra and it adds some glue code for Seaside use. Is it correct? > > I did not check but I think so Yes, Seaside-Gettext an extension of Gettext for Seaside apps. Johan

Sept. 14, 2014

Re: [Pharo-users] Gettext with pharo 3 and seaside 3.1.2

by Sven Van Caekenberghe

On 14 Sep 2014, at 12:59, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 13 Sep 2014, at 20:51, stepharo <stepharo(a)free.fr> wrote: > >> So I'm checking and when we load Gettext, >> System-Localization only contains >> ISOLanguageDefinition >> Locale >> >> Locale is used by LanguageEnvironment, LocalID, TimeZone, Unicode >> >> When we will clean leadingChar some of these will go away. >> >> So not all the package System-Localisation can be moved out the image to got in a newer version of getText >> > > > Localization is very basic functionality that should be provided by the platform itself. > We are in the situation that we are in only because people see Pharo as something âto build on topâ. > > This way everyone does their own I18N stuff, while the right thing would be to have *one* that is good and > part or Pharo itself. > > Just think about it: Pharo itself should have translated menus. So we need *something* in the system anyway. > Why then not make it good and make it the one that everyone is using? > > Marcus +1

Sept. 14, 2014

Re: [Pharo-users] Gettext with pharo 3 and seaside 3.1.2

by Marcus Denker

On 13 Sep 2014, at 20:51, stepharo <stepharo(a)free.fr> wrote: > So I'm checking and when we load Gettext, > System-Localization only contains > ISOLanguageDefinition > Locale > > Locale is used by LanguageEnvironment, LocalID, TimeZone, Unicode > > When we will clean leadingChar some of these will go away. > > So not all the package System-Localisation can be moved out the image to got in a newer version of getText > Localization is very basic functionality that should be provided by the platform itself. We are in the situation that we are in only because people see Pharo as something âto build on topâ. This way everyone does their own I18N stuff, while the right thing would be to have *one* that is good and part or Pharo itself. Just think about it: Pharo itself should have translated menus. So we need *something* in the system anyway. Why then not make it good and make it the one that everyone is using? Marcus

Sept. 14, 2014

Re: [Pharo-users] [Esug-list] How to contribute CP1251TextConverter ?

by Ben Coman

Sept. 14, 2014

Re: [Pharo-users] Gettext with pharo 3 and seaside 3.1.2

by stepharo

So I'm checking and when we load Gettext, System-Localization only contains ISOLanguageDefinition Locale Locale is used by LanguageEnvironment, LocalID, TimeZone, Unicode When we will clean leadingChar some of these will go away. So not all the package System-Localisation can be moved out the image to got in a newer version of getText Stef

Sept. 13, 2014

Re: [Pharo-users] Gettext with pharo 3 and seaside 3.1.2

by stepharo

On 13/9/14 15:57, Hilaire wrote: > Hello, > > I guess the gettext package on the seaside repo depends on the gettext > package at PharoExtra and it adds some glue code for Seaside use. Is > it correct? I did not check but I think so > > > Le 13/09/2014 12:43, Johan Brichau a Ã©crit : >> >> On 13 Sep 2014, at 10:09, stepharo >> <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >>> Then what is the seaside-Getext? Is is a superset of >>> pharoExtras-gettext? >> >> https://code.google.com/p/seaside/wiki/Gettext >> >> In short: itâs a Seaside extension to internationalise your web app. >> >>> For application not doing web, does it make sense to use it? >> >> No, but I donât see how you guys complain about that. The package is in >> the Seaside repo and in the ConfigurationOfSeaside3. >> Can you explain the issue? >> >>> Is it packaged separately? >> >> yes. >> >> Johan > >

Sept. 13, 2014

Re: [Pharo-users] Gettext with pharo 3 and seaside 3.1.2

by stepharo

Thanks Johan I would like to know we could move all the system-Localization classes to the getText package. Or another package outside the core because we basically shortcut completely its use. I will look a bit around. > On 13 Sep 2014, at 10:09, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > >> Then what is the seaside-Getext? Is is a superset of pharoExtras-gettext? > > https://code.google.com/p/seaside/wiki/Gettext could we edit the wiki to say to load getText from PharoExtras? So I have the impression that we could move System-Localization to Gettext without impacting - current users - pharo core - current seasiders. > In short: itâs a Seaside extension to internationalise your web app. > >> For application not doing web, does it make sense to use it? > > No, but I donât see how you guys complain about that. The package is > in the Seaside repo and in the ConfigurationOfSeaside3. > Can you explain the issue? there are two issues: - system-Localization is not used in the image because NaturalLanguageTranslator>>translate: aString ^ aString - when people load getText, the package get dirty because a new class definition is installed. >> Is it packaged separately? > > yes. > > Johan

Sept. 13, 2014