November 2017 - Pharo-users

Re: [Pharo-users] I18n in pharo

by Marcus Denker

> On 10 Nov 2017, at 11:18, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> On 10 Nov 2017, at 04:05, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> wrote: >> >> >> >> 2017-11-09 23:50 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@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. > 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

Nov. 10, 2017

Re: [Pharo-users] I18n in pharo

by Esteban Lorenzano

> On 10 Nov 2017, at 04:05, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > > 2017-11-09 23:50 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@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 <astares(a)gmx.de <mailto:astares@gmx.de>> wrote: > > > > The Pharo 7/8 roadmap does not (yet) include I18N: https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/R… <https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/R…> > > > > 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/1… <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-September/1…> > > 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.h… <https://lists.gforge.inria.fr/pipermail/pharo-project/2012-October/070652.h…> > > > > 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.potapov(a)gmail.com <mailto:vikenti.potapov@gmail.com>> > >> An: pharo-users(a)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> > > >

Nov. 10, 2017

Re: [Pharo-users] I18n in pharo

by Marcus Denker

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 <hilaire(a)drgeo.eu> 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 > > >

Nov. 10, 2017

Re: [Pharo-users] I18n in pharo

by Hilaire

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

Nov. 10, 2017

Adding an Iceberg repository at startup

by Prof. Andrew P. Black

I would like to have the git repositories that Iâm working from automatically added to the list of known repositories in Iceberg at startup time. In other words, I don;t want to have to do a bunch of âAdd local repositoryâ commands before I can start work. What magic can I put in my settings.st file to make this happen? Andrew

Nov. 10, 2017

Re: [Pharo-users] including Pillar in Pharo image by default

by H. Hirzel

Hello Peter Uhnak summarized this thread about what what to include of Pillar in the base image on Aug 17, 2017 ([1] original question, [2] summary). The issue of having a "Mini pillar" in the image was brought up by Stephan Ducasse and summarized by Cyril Ferlicot. I will start a new thread with the subject 'Mini Pillar'. Regards Hannes [1] On 8/11/17, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > Hi, > > I would like to propose including Pillar in the Pharo image by default. > > My reasoning: > > Since we are moving to git, and most people will use github, gitlab, and the > likes, it is expected to include a README.md file (or possibly more > extensive documentation) alongside the code. > > Which means that people will (and are) writing the README mostly by hand, > which of course is problematic, as e.g. code snippets can get deprecated, > screenshots become outdated, etc. > > As Pillar tries to address these problems, it would make sense to me to > include Pillar in the image by default, as anyone using git (which > eventually should be everyone) will most likely benefit from writing their > documentation in Pillar. > Similarly using Pillar would open an avenue to provide the documentation > in-image, e.g. one exporter for html/markdown, and another one for Pharo's > Help system. > > I could, of course, install Pillar every time, but considering thats extra > effort and in the extra time I can fix the issues by hand, I don't have such > an incentive to use Pillar for this. > > Questions & Problems: > > I don't know by how much would pillar increase the image size. Perhaps there > could be (a) "lightweight Pillar" (that would include just pillar & markdown > exporter), or (b) we would have different images for different uses. > > By different images I mean something along the lines of > a) developer image - meant to be directly used by developers to create their > software > b) production image - as a foundation for running systems / users > > Does this make sense? > > Peter > > ------------------------------- [2] Peter Uhnak <i.uhnak(a)gmail.com> Thu, Aug 17, 2017 at 10:26 AM Reply-To: Pharo Development List <pharo-dev(a)lists.pharo.org> To: Pharo Development List <pharo-dev(a)lists.pharo.org> Even though I've initiated this discussion I kind of stopped reading because everyone started discussing completely unrelated things... The initial point was.... "we are using github/gitlab more and more, lets leverage it more" New, lets separate the concepts at play here... "Pillar - document model" - the workhorse of pillar and (imho) the most important part of it, and also the part I am interested in being included. Because then I can generate the document directly without using any syntax... "Pillar - syntax" - we can have endless arguments whether the syntax is good or bad, and imho that should be a separate discussion unrelated to the Pillar inclusion "Markdown for unrelated usecases" - whether you can or cannot write your thesis in markdown is really irelevant here "Markdown - export" - there will always be different variants and extensions for Markdown, simply because the sites using markdown offer different capabilities. Therefore the first focus should be on the most impact/effort ratio, which is CommonMark (basically the only meaningful Markdown specification), and GFM (which is a CommonMark with added tables and strikethrough). Adding support for more extensive export support, whether code related (e.g. GitLab), or code unrelated (writing a thesis) should be a future discussion, it is not relevant or too effortful right now. "Markdown - import" - I would love to be able to write markdown and have it imported into the Pillar document model, however that is imho moot point right now, as it can always be added later To summarize: * primary * include pillar document model * include pillar syntax (as an import format) * add CommonMark+GFM export * secondary * discuss Pillar syntax if needed (in a _new_ thread) * discuss Markdown parser / importing CommonMark into Pillar model * any other discussion not pertinent here should go elsewhere Peter ------------------------------------------------------------------- [3] Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> AttachmentFri, Aug 11, 2017 at 6:57 PM Reply-To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> To: pharo-users(a)lists.pharo.org Reply | Reply to all | Forward | Print | Delete | Show original - Show quoted text - Hi, I know that Stephane want to includes a light version of Pillar in the image. Currently he is working on a way to remove Magritte dependency from Pillar. Another step would be to get a minimal parser not relying on PetitParser. This parser would parse only a subset of the Pillar syntax that can be used for writing class comments. If this subset is defined (I we have the list of all Document Items we want to understand), I can give a try to make this light parse. -------------------- Let us rephrase it: - I would like to have a mini pillar with a simplified model and visitor to display class comments. - then think about Pharo 70 as the core and birth of a new generation of imageS I will restart to revisit Pillar once I'm done with the Lecture at Prague. Stef ---------------------------- Stephane Ducasse <stepharo.self(a)gmail.com> Fri, Aug 11, 2017 at 7:09 PM Reply-To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Reply | Reply to all | Forward | Print | Delete | Show original Tx cyril For class comment I image that we want ! - - *url* and bold [[[ ]]] Did I miss something. Stef ----------------------------- Stephane Ducasse <stepharo.self(a)gmail.com> Sun, Aug 13, 2017 at 9:08 PM Reply-To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Reply | Reply to all | Forward | Print | Delete | Show original Hi tim I personally do not care much about the syntax but I care about what I can do with it (ref, cite, ... ) I cannot write books in markdown because reference to figures!!!!!! were missing. And of course a parser because markdown is not really nice to parse and I will not write a parser because I have something else to do. I want to make pillar smaller, simpler, nicer. Now if someone come up with a parser that parse for REAL a markdown that can be extended with decent behavior (figure reference, section reference, cite) and can be extended because there are many things that can be nice to have (for example I want to be able to write the example below) and emit a PillarModel (AST) we can talk to have another syntax for Pillar but not before. [[[test 2+3 >>> 5 ]]] and being able to verify that the doc is in sync. Stef

