I18n in pharo

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

I18n in pharo

vikenti

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.


Reply | Threaded
Open this post in threaded view
|

Re: I18n in pharo

Stephane Ducasse-3
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, Викентий Потапов
<[hidden email]> 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.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: I18n in pharo

Denis Kudriashov
Hi

2017-11-09 22:15 GMT+01:00 Stephane Ducasse <[hidden email]>:
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, Викентий Потапов
<[hidden email]> 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.
>
>


Reply | Threaded
Open this post in threaded view
|

Re: I18n in pharo

Denis Kudriashov
In reply to this post by vikenti
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 Викентий Потапов <[hidden email]>:

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.



Reply | Threaded
Open this post in threaded view
|

Re: I18n in pharo

Torsten Bergmann
In reply to this post by vikenti
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: "Викентий Потапов" <[hidden email]>
> An: [hidden email]
> 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.
>
>
>

GetTextNewTools.png (94K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: I18n in pharo

EstebanLM
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 <[hidden email]> 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: "Викентий Потапов" <[hidden email]>
>> An: [hidden email]
>> 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.
>>
>>
> <GetTextNewTools.png>


Reply | Threaded
Open this post in threaded view
|

Re: I18n in pharo

Pavel Krivanek-3


2017-11-09 23:50 GMT+01:00 Esteban Lorenzano <[hidden email]>:
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 <[hidden email]> 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: "Викентий Потапов" <[hidden email]>
>> An: [hidden email]
>> 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.
>>
>>
> <GetTextNewTools.png>



Reply | Threaded
Open this post in threaded view
|

Re: I18n in pharo

Stephan Eggermont-3
In reply to this post by vikenti
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



Reply | Threaded
Open this post in threaded view
|

Re: I18n in pharo

HilaireFernandes
In reply to this post by vikenti
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



Reply | Threaded
Open this post in threaded view
|

Re: I18n in pharo

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

> On 10 Nov 2017, at 11:10, Hilaire <[hidden email]> 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
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: I18n in pharo

EstebanLM
In reply to this post by Pavel Krivanek-3


On 10 Nov 2017, at 04:05, Pavel Krivanek <[hidden email]> wrote:



2017-11-09 23:50 GMT+01:00 Esteban Lorenzano <[hidden email]>:
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 <[hidden email]> 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: "Викентий Потапов" <[hidden email]>
>> An: [hidden email]
>> 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.
>>
>>
> <GetTextNewTools.png>




Reply | Threaded
Open this post in threaded view
|

Re: I18n in pharo

Marcus Denker-4


On 10 Nov 2017, at 11:18, Esteban Lorenzano <[hidden email]> wrote:



On 10 Nov 2017, at 04:05, Pavel Krivanek <[hidden email]> wrote:



2017-11-09 23:50 GMT+01:00 Esteban Lorenzano <[hidden email]>:
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

Reply | Threaded
Open this post in threaded view
|

Re: I18n in pharo

HilaireFernandes
In reply to this post by Marcus Denker-4
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



Reply | Threaded
Open this post in threaded view
|

Re: I18n in pharo

Hannes Hirzel
On 11/10/17, Hilaire <[hidden email]> 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
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: I18n in pharo

Hannes Hirzel
Maybe in a different thread...

On 11/10/17, H. Hirzel <[hidden email]> wrote:

> On 11/10/17, Hilaire <[hidden email]> 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
>>
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: I18n in pharo

cedreek
In reply to this post by HilaireFernandes
>
> 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
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: I18n in pharo

aglynn42
In reply to this post by Torsten Bergmann

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: [hidden email]
Sent: Thursday, November 9, 2017 4:59 PM
To: [hidden email]
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: "Викентий Потапов" <[hidden email]>

> An: [hidden email]

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

>

>

> 

 

Reply | Threaded
Open this post in threaded view
|

Re: I18n in pharo

aglynn42

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: [hidden email]
Sent: Friday, November 10, 2017 6:09 PM
To: [hidden email]
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: [hidden email]
Sent: Thursday, November 9, 2017 4:59 PM
To: [hidden email]
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: "Викентий Потапов" <[hidden email]>

> An: [hidden email]

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

>

>

> 

 

 

Reply | Threaded
Open this post in threaded view
|

Re: I18n in pharo

Stephane Ducasse-3
In reply to this post by Torsten Bergmann
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 <[hidden email]> 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: "Викентий Потапов" <[hidden email]>
>> An: [hidden email]
>> 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.
>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: I18n in pharo

Stephane Ducasse-3
In reply to this post by Pavel Krivanek-3
Hi Pavel

Does it make sense to have loaded by default?

Stef

On Fri, Nov 10, 2017 at 8:05 AM, Pavel Krivanek
<[hidden email]> wrote:

>
>
> 2017-11-09 23:50 GMT+01:00 Esteban Lorenzano <[hidden email]>:
>>
>> 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 <[hidden email]> 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: "Викентий Потапов" <[hidden email]>
>> >> An: [hidden email]
>> >> 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.
>> >>
>> >>
>> > <GetTextNewTools.png>
>>
>>
>

123