Generate translation files automatically

[DanWin]

Instead of updating the binary translation files manually, update them automatically when building.
Now we only need to sync the *.ts files.
As a translator you can get confused with .qm and .ts files. #597
This removes the need of updating the .ts file together with the .qm file. It will also help keeping the repository smaller.

[lukas-w]

Sounds like a reasonable thing to do.

[tresf]

Sounds like a reasonable thing to do.

After some evaluation of our build logic, I believe this commit is causing a downstream effect on the Windows builds. @tobydox would occasionally sync these, and I have a feeling this is because lupdate/lrelease was never packaged for mingw causing (what I believe to be) these files never generating.

Now I'm wondering if it's related to #2577 since my build machine may have had these laying around from a Linux build, whereas Travis certainly wouldn't have.

The prob I've identified is here: src/CMakeLists.txt#L151. On a standard win32 build this value QT_LUPDATE_EXECUTABLE is undefined on my machine.

This was exposed while I'm working on the Qt5 packaging (#2608) and I'm seeing the same problem. This is my proposed change for Qt5 #2608 (diff) but now I'm having second thoughts.

So... do we ask @tobydox to package these language tools into Qt4/Qt5 mingw or do we go back to periodically uploading these .qm files so they're ready around release time?

[lukas-w]

Can't we just add qt4-linguist-tools to Travis' Windows dependencies and use that? We don't need a windows build of lrelease, and we can't even use it without wine on Travis.

[tresf]

We don't need a windows build of lrelease, and we can't even use it without wine on Travis.

Well, that's assuming Toby's build uses win binaries, but it actually uses ELF binaries.

Can't we just add qt4-linguist-tools to Travis' Windows dependencies and use that?

Yes, so as long as we have a way to locate it (or tell PkgConfig to). The lrelease/lupdate variables are unusable in their current form.

[lukas-w]

The lrelease/lupdate variables are unusable in their current form.

That's true. So we'll just have to change the CMake scripts to use the system's lrelease even when cross-compiling. We could just set the variable to lrelease instead of an empty string, so it'll at least fall back to searching in the PATH variable. That should do the trick on most systems including Travis.

[liushuyu]

In fact, I saw the binary translation files were generated, but not installed to the installation directory. But if you re-run make install, the files will appear in the correct directory. Strange.

[tresf]

@liushuyu thanks that helps a lot. I'll bump the convo back over to #2611, since this commit most likely isn't the culprit.