Some translations claim to fail to load from Resource Manager

• Jan 14, 2014 - 09:46
S4 - Minor

Some translations fail to load from Resource Manager, they give a "Failed, try again":

  • Čeština
  • Galego
  • Polski

Happens since at least yesterday, 9e88861


Could this be a race condition between the musescore version and qm files being build for the nightly and the translation being updated on transifex?
With a self build binary I saw that almost all translations failed to update

Also it seems it does update the translations and takes them into effect but still claims the update to have failed?!?

Output in Qt-Creator's debug Output:

Debug: ""
Debug: 13.9358 %
Debug: 100 %
Debug: here writing to file "<?d↑???!∟?`???B

Apparently some junk...

Corresponding line in ...mscore/downloadutils.cpp:30

qDebug() << "here writing to file "<< sdata << " at " << _localFile;

Looks like sdata is screwd?

Building mscore first, then changing a Translation on Transifex, then updating it via Resource Manager
a) produces the same bogus output
b) succeeds, so seems to confirm my suspicion of a race condition.
So we're looking at 2 problems, one (minor?) with debug output and one with an incorreclty reported error

Here's another issue that waited on lasconic's return ;-)

Tried again today, after having done a factory reset, deleted all personal MuseScore settings and directories and with the latest nighly, 8b56364:

It fails on most languages, it's easier to list the ones that work... instead a picture, or rather 2:
However, looking into the directory where these files are supposed to get download too I can see that they are all there (and all from today):

I can't be 100% sure for all other languages, but for Italian language, which is one of the "failing" updates, the file downloaded by the script (and found in the MuseScoreDevelopment\locale folder) is smaller than the dimension (in KB) given by the resource manager.
Could this be related to the "failure"?

Indeed, nicely spotted. Seems to be true for all the failed ones!

Would it be possible that the sizes and hashes in the details.json file are simply wrong?

Status (old) active fixed

Should be fixed. Reopen if necessary.
For an unknown reason the hash and size were wrong in details.json. I also made some improvements in the download process in 8bb2007233