Re: [Pharo-users] I18n in pharo

[Hilaire]

Ok, got it.


Le 12/11/2017 à 13:04, Stephane Ducasse a écrit :

Yes. Morph and Polymorph as well as Athens but Sparta offers a similar
API. So conversion should be easy.
And Bloc opens a lot of possibilities. Bloc is the result of around 4
years of effort understanding the domain
and comparing solutions.


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

Re: [Pharo-users] I18n in pharo

[Pavel Krivanek]

2017-11-12 13:02 GMT+01:00 Stephane Ducasse :

> Excellent Pavel. This is great.
> So I do not get it. What is then not working?
>

The layout of the menu is wrong and everything needs to be proven with the
newer versions of the dependent packages.

-- Pavel


>
> Stef
>
> On Sun, Nov 12, 2017 at 12:13 AM, Pavel Krivanek
>  wrote:
> >
> >
> > 2017-11-10 11:52 GMT+01:00 Hilaire :
> >>
> >> A cleaner Pharo will help there.
> >>
> >> To be frank, I found later Pharo releases not inspiring. Bigger, bigger
> >> and bigger with added code, protocol changes, and bugs at will. It is
> >> becoming too complicated for a hobby use of it.
> >>
> >> I decided I will not finish porting DrGeo to P6 or P7, and it will
> likely
> >> die with P3.
> >
> >
> > To run DrGeo on Pharo 7 is not hard (see the screenshot) - of course it
> has
> > some issues but they can be definitely solved. It would be pity to throw
> it
> > away - at least you can benefit from 64-bit and faster VM.
> >
> > -- Pavel
> >
> >>
> >> Pharo should have been clean up to the bones before adding. It was the
> >> initial moto, no?
> >>
> >>
> >> Le 10/11/2017 à 11:14, Marcus Denker a écrit :
> >>>
> >>> It would be nice if someone who uses it would take the lead
> >>> so we can improve the default that is shipped with Pharo.
> >>
> >>
> >> --
> >> Dr. Geo
> >> http://drgeo.eu
> >>
> >>
> >>
> >
>
>

Re: [Pharo-users] I18n in pharo

[Stephane Ducasse]

Hilaire

Bloc, Brick are not in Pharo yet. So either you want to build on top
of Bloc and you use Bloc or not.
Easy.
Right now in Pharo we have
 - plain Morphic (with Polymorph but this is the same)
 - Spec to build user interface independent of the underlying layer
(Morphic for now)
 - Glamour to build browser/navigation

Now if you need vector graphics: you use Athens in Pharo.
In the future we will have Sparta which is better adapted for Bloc
(local coordinates over global coordinates) but this is the same kind
of API.

So this is not complex.
The decision tree is

Using plain Pharo or not => Morphic or Bloc


Stef


On Sat, Nov 11, 2017 at 9:29 PM, Hilaire  wrote:
> P6 is definitely a better IDE compare to previous version, and for coming
> Calypso looks fantastic, but P6 is a worst vehicle for a desktop
> application. There is much more code included and you are on your on to
> shrink/clean it to deploy your desktop application to make it looks and
> behave user friendly. May be for a specialized audience it could be just
> fine to deploy as is.
>
> About my perception on Pharo, from a distant POV, I see
> parallel/overlapping/contiguous layers like Morphic, Athens, Sparta, Bloc,
> Brick, Spec, GT, Polymorph all this looks confusing for me and I really
> don't know or understand where to put my eggs.
>
> When I took a look at Pharo keyboard shortcut, it seems to be -- without
> been sure 100% -- there are two different implementations. One from GT and
> another one, probably a legacy one. How can it happen? Then you wonder about
> other part of the system. It makes fells like changes/implementations are
> not coherent, and you don't really fell the environment as coherent or
> trustful.
>
> May be the twist is ontological, Pharo (and Squeak) taking too much
> responsibilities and not delegating enough to the host environment: GUI,
> Freetype, Canvas. The energy required is then out of reach or the needed
> coherence in teams works too complex. Don't know, just blind guesses, I will
> now shut up.
>
>
> Le 10/11/2017 à 12:23, Cédrick Béler a écrit :
>>
>> But I have the opposite impression (of course I don’t have to maintain a
>> big project like yours - I wouldn’t say you’re the hobby user:)  ). But I
>> really find P6 more consistent than what I used to try in the past (last
>> squeaks up to 3.9 and firsts pharo).
>
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>

Re: [Pharo-users] I18n in pharo

[Stephane Ducasse]

> Looks like a big sandwich, though.
>
> Will Athne be throwm away? With Polymorph and Morph?

Yes. Morph and Polymorph as well as Athens but Sparta offers a similar
API. So conversion should be easy.
And Bloc opens a lot of possibilities. Bloc is the result of around 4
years of effort understanding the domain
and comparing solutions.

Stef

Re: [Pharo-users] I18n in pharo

[Stephane Ducasse]

Excellent Pavel. This is great.
So I do not get it. What is then not working?

Stef

On Sun, Nov 12, 2017 at 12:13 AM, Pavel Krivanek
 wrote:
>
>
> 2017-11-10 11:52 GMT+01:00 Hilaire :
>>
>> A cleaner Pharo will help there.
>>
>> To be frank, I found later Pharo releases not inspiring. Bigger, bigger
>> and bigger with added code, protocol changes, and bugs at will. It is
>> becoming too complicated for a hobby use of it.
>>
>> I decided I will not finish porting DrGeo to P6 or P7, and it will likely
>> die with P3.
>
>
> To run DrGeo on Pharo 7 is not hard (see the screenshot) - of course it has
> some issues but they can be definitely solved. It would be pity to throw it
> away - at least you can benefit from 64-bit and faster VM.
>
> -- Pavel
>
>>
>> Pharo should have been clean up to the bones before adding. It was the
>> initial moto, no?
>>
>>
>> Le 10/11/2017 à 11:14, Marcus Denker a écrit :
>>>
>>> It would be nice if someone who uses it would take the lead
>>> so we can improve the default that is shipped with Pharo.
>>
>>
>> --
>> Dr. Geo
>> http://drgeo.eu
>>
>>
>>
>

Re: [Pharo-users] I18n in pharo

[Hilaire]

I guess you used the latest source code version, which was reto-porting 
to P3.


The prior one should get you a correct layout.


Le 12/11/2017 à 00:13, Pavel Krivanek a écrit :
To run DrGeo on Pharo 7 is not hard (see the screenshot) - of course 
it has some issues but they can be definitely solved. It would be pity 
to throw it away - at least you can benefit from 64-bit and faster VM.


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

Re: [Pharo-users] I18n in pharo

[Hilaire]

Likely your extracted list from the items I mentionned is contiguous :)

Looks like a big sandwich, though.

Will Athne be throwm away? With Polymorph and Morph?



Le 11/11/2017 à 21:56, Aliaksei Syrel a écrit :
Could you, please, explain in a bit more detail why do you think that 
Sparta, Bloc, Brick and GT are overlapping layers?


In attachment you can find a layered architecture diagram that 
explains how those technologies are stacked _from our_ point of view :)

Inline images 1


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

Re: [Pharo-users] I18n in pharo

[stephan]

On 11-11-17 21:18, H. Hirzel wrote:

On 11/11/17, stephan  wrote:

On 10-11-17 12:23, Cédrick Béler wrote:

Plus I have the impression Morphic mess is about to be solved.


There is still an awful lot of essential complexity in beautiful
graphics and typography that is not going away. Microsoft Word still
cannot layout a paragraph of text after 34 years of development


Can you point to an example of this?


https://en.wikipedia.org/wiki/Microtypography

Stephan

Re: [Pharo-users] I18n in pharo

[Hilaire]

P6 is definitely a better IDE compare to previous version, and for 
coming Calypso looks fantastic, but P6 is a worst vehicle for a desktop 
application. There is much more code included and you are on your on to 
shrink/clean it to deploy your desktop application to make it looks and 
behave user friendly. May be for a specialized audience it could be just 
fine to deploy as is.


About my perception on Pharo, from a distant POV, I see 
parallel/overlapping/contiguous layers like Morphic, Athens, Sparta, 
Bloc, Brick, Spec, GT, Polymorph all this looks confusing for me and I 
really don't know or understand where to put my eggs.


When I took a look at Pharo keyboard shortcut, it seems to be -- without 
been sure 100% -- there are two different implementations. One from GT 
and another one, probably a legacy one. How can it happen? Then you 
wonder about other part of the system. It makes fells like 
changes/implementations are not coherent, and you don't really fell the 
environment as coherent or trustful.


