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", "[EMAIL PROTECTED]", "[EMAIL PROTECTED]"... This way, there will always be a "New" as before, and en_US.po will contain:
msgid "New" msgstr ""
msgid "[EMAIL PROTECTED]" 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
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
