On 07 Sep 2014, at 20:32, stepharo <stepharo@free.fr> wrote:

On 7/9/14 15:32, Peter Schorsch wrote:

...

Hi,

Just started with pharo and seaside.

Welcome!

...

Now I want to write an example seaside-application but with a multi lingual interface. So I installed pharo3 and then seaside via configuration browser.

But then I had to realize that the seaside-gettext package was not installed; and also no gettext package. I found a gettext package in the repository http://smalltalkhub.com/mc/PharoExtras/Gettext.

I installed the package ConfigurationOfGettext, but the configuraitonof-browser does not show it. The configuration browser only shows the configurations that are published in a given repository. So I installed the package Gettext via monticello.

I think that people will reply to you. I know that there was a conflict between one class in the getText and one in Pharo30.

There is an issue here: https://pharo.fogbugz.com/f/cases/13655/System-Localization-and-Gettext-have... Marcus

Hi, I don't know if it is related but I have problems importing french files inside Pharo 3: Anytime when there is an accentuated character there is an error, and the file is not imported. Even if the character is a quote inside double quotes (like in "it don't work") there is an error message. Right now I can't import MathsOntologie ( http://ss3.gemstone.com/ss/MathsOntologie/MathsOntologie-AlainBusser.68.mcz) into Pharo 3 and I have to go on developing it in Pharo 1.4... Alain On Mon, Sep 8, 2014 at 1:16 PM, Hilaire <hilaire@drgeo.eu> wrote:

What is the purpose of the seaside-gettext package ? Is it a relic or is it useful? Gettext is orthogonal to Seaside.

Hilaire

Le 07/09/2014 15:32, Peter Schorsch a écrit :

...

But then I had to realize that the seaside-gettext package was not installed; and also no gettext package. I found a gettext package in the repositoryhttp://smalltalkhub.com/mc/PharoExtras/Gettext.

I installed the package ConfigurationOfGettext, but the configuraitonof-browser does not show it. So I installed the package Gettext via monticello.

-- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu

Oh, by the way, it looks like the accents are on the instance variable names. I edited the subject to not pollute the original discussion thread. Hilaire Le 08/09/2014 20:01, Hilaire a écrit :

Marcus,

Alain's MathOntologie package provide Classes and Messages with French accent, to ease the understanding of programming to high school students. I am suspecting the new compiler or something related does not accepted accented caracters or something different to ASCII.

Alain, in your package I noted the sources is not utf-8 but iso-8859-15 (8 bits), I converted it to utf-8 and tried to get it loaded in Pharo3, but still accent characters caused problem, see screenshot.

Enclosed source file utf-8 converted and improper imported source code with accented variable name.

Hilaire

Le 08/09/2014 12:18, Alain Busser a écrit :

...

Hi,

I don't know if it is related but I have problems importing french files inside Pharo 3: Anytime when there is an accentuated character there is an error, and the file is not imported. Even if the character is a quote inside double quotes (like in "it don't work") there is an error message. Right now I can't import MathsOntologie (http://ss3.gemstone.com/ss/MathsOntologie/MathsOntologie-AlainBusser.68.mcz)

into Pharo 3 and I have to go on developing it in Pharo 1.4...

Alain

-- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu

What kind of bug do you have with accent ? Do you have a stack trace ? More importantly, can you give us a reproducible case ? I will investigate tomorrow if you have a reproducible case to check if this is due to Opal. It may also be recent changes related to fonts. 2014-09-08 21:07 GMT+02:00 Sven Van Caekenberghe <sven@stfx.eu>:

I don't think it is related to Opal: I made a test class with an instance variable, accessor and class comment with accents - which I can file out and file in:

I tested in 3.0 and 4.0

The problem might be with Monticello.

On 08 Sep 2014, at 20:05, Hilaire <hilaire@drgeo.eu> wrote:

...

Oh, by the way, it looks like the accents are on the instance variable names.

I edited the subject to not pollute the original discussion thread.

Hilaire

Le 08/09/2014 20:01, Hilaire a écrit :

...

Marcus,

Alain's MathOntologie package provide Classes and Messages with French accent, to ease the understanding of programming to high school students. I am suspecting the new compiler or something related does not accepted accented caracters or something different to ASCII.

Alain, in your package I noted the sources is not utf-8 but iso-8859-15 (8 bits), I converted it to utf-8 and tried to get it loaded in Pharo3, but still accent characters caused problem, see screenshot.

Enclosed source file utf-8 converted and improper imported source code with accented variable name.

Hilaire

Le 08/09/2014 12:18, Alain Busser a écrit :

...

Hi,

I don't know if it is related but I have problems importing french files inside Pharo 3: Anytime when there is an accentuated character there is an error, and the file is not imported. Even if the character is a quote inside double quotes (like in "it don't work") there is an error message. Right now I can't import MathsOntologie ( http://ss3.gemstone.com/ss/MathsOntologie/MathsOntologie-AlainBusser.68.mcz )

into Pharo 3 and I have to go on developing it in Pharo 1.4...

