[Interest] Translation support totally broken

Till Oliver Knoll till.oliver.knoll at gmail.com
Wed Dec 18 16:58:22 CET 2013


Am 18.12.2013 um 16:05 schrieb Philipp Kursawe <phil.kursawe at gmail.com>:

> ...
> 
> First flaw I see is the whole "Embedd the default text in the source code". Translations should always be external and id based.

No. No no no no no!

"ID based translation" is the bigest fuckup since the invention of i18n!

Oh just how I hated that concept when back in Java. Or any other framework for that matter.

In Qt you have the /actual messages/ in the source code, so I never have to wonder what e.g.

  dialog->showMessage(resourceBundle->msg('msg_12345', arg1, arg2, arg3); // hold on! Does that message really take 3 args? WTF!

is supposed to show. And believe me, I have seen that: people just start using that "msg_12345" in every possible context (class), as soon as they have figured out that the actual message behind that ID "more or less" fits the purpose - because it is such a PITA to add/edit another resource file and figure out what "the next proper ID" would be, let alone to add this ID to every other damn translation resource bundle (if you're unlucky enough that at least that step is not handled by your tool chain).

Sure, you can try to come up with some "semantically meaningful" way of creating your IDs such as "main_window_err_file_dupl" - good luck with that! Over time you /will/ have generic IDs again like "something_went_wrong"!

And off course since your code is now actually without any meaningful messages (except the ones for which the developers actually avoided to translate, see PITA), you are now /forced/ to deliver a resource bundle (or at least compile the resources into your executable).

I don't want to deal with "resource IDs"! I want to have meaningful text messages within the code - the rest should be taken care of by the toolkit. And that's /exactly/ how Qt works, and the /only/ burden for developers is to wrap the messages into a tr() method call (for QObject derived classes). Done!

> The Qt tools cannot even handle the (default) way in Qt to embed the base language in the source code. When you change the wording or move the text definition in the cpp file the ts file will contain one new entry and an obsolete entry (most of the time).

Because the text is now in a different context and might hence need a /different/ translation. So that is by design!

If you're worried about that: stop moving your text around. Or in other words: start with i18n only /after/ your strings have been finalised (good practise for i18n anyway).

Even if you /have/ to move a text after translation: QTranslator is clever enough to detect that it is the same string and will suggest the /same/ translation. All you have to do is to confirm it (hint: CTRL + Enter). Done.

> 
> But when you want to use id based translations you lose the context.

Just don't. Use proper text.


> ... 
> So imagine I have 2 plugins, both define a string with the id "about". I create on translator for each plugin I load and add them the the global translator table using qApp.installTranslator.

Redundant text messages can be a sign of bad design: in that example the common app libs should/could provide a common "About Dialog" functionality, the plugins would call that and only provide the plugin specific text.

> se where you want to bundle common strings in one place and use them from different plugins. How can this situation be solved?

Each plugin loads its own resource bundle. No problems, I have done that.

> I still sometimes feel that with Qt you go a long way very fast but when you hit a wall then you hit it hard.

That usually means you're on the wrong path: in your instance that's your attempt to use "IDs" and place "common messages" into a common resource bundle (*.ts).

That's simply not the intended way: each plugin defines its own unique messages, and they are placed into /separate/ bundles (*.ts).

If you see that you have many strings in common then think about placing that functionality into a common lib!

Cheers,
  Oliver


> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest



More information about the Interest mailing list