>>>>> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> I don't see where in your patch
Abdelrazak> MenuTranslator::translate() is called. If this is called
Abdelrazak> internally by Qt, then I suggest to add a virtual
Abdelrazak> destructor to MenuTranslator.
This is indeed called internally by Qt (qt tries to use its own
translation system and my goal is to use gettext instead for some of
the strings).
Concerning the virtual destructor, well, I do not delete the object :)
I know I should, but I was not sure what the best way is.
Abdelrazak> If this translator things work for menus, it could work
Abdelrazak> for all other dialogs. In which case, I would strongly
Abdelrazak> suggest to do this for all and to replace all occurences
Abdelrazak> of 'toqstr(_(s))' to simply 'tr(s)'.
I am not sure what you mean. That we should use this for all the Qt
translation needs? It may be a good idea. I suspect that KDE has such
a translator that goes through gettext.
>> +
>> +
>> +void GuiApplication::addMenuTranslator() +{ + menu_trans_ = new
>> MenuTranslator(); + qApp->installTranslator(menu_trans_);
Abdelrazak> AFAIS, this is called from the constructor. I would prefer
Abdelrazak> to not take any risk with the qApp pointer. Please call
Abdelrazak> installTranslator() directly (GuiApplication derives from
Abdelrazak> QApplication):
And in the translator too, I guess?
Updated patch attached. Do I need a constructor too? What would be the
least intrusive way to delete the translator at exit? The alternative
is to make menu_trans_ a non-pointer, but that forces me to expose
MenuTranslator in GuiApplication.h. It might be the way to go
actually, especially if we use it more generally.
But first, I have to make sure that the patch does something useful on
Qt/Mac...
JMarc
