Translation problems; possible solution

[Christian Stimming]

A. Alper ATICI schrieb:
>>The programmer should write _("New Account"), _("New Loan") or _("New
>>Invoice") in the source code. 
> 
> I think this puts some unfair burden on the developer. 
> Context difference is the problem of translators, and they should guide
> the developer via reference comments in PO file.
> 
> How about mangling msgid's? i.e. "New", "New at 001#", "New at 002#"... 
> This way, there will always be a "New" as before, and en_US.po will 
> contain:
> 
> msgid "New"
> msgstr ""
> 
> msgid "New at 001#"
> msgstr "New"

<rant>Do people actually *read* my posting? 
http://article.gmane.org/gmane.comp.gnome.apps.gnucash.devel/10632 I 
already explained in detail the problem here, I pointed to previous 
proposed solutions, and I explained in length why these solutions still 
won't work. Why the f*** do you continue this discussion as if I didn't 
explain anything about these issues so far?</rant>

So, again. The shortcoming here is a general problem of the gettext 
system and we still don't have a real solution at hand.

First of all, it is not tolerable to drop support for a "C" locale. 
People have to be able to get meaningful string messages even if they 
don't have any gettext installed and/or set up correctly. It is 
therefore not possible to enforce *every* language including "en" to 
offer a respective po file. Instead, we need a solution that will still 
work even without any po file around.

Secondly, this has been explained in long detail already. The gettext 
manual itself explains this problem here 
http://www.gnu.org/manual/gettext/html_chapter/gettext_10.html#SEC151 , 
also referenced in the recent gnome-i18n discussion 
http://mail.gnome.org/archives/gnome-i18n/2003-October/msg00197.html . 
The respective discussion on gnome-i18n some years ago came pretty much 
to the same conclusion, 
http://mail.gnome.org/archives/gnome-i18n/2001-April/msg00058.html : For 
these short ambiguous messages, they prepend a *prefix* to the msgid, 
separated by a the special character `|'. The translators only translate 
the part after the special character. E.g. for de.po

msgid "create a new file|New"
msgstr "Neu"
or
msgid "button label to transfer some money, i.e. the verb|Transfer"
msgstr "Buchen"
and
msgid "the noun|Transfer"
msgstr "Buchung"

Part of this solution is that a new gettext wrapper functions is needed, 
qualifier_prefix_gettext() or short Q_() instead of _(). Such a function 
will either retrieve the translation, or, if none is available, remove 
the prefix from the msgid. To my knowledge, none of our available 
libraries already implements such a gettext wrapper function. 
http://mail.gnome.org/archives/gnome-i18n/2001-September/msg00108.html 
Some applications do this on their own and so does gnucash in 
src/engine/messages.h. In theory we could now replace the _() call by 
Q_() and add such a qualifying prefix to the msgid.

HOWEVER, the most critical strings of these kind come from inside GLADE, 
i.e. the gettext call that would need to be replaced is located inside 
libglade. This lies beyond our control and currently we can't do 
anything about it.

Thinking about it, we might be able to use the prefix_gettext() even for 
glade strings: When a widget is loaded and initialized in glade (using 
gettext()), we could afterwards change the labels "manually" from 
gnucash again, this time using prefix_gettext(). I.e.

   GladeXML *xml = gnc_glade_xml_new ("register.glade",
			"Some Register Widget");
   GtkWidget *dialog = glade_xml_get_widget (xml, "The widget window");
   GtkWidget *some_label = glade_xml_get_widget (xml, "some_label");
   gtk_label_set_text (GTK_LABEL (some_label), Q_("new file|New"));
   gtk_widget_show_all (dialog);

This actually might work. It's a bit confusing for the developer that he 
has one label inside the register.glade file but another one that is 
actually displayed, but since the developers need to know a lot about 
their GUI elements anyway I think they would very well be able to handle 
that. And this could be handled in a graceful upgrade: If one developer 
introduces such a prefix_gettext in some widget, the rest of the program 
isn't affected at all. And for the translators this new kind of 
translatable strings can be explained in lengthy comments right in that 
source file.

Actually I might try this out some time in future. Probably not in 1.8.8 
but maybe after that.

Christian