May be the twist is ontological, Pharo (and Squeak) taking too much 
responsibilities and not delegating enough to the host environment: GUI, 
Freetype, Canvas. The energy required is then out of reach or the needed 
coherence in teams works too complex. Don't know, just blind guesses, I 
will now shut up.



Le 10/11/2017 à 12:23, Cédrick Béler a écrit :

But I have the opposite impression (of course I don’t have to maintain a big 
project like yours - I wouldn’t say you’re the hobby user:)  ). But I really 
find P6 more consistent than what I used to try in the past (last squeaks up to 
3.9 and firsts pharo).


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

Re: [Pharo-users] I18n in pharo

[H. Hirzel]

On 11/11/17, stephan  wrote:
> On 10-11-17 12:23, Cédrick Béler wrote:
>> Plus I have the impression Morphic mess is about to be solved.
>
> There is still an awful lot of essential complexity in beautiful
> graphics and typography that is not going away. Microsoft Word still
> cannot layout a paragraph of text after 34 years of development

Can you point to an example of this?

--Hannes


> Stephan
>
>
>

Re: [Pharo-users] I18n in pharo

[stephan]

On 10-11-17 12:23, Cédrick Béler wrote:

Plus I have the impression Morphic mess is about to be solved.


There is still an awful lot of essential complexity in beautiful 
graphics and typography that is not going away. Microsoft Word still 
cannot layout a paragraph of text after 34 years of development


Stephan

Re: [Pharo-users] I18n in pharo

[Pavel Krivanek]

2017-11-11 12:16 GMT+01:00 Stephane Ducasse :

> Hi Pavel
>
> Does it make sense to have loaded by default?
>

I'm not sure. For Pharo itself it does not make sense to be translated but
the applications can use some standard Pharo services like inform/confirm
dialogs, file dialog etc. So if they want to use some external translation
mechanism, they will fight to two different frameworks.

-- Pavel



>
> Stef
>
> On Fri, Nov 10, 2017 at 8:05 AM, Pavel Krivanek
>  wrote:
> >
> >
> > 2017-11-09 23:50 GMT+01:00 Esteban Lorenzano :
> >>
> >> I think this is two different problems:
> >>
> >> 1. pharo itself supporting different languages/keyboards, etc.
> >> 2. pharo allowing the development of i18n applications
> >>
> >> I think we still need to work on point 1, but for point 2 we already
> have
> >> gettext package, which is a standard we can/should use. Maybe that
> needs to
> >> be better documented (as everything), but well… we have a solution
> there :)
> >
> >
> > Will we include it into the standard image?
> >
> > -- Pavel
> >
> >>
> >> Esteban
> >>
> >> > On 9 Nov 2017, at 18:58, Torsten Bergmann  wrote:
> >> >
> >> > The Pharo 7/8 roadmap does not (yet) include I18N:
> >> > https://github.com/pharo-project/pharo-workingRoadmaps/
> blob/master/Pharo7/ROADMAP.md
> >> >
> >> > and the Pharo core image still includes the
> "NaturalLanguageTranslator"
> >> > solution still from Squeak. See this class for more details and
> >> > all senders of #translated message. So far the whole Pharo UI is in
> >> > English and while books, the mooc or others were translated the Pharo
> >> > image so far is not.
> >> > I guess some more work would be needed also on the font frontier to
> >> > provide an internationalized image and the different languages.
> >> >
> >> >
> >> >
> >> > But for own applications (like web applications) there are some more
> >> > (external) solutions:
> >> >
> >> >
> >> > 1. I once wrote and announced an own I18N framwork:
> >> > http://lists.pharo.org/pipermail/pharo-dev_lists.
> pharo.org/2014-September/100247.html
> >> >   which is fully documented on
> >> > http://smalltalkhub.com/#!/~TorstenBergmann/I18N but is a completely
> >> > proprietary solution.
> >> >
> >> > 2. There is also some stuff from Jan van de Sandt:
> >> >
> >> > https://lists.gforge.inria.fr/pipermail/pharo-project/2012-
> October/070652.html
> >> >
> >> > 3. And there is GetText (from Seaside web framework) which I guess is
> >> > either here http://smalltalkhub.com/#!/~PharoExtras/Gettext
> >> >   or now maintained here:
> >> > https://github.com/SeasideSt/Seaside/wiki/Gettext
> >> >
> >> >   Unfortunately back at the time this one was not independently
> loadable
> >> > and had other trouble which I critisized on
> >> >   http://forum.world.st/ANN-Easy-I18N-for-Pharo-td4778194.html
> >> >
> >> >   Maybe situation for this project has improved.
> >> >
> >> >
> >> > But so far nobody pushed I18N really into Pharo ...
> >> >
> >> > 4. Therefore back in 2014 I started with a consolidation by starting a
> >> > clean room implementation of Gettext - based on code from 3.
> >> >   but now with tests and Pharo Spec based tools (see screenshot
> >> > attached). I did it in an own repo to be able to experiment and
> >> >   not break the Seaside solution right in the beginning.
> >> >
> >> >   My code is on STHub
> >> > http://smalltalkhub.com/#!/~TorstenBergmann/Gettext  and it is not
> yet fully
> >> > usable and so far still
> >> >   unfinished
> >> >
> >> >   But one can load the project still in Pharo 7 using
> >> >
> >> > Gofer it
> >> >   smalltalkhubUser: 'TorstenBergmann' project: 'Gettext';
> >> >   configuration;
> >> >   load.
> >> >
> >> > (Smalltalk at: #ConfigurationOfGettext) project bleedingEdge load
> >> >
> >> >   All 11 Tests are green so at least what is there should work. Check
> >> > the world menu and the code. Load the "Foo" package from the same
> repository
> >> >   to see something in the tools. The idea was to have support for MO
> and
> >> > PO files completely written in Smalltalk as well as tools that allow
> you
> >> >   to find and translate internationalized text.
> >> >
> >> >   But as always: this would require more work. I would still favour a
> >> > fully in Pharo written solution (following the gettext formats) but
> maybe
> >> > for
> >> >   performance reasons then also bind to libgettext using UFFI.
> >> >
> >> >
> >> > Hope this gives some insights on the current existing
> solutions/status.
> >> >
> >> > Thanks
> >> > Torsten
> >> >
> >> >
> >> >> Gesendet: Donnerstag, 09. November 2017 um 21:29 Uhr
> >> >> Von: "Викентий Потапов" 
> >> >> An: pharo-users@lists.pharo.org
> >> >> Betreff: [Pharo-users] I18n in pharo
> >> >>
> >> >>
> >> >> Will Pharo 7 be ready for i18n of applications?
> >> >> I mean some simple and useful way like in Cincom Visual 

Re: [Pharo-users] I18n in pharo

[Stephane Ducasse]

>
> It’s quite a moving target with so many fundamental changes (GIT being one, 
> Bootstrap another huge one).


I would not call it moving target. The API changes slowly and we
deprecate most of them.


> But I have the opposite impression (of course I don’t have to maintain a big 
> project like yours - I wouldn’t say you’re the hobby user :) ). But I really 
> find P6 more consistent than what I used to try in the past (last squeaks up 
> to 3.9 and firsts pharo).

Me too.


> And the bootstrapping of P7 will (I think) finally solve big image issues 
> (allowing to build cleaner distributions). I believe it will be a huge step 
> forward. At least for me and especially to convince others to try out Pharo.
> I just dream of having a network of small images running and communicating, 
> eventually accessed and programmed by a larger developper image (with 
> TelePharo).


Yes we want the same.


> I haven’t tried the bootstrap yet but sure in the future.

It is working already and you can use the Bootstrap. Pavel has been
working on providing package and configurations that we can reload.

> Plus I have the impression Morphic mess is about to be solved.

Well I hope :)


> What’s more problematic to me (as I guess for newcomers) is to find the 
> ‘good’ packages'. For instance, I’m still puzzled when I have to choose 
> between OSProcess and OSSubprocess (and sometimes depending on loaded 
> projects, we need both…).


People should document their packages and publish them in the meta catalog.
We cannot do more.
We should publish a package market but we are behind our plans.


>
>>
>> I decided I will not finish porting DrGeo to P6 or P7, and it will likely 
>> die with P3.
>>
>> Pharo should have been clean up to the bones before adding. It was the 
>> initial moto, no?
>
> I have the (naive) impression that bootstrap will help a lot here, so be 
> patient ;). Maybe porting to P7/P8 will be more appropriate.
> What I would like, is a kind of notation for package to know its state and 
> usage possibilities.
> We see for instance that several I18N exists already (but not 100% integrated 
> hence this post)...
>
> My 2 cents,
>
> Cédrick
>
>
> OT question: Would it be possible in the future to generate a bootstrap image 
> of a given program from a bigger developer image containing running program 
> (like if running tests where activating all code dependancies ? … like 
> tracing usage… I guess this is not trivial at all ! I guess this is 
> particularly difficult to trace all use cases and as dynamically bound, it 
> sure must be hard).

