Translation problems; possible solution
stimming at tuhh.de
Wed Oct 22 16:28:24 CDT 2003
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
> msgid "New"
> msgstr ""
> msgid "New at 001#"
> msgstr "New"
<rant>Do people actually *read* my posting?
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
also referenced in the recent gnome-i18n discussion
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"
msgid "button label to transfer some money, i.e. the verb|Transfer"
msgid "the noun|Transfer"
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.
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"));
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
Actually I might try this out some time in future. Probably not in 1.8.8
but maybe after that.
More information about the gnucash-devel