[ANN] Easy I18N for Pharo

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 <[hidden email]> wrote:

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 [hidden email] 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          [hidden email]
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 :

--
Dr. Geo - http://drgeo.eu
iStoa - http://istao.drgeo.eu

2014-09-15 12:38 GMT-03:00 Johan Brichau <[hidden email]>:

> On 15 Sep 2014, at 12:27, [hidden email] 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!

Johan wrote:
>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?

The main problems I have with external tools is the lack of translation context and the
slow feedback cycle. That is killing for translation speed and quality.

Stephan

On 15 Sep 2014, at 19:31, Stephan Eggermont <[hidden email]> wrote:

> The main problems I have with external tools is the lack of translation context and the
> slow feedback cycle. That is killing for translation speed and quality.


I can understand that in-app tools work well for developers but when you start working with translators (humans) that are not developers (and certainly not Smalltalkers), you want to export the translation work. Now, Gettext is certainly not the walhalla, but I see a lot of things to do in-app before even getting to the level of those external tools.

Also, there is translation context exported to Gettext (but this does not help actually) and whenever a translator changes the file, we immediately read it again in the app, so I don’t really understand the slow feedback cycle issue.

There are other tools btw:
- http://translate-toolkit.readthedocs.org/en/latest/index.html
- http://www.arizona-software.ch/ilocalize/

I’m all for an approach where Pharo explicitly caters for multiple possible translators, where Gettext would just be one possible option. This is more or less what exists today, except that it’s ad-hoc and deserves a cleaned implementation and design. Gettext and other translators can plugin to the Locale and Translator class hierarchies that are there.

Johan

2014-09-15 15:35 GMT-03:00 Johan Brichau <[hidden email]>:
> On 15 Sep 2014, at 19:31, Stephan Eggermont <[hidden email]> wrote:
>> The main problems I have with external tools is the lack of translation context and the
>> slow feedback cycle. That is killing for translation speed and quality.
> I can understand that in-app tools work well for developers but when you start working with translators (humans) that are not developers (and certainly not Smalltalkers), you want to export the translation work. Now, Gettext is certainly not the walhalla, but I see a lot of things to do in-app before even getting to the level of those external tools.

+1

We used a Gettext like (custom dev) approach in the past, and it was
the analyst and expert users who did the translations and
customizations (regional dialects). It involved 3 languages and
several dialects of Spanish. Some specific terms are different in
different countries and/or each corporation has a different jargon
which THEY WANT to see on the screen/reports.

It worked very well. And because the files were plain text it was even
easier to integrate different modifications to the master file using
standard tools like git/diff.

Regards!