Yes guille did it with tornado.
Now it was experiemental.
You will be in better shape to take the miniimage and load what you need.



>
>>
>>
>> Le 10/11/2017 à 11:14, Marcus Denker a écrit :
>>> It would be nice if someone who uses it would take the lead
>>> so we can improve the default that is shipped with Pharo.
>>
>> --
>> Dr. Geo
>> http://drgeo.eu
>>
>>
>>
>
>

Re: [Pharo-users] I18n in pharo

[Stephane Ducasse]

Hilaire

I think that Pharo is getting a lot more modular. Do you imagine that
we can reload Morphic? That we have a minimal image
that does not rely on the compiler? and that we can reload the
compiler, SUnit and more.
We will start another pass because we will run an experience to get microPharo.
Did you see the amazonLambda experience?

Many people are telling to us that Pharo and that the system is
improving and it is really improving.
Now we do not make progress without breaking eggs. And we are cleaning
but probably things that
you do not care: such as startup list, streams, layouts
We will throw away a lot of code with Bloc too.

> A cleaner Pharo will help there.
>
> To be frank, I found later Pharo releases not inspiring. Bigger, bigger and
> bigger with added code, protocol changes, and bugs at will.

Hilaire
- when did you report bugs that we did not consider? and that we did
not fix if it was something that we could do fast?


> It is becoming
> too complicated for a hobby use of it.
>
> I decided I will not finish porting DrGeo to P6 or P7, and it will likely
> die with P3.

I'm sad that you decided that because we like DrGeo. Now we cannot do
much if you do not want to do it.
May be you should come to visit us from time to time.


> Pharo should have been clean up to the bones before adding. It was the
> initial moto, no?

And this is what we are doing.
But seriously do you think that it is easy?
Did you look at the ESUG videos of Prague. I can tell you that
christophe, pavel and guille
worked several months and this is not just for hacking around.

So you probably do not know what we did and what we are doing.

Stef
>
>
> Le 10/11/2017 à 11:14, Marcus Denker a écrit :
>>
>> It would be nice if someone who uses it would take the lead
>> so we can improve the default that is shipped with Pharo.
>
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>

Re: [Pharo-users] I18n in pharo

[Stephane Ducasse]

Marcus
translate is incomplete and I would not focus on translating Pharo. I
would prefer to improve the self documentation in english.
Let us concentrate where we can get better.

Stef

On Fri, Nov 10, 2017 at 11:20 AM, Marcus Denker  wrote:
>
>
> On 10 Nov 2017, at 11:18, Esteban Lorenzano  wrote:
>
>
>
> On 10 Nov 2017, at 04:05, Pavel Krivanek  wrote:
>
>
>
> 2017-11-09 23:50 GMT+01:00 Esteban Lorenzano :
>>
>> I think this is two different problems:
>>
>> 1. pharo itself supporting different languages/keyboards, etc.
>> 2. pharo allowing the development of i18n applications
>>
>> I think we still need to work on point 1, but for point 2 we already have
>> gettext package, which is a standard we can/should use. Maybe that needs to
>> be better documented (as everything), but well… we have a solution there :)
>
>
> Will we include it into the standard image?
>
>
> No. The whole idea with PharoExtras was “there are packages we care about
> and we want to make them available, but there is no reason to keep them *in*
> image”.
> I do not see why we should change that policy.
>
> Now, we definitively need better documentation about it.
>
>
> But having I18 support is not bad… e.g. there are many programs out there
> that provide translated menus.
> It would not be completely a bad idea to do that for Pharo, too.
>
> Marcus
>

Re: [Pharo-users] I18n in pharo

[Stephane Ducasse]

tx hiliare for the feedback.


On Fri, Nov 10, 2017 at 11:10 AM, Hilaire  wrote:
> You can go with http://smalltalkhub.com/#!/~PharoExtras/Gettext
>
> For non latin language you will have to provide extra font at load time.
>
> It works fine on DrGeo based on P3, wtih Latin, Cyrilic, Korean, Chinese
> ideogram, Japanese[1] messages.
>
> I have no idea regarding its compatibility with P7 however.
>
> Will not work with right to left languages, though.
>
> For asian input methods, a no go too.
>
> Hilaire
>
> [1] https://twitter.com/GNUDrGeo/status/832878470216691712
>
>
> Le 09/11/2017 à 21:29, Викентий Потапов a écrit :
>>
>> It is very important for huge commercial applications, especially with
>> lots of UI forms, dialogs and user-messages.
>
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>

Re: [Pharo-users] I18n in pharo

[Stephane Ducasse]

Hi Pavel

Does it make sense to have loaded by default?

Stef

On Fri, Nov 10, 2017 at 8:05 AM, Pavel Krivanek
 wrote:
