Gettext with pharo 3 and seaside 3.1.2
Locked
123
123
 
|
Hi johan usman and other
I would like to get a clearer picture. https://pharo.fogbugz.com/f/cases/13655/System-Localization-and-Gettext-have-classes-with-identical-names We could change the name of in the PharoExtras package gettext so that we do not have conflicts with the in-image mechanisms. I'm skeptical about all these translated messages everywhere. What people do for the applications? Then what is the seaside-Getext? Is is a superset of pharoExtras-gettext? For application not doing web, does it make sense to use it? Is it packaged separately? Stef |
|
|
In reply to this post by Usman Bhatti
> http://pharo.gemtalksystems.com/book/LanguageAndLibraries/Localisation/PreparingImage/ > Thanks I turned it into a chapter Stef |
Re: Gettext with pharo 3 and seaside 3.1.2
|
|
In reply to this post by stepharo
On 13 Sep 2014, at 10:09, stepharo <[hidden email]> wrote: Then what is the seaside-Getext? Is is a superset of pharoExtras-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
|
Re: Gettext with pharo 3 and seaside 3.1.2
|
In reply to this post by Johan Brichau-2
Le 13/09/2014 09:57, Johan Brichau a écrit :
> Hi, > > The Seaside-Gettext package is in the Seaside repository > http://www.smalltalkhub.com/#!/~Seaside/Seaside30Addons > <http://www.smalltalkhub.com/#%21/%7ESeaside/Seaside30Addons> > The package in the PharoExtras repository is a relic. You mean the Seaside-Gettext-Slime right? Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu |
Re: Gettext with pharo 3 and seaside 3.1.2
|
|
In reply to this post by Johan Brichau-2
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? Le 13/09/2014 12:43, Johan Brichau a écrit : > > On 13 Sep 2014, at 10:09, stepharo > <[hidden email] > <mailto:[hidden email]>> 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 -- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu |
|
|
In reply to this post by Johan Brichau-2
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. 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. 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.
|
|
|
In reply to this post by HilaireFernandes
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 >> <[hidden email] >> <mailto:[hidden email]>> 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 > > |
|
|
In reply to this post 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 |
Re: Gettext with pharo 3 and seaside 3.1.2
|
|
On 13 Sep 2014, at 20:51, stepharo <[hidden email]> 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 |
Re: Gettext with pharo 3 and seaside 3.1.2
|
|
On 14 Sep 2014, at 12:59, Marcus Denker <[hidden email]> wrote: > > On 13 Sep 2014, at 20:51, stepharo <[hidden email]> 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 |
Re: Gettext with pharo 3 and seaside 3.1.2
|
|
In reply to this post by stepharo
On 13 Sep 2014, at 19:54, stepharo <[hidden email]> 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 |
Re: Gettext with pharo 3 and seaside 3.1.2
|
|
In reply to this post by Marcus Denker-4
> 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 :) |
Re: Gettext with pharo 3 and seaside 3.1.2
|
|
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 <[hidden email]> 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 :) > |
Re: Gettext with pharo 3 and seaside 3.1.2
|
|
In reply to this post by Marcus Denker-4
On 14 Sep 2014, at 12:59, Marcus Denker <[hidden email]> 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/ |
Re: Gettext with pharo 3 and seaside 3.1.2
|
|
Le 14/09/2014 16:49, Johan Brichau a écrit :
> 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? Make sense > 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… But please keep it external, with just the needed existing #translated hook and necessary support class. Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu |
|
|
In reply to this post by Marcus Denker-4
>> 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. Frankly do you want to have menu in german? I would really like to avoid to have String poluted with translation. Translation of external string have not really something to do in a language core. > Just think about it: Pharo itself should have translated menus. Really. Who would be using them **AND** maintain their translation. > So we need *something* in the system anyway. > Why then not make it good and make it the one that everyone is using? May be but not by forcing all the internationalization code to be in the bootstrap because it is not its place. I would like to get the leadingChar cleaned and use Unicode and we could get rid of a lot of strange code. > Marcus |
|
|
In reply to this post by Peter Schorsch
On 14/9/14 16:18, Peter Schorsch 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. Evolution is more difficult than writing a new language in 2014! > > If I understood something wrong please correct me - I still want to > learn pharo and seaside :) > > |
|
|
In reply to this post by Johan Brichau-2
On 14/9/14 16:39, Johan Brichau wrote: > 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. the fallback was simply to not translate the strings. You see we cannot try to reduce the use of strings and add translations to all the possible languages in the image. I personally do not need Pharo menu in French and do not count on me to translate them. I have been this road once and never again. Stef > > Johan > > On 14 Sep 2014, at 16:18, Peter Schorsch <[hidden email]> 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 :) >> > > > |
|
|
In reply to this post by Marcus Denker-4
Marcus I think that we should sync because personally I do not want to
giant kernel. I want a bootstrap and modular packages. I think that making all the packages internal to the image is a recipe to get a monolithic system. I do not see why loading a package would hurt. Stef On 14/9/14 12:59, Marcus Denker wrote: > On 13 Sep 2014, at 20:51, stepharo <[hidden email]> 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 > |
Re: Gettext with pharo 3 and seaside 3.1.2
|
|
In reply to this post by Peter Schorsch
QCMagritte provides a visitor that walks your magritte descriptions and knows properties that might need translation. With those (and any extra terms you add directly) it builds up a dictionary of terms to translate. It provides a web UI where the translations can be entered and supports loading from and saving to utf8 csv. When generating the seaside components, it supports chaining multiple visitors to separate concerns (translation, bootstrap layout, access control).
In a system with users, it allows a user to set her preferred language to be used in the application. Unavailable translations just show the translation key. Stephan |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |