As I've already mentioned in
http://thread.gmane.org/gmane.comp.finance.aqbanking.devel/1300 , the German
translation of the qt3-wizard.exe on win32 is not working. It turns out qt4's
QObject::tr("") translation function behaves differently on Windows compared
to Linux and I will propose a workaround below.
First, one explanation about qt's translation messages and gettext's ones:
With gettext translations, each string is defined by the source string
(called "msgid" - the text the programmer writes into the source code) which
at runtime will be passed to _("...") and that's it. With qt's translation
function, each string is defined by the sourceText *and* an *additional*
context string, which is usually taken as the class name of the current
class! You can see these arguments at the static method
QApplication::translate(). But in QObject::tr() and derived classes, qt's
type system will automatically add the name of the current class as the
additional context argument and you can't influence that argument there
anymore.
Our current translation is collected in a gettext de.po file and converted to
qt's binary format de.qm by invoking msgfmt with the --qt argument. As I
mentioned, gettext doesn't have the "context" string, hence in the resulting
de.qm all messages have their "context" string set to NULL. Nevertheless all
QObject::tr() function calls will look for a translation with a non-NULL
context string... you get the point?
On Linux, QObject::tr() does not find a translation with the correct context,
only one with NULL context, and that one is used. This is the same with qt3
and qt-4.2.3, on Linux.
On Windows, QObject::tr() does not find a translation with the correct
context, hence no translation at all is returned! Shoot. This is the same in
qt-4.2.3 and qt-4.3.0, on Windows. Once I create a translation file by
QtLinguist with the correct context set, a translation will be returned and
all is fine.
However for our 1125 translation strings it is impossible to retrieve the
correct translation context. So we need some other workaround. My proposal is
to try to replace all QObject::tr() function calls by
QApplication::translate(NULL, "..."), which should then return our existing
translation strings that have a Null as context.
So I'd propose
#define _tr(sourceText) QApplication::translate(0, sourceText)
and then replacing all tr("...") by _tr("..."). Feel free to propose other
names. And I have yet to check whether this actually fixes the problem for
all of qbanking on win32, but I suspect it does.
Christian
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Aqbanking-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/aqbanking-devel