>
>
> 2017-11-09 23:50 GMT+01:00 Esteban Lorenzano :
>>
>> I think this is two different problems:
>>
>> 1. pharo itself supporting different languages/keyboards, etc.
>> 2. pharo allowing the development of i18n applications
>>
>> I think we still need to work on point 1, but for point 2 we already have
>> gettext package, which is a standard we can/should use. Maybe that needs to
>> be better documented (as everything), but well… we have a solution there :)
>
>
> Will we include it into the standard image?
>
> -- Pavel
>
>>
>> Esteban
>>
>> > On 9 Nov 2017, at 18:58, Torsten Bergmann  wrote:
>> >
>> > The Pharo 7/8 roadmap does not (yet) include I18N:
>> > https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/ROADMAP.md
>> >
>> > and the Pharo core image still includes the "NaturalLanguageTranslator"
>> > solution still from Squeak. See this class for more details and
>> > all senders of #translated message. So far the whole Pharo UI is in
>> > English and while books, the mooc or others were translated the Pharo
>> > image so far is not.
>> > I guess some more work would be needed also on the font frontier to
>> > provide an internationalized image and the different languages.
>> >
>> >
>> >
>> > But for own applications (like web applications) there are some more
>> > (external) solutions:
>> >
>> >
>> > 1. I once wrote and announced an own I18N framwork:
>> > http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-September/100247.html
>> >   which is fully documented on
>> > http://smalltalkhub.com/#!/~TorstenBergmann/I18N but is a completely
>> > proprietary solution.
>> >
>> > 2. There is also some stuff from Jan van de Sandt:
>> >
>> > https://lists.gforge.inria.fr/pipermail/pharo-project/2012-October/070652.html
>> >
>> > 3. And there is GetText (from Seaside web framework) which I guess is
>> > either here http://smalltalkhub.com/#!/~PharoExtras/Gettext
>> >   or now maintained here:
>> > https://github.com/SeasideSt/Seaside/wiki/Gettext
>> >
>> >   Unfortunately back at the time this one was not independently loadable
>> > and had other trouble which I critisized on
>> >   http://forum.world.st/ANN-Easy-I18N-for-Pharo-td4778194.html
>> >
>> >   Maybe situation for this project has improved.
>> >
>> >
>> > But so far nobody pushed I18N really into Pharo ...
>> >
>> > 4. Therefore back in 2014 I started with a consolidation by starting a
>> > clean room implementation of Gettext - based on code from 3.
>> >   but now with tests and Pharo Spec based tools (see screenshot
>> > attached). I did it in an own repo to be able to experiment and
>> >   not break the Seaside solution right in the beginning.
>> >
>> >   My code is on STHub
>> > http://smalltalkhub.com/#!/~TorstenBergmann/Gettext  and it is not yet 
>> > fully
>> > usable and so far still
>> >   unfinished
>> >
>> >   But one can load the project still in Pharo 7 using
>> >
>> > Gofer it
>> >   smalltalkhubUser: 'TorstenBergmann' project: 'Gettext';
>> >   configuration;
>> >   load.
>> >
>> > (Smalltalk at: #ConfigurationOfGettext) project bleedingEdge load
>> >
>> >   All 11 Tests are green so at least what is there should work. Check
>> > the world menu and the code. Load the "Foo" package from the same 
>> > repository
>> >   to see something in the tools. The idea was to have support for MO and
>> > PO files completely written in Smalltalk as well as tools that allow you
>> >   to find and translate internationalized text.
>> >
>> >   But as always: this would require more work. I would still favour a
>> > fully in Pharo written solution (following the gettext formats) but maybe
>> > for
>> >   performance reasons then also bind to libgettext using UFFI.
>> >
>> >
>> > Hope this gives some insights on the current existing solutions/status.
>> >
>> > Thanks
>> > Torsten
>> >
>> >
>> >> Gesendet: Donnerstag, 09. November 2017 um 21:29 Uhr
>> >> Von: "Викентий Потапов" 
>> >> An: pharo-users@lists.pharo.org
>> >> Betreff: [Pharo-users] I18n in pharo
>> >>
>> >>
>> >> Will Pharo 7 be ready for i18n of applications?
>> >> I mean some simple and useful way like in Cincom Visual Works, where
>> >> translation dictionaries are separated from code and could be dinamycally
>> >> changed without changing my application.
>> >>
>> >> It is very important for huge commercial applications, especially with
>> >> lots of UI forms, dialogs and user-messages.
>> >>
>> >> I transfer my code from Cincom VW (VW is not available now for Russia
>> >> due to politic situation) to Pharo and is very interested in simple
>> >> internationalization mechanism. I don't want to reinvent the wheel but
>> >> sometimes it seems to me that pharo developers are forced to do it.
>> >>
>> >> By the way, the error i had 

Re: [Pharo-users] I18n in pharo

[Stephane Ducasse]

Hi torsten

Thanks for your summary. I was lost with all the efforts around.
Two points:

- I do not think that Pharo IDE should be multilingual
- I would love to have one or two strong solutions for Application
internationalisation.

Now Questions:

- what do you mean by propretiary solution. The license is MIT.
- I think that it would be good to have your solution and getText
ready to be loaded and for me this would be nice.

Now I have a question how people developing seaside components manage
to have internationalised
version?

Stef



On Thu, Nov 9, 2017 at 10:58 PM, Torsten Bergmann  wrote:
> The Pharo 7/8 roadmap does not (yet) include I18N: 
> https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/ROADMAP.md
>
> and the Pharo core image still includes the "NaturalLanguageTranslator" 
> solution still from Squeak. See this class for more details and
> all senders of #translated message. So far the whole Pharo UI is in English 
> and while books, the mooc or others were translated the Pharo
> image so far is not.
> I guess some more work would be needed also on the font frontier to provide 
> an internationalized image and the different languages.
>
>
>
> But for own applications (like web applications) there are some more 
> (external) solutions:
>
>
> 1. I once wrote and announced an own I18N framwork:  
> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-September/100247.html
>which is fully documented on 
> http://smalltalkhub.com/#!/~TorstenBergmann/I18N but is a completely 
> proprietary solution.
>
> 2. There is also some stuff from Jan van de Sandt:
>
> https://lists.gforge.inria.fr/pipermail/pharo-project/2012-October/070652.html
>
> 3. And there is GetText (from Seaside web framework) which I guess is either 
> here http://smalltalkhub.com/#!/~PharoExtras/Gettext
>or now maintained here: https://github.com/SeasideSt/Seaside/wiki/Gettext
>
>Unfortunately back at the time this one was not independently loadable and 
> had other trouble which I critisized on
>http://forum.world.st/ANN-Easy-I18N-for-Pharo-td4778194.html
>
>Maybe situation for this project has improved.
>
>
> But so far nobody pushed I18N really into Pharo ...
>
> 4. Therefore back in 2014 I started with a consolidation by starting a clean 
> room implementation of Gettext - based on code from 3.
>but now with tests and Pharo Spec based tools (see screenshot attached). I 
> did it in an own repo to be able to experiment and
>not break the Seaside solution right in the beginning.
>
>My code is on STHub  http://smalltalkhub.com/#!/~TorstenBergmann/Gettext  
> and it is not yet fully usable and so far still
>unfinished
>
>But one can load the project still in Pharo 7 using
>
>  Gofer it
>smalltalkhubUser: 'TorstenBergmann' project: 'Gettext';
>configuration;
>load.
>
>  (Smalltalk at: #ConfigurationOfGettext) project bleedingEdge load
>
>All 11 Tests are green so at least what is there should work. Check the 
> world menu and the code. Load the "Foo" package from the same repository
>to see something in the tools. The idea was to have support for MO and PO 
> files completely written in Smalltalk as well as tools that allow you
>to find and translate internationalized text.
>
>But as always: this would require more work. I would still favour a fully 
> in Pharo written solution (following the gettext formats) but maybe for
>performance reasons then also bind to libgettext using UFFI.
>
>
> Hope this gives some insights on the current existing solutions/status.
>
> Thanks
> Torsten
>
>
>> Gesendet: Donnerstag, 09. November 2017 um 21:29 Uhr
>> Von: "Викентий Потапов" 
>> An: pharo-users@lists.pharo.org
>> Betreff: [Pharo-users] I18n in pharo
>>
>>
>> Will Pharo 7 be ready for i18n of applications?
>> I mean some simple and useful way like in Cincom Visual Works, where 
>> translation dictionaries are separated from code and could be dinamycally 
>> changed without changing my application.
>>
>> It is very important for huge commercial applications, especially with lots 
>> of UI forms, dialogs and user-messages.
>>
>> I transfer my code from Cincom VW (VW is not available now for Russia due to 
>> politic situation) to Pharo and is very interested in simple 
>> internationalization mechanism. I don't want to reinvent the wheel but 
>> sometimes it seems to me that pharo developers are forced to do it.
>>
>> By the way, the error i had last week with clean Pharo 6\Pharo 6.1 
>> installation ("UTF8InvalidText: Invalid utf8 input detected" on image load - 
>> error caused by cyrillic path to application folder) didn't solved and i had 
>> no feedback from community.
>>
>> best regards,
>> Vikenti Potapov.
>>
>>
>>

Re: [Pharo-users] I18n in pharo

[Andrew Glynn]

There’s an online translation service for XLIff files (well, there’s quite a 
few but most I’ve found use human translators, and as a result cost a fair 
bit).  It’s not free either, but for 2-3 languages it’s relatively reasonable 
at $19/mo., and a couple of months’ subscription would allow for a fair number 
of automated translations which could be quickly tweaked.

https://lingohub.com/pricing/

Mojito allows you to integrate the Xliff translation as part of a Travis CI 
build.  It’s written in Java but supports localization for a number of 
languages, which implies it wouldn’t take much modification to support Pharo.

https://github.com/box/mojito

There’s also a number of Xliff editors on GitHub, including a plugin for Oxygen 
XML, which I happen to use when I do edit XML rather than using IADS with SGML 
and exporting XML.

Not sure if this is the kind of thing you’re looking for, but it might be a 
quick way to get key applications’ text  translated and be used by a relatively 
simple Pharo / Seaside tool.  It’s even possible that a decent modification of 
Mojito might allow semi-automated translations using LingoHub.

Andrew Glynn

From: Andrew Glynn
Sent: Friday, November 10, 2017 6:09 PM
To: Any question about pharo is welcome
Subject: RE: [Pharo-users] I18n in pharo

I’d think about porting the I18n Gem from Ruby but replacing Gettext with xliff 
to be a better, more generalized solution.  Cascade in the Ruby Gem is a useful 
feature missing from other implementations I’ve used.

https://github.com/svenfuchs/i18n/tree/master/test

http://docs.oasis-open.org/xliff/xliff-core/xliff-core.html

It would also likely be easier and more reliable, since the XML support in 
Pharo is already quite good.

Andrew Glynn





Sent from Mail for Windows 10

From: Torsten Bergmann
Sent: Thursday, November 9, 2017 4:59 PM
To: pharo-users@lists.pharo.org
Subject: Re: [Pharo-users] I18n in pharo

The Pharo 7/8 roadmap does not (yet) include I18N: 
https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/ROADMAP.md
   

and the Pharo core image still includes the "NaturalLanguageTranslator" 
solution still from Squeak. See this class for more details and 
all senders of #translated message. So far the whole Pharo UI is in English and 
while books, the mooc or others were translated the Pharo
image so far is not.
I guess some more work would be needed also on the font frontier to provide an 
internationalized image and the different languages.



But for own applications (like web applications) there are some more (external) 
solutions:


1. I once wrote and announced an own I18N framwork:  
http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-September/100247.html
   which is fully documented on 
http://smalltalkhub.com/#!/~TorstenBergmann/I18N but is a completely 
proprietary solution.

2. There is also some stuff from Jan van de Sandt:
   
https://lists.gforge.inria.fr/pipermail/pharo-project/2012-October/070652.html

3. And there is GetText (from Seaside web framework) which I guess is either 
here http://smalltalkhub.com/#!/~PharoExtras/Gettext
   or now maintained here: https://github.com/SeasideSt/Seaside/wiki/Gettext

   Unfortunately back at the time this one was not independently loadable and 
had other trouble which I critisized on 
   http://forum.world.st/ANN-Easy-I18N-for-Pharo-td4778194.html

   Maybe situation for this project has improved.


But so far nobody pushed I18N really into Pharo ... 

4. Therefore back in 2014 I started with a consolidation by starting a clean 
room implementation of Gettext - based on code from 3.
   but now with tests and Pharo Spec based tools (see screenshot attached). I 
did it in an own repo to be able to experiment and
   not break the Seaside solution right in the beginning.

   My code is on STHub  http://smalltalkhub.com/#!/~TorstenBergmann/Gettext  
and it is not yet fully usable and so far still 
   unfinished

   But one can load the project still in Pharo 7 using

 Gofer it 
   smalltalkhubUser: 'TorstenBergmann' project: 'Gettext';
   configuration;
   load.

 (Smalltalk at: #ConfigurationOfGettext) project bleedingEdge load

   All 11 Tests are green so at least what is there should work. Check the 
world menu and the code. Load the "Foo" package from the same repository 
   to see something in the tools. The idea was to have support for MO and PO 
files completely written in Smalltalk as well as tools that allow you 
   to find and translate internationalized text. 

   But as always: this would require more work. I would still favour a fully in 
Pharo written solution (following the gettext formats) but maybe for
   performance reasons then also bind to libgettext using UFFI.


Hope this gives some insights on the current existing solutions/status.

Thanks
Torsten


> Gesendet: Donnerstag, 09. November 2017 um 21:29 Uhr
> Von: "Викентий Потапов" <vikenti.pota...@gmail

Re: [Pharo-users] I18n in pharo

[Andrew Glynn]

I’d think about porting the I18n Gem from Ruby but replacing Gettext with xliff 
to be a better, more generalized solution.  Cascade in the Ruby Gem is a useful 
feature missing from other implementations I’ve used.

https://github.com/svenfuchs/i18n/tree/master/test

http://docs.oasis-open.org/xliff/xliff-core/xliff-core.html

It would also likely be easier and more reliable, since the XML support in 
Pharo is already quite good.

Andrew Glynn





Sent from Mail for Windows 10

From: Torsten Bergmann
Sent: Thursday, November 9, 2017 4:59 PM
To: pharo-users@lists.pharo.org
Subject: Re: [Pharo-users] I18n in pharo

The Pharo 7/8 roadmap does not (yet) include I18N: 
https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/ROADMAP.md
   

and the Pharo core image still includes the "NaturalLanguageTranslator" 
solution still from Squeak. See this class for more details and 
all senders of #translated message. So far the whole Pharo UI is in English and 
while books, the mooc or others were translated the Pharo
image so far is not.
I guess some more work would be needed also on the font frontier to provide an 
internationalized image and the different languages.



But for own applications (like web applications) there are some more (external) 
solutions:


1. I once wrote and announced an own I18N framwork:  
http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-September/100247.html
   which is fully documented on 
http://smalltalkhub.com/#!/~TorstenBergmann/I18N but is a completely 
proprietary solution.

2. There is also some stuff from Jan van de Sandt:
   
https://lists.gforge.inria.fr/pipermail/pharo-project/2012-October/070652.html

3. And there is GetText (from Seaside web framework) which I guess is either 
here http://smalltalkhub.com/#!/~PharoExtras/Gettext
   or now maintained here: https://github.com/SeasideSt/Seaside/wiki/Gettext

   Unfortunately back at the time this one was not independently loadable and 
had other trouble which I critisized on 
   http://forum.world.st/ANN-Easy-I18N-for-Pharo-td4778194.html

   Maybe situation for this project has improved.


But so far nobody pushed I18N really into Pharo ... 

4. Therefore back in 2014 I started with a consolidation by starting a clean 
room implementation of Gettext - based on code from 3.
   but now with tests and Pharo Spec based tools (see screenshot attached). I 
did it in an own repo to be able to experiment and
   not break the Seaside solution right in the beginning.

   My code is on STHub  http://smalltalkhub.com/#!/~TorstenBergmann/Gettext  
and it is not yet fully usable and so far still 
   unfinished

   But one can load the project still in Pharo 7 using

 Gofer it 
   smalltalkhubUser: 'TorstenBergmann' project: 'Gettext';
   configuration;
   load.

 (Smalltalk at: #ConfigurationOfGettext) project bleedingEdge load

   All 11 Tests are green so at least what is there should work. Check the 
world menu and the code. Load the "Foo" package from the same repository 
   to see something in the tools. The idea was to have support for MO and PO 
files completely written in Smalltalk as well as tools that allow you 
   to find and translate internationalized text. 

   But as always: this would require more work. I would still favour a fully in 
Pharo written solution (following the gettext formats) but maybe for
   performance reasons then also bind to libgettext using UFFI.


Hope this gives some insights on the current existing solutions/status.

Thanks
Torsten


> Gesendet: Donnerstag, 09. November 2017 um 21:29 Uhr
> Von: "Викентий Потапов" <vikenti.pota...@gmail.com>
> An: pharo-users@lists.pharo.org
> Betreff: [Pharo-users] I18n in pharo
>
> 
> Will Pharo 7 be ready for i18n of applications?
> I mean some simple and useful way like in Cincom Visual Works, where 
> translation dictionaries are separated from code and could be dinamycally 
> changed without changing my application.
> 
> It is very important for huge commercial applications, especially with lots 
> of UI forms, dialogs and user-messages.
> 
> I transfer my code from Cincom VW (VW is not available now for Russia due to 
> politic situation) to Pharo and is very interested in simple 
> internationalization mechanism. I don't want to reinvent the wheel but 
> sometimes it seems to me that pharo developers are forced to do it.
> 
> By the way, the error i had last week with clean Pharo 6\Pharo 6.1 
> installation ("UTF8InvalidText: Invalid utf8 input detected" on image load - 
> error caused by cyrillic path to application folder) didn't solved and i had 
> no feedback from community. 
> 
> best regards,
> Vikenti Potapov. 
> 
> 
>

Re: [Pharo-users] I18n in pharo

[Cédrick Béler]

> 
> A cleaner Pharo will help there.
> 
> To be frank, I found later Pharo releases not inspiring. Bigger, bigger and 
> bigger with added code, protocol changes, and bugs at will. It is becoming 
> too complicated for a hobby use of it.

It’s quite a moving target with so many fundamental changes (GIT being one, 
Bootstrap another huge one).

But I have the opposite impression (of course I don’t have to maintain a big 
project like yours - I wouldn’t say you’re the hobby user :) ). But I really 
find P6 more consistent than what I used to try in the past (last squeaks up to 
3.9 and firsts pharo).

And the bootstrapping of P7 will (I think) finally solve big image issues 
(allowing to build cleaner distributions). I believe it will be a huge step 
forward. At least for me and especially to convince others to try out Pharo.
I just dream of having a network of small images running and communicating, 
eventually accessed and programmed by a larger developper image (with 
TelePharo).

I haven’t tried the bootstrap yet but sure in the future.

Plus I have the impression Morphic mess is about to be solved. 

What’s more problematic to me (as I guess for newcomers) is to find the ‘good’ 
packages'. For instance, I’m still puzzled when I have to choose between 
OSProcess and OSSubprocess (and sometimes depending on loaded projects, we need 
both…).

> 
> I decided I will not finish porting DrGeo to P6 or P7, and it will likely die 
> with P3.
> 
> Pharo should have been clean up to the bones before adding. It was the 
> initial moto, no?

I have the (naive) impression that bootstrap will help a lot here, so be 
patient ;). Maybe porting to P7/P8 will be more appropriate.
What I would like, is a kind of notation for package to know its state and 
usage possibilities.
We see for instance that several I18N exists already (but not 100% integrated 
hence this post)...

My 2 cents,

Cédrick


OT question: Would it be possible in the future to generate a bootstrap image 
of a given program from a bigger developer image containing running program 
(like if running tests where activating all code dependancies ? … like tracing 
usage… I guess this is not trivial at all ! I guess this is particularly 
difficult to trace all use cases and as dynamically bound, it sure must be 
hard).

> 
> 
> Le 10/11/2017 à 11:14, Marcus Denker a écrit :
>> It would be nice if someone who uses it would take the lead
>> so we can improve the default that is shipped with Pharo.
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

Re: [Pharo-users] I18n in pharo

[H. Hirzel]

Maybe in a different thread...

On 11/10/17, H. Hirzel  wrote:
> On 11/10/17, Hilaire  wrote:
>> A cleaner Pharo will help there.
>>
>> To be frank, I found later Pharo releases not inspiring. Bigger, bigger
>> and bigger with added code, protocol changes, and bugs at will. It is
>> becoming too complicated for a hobby use of it.
>>
>> I decided I will not finish porting DrGeo to P6 or P7, and it will
>> likely die with P3.
>
> What are the main show stoppers which make it difficult to port your
> application to P6?
>
>>
>> Pharo should have been clean up to the bones before adding. It was the
>> initial moto, no?
>>
>>
>> Le 10/11/2017 à 11:14, Marcus Denker a écrit :
>>> It would be nice if someone who uses it would take the lead
>>> so we can improve the default that is shipped with Pharo.
>>
>> --
>> Dr. Geo
>> http://drgeo.eu
>>
>>
>>
>>
>

Re: [Pharo-users] I18n in pharo

[H. Hirzel]

On 11/10/17, Hilaire  wrote:
> A cleaner Pharo will help there.
>
> To be frank, I found later Pharo releases not inspiring. Bigger, bigger
> and bigger with added code, protocol changes, and bugs at will. It is
> becoming too complicated for a hobby use of it.
>
> I decided I will not finish porting DrGeo to P6 or P7, and it will
> likely die with P3.

What are the main show stoppers which make it difficult to port your
application to P6?

>
> Pharo should have been clean up to the bones before adding. It was the
> initial moto, no?
>
>
> Le 10/11/2017 à 11:14, Marcus Denker a écrit :
>> It would be nice if someone who uses it would take the lead
>> so we can improve the default that is shipped with Pharo.
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>

Re: [Pharo-users] I18n in pharo

[Hilaire]

A cleaner Pharo will help there.

To be frank, I found later Pharo releases not inspiring. Bigger, bigger 
and bigger with added code, protocol changes, and bugs at will. It is 
becoming too complicated for a hobby use of it.


I decided I will not finish porting DrGeo to P6 or P7, and it will 
likely die with P3.


Pharo should have been clean up to the bones before adding. It was the 
initial moto, no?



Le 10/11/2017 à 11:14, Marcus Denker a écrit :

It would be nice if someone who uses it would take the lead
so we can improve the default that is shipped with Pharo.


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

Re: [Pharo-users] I18n in pharo

[Marcus Denker]

> On 10 Nov 2017, at 11:18, Esteban Lorenzano  wrote:
> 
> 
> 
>> On 10 Nov 2017, at 04:05, Pavel Krivanek > > wrote:
>> 
>> 
>> 
>> 2017-11-09 23:50 GMT+01:00 Esteban Lorenzano > >:
>> I think this is two different problems:
>> 
>> 1. pharo itself supporting different languages/keyboards, etc.
>> 2. pharo allowing the development of i18n applications
>> 
>> I think we still need to work on point 1, but for point 2 we already have 
>> gettext package, which is a standard we can/should use. Maybe that needs to 
>> be better documented (as everything), but well… we have a solution there :)
>> 
>> Will we include it into the standard image?
> 
> No. The whole idea with PharoExtras was “there are packages we care about and 
> we want to make them available, but there is no reason to keep them *in* 
> image”.
> I do not see why we should change that policy. 
> 
> Now, we definitively need better documentation about it.
> 

But having I18 support is not bad… e.g. there are many programs out there that 
provide translated menus.
It would not be completely a bad idea to do that for Pharo, too.

Marcus

Re: [Pharo-users] I18n in pharo

[Esteban Lorenzano]

> On 10 Nov 2017, at 04:05, Pavel Krivanek  wrote:
> 
> 
> 
> 2017-11-09 23:50 GMT+01:00 Esteban Lorenzano  >:
> I think this is two different problems:
> 
> 1. pharo itself supporting different languages/keyboards, etc.
> 2. pharo allowing the development of i18n applications
> 
> I think we still need to work on point 1, but for point 2 we already have 
> gettext package, which is a standard we can/should use. Maybe that needs to 
> be better documented (as everything), but well… we have a solution there :)
> 
> Will we include it into the standard image?

