- Pharo-users - lists.pharo.org

Re: [Pharo-users] [ANN] Easy I18N for Pharo

by jtuchel＠objektfabrik.de

There is a small error in the documentation on that page: If you now open the translation viewer you will see both translations: 'Welcome' for the english language and 'Willkommen' for german language registered with the given message key. So depending on the translator that one asks a different String is returned: (I18NTranslator forLanguage: 'DE') welcome. returns 'Willkommen' and (I18NTranslator forLanguage: 'DE') welcome. returns 'Welcome' I think the second line of code should be (I18NTranslator forLanguage: 'EN') welcome. Joachim Am 15.09.14 um 10:29 schrieb Sven Van Caekenberghe: > Perfect! Well done & presented (as usual ;-) > > The way I see it, that is all there is to it. > > I like it that a single image can translate into multiple languages. > > I guess some people would also like > > String>>#translated > ^ I18NTranslator defaultTranslator at: self > > I assume that the actual storage is open ended to also allow databases and so on ? > > On 15 Sep 2014, at 10:23, Torsten Bergmann <astares(a)gmx.de> wrote: > >> Need an easy translation framework for your Pharo application >> with no external dependency? >> >> Then check out the I18N project: >> >> http://smalltalkhub.com/#!/~TorstenBergmann/I18N >> >> Docu and examples can be found on the same page, screenshot >> is attached. >> >> Bye >> T.<i18n.png> > > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Sept. 15, 2014

Re: [Pharo-users] [ANN] Easy I18N for Pharo

by Sven Van Caekenberghe

Perfect! Well done & presented (as usual ;-) The way I see it, that is all there is to it. I like it that a single image can translate into multiple languages. I guess some people would also like String>>#translated ^ I18NTranslator defaultTranslator at: self I assume that the actual storage is open ended to also allow databases and so on ? On 15 Sep 2014, at 10:23, Torsten Bergmann <astares(a)gmx.de> wrote: > Need an easy translation framework for your Pharo application > with no external dependency? > > Then check out the I18N project: > > http://smalltalkhub.com/#!/~TorstenBergmann/I18N > > Docu and examples can be found on the same page, screenshot > is attached. > > Bye > T.<i18n.png>

Sept. 15, 2014

[ANN] Easy I18N for Pharo

by Torsten Bergmann

Need an easy translation framework for your Pharo application with no external dependency? Then check out the I18N project: http://smalltalkhub.com/#!/~TorstenBergmann/I18N Docu and examples can be found on the same page, screenshot is attached. Bye T.

Sept. 15, 2014

Gettext with pharo 3 and seaside 3.1.2

by Torsten Bergmann

Have a look at I18N project: http://smalltalkhub.com/#!/~TorstenBergmann/I18N/ The docu with examples and all is on the same page.

Sept. 15, 2014

Re: [Pharo-users] [Pharo-dev] Yosemite & Pharo

by Sven Van Caekenberghe

On 15 Sep 2014, at 09:36, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi pharoers, > > so Iâve installed Yosemite beta and: > > 1) there were no problems with Pharo by now Good. > 2) sometimes Yosemite lags in general (on rich 3D graphics for e.g.) and battery life is worse. Hmm, let's hope they fix that ;-) > 3) the most important thing that Iâve noticed: there are no black bars if full screen mode. Is an improvement in Pharo, or just how Yosemite works? That would be excellent news, I missed that. That would then fix https://pharo.fogbugz.com/f/cases/12648/Full-screen-on-Mac-OS-X-10-9-partia… > Cheers. > Uko Thanks for testing and for the report.

Sept. 15, 2014

Yosemite & Pharo

by Yuriy Tymchuk

Hi pharoers, so Iâve installed Yosemite beta and: 1) there were no problems with Pharo by now 2) sometimes Yosemite lags in general (on rich 3D graphics for e.g.) and battery life is worse. 3) the most important thing that Iâve noticed: there are no black bars if full screen mode. Is an improvement in Pharo, or just how Yosemite works? Cheers. Uko

Sept. 15, 2014

Re: [Pharo-users] Gettext with pharo 3 and seaside 3.1.2

by Marcus Denker

