Can lupdate extract strings translated with QTranslator::translate()?
-
In the project I'm working on, all of the GUI will be separated into an application constituting the View of an MVC model. The Controller and Model will live in a DLL/dylib/etc. This DLL will be used as a service and any number of host applications (including non-Qt applications) will be able to load and use that service DLL. As such, the service will not contain any GUI objects. However, there is still a need for the Controller DLL to query the user for information from time-to-time, for example: "The file you are opening is an older configuration, do you want to update it?" YES/NO
For these latter cases we intend to use a callback function where the Controller can ask the host application (View) to open message box and return the result. The strings used to populate that message box would be constructed and managed in the Controller code. Since the Controller doesn't have access to a QApp it won't have access to the tr() macro. However, we do wish for our translation vendors to only need a single method to manage translated strings, i.e. through QtLinguist. It seems that we can have a separate set of string resources for the Controller DLL and that with the absence of a QApp we can create our own QTranslator objects and manage the string resources manually.
All this brings me to my actual question. The strings in the Controller DLL will not be using the tr() macro from either QObject or QApp, instead they will use the QTranslator::translate() method directly. So the question is, when the lupdate tool is used to extract translatable strings, will it extract strings that are being translated through the QTranslate::translate() method or will it only see strings if they use tr()?
Thanks,
~Mark -
Hi,
Why about using the technique showed in Translating non Qt classes ?
-
In the project I'm working on, all of the GUI will be separated into an application constituting the View of an MVC model. The Controller and Model will live in a DLL/dylib/etc. This DLL will be used as a service and any number of host applications (including non-Qt applications) will be able to load and use that service DLL. As such, the service will not contain any GUI objects. However, there is still a need for the Controller DLL to query the user for information from time-to-time, for example: "The file you are opening is an older configuration, do you want to update it?" YES/NO
For these latter cases we intend to use a callback function where the Controller can ask the host application (View) to open message box and return the result. The strings used to populate that message box would be constructed and managed in the Controller code. Since the Controller doesn't have access to a QApp it won't have access to the tr() macro. However, we do wish for our translation vendors to only need a single method to manage translated strings, i.e. through QtLinguist. It seems that we can have a separate set of string resources for the Controller DLL and that with the absence of a QApp we can create our own QTranslator objects and manage the string resources manually.
All this brings me to my actual question. The strings in the Controller DLL will not be using the tr() macro from either QObject or QApp, instead they will use the QTranslator::translate() method directly. So the question is, when the lupdate tool is used to extract translatable strings, will it extract strings that are being translated through the QTranslate::translate() method or will it only see strings if they use tr()?
Thanks,
~MarkSo the question is, when the lupdate tool is used to extract translatable strings, will it extract strings that are being translated through the QTranslate::translate() method or will it only see strings if they use tr()?
I don't believe so. You can use
QT_TR_NOOPto mark things for translation, however I question the wisdom of not havingQCoreApplication. It's a requirement forQObjects and you are most probably going to experience weirdness (and possibly crashes) without it. -
Thanks for the replies. Yes, it seems QT_TR_NOOP and QT_TRANSLATE_NOOP are what I was looking for in the absence of QCoreApplication, and Q_DECLARE_TR_FUNCTIONS in the case where QCoreApplication is available. Whether we have QCoreApplication available or not is still an open question, but something for a different discussion thread I think.
Thanks again,
~Mark