No. The whole idea with PharoExtras was “there are packages we care about and 
we want to make them available, but there is no reason to keep them *in* image”.
I do not see why we should change that policy. 

Now, we definitively need better documentation about it.

Esteban

> 
> -- Pavel
> 
> 
> Esteban
> 
> > On 9 Nov 2017, at 18:58, Torsten Bergmann  > > wrote:
> >
> > The Pharo 7/8 roadmap does not (yet) include I18N: 
> > https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/ROADMAP.md
> >  
> > 
> >
> > and the Pharo core image still includes the "NaturalLanguageTranslator" 
> > solution still from Squeak. See this class for more details and
> > all senders of #translated message. So far the whole Pharo UI is in English 
> > and while books, the mooc or others were translated the Pharo
> > image so far is not.
> > I guess some more work would be needed also on the font frontier to provide 
> > an internationalized image and the different languages.
> >
> >
> >
> > But for own applications (like web applications) there are some more 
> > (external) solutions:
> >
> >
> > 1. I once wrote and announced an own I18N framwork:  
> > http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-September/100247.html
> >  
> > 
> >   which is fully documented on 
> > http://smalltalkhub.com/#!/~TorstenBergmann/I18N 
> >  but is a completely 
> > proprietary solution.
> >
> > 2. There is also some stuff from Jan van de Sandt:
> >   
> > https://lists.gforge.inria.fr/pipermail/pharo-project/2012-October/070652.html
> >  
> > 
> >
> > 3. And there is GetText (from Seaside web framework) which I guess is 
> > either here http://smalltalkhub.com/#!/~PharoExtras/Gettext 
> > 
> >   or now maintained here: https://github.com/SeasideSt/Seaside/wiki/Gettext 
> > 
> >
> >   Unfortunately back at the time this one was not independently loadable 
> > and had other trouble which I critisized on
> >   http://forum.world.st/ANN-Easy-I18N-for-Pharo-td4778194.html 
> > 
> >
> >   Maybe situation for this project has improved.
> >
> >
> > But so far nobody pushed I18N really into Pharo ...
> >
> > 4. Therefore back in 2014 I started with a consolidation by starting a 
> > clean room implementation of Gettext - based on code from 3.
> >   but now with tests and Pharo Spec based tools (see screenshot attached). 
> > I did it in an own repo to be able to experiment and
> >   not break the Seaside solution right in the beginning.
> >
> >   My code is on STHub  http://smalltalkhub.com/#!/~TorstenBergmann/Gettext 
> >   and it is not yet 
> > fully usable and so far still
> >   unfinished
> >
> >   But one can load the project still in Pharo 7 using
> >
> > Gofer it
> >   smalltalkhubUser: 'TorstenBergmann' project: 'Gettext';
> >   configuration;
> >   load.
> >
> > (Smalltalk at: #ConfigurationOfGettext) project bleedingEdge load
> >
> >   All 11 Tests are green so at least what is there should work. Check the 
> > world menu and the code. Load the "Foo" package from the same repository
> >   to see something in the tools. The idea was to have support for MO and PO 
> > files completely written in Smalltalk as well as tools that allow you
> >   to find and translate internationalized text.
> >
> >   But as always: this would require more work. I would still favour a fully 
> > in Pharo written solution (following the gettext formats) but maybe for
> >   performance reasons then also bind to libgettext using UFFI.
> >
> >
> > Hope this gives some insights on the current existing solutions/status.
> >
> > Thanks
> > Torsten
> >
> >
> >> Gesendet: Donnerstag, 09. November 2017 um 21:29 Uhr
> >> Von: "Викентий Потапов"  >> >
> >> An: 

Re: [Pharo-users] I18n in pharo

[stephan]

On 09-11-17 21:29, Викентий Потапов wrote:


Will Pharo 7 be ready for i18n of applications?


With QCMagritte we have provided string translations since Pharo 4 or 
so. In a Magritte-based application you can just add a visitor that 
walks the descriptions and extracts what needs translating. We 
demonstrated a web based interface allowing live translations (and im- 
and export to csv) for that a few years ago.


https://www.youtube.com/watch?v=cTut44Xs3_U

It needs updating for Pharo 6/7 again, and is missing things like 
translating keybindings. I am not so impressed by the gettext 
functionality but it is something that translators are used to.


Stephan

Re: [Pharo-users] I18n in pharo

[Pavel Krivanek]

2017-11-09 23:50 GMT+01:00 Esteban Lorenzano :

> I think this is two different problems:
>
> 1. pharo itself supporting different languages/keyboards, etc.
> 2. pharo allowing the development of i18n applications
>
> I think we still need to work on point 1, but for point 2 we already have
> gettext package, which is a standard we can/should use. Maybe that needs to
> be better documented (as everything), but well… we have a solution there :)
>

