2017-11-11 12:16 GMT+01:00 Stephane Ducasse <stepharo.s...@gmail.com>:
> 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 > <pavel.kriva...@gmail.com> wrote: > > > > > > 2017-11-09 23:50 GMT+01:00 Esteban Lorenzano <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? > > > > -- Pavel > > > >> > >> Esteban > >> > >> > On 9 Nov 2017, at 18:58, Torsten Bergmann <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 > >> > > >> > 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. > >> >> > >> >> > >> > <GetTextNewTools.png> > >> > >> > > > >
