GNOME Bugzilla – Bug 605540
texts displayed with gimp-message are not translated
Last modified: 2010-02-11 20:30:03 UTC
Start GIMP with a different-than-English locale (in order to show a different-than-English UI language); create or open any simple image; go to Filters -> Animation -> Blend... then click OK; a Blend message shows up. The text from that message ("Blend Animation needs at least three source layers") shows not translated, in spite of the fact that it is translated in the .po file. Tested with French and Romanian translation. I don't know if the not-translated status is related to the message box frame or to the message itself – in other words I don't know if another message from another filter displayed in same alert box will show translated or not. Cristi
Script-Fu doesn't have full internationalisation support. Only the menu registration supports i18n. Don't we have a bug-report for this already?
There's bug #565268, but it is slightly different.
This is a long-standing bug in Script-Fu that no one has ever card to address. Support for i18n was simply never finished and is limited to the auto-generated parameter dialogs and the GIMP menu entries.
Created attachment 152217 [details] [review] Add a new token for '_' and use gettext accordingly This patch provides internationnalization for all string in scheme prefix by '_'. The patch is for 2.6.1 but should apply cleanly on 2.6.8 too. As strings are now translated from source, the gettext() occurence for menus in script-fu plug-in should be useless. Anyway, it is not dynamic. Once the string is translated, the original one is discard. Thus, one cannot change dynamically the langage. If this is a problem, a new to_be_translated_string atom must be created, and strvalue() of such an atom will use gettext.
I don't understand what means "Anyway, it is not dynamic. Once the string is translated, the original one is discard. Thus, one cannot change dynamically the langage.". Multilanguage environment is a must, where with "multilanguage" I mean different users on same machine should be able to switch to any desired language [from those available] according to their personal taste or culture. Cristi
"not dynamic" is for one application instance. Some application may be able to change their locale on the fly. In this case, once you launch Gimp in Romanian, all english messages are discarded. You'll have to relaunch Gimp to get it in French. (OK, at this time, you cannot change language in Gimp without relaunch but Bug #576910 may change this ) In your particular concern, two Gimp instance could use different language as usual : the script files on disk are not modified.
Patch should be considered for GIMP 2.8. Kevin, please review this.
My first impression is its on the right track, but as written, it will leak memory. I will have to take a closer look at the handling of the string returned from the gettext() call.
Strings returned by gettext() are statically allocated and must not be modified or freed.
For gettext(), I already checked. My own concern is x returned by readstrexp() : as I understand it, it's an atom in sc context ; thus it should be freed by garbage collector, shouldn't it ?
Correct, there is no problem with gettext() as it does not return a newly allocated string. As for the handling of x, readstrexp() returns a pointer to a newly allocated data cell for a valid string. Setting x to the return from mk_string() will "leak" the recently allocated cell. This cell will eventually be GC'ed. Most of the overhead of calling mk_string() and having to later GC the leaked cell can be avoided by changing the mk_string line to the following: sc->free(strvalue(x)); strlength(x) = g_utf8_strlen(trans_str, -1); strvalue(x) = store_string(sc, strlength(x), trans_str, 0);
commit 93440be0b263442dae1dbbfcd076f327be490a3a Author: Kevin Cozens <kcozens@cvs.gnome.org> Date: Thu Feb 11 12:02:57 2010 -0500 Bug 605540 - texts displayed with gimp-message are not translated Applied modified version of patch supplied by Eric Lamarque.