Will we include it into the standard image?

-- Pavel


> Esteban
>
> > On 9 Nov 2017, at 18:58, Torsten Bergmann  wrote:
> >
> > The Pharo 7/8 roadmap does not (yet) include I18N:
> https://github.com/pharo-project/pharo-workingRoadmaps/
> blob/master/Pharo7/ROADMAP.md
> >
> > and the Pharo core image still includes the "NaturalLanguageTranslator"
> solution still from Squeak. See this class for more details and
> > all senders of #translated message. So far the whole Pharo UI is in
> English and while books, the mooc or others were translated the Pharo
> > image so far is not.
> > I guess some more work would be needed also on the font frontier to
> provide an internationalized image and the different languages.
> >
> >
> >
> > But for own applications (like web applications) there are some more
> (external) solutions:
> >
> >
> > 1. I once wrote and announced an own I18N framwork:
> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-September/
> 100247.html
> >   which is fully documented on http://smalltalkhub.com/#!/~
> TorstenBergmann/I18N but is a completely proprietary solution.
> >
> > 2. There is also some stuff from Jan van de Sandt:
> >   https://lists.gforge.inria.fr/pipermail/pharo-project/2012-
> October/070652.html
> >
> > 3. And there is GetText (from Seaside web framework) which I guess is
> either here http://smalltalkhub.com/#!/~PharoExtras/Gettext
> >   or now maintained here: https://github.com/SeasideSt/
> Seaside/wiki/Gettext
> >
> >   Unfortunately back at the time this one was not independently loadable
> and had other trouble which I critisized on
> >   http://forum.world.st/ANN-Easy-I18N-for-Pharo-td4778194.html
> >
> >   Maybe situation for this project has improved.
> >
> >
> > But so far nobody pushed I18N really into Pharo ...
> >
> > 4. Therefore back in 2014 I started with a consolidation by starting a
> clean room implementation of Gettext - based on code from 3.
> >   but now with tests and Pharo Spec based tools (see screenshot
> attached). I did it in an own repo to be able to experiment and
> >   not break the Seaside solution right in the beginning.
> >
> >   My code is on STHub  http://smalltalkhub.com/#!/~
> TorstenBergmann/Gettext  and it is not yet fully usable and so far still
> >   unfinished
> >
> >   But one can load the project still in Pharo 7 using
> >
> > Gofer it
> >   smalltalkhubUser: 'TorstenBergmann' project: 'Gettext';
> >   configuration;
> >   load.
> >
> > (Smalltalk at: #ConfigurationOfGettext) project bleedingEdge load
> >
> >   All 11 Tests are green so at least what is there should work. Check
> the world menu and the code. Load the "Foo" package from the same repository
> >   to see something in the tools. The idea was to have support for MO and
> PO files completely written in Smalltalk as well as tools that allow you
> >   to find and translate internationalized text.
> >
> >   But as always: this would require more work. I would still favour a
> fully in Pharo written solution (following the gettext formats) but maybe
> for
> >   performance reasons then also bind to libgettext using UFFI.
> >
> >
> > Hope this gives some insights on the current existing solutions/status.
> >
> > Thanks
> > Torsten
> >
> >
> >> Gesendet: Donnerstag, 09. November 2017 um 21:29 Uhr
> >> Von: "Викентий Потапов" 
> >> An: pharo-users@lists.pharo.org
> >> Betreff: [Pharo-users] I18n in pharo
> >>
> >>
> >> Will Pharo 7 be ready for i18n of applications?
> >> I mean some simple and useful way like in Cincom Visual Works, where
> translation dictionaries are separated from code and could be dinamycally
> changed without changing my application.
> >>
> >> It is very important for huge commercial applications, especially with
> lots of UI forms, dialogs and user-messages.
> >>
> >> I transfer my code from Cincom VW (VW is not available now for Russia
> due to politic situation) to Pharo and is very interested in simple
> internationalization mechanism. I don't want to reinvent the wheel but
> sometimes it seems to me that pharo developers are forced to do it.
> >>
> >> By the way, the error i had last week with clean Pharo 6\Pharo 6.1
> installation ("UTF8InvalidText: Invalid utf8 input detected" on image load
> - error caused by cyrillic path to application folder) didn't solved and i
> had no feedback from community.
> >>
> >> best regards,
> >> Vikenti Potapov.
> >>
> >>
> > 
>
>
>

Re: [Pharo-users] I18n in pharo

[Esteban Lorenzano]

I think this is two different problems: 

1. pharo itself supporting different languages/keyboards, etc. 
2. pharo allowing the development of i18n applications

I think we still need to work on point 1, but for point 2 we already have 
gettext package, which is a standard we can/should use. Maybe that needs to be 
better documented (as everything), but well… we have a solution there :)