Nov. 10, 2017

Re: [Pharo-users] Why does the test runner show red when I correct a test?

by Denis Kudriashov

Hi Richard 2017-11-09 23:51 GMT+01:00 Richard Sargent < richard.sargent(a)gemtalksystems.com>: > I think it is correct to show green if you fix your problem in the >> debugger and then proceed and it passes all assertions. But it should >> equally fail if you proceed and it asserts false or craps out. >> > > It would be a lie. The truth is only that from that point on, it is > correct. You have no guarantee that your correction hasn't broken something > that would occur in the next run prior to the point at which you applied > the correction. > I think it is correct because icon shows the last run state. It is not depends on the way how user manages to pass or fail the test. So user can hack the test from the debugger and make it pass or fail using inspector, scripting or whatever interaction with available objects. When he closes the debugger (by proceed or window close) it is expected to see the result of this hacking in the UI. So test icon should be updated accordingly. Then it is up to user to check how test is working in normal way. > > Hence my assertion that you cannot determine the colour until the next run. > > > > On Thu, Nov 9, 2017 at 2:47 PM, Tim Mackinnon <tim(a)testit.works> wrote: > >> Thanks Denis - I'll try my simple TDD test case in Pharo 7 (I haven't >> tried it yet - probably time to). >> >> I think it is correct to show green if you fix your problem in the >> debugger and then proceed and it passes all assertions. But it should >> equally fail if you proceed and it asserts false or craps out. >> >> Strange it would vary in 6.1 - but I'll check. >> >> Tim >> >> Sent from my iPhone >> >> >> >> Sent from my iPhone >> On 9 Nov 2017, at 19:54, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> In Pharo 7 it works. >> >> 2017-11-09 18:29 GMT+01:00 Tim Mackinnon <tim(a)testit.works>: >> >>> Thanks for looking at this - there is an issue however - when you apply >>> that change (at least in a Pharo 6.1 image) - it shows green even when a >>> test fails? So I think its turned one problem into the opposite one. >>> >>> Unfortunately I havenât got a chance to look a bit deeper to help - but >>> it might be worth rolling back this change for now. We should fix it though >>> - and the answer must be in the area you have identified. >>> >>> tim >>> >>> On 9 Nov 2017, at 12:43, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>> >>> And now it is in latest Pharo >>> >>> 2017-11-09 12:16 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>> >>>> Hi Tim. >>>> >>>> Fix is here 20661-Fixing-test-from-debugger-should-mark-test-as-gre >>>> en-when-proceed <https://github.com/pharo-project/pharo/pull/456> . >>>> Thank's for reporting. It forces me to fix. I always noticed it but >>>> never take it seriously :) >>>> >>>> 2017-11-09 11:32 GMT+01:00 Tim Mackinnon <tim(a)testit.works>: >>>> >>>>> Hi - I really like the build in test runner in the Pharo browsers, and >>>>> I was preparing a talk to show how great TDD is in Pharo and how we arenât >>>>> ashamed of our debugger when testing (it augments the experience in fact - >>>>> letting you poke around and get your thoughts straight). >>>>> >>>>> However - if I pick rerun in the test runner debugger - and step >>>>> through a test and then correct the failing code, and hit resume - the >>>>> browser always shows a red failure, even though the execution is now >>>>> correct. I have to run the test again. >>>>> >>>>> This doesnât seem right to me - are we missing a success event or >>>>> something? >>>>> >>>>> >>>>> Tim >>>>> >>>> >>>> >>> >>> >> >

Nov. 10, 2017

Re: [Pharo-users] Why does the test runner show red when I correct a test?

by Denis Kudriashov

And give me concrete steps to see that it is not working (if you will find it) 2017-11-09 23:47 GMT+01:00 Tim Mackinnon <tim(a)testit.works>: > Thanks Denis - I'll try my simple TDD test case in Pharo 7 (I haven't > tried it yet - probably time to). > > I think it is correct to show green if you fix your problem in the > debugger and then proceed and it passes all assertions. But it should > equally fail if you proceed and it asserts false or craps out. > > Strange it would vary in 6.1 - but I'll check. > > Tim > > Sent from my iPhone > > > > Sent from my iPhone > On 9 Nov 2017, at 19:54, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > In Pharo 7 it works. > > 2017-11-09 18:29 GMT+01:00 Tim Mackinnon <tim(a)testit.works>: > >> Thanks for looking at this - there is an issue however - when you apply >> that change (at least in a Pharo 6.1 image) - it shows green even when a >> test fails? So I think its turned one problem into the opposite one. >> >> Unfortunately I havenât got a chance to look a bit deeper to help - but >> it might be worth rolling back this change for now. We should fix it though >> - and the answer must be in the area you have identified. >> >> tim >> >> On 9 Nov 2017, at 12:43, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> And now it is in latest Pharo >> >> 2017-11-09 12:16 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >>> Hi Tim. >>> >>> Fix is here 20661-Fixing-test-from-debugger-should-mark-test-as-gre >>> en-when-proceed <https://github.com/pharo-project/pharo/pull/456> . >>> Thank's for reporting. It forces me to fix. I always noticed it but >>> never take it seriously :) >>> >>> 2017-11-09 11:32 GMT+01:00 Tim Mackinnon <tim(a)testit.works>: >>> >>>> Hi - I really like the build in test runner in the Pharo browsers, and >>>> I was preparing a talk to show how great TDD is in Pharo and how we arenât >>>> ashamed of our debugger when testing (it augments the experience in fact - >>>> letting you poke around and get your thoughts straight). >>>> >>>> However - if I pick rerun in the test runner debugger - and step >>>> through a test and then correct the failing code, and hit resume - the >>>> browser always shows a red failure, even though the execution is now >>>> correct. I have to run the test again. >>>> >>>> This doesnât seem right to me - are we missing a success event or >>>> something? >>>> >>>> >>>> Tim >>>> >>> >>> >> >> >

Nov. 10, 2017

Re: [Pharo-users] I18n in pharo

by 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

Nov. 10, 2017

Re: [Pharo-users] I18n in pharo

by Pavel Krivanek

2017-11-09 23:50 GMT+01:00 Esteban Lorenzano <estebanlm(a)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 <astares(a)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.potapov(a)gmail.com> > >> An: pharo-users(a)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> > > >

Nov. 10, 2017