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.
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@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>
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@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
Sven Van Caekenberghe wrote:
Perfect! Well done & presented (as usual ;-)
I18N is nothing fancy, but thanks. Hope it is usefull for others too.
The way I see it, that is all there is to it.
Yes - at least it solved my basic needs so far and maybe it helps us thinking about more internationalized applications for Pharo (or I18N the Pharo image itself)
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 ?
You decide where your translations come from/are loaded from. I use INIFile as it is plain simple to do. Internally I18NTranslator is nothing more than a simple object handling dictionaries. So the strings usually will be stored with the image (or flushed out and reloaded again at startup). If necessary the code can be refactored so that multiple storage backends or a cache can be added. Not on my todo list so far. Bye T.
Nice for project with a delimited scope. Problem: you cut yourself from translators aggregated in oneline free software community. For example https://translations.launchpad.net/drgeo For DrGeo this is a show stopper. Hilaire Le 15/09/2014 10:23, Torsten Bergmann a écrit :
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.
-- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu
With a .po bridge to/from I18N, wouldn't we have a pretty nice solution? Phil On Mon, Sep 15, 2014 at 11:35 AM, Hilaire <hilaire@drgeo.eu> wrote:
Nice for project with a delimited scope. Problem: you cut yourself from translators aggregated in oneline free software community. For example https://translations.launchpad.net/drgeo For DrGeo this is a show stopper.
Hilaire
Le 15/09/2014 10:23, Torsten Bergmann a écrit :
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.
-- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu
On 15 Sep 2014, at 12:27, phil@highoctane.be wrote:
With a .po bridge to/from I18N, wouldn't we have a pretty nice solution?
That is exactly what Gettext does. Once the translation dictionary is loaded into Pharo, itâs just string mapping. How strings are translated (i.e. sending #translate or doing whatever) could be factored out. The Gettext template generator is a metaprogram that extracts the strings from your source code, and that could be parameterized. A question: without looking at the code of i18n, I notice the assumption that each âUI stringâ is identified by a symbol. Is that correct or just how the example is presented? In most cases, you construct âUI stringsâ in your code as follows: âThe user {name} clicked on item {number}â translatedWith: { name -> self username . number -> self number } So, I donât know if i18n relies on the keys being symbols or not, but this kind of thing works with the Gettext translators. Normally, this should not be an issue since it just means using strings as the keys in the translation dictionaries. But it struck me because for a translator (i.e. a human) who just gets the thousand strings to translate, being able to translate this kind of sentences (instead of symbols) is essential. I also agree 100% with Hilaire: Gettext is a standard where plenty of external tools can work with. Though itâs nice to have translation tools in the image, you will have to do everything yourself. Just take a look at everyhting that is done by poedit [1]. Do we really want to implement everything ourselves? [1] http://poedit.net/ Johan
Phil
On Mon, Sep 15, 2014 at 11:35 AM, Hilaire <hilaire@drgeo.eu> wrote:
Nice for project with a delimited scope. Problem: you cut yourself from translators aggregated in oneline free software community. For example https://translations.launchpad.net/drgeo For DrGeo this is a show stopper.
Hilaire
Le 15/09/2014 10:23, Torsten Bergmann a écrit : 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.
-- Dr. Geo - http://drgeo.eu iStoa - http://istao.drgeo.eu
2014-09-15 12:38 GMT-03:00 Johan Brichau <johan@inceptive.be>:
On 15 Sep 2014, at 12:27, phil@highoctane.be wrote: A question: without looking at the code of i18n, I notice the assumption that each âUI stringâ is identified by a symbol. Is that correct or just how the example is presented?
As I understood it, I18N uses the selectors as keys in a dictionary, as if it were a constant. What I don't like about this approach is it gets really convoluted as soon as you have a lot of entries in your table, with very similar names. In the long run it causes some codification for the strings, like the one used by VisualAge Smalltalk. Stuff like: getMRI: AbtMsgBase::MsgBaseFooMessage group: 'AbtMsgBase'
In most cases, you construct âUI stringsâ in your code as follows:
âThe user {name} clicked on item {number}â translatedWith: { name -> self username . number -> self number }
+1 In my experience this is the best approach to translate UIs, because the source code is legible in the original language (whatever it is, usually english).
I also agree 100% with Hilaire: Gettext is a standard where plenty of external tools can work with. Though itâs nice to have translation tools in the image, you will have to do everything yourself. Just take a look at everyhting that is done by poedit [1]. Do we really want to implement everything ourselves?
Yes please, let's stick with a proven and used solution with external support such as Gettext. Also, saying Pharo supports Gettext is a sales point. Regards!
participants (7)
-
Esteban A. Maringolo -
Hilaire -
Johan Brichau -
jtuchel＠objektfabrik.de -
phil＠highoctane.be -
Sven Van Caekenberghe -
Torsten Bergmann