-----BEGIN PGP SIGNED MESSAGE-----

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 
http://www.gnu.org/manual/gettext/html_node/gettext_151.html#SEC151 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 (www.gnucash.org) 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 [EMAIL PROTECTED]: 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. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iQCVAwUBP7d2gGXAi+BfhivFAQFakwP8CffXOOBDEzC1AKJpA9gQl5dZ8sCMUwV3
xRQaOS9CgQ0rGEjKMJGiOOlRpAul370d0kMf6kteZx2iMpg/S7k/HzmOrE4kcn+R
uXVC0DHedchYQOFpTyAS7PiqXCUX32Wa40X+O1+b+6uWC6QZRt9JfadYvhxufPFz
UghVctwzd3Q=
=mj9B
-----END PGP SIGNATURE-----

_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel

Reply via email to