Alain

-- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu

2014-09-09 14:12 GMT+02:00 Alain Busser <alain.busser@gmail.com>:

Is this a reproducible case? http://ss3.gemstone.com/ss/MathsOntologie/MathsOntologie-AlainBusser.68.mcz

Well I tried to merge that in the latest Pharo 4. With Opal I got the error 'unknown character' With the old compiler I got unmatched string quote. If it's French, could it be a ' ? It looks like a parser bug to me... I hope not :-)

Alain

On Tue, Sep 9, 2014 at 5:43 AM, Clément Bera <bera.clement@gmail.com> wrote:

...

What kind of bug do you have with accent ? Do you have a stack trace ?

More importantly, can you give us a reproducible case ? I will investigate tomorrow if you have a reproducible case to check if this is due to Opal.

It may also be recent changes related to fonts.

2014-09-08 21:07 GMT+02:00 Sven Van Caekenberghe <sven@stfx.eu>:

...

I don't think it is related to Opal: I made a test class with an instance variable, accessor and class comment with accents - which I can file out and file in:

I tested in 3.0 and 4.0

The problem might be with Monticello.

On 08 Sep 2014, at 20:05, Hilaire <hilaire@drgeo.eu> wrote:

...

Oh, by the way, it looks like the accents are on the instance variable names.

I edited the subject to not pollute the original discussion thread.

Hilaire

Le 08/09/2014 20:01, Hilaire a écrit :

...

Marcus,

Alain's MathOntologie package provide Classes and Messages with French accent, to ease the understanding of programming to high school students. I am suspecting the new compiler or something related does not accepted accented caracters or something different to ASCII.

Alain, in your package I noted the sources is not utf-8 but iso-8859-15 (8 bits), I converted it to utf-8 and tried to get it loaded in Pharo3, but still accent characters caused problem, see screenshot.

Enclosed source file utf-8 converted and improper imported source code with accented variable name.

Hilaire

Le 08/09/2014 12:18, Alain Busser a écrit :

...

Hi,

I don't know if it is related but I have problems importing french files inside Pharo 3: Anytime when there is an accentuated character there is an error, and the file is not imported. Even if the character is a quote inside double quotes (like in "it don't work") there is an error message. Right now I can't import MathsOntologie ( http://ss3.gemstone.com/ss/MathsOntologie/MathsOntologie-AlainBusser.68.mcz )

into Pharo 3 and I have to go on developing it in Pharo 1.4...

Alain

-- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu

IIRC, there are two sources of imported code in Monticello. By default it reads from the DataStream encoded .bin file, which stores source containing wide character as... a binary WideString. Unless the .bin file is somehow corrupted, importing non-ascii .mcz therefore works as long as you have a working DataStream reader. * If that path fails, it will read from the .st file, which, IIRC, had utf8 encoding added quite recently by Nicolas Cellier. So to narrow this down further, one has to ask: For what reason did the DataStream reading fail? - Did the DataStream get written (correctly)? - Did the DataStream fail to read a correctly written file? (f.ex. due to class shape changes in image, without proper backwards compat reading methods added) Why didn't the fallback .st work? - Did the .st file write out as utf8? (could be the case not if written from an older image, but then I'd expect the FileStream to barf, not the compiler) - Did the .st get written as the *correct* utf8? - Did the .st file read in as utf8? Once which combination of those things failed in this case is found, it should be easier to see what a fix could/should be. Cheers, Henry * Which is why non-ascii packages at least used to fail to import in Gemstone, their DataStream reader could not translate WideString instances to the proper internal string representations, and the fallback .st didn't use to be properly encoded. IIRC, the VW reader goes straight for the .st, so same problem there. There's a reason Seaside has ascii-only as a requirement :) On 09 Sep 2014, at 7:07 , Sven Van Caekenberghe <sven@stfx.eu> wrote:

Check/read my mail again: I don't think it is the compiler (my tests show it is not), then it must be Monticello, in the sense that it treats its input stream (encoding) wrongly.

On 09 Sep 2014, at 15:25, Clément Bera <bera.clement@gmail.com> wrote:

...

2014-09-09 14:12 GMT+02:00 Alain Busser <alain.busser@gmail.com>: Is this a reproducible case? http://ss3.gemstone.com/ss/MathsOntologie/MathsOntologie-AlainBusser.68.mcz

Well I tried to merge that in the latest Pharo 4.

With Opal I got the error 'unknown character'

With the old compiler I got unmatched string quote.

If it's French, could it be a ' ?

It looks like a parser bug to me...

I hope not :-)

Alain

On Tue, Sep 9, 2014 at 5:43 AM, Clément Bera <bera.clement@gmail.com> wrote: What kind of bug do you have with accent ? Do you have a stack trace ?

More importantly, can you give us a reproducible case ? I will investigate tomorrow if you have a reproducible case to check if this is due to Opal.

It may also be recent changes related to fonts.