Esteban

> On 9 Nov 2017, at 18:58, Torsten Bergmann  wrote:
> 
> The Pharo 7/8 roadmap does not (yet) include I18N: 
> https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/ROADMAP.md
>
> 
> and the Pharo core image still includes the "NaturalLanguageTranslator" 
> solution still from Squeak. See this class for more details and 
> all senders of #translated message. So far the whole Pharo UI is in English 
> and while books, the mooc or others were translated the Pharo
> image so far is not.
> I guess some more work would be needed also on the font frontier to provide 
> an internationalized image and the different languages.
> 
> 
> 
> But for own applications (like web applications) there are some more 
> (external) solutions:
> 
> 
> 1. I once wrote and announced an own I18N framwork:  
> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-September/100247.html
>   which is fully documented on 
> http://smalltalkhub.com/#!/~TorstenBergmann/I18N but is a completely 
> proprietary solution.
> 
> 2. There is also some stuff from Jan van de Sandt:
>   
> https://lists.gforge.inria.fr/pipermail/pharo-project/2012-October/070652.html
> 
> 3. And there is GetText (from Seaside web framework) which I guess is either 
> here http://smalltalkhub.com/#!/~PharoExtras/Gettext
>   or now maintained here: https://github.com/SeasideSt/Seaside/wiki/Gettext
> 
>   Unfortunately back at the time this one was not independently loadable and 
> had other trouble which I critisized on 
>   http://forum.world.st/ANN-Easy-I18N-for-Pharo-td4778194.html
> 
>   Maybe situation for this project has improved.
> 
> 
> But so far nobody pushed I18N really into Pharo ... 
> 
> 4. Therefore back in 2014 I started with a consolidation by starting a clean 
> room implementation of Gettext - based on code from 3.
>   but now with tests and Pharo Spec based tools (see screenshot attached). I 
> did it in an own repo to be able to experiment and
>   not break the Seaside solution right in the beginning.
> 
>   My code is on STHub  http://smalltalkhub.com/#!/~TorstenBergmann/Gettext  
> and it is not yet fully usable and so far still 
>   unfinished
> 
>   But one can load the project still in Pharo 7 using
> 
> Gofer it 
>   smalltalkhubUser: 'TorstenBergmann' project: 'Gettext';
>   configuration;
>   load.
> 
> (Smalltalk at: #ConfigurationOfGettext) project bleedingEdge load
> 
>   All 11 Tests are green so at least what is there should work. Check the 
> world menu and the code. Load the "Foo" package from the same repository 
>   to see something in the tools. The idea was to have support for MO and PO 
> files completely written in Smalltalk as well as tools that allow you 
>   to find and translate internationalized text. 
> 
>   But as always: this would require more work. I would still favour a fully 
> in Pharo written solution (following the gettext formats) but maybe for
>   performance reasons then also bind to libgettext using UFFI.
> 
> 
> Hope this gives some insights on the current existing solutions/status.
> 
> Thanks
> Torsten
> 
> 
>> Gesendet: Donnerstag, 09. November 2017 um 21:29 Uhr
>> Von: "Викентий Потапов" 
>> An: pharo-users@lists.pharo.org
>> Betreff: [Pharo-users] I18n in pharo
>> 
>> 
>> Will Pharo 7 be ready for i18n of applications?
>> I mean some simple and useful way like in Cincom Visual Works, where 
>> translation dictionaries are separated from code and could be dinamycally 
>> changed without changing my application.
>> 
>> It is very important for huge commercial applications, especially with lots 
>> of UI forms, dialogs and user-messages.
>> 
>> I transfer my code from Cincom VW (VW is not available now for Russia due to 
>> politic situation) to Pharo and is very interested in simple 
>> internationalization mechanism. I don't want to reinvent the wheel but 
>> sometimes it seems to me that pharo developers are forced to do it.
>> 
>> By the way, the error i had last week with clean Pharo 6\Pharo 6.1 
>> installation ("UTF8InvalidText: Invalid utf8 input detected" on image load - 
>> error caused by cyrillic path to application folder) didn't solved and i had 
>> no feedback from community. 
>> 
>> best regards,
>> Vikenti Potapov. 
>> 
>> 
> 

Re: [Pharo-users] I18n in pharo

[Torsten Bergmann]

The Pharo 7/8 roadmap does not (yet) include I18N: 
https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/ROADMAP.md
   

and the Pharo core image still includes the "NaturalLanguageTranslator" 
solution still from Squeak. See this class for more details and 
all senders of #translated message. So far the whole Pharo UI is in English and 
while books, the mooc or others were translated the Pharo
image so far is not.
I guess some more work would be needed also on the font frontier to provide an 
internationalized image and the different languages.



But for own applications (like web applications) there are some more (external) 
solutions:


1. I once wrote and announced an own I18N framwork:  
http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-September/100247.html
   which is fully documented on 
http://smalltalkhub.com/#!/~TorstenBergmann/I18N but is a completely 
proprietary solution.

2. There is also some stuff from Jan van de Sandt:
   
https://lists.gforge.inria.fr/pipermail/pharo-project/2012-October/070652.html

3. And there is GetText (from Seaside web framework) which I guess is either 
here http://smalltalkhub.com/#!/~PharoExtras/Gettext
   or now maintained here: https://github.com/SeasideSt/Seaside/wiki/Gettext

   Unfortunately back at the time this one was not independently loadable and 
had other trouble which I critisized on 
   http://forum.world.st/ANN-Easy-I18N-for-Pharo-td4778194.html

   Maybe situation for this project has improved.


But so far nobody pushed I18N really into Pharo ... 

4. Therefore back in 2014 I started with a consolidation by starting a clean 
room implementation of Gettext - based on code from 3.
   but now with tests and Pharo Spec based tools (see screenshot attached). I 
did it in an own repo to be able to experiment and
   not break the Seaside solution right in the beginning.

   My code is on STHub  http://smalltalkhub.com/#!/~TorstenBergmann/Gettext  
and it is not yet fully usable and so far still 
   unfinished

   But one can load the project still in Pharo 7 using

 Gofer it 
   smalltalkhubUser: 'TorstenBergmann' project: 'Gettext';
   configuration;
   load.

 (Smalltalk at: #ConfigurationOfGettext) project bleedingEdge load

   All 11 Tests are green so at least what is there should work. Check the 
world menu and the code. Load the "Foo" package from the same repository 
   to see something in the tools. The idea was to have support for MO and PO 
files completely written in Smalltalk as well as tools that allow you 
   to find and translate internationalized text. 

   But as always: this would require more work. I would still favour a fully in 
Pharo written solution (following the gettext formats) but maybe for
   performance reasons then also bind to libgettext using UFFI.


Hope this gives some insights on the current existing solutions/status.

Thanks
Torsten


> Gesendet: Donnerstag, 09. November 2017 um 21:29 Uhr
> Von: "Викентий Потапов" 
> An: pharo-users@lists.pharo.org
> Betreff: [Pharo-users] I18n in pharo
>
> 
> Will Pharo 7 be ready for i18n of applications?
> I mean some simple and useful way like in Cincom Visual Works, where 
> translation dictionaries are separated from code and could be dinamycally 
> changed without changing my application.
> 
> It is very important for huge commercial applications, especially with lots 
> of UI forms, dialogs and user-messages.
> 
> I transfer my code from Cincom VW (VW is not available now for Russia due to 
> politic situation) to Pharo and is very interested in simple 
> internationalization mechanism. I don't want to reinvent the wheel but 
> sometimes it seems to me that pharo developers are forced to do it.
> 
> By the way, the error i had last week with clean Pharo 6\Pharo 6.1 
> installation ("UTF8InvalidText: Invalid utf8 input detected" on image load - 
> error caused by cyrillic path to application folder) didn't solved and i had 
> no feedback from community. 
> 
> best regards,
> Vikenti Potapov. 
> 
> 
>

Re: [Pharo-users] I18n in pharo

[Denis Kudriashov]

In my experience I used my own custom implementation to support multiple
languages. It was based on super simple dictionary of
lang->labelName->text. I loaded it from custom xml file.
My problem was that I never understood how gettext is supposed to be used
on Windows.

2017-11-09 21:29 GMT+01:00 Викентий Потапов :

>
> Will Pharo 7 be ready for i18n of applications?
> I mean some simple and useful way like in Cincom Visual Works, where
> translation dictionaries are separated from code and could be dinamycally
> changed without changing my application.
>
> It is very important for huge commercial applications, especially with
> lots of UI forms, dialogs and user-messages.
>
> I transfer my code from Cincom VW (VW is not available now for Russia due
> to politic situation) to Pharo and is very interested in simple
> internationalization mechanism. I don't want to reinvent the wheel but
> sometimes it seems to me that pharo developers are forced to do it.
>
> By the way, the error i had last week with clean Pharo 6\Pharo 6.1
> installation ("UTF8InvalidText: Invalid utf8 input detected" on image load
> - error caused by cyrillic path to application folder) didn't solved and i
> had no feedback from community.
>
> best regards,
> Vikenti Potapov.
>
>
>

Re: [Pharo-users] I18n in pharo

[Denis Kudriashov]

Hi

2017-11-09 22:15 GMT+01:00 Stephane Ducasse :

> Hi vikenti
>
> I would love. Now if nobody using a different alphabet does not give
> us feedback and help we will not really make progress.
> Denis how do you it?
>

I got this kind of errors in past with Pharo 1 on Windows XP. Now I was
sure that it was fixed. I checked it with Pharo 3 (I guess).
Now I have no such environment to test.


> Hilaire is using gettext or something like that in DrGeo.
>
> Vikenti did you check the Entreprise Pharo book because it contains
> nice chapters from svn on cahracter encoding.
>
>
>
>
> By the way, the error i had last week with clean Pharo 6\Pharo 6.1
> installation ("UTF8InvalidText: Invalid utf8 input detected" on image
> load - error caused by cyrillic path to application folder) didn't
> solved and i had no feedback from community.
>
> Did you report it?
> We are slowly deprecating the old streams (because they are messy) and
> replacing then with ZnStreams.
> Now if you want to help this would be useful to produce a better Pharo.
>
> Stef
>
>
>
> On Thu, Nov 9, 2017 at 9:29 PM, Викентий Потапов
>  wrote:
> >
> > Will Pharo 7 be ready for i18n of applications?
> > I mean some simple and useful way like in Cincom Visual Works, where
> translation dictionaries are separated from code and could be dinamycally
> changed without changing my application.
> >
> > It is very important for huge commercial applications, especially with
> lots of UI forms, dialogs and user-messages.
> >
> > I transfer my code from Cincom VW (VW is not available now for Russia
> due to politic situation) to Pharo and is very interested in simple
> internationalization mechanism. I don't want to reinvent the wheel but
> sometimes it seems to me that pharo developers are forced to do it.
> >
> > By the way, the error i had last week with clean Pharo 6\Pharo 6.1
> installation ("UTF8InvalidText: Invalid utf8 input detected" on image load
> - error caused by cyrillic path to application folder) didn't solved and i
> had no feedback from community.
> >
> > best regards,
> > Vikenti Potapov.
> >
> >
>
>

Re: [Pharo-users] I18n in pharo

[Stephane Ducasse]

Hi vikenti

I would love. Now if nobody using a different alphabet does not give
us feedback and help we will not really make progress.
Denis how do you it?
Hilaire is using gettext or something like that in DrGeo.

Vikenti did you check the Entreprise Pharo book because it contains
nice chapters from svn on cahracter encoding.




By the way, the error i had last week with clean Pharo 6\Pharo 6.1
installation ("UTF8InvalidText: Invalid utf8 input detected" on image
load - error caused by cyrillic path to application folder) didn't
solved and i had no feedback from community.

Did you report it?
We are slowly deprecating the old streams (because they are messy) and
replacing then with ZnStreams.
Now if you want to help this would be useful to produce a better Pharo.

Stef



On Thu, Nov 9, 2017 at 9:29 PM, Викентий Потапов
 wrote:
>
> Will Pharo 7 be ready for i18n of applications?
> I mean some simple and useful way like in Cincom Visual Works, where 
> translation dictionaries are separated from code and could be dinamycally 
> changed without changing my application.
>
> It is very important for huge commercial applications, especially with lots 
> of UI forms, dialogs and user-messages.
>
> I transfer my code from Cincom VW (VW is not available now for Russia due to 
> politic situation) to Pharo and is very interested in simple 
> internationalization mechanism. I don't want to reinvent the wheel but 
> sometimes it seems to me that pharo developers are forced to do it.
>
> By the way, the error i had last week with clean Pharo 6\Pharo 6.1 
> installation ("UTF8InvalidText: Invalid utf8 input detected" on image load - 
> error caused by cyrillic path to application folder) didn't solved and i had 
> no feedback from community.
>
> best regards,
> Vikenti Potapov.
>
>