Re: [Pharo-users] [ANN] Easy I18N for Pharo
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 <stephan@stack.nl> 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 <johan@inceptive.be>:
On 15 Sep 2014, at 19:31, Stephan Eggermont <stephan@stack.nl> 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!
participants (3)
-
Esteban A. Maringolo -
Johan Brichau -
Stephan Eggermont