On 14 Sep 2014, at 19:16, stepharo <stepharo(a)free.fr> wrote: > Marcus I think that we should sync because personally I do not want to giant kernel. I want a bootstrap and modular packages. > I think that making all the packages internal to the image is a recipe to get a monolithic system. > I do not see why loading a package would hurt. > Yes, letâs discuss it sometimes this week. > Stef > > > On 14/9/14 12:59, Marcus Denker wrote: >> On 13 Sep 2014, at 20:51, stepharo <stepharo(a)free.fr> wrote: >> >>> So I'm checking and when we load Gettext, >>> System-Localization only contains >>> ISOLanguageDefinition >>> Locale >>> >>> Locale is used by LanguageEnvironment, LocalID, TimeZone, Unicode >>> >>> When we will clean leadingChar some of these will go away. >>> >>> So not all the package System-Localisation can be moved out the image to got in a newer version of getText >>> >> >> Localization is very basic functionality that should be provided by the platform itself. >> We are in the situation that we are in only because people see Pharo as something âto build on topâ. >> >> This way everyone does their own I18N stuff, while the right thing would be to have *one* that is good and >> part or Pharo itself. >> >> Just think about it: Pharo itself should have translated menus. So we need *something* in the system anyway. >> Why then not make it good and make it the one that everyone is using? >> >> Marcus >> > >

Sept. 15, 2014

Re: [Pharo-users] Gettext with pharo 3 and seaside 3.1.2

by Stephan Eggermont

QCMagritte provides a visitor that walks your magritte descriptions and knows properties that might need translation. With those (and any extra terms you add directly) it builds up a dictionary of terms to translate. It provides a web UI where the translations can be entered and supports loading from and saving to utf8 csv. When generating the seaside components, it supports chaining multiple visitors to separate concerns (translation, bootstrap layout, access control). In a system with users, it allows a user to set her preferred language to be used in the application. Unavailable translations just show the translation key. Stephan

Sept. 14, 2014

Re: [Pharo-users] Gettext with pharo 3 and seaside 3.1.2

by stepharo

Marcus I think that we should sync because personally I do not want to giant kernel. I want a bootstrap and modular packages. I think that making all the packages internal to the image is a recipe to get a monolithic system. I do not see why loading a package would hurt. Stef On 14/9/14 12:59, Marcus Denker wrote: > On 13 Sep 2014, at 20:51, stepharo <stepharo(a)free.fr> wrote: > >> So I'm checking and when we load Gettext, >> System-Localization only contains >> ISOLanguageDefinition >> Locale >> >> Locale is used by LanguageEnvironment, LocalID, TimeZone, Unicode >> >> When we will clean leadingChar some of these will go away. >> >> So not all the package System-Localisation can be moved out the image to got in a newer version of getText >> > > Localization is very basic functionality that should be provided by the platform itself. > We are in the situation that we are in only because people see Pharo as something âto build on topâ. > > This way everyone does their own I18N stuff, while the right thing would be to have *one* that is good and > part or Pharo itself. > > Just think about it: Pharo itself should have translated menus. So we need *something* in the system anyway. > Why then not make it good and make it the one that everyone is using? > > Marcus >

Sept. 14, 2014

Re: [Pharo-users] Gettext with pharo 3 and seaside 3.1.2

by stepharo

On 14/9/14 16:39, Johan Brichau wrote: > Peter, > > Gettext works. See DrGeo, for example. > Also, the Seaside-Gettext extension works just fine. > > If I understand correctly, the Pharo IDE (and rest of the system) has not been working with ant localization implementation. the fallback was simply to not translate the strings. You see we cannot try to reduce the use of strings and add translations to all the possible languages in the image. I personally do not need Pharo menu in French and do not count on me to translate them. I have been this road once and never again. Stef > > Johan > > On 14 Sep 2014, at 16:18, Peter Schorsch <tralalas(a)freenet.de> wrote: > >>> Localization is very basic functionality that should be provided by >>> the platform itself. We are in the situation that we are in only >>> because people see Pharo as something âto build on topâ. >>> >>> This way everyone does their own I18N stuff, while the right thing >>> would be to have *one* that is good and part or Pharo itself. >>> >>> Just think about it: Pharo itself should have translated menus. So we >>> need *something* in the system anyway. Why then not make it good and >>> make it the one that everyone is using? >> As a beginner with pharo I TOTALLY agree with that statement. E.g. so >> far I understood there are 3 different localization existing: >> >> * System internal localization >> - never seen before, never read about before >> * Gettext >> - does not work >> * QCMagritte >> - shall work, did not managed it by myself. Only uses csv >> table if I understood correctly. >> >> Here is my suggestion (keep in mind that I did not fully understood >> QCMagritte atm). My wish is a localization that: >> >> * supports the gettext format for in and output >> * has fallback options if a phrase is not translated >> * pharo internal interface maybe a Dictionary >> * support of different number formats (e.g. date etc.) >> * does NOT depend on the env locales - only the IDE of pharo >> >> Honestly, I am surprised that pharo does not work fully with utf8 >> (see MathOntology discussion) and has no well documentated and working >> localization. >> >> If I understood something wrong please correct me - I still want to >> learn pharo and seaside :) >> > > >

Sept. 14, 2014