What is the best approach to translate text coming from a remote system?
-
Context
- Already have a Qt Core network service running on a remote Linux device
- Also have a desktop Qt widget dashboard app that connects to the remote service and shows info about it, allows control, receive error messages, etc
- Neither codebase was written with translation in mind
- Now I need to translate the Qt widget app to add Spanish support
- I don't want to modify the device service to make it language-aware, or modify the protocol between the widget app and the device (such as switching from strings to codes). Minor refactoring of the service code to help the desktop app is fine, such as extracting strings into their own shared header.
Having read Qt's translation doc, I get how to translate a widget app, when all the text is local, and I've taken care of those. What I'm wondering about is these:
1. Dynamic error messages
When the remote system sends a single string containing a dynamic error message like "Operation XYZ failed: access denied". In this case, the error message is built dynamically by using returning QString("Operation %1 failed: %2").arg(operationID, reason) and written over TCP.
The desktop app receives a TCP message like this: "<Response type=error>Operation XYZ failed: access denied</Response>", which I decrypt and put in a single QString.
What is the best approach to make these things easily translatable and in sync in both apps? The brute force approach would be splitting error messages using regexes and then look up the translated substrings, but I'd like to know if there's a cleaner approach. The Qt doc does not go this far.
2. Different enum values for a status
The remote device sends status updates with key/value pairs like "Battlecruiser=Operational" "HailingFrequencies=Open". There's different values possible.
So I need to automatically translate the value of "HailingFrequencies" based on the possible values, which I thankfully have in a CSV document.Here, I'm thinking of auto-generating a massive translation function from the CSV: getTranslatedValue(QString statusKey, QString value), which I'd call with getTranslatedValue("HailingFrequencies", "Open") (obviously it would be variables at runtime, not string literals).
getTranslatedValue would read a global variable specifying the currently selected language, and translate using a dictionary accordingly.Is this the right approach or is there a better one?
-
Hi,
Just a shot in the dark: what about passing the language as query parameter or in the endpoint path and use QTranslator server side to return the appropriate translation ?
-
I don't think that there is any translation library that allows for dynamic error messages in the way you are describing. In general, you'd translate "Operation %1 failed: %2" (which even allows to place the parameters at different positions in the translation) and then pass the arguments to the translated string. It is not really maintainable to use regexes to extract parts of the string for translation. It almost makes more sense to have a translation of the full string "Operation XYZ failed: access denied.". It is very cumbersome anyway if you cannot extract the string for translation automatically because they are not marked. You should at least consider using a macro like this
QString(_("Operation %1 failed: %2")).arg(operationId, reason) which is just an empty define:#define _(STR)`. (Since you have a CSV, this last point might be moot.)If you want to use Qt for translation, you can have a list of strings by writing them down with QT_TR_NOOP(). These translations will then be found by Qt. You can generate the QT_TR_NOOP() from your CSV. Or directly generate a .ts-file from your CSV. You also don't have to write a function getTranslatedValue, but can just use tr() in the places where the error string is returned (or displayed).
The best solution is to have the the translation already on the server side.
-
@SGaist I'd rather not modify the backend if I can. It's a much more important and complex app than the dashboard and I want to keep things as simple as possible on it. Making it handle translations, and then adding a language flag to the protocol, isn't the aproach I wish to take.
I'm fine with extracting error message templates from random .cpp files to a shared header like "const QString ERROR_OPERATION_FAILED = QObject::tr("Operation %1 failed: %2"); Then both backend and frontend use the constants and therefore are kept in sync.@SimonSchroeder Thanks for the feedback. I'll listen to your advice about avoiding regexes. I will go through the effort of enumerating all possible parameters and make them all their own "tr macro" constants (so 1 error message template becomes 10 non-template entries) in their own shared header.
