> On 10 Nov 2017, at 04:05, Pavel Krivanek <pavel.kriva...@gmail.com> wrote: > > > > 2017-11-09 23:50 GMT+01:00 Esteban Lorenzano <esteba...@gmail.com > <mailto:esteba...@gmail.com>>: > 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 <asta...@gmx.de > > <mailto:asta...@gmx.de>> wrote: > > > > The Pharo 7/8 roadmap does not (yet) include I18N: > > https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/ROADMAP.md > > > > <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 > > > > <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-September/100247.html> > > which is fully documented on > > http://smalltalkhub.com/#!/~TorstenBergmann/I18N > > <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 > > > > <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 > > <http://smalltalkhub.com/#!/~PharoExtras/Gettext> > > or now maintained here: https://github.com/SeasideSt/Seaside/wiki/Gettext > > <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 > > <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 > > <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 > >> <mailto:vikenti.pota...@gmail.com>> > >> An: pharo-users@lists.pharo.org <mailto: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. > >> > >> > > <GetTextNewTools.png> > > >
