libglade Feature Request: Disambiguating translation msgids

Mark McLoughlin mark at
Mon Nov 17 07:43:56 CST 2003

Hi Christian,
	James Henstridge is the maintainer of libglade.

	You seem to have a good handle on this issue - you should probably just
go ahead and write the patch and send it to James.


On Sun, 2003-11-16 at 13:07, Christian Stimming wrote:
> Sorry if I'm bothering you directly -- I didn't find any libglade development 
> mailing list. If there is one, please forward this to there.
> A long known issue in the internationalization and translation of GUI 
> application is the problem with ambiguous message string. If GUIs contain 
> very short strings (e.g. a button label "File") in different places with 
> different meanings (detailed explanation [1]), then all these labels are 
> forced to have one common translation. This frequently leads to totally wrong 
> translations, and translation teams all over the place are longing for a 
> solution for this problem.
> The gettext manual knows about this as well 
> but it 
> defers the solution into the application domain. It proposes to introduce a 
> new "qualified_gettext()" function and "disambiguating comments" into the 
> msgid, so that the msgid then reads "noun|File" instead of just "File". Every 
> occurrence of the call to gettext() (or _() ) in the program code should then 
> be replaced by a call to the newly introduced qualified_gettext() (or Q_() ) 
> function or however it's called. 
> Fortunately, just recently exactly these extra functions have been introduced 
> into glib: On November 5th, Matthias Clausen introduced glib/gi18n.h into 
> glib CVS, and they define such a Q_() function (using g_strip_context() from 
> gstrfuncs.h).
> I'm writing to you because in order to make use of this extra functionality, 
> the code place where gettext() is called has to be changed in order to call 
> the qualified_gettext() or Q_(). For message strings that have been defined 
> in a Glade XML file this would be in libglade/glade/glade-parser.c in 
> glade_parser_end_element(). Maybe one could even introduce a xml-file-wide 
> option that either stays with the conventional gettext() or turns on the new 
> qualified gettext() calls. That way, nothing would change for old projects, 
> but those projects who want to make use of glib's functionality here can 
> consciously turn on this new feature.
> It is important that this is done in libglade (as opposed to the application's 
> code), because the message strings in question usually only show up inside 
> the glade XML file. In the project I'm involved ( we don't 
> define the button labels inside (our) C code (where we could switch from _() 
> to Q_() on our own) but only inside the Glade XML files. Therefore we can 
> only make use of the qualified gettext functions if libglade uses these, and 
> we cannot make this transition in our application code alone.
> What do you think about such a change? If you are interested, I could also 
> prepare some patches to implement this.
> Christian Stimming
> [1] From an earlier posting to translation-i18n at Think 
> of any english word that can both be a noun and a verb (e.g. "a file"
> and "to file"). Think of the fact that almost always in at least some
> languages the translation of the verb is [very] different from the
> translation of the noun (e.g. in German the noun is "Datei" and the verb is
> "ablegen"). Now think of a GUI button that is labelled with this word. Now
> think of a case where this button has the meaning of the verb, and another
> case where this button has the meaning of the noun (e.g. "File" meaning "to
> file something somewhere" as opposed to "File" meaning "do something with a
> file"). There you are -- the msgid in both cases is identical, but the msgstr
> should be different. Therefore we need a disambiguating addition in the
> msgids. In the example this can be as simple as (in gettext manual's format)
> "noun|File" and "verb|File", but you could also use the real meaning: "to
> file something somewhere|File" and so on. 
> Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
> xRQaOS9CgQ0rGEjKMJGiOOlRpAul370d0kMf6kteZx2iMpg/S7k/HzmOrE4kcn+R
> uXVC0DHedchYQOFpTyAS7PiqXCUX32Wa40X+O1+b+6uWC6QZRt9JfadYvhxufPFz
> UghVctwzd3Q=
> =mj9B

More information about the gnucash-devel mailing list