2014-09-08 21:07 GMT+02:00 Sven Van Caekenberghe <sven@stfx.eu>: I don't think it is related to Opal: I made a test class with an instance variable, accessor and class comment with accents - which I can file out and file in:

I tested in 3.0 and 4.0

The problem might be with Monticello.

On 08 Sep 2014, at 20:05, Hilaire <hilaire@drgeo.eu> wrote:

...

Oh, by the way, it looks like the accents are on the instance variable names.

I edited the subject to not pollute the original discussion thread.

Hilaire

Le 08/09/2014 20:01, Hilaire a écrit :

...

Marcus,

Alain's MathOntologie package provide Classes and Messages with French accent, to ease the understanding of programming to high school students. I am suspecting the new compiler or something related does not accepted accented caracters or something different to ASCII.

Alain, in your package I noted the sources is not utf-8 but iso-8859-15 (8 bits), I converted it to utf-8 and tried to get it loaded in Pharo3, but still accent characters caused problem, see screenshot.

Enclosed source file utf-8 converted and improper imported source code with accented variable name.

Hilaire

Le 08/09/2014 12:18, Alain Busser a écrit :

...

Hi,

I don't know if it is related but I have problems importing french files inside Pharo 3: Anytime when there is an accentuated character there is an error, and the file is not imported. Even if the character is a quote inside double quotes (like in "it don't work") there is an error message. Right now I can't import MathsOntologie (http://ss3.gemstone.com/ss/MathsOntologie/MathsOntologie-AlainBusser.68.mcz)

into Pharo 3 and I have to go on developing it in Pharo 1.4...

Alain

-- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu

Absolutely right. I open a ticket for Alain https://pharo.fogbugz.com/f/cases/13980/Math-Ontologie-on-Pharo-3-0. Alain I suggest you get your hand in the Pharo bug tracker (http://bugs.pharo.org) and create yourself an account[1] there to comment and to report additional problem you may meet. [1] https://pharo.fogbugz.com/default.asp?W41 Le 09/09/2014 09:56, Marcus Denker a écrit :

I will have a look and check… (with the first goal to add an issue tracker entry for it) On 08 Sep 2014, at 20:01, Hilaire<hilaire-QBJRSr1f4Ts@public.gmane.org> wrote:

-- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu

Hi, The Seaside-Gettext package is in the Seaside repository http://www.smalltalkhub.com/#!/~Seaside/Seaside30Addons The package in the PharoExtras repository is a relic. The ConfigurationOfSeaside3 correctly references the Seaside-Gettext package and it’s absolutely functional (using this in production systems). What is a bit silly is that the ConfigurationOfSeaside3 relies on people chosing the appropriate groups to load and the Pharo configuration browser always loads the default transparantly. I will probably update that for Seaside 3.2.0, so that the default loads everything for newcomers, but for the current version some load configurations might rely on it and that’s the way it is. Johan On 08 Sep 2014, at 11:16, Hilaire <hilaire@drgeo.eu> wrote:

What is the purpose of the seaside-gettext package ? Is it a relic or is it useful? Gettext is orthogonal to Seaside.

Hilaire

Le 07/09/2014 15:32, Peter Schorsch a écrit :

...

But then I had to realize that the seaside-gettext package was not installed; and also no gettext package. I found a gettext package in the repositoryhttp://smalltalkhub.com/mc/PharoExtras/Gettext.

I installed the package ConfigurationOfGettext, but the configuraitonof-browser does not show it. So I installed the package Gettext via monticello.

-- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu

On 13 Sep 2014, at 10:09, stepharo <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

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@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

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@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

On 13 Sep 2014, at 20:51, stepharo <stepharo@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

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 :)

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 <tralalas@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 :)

On 14 Sep 2014, at 12:59, Marcus Denker <marcus.denker@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/

...

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. To me it was not that obvious. 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

On 14 Sep 2014, at 19:16, stepharo <stepharo@free.fr> wrote:

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.

Yes, let’s discuss it sometimes this week.

Stef

On 14/9/14 12:59, Marcus Denker wrote:

...

On 13 Sep 2014, at 20:51, stepharo <stepharo@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

probably GraphET https://www.facebook.com/media/set/?set=a.566523986767536.1073741839.3405434... On 25 Sep 2014, at 09:08, Friedrich Dominicus <frido@q-software-solutions.de> wrote:

If one is intersted in graphics of diverse functions?

E.g plotting x^2,x^3 and the like. I checked the DrGeo stuff but that's geometry and not just analysis of functions and the like?

Does there exist something for that?

Regards Friedrich

There is a new Charter builder now. It’s not very stable yet as far as I can tell, but it’s the future of charts in Roassal https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Charter/0202... <https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Charter/0202...> Uko

On 25 Sep 2014, at 09:19, Friedrich Dominicus <frido@q-software-solutions.de> wrote:

Esteban Lorenzano <estebanlm@gmail.com> writes:

...

probably GraphET

https://www.facebook.com/media/set/?set=a.566523986767536.1073741839.3405434... Thanks, that seems to be it

Regards Friedrich