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?!?
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"?
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
Comments
Thanks for checking on this. I'll check it out with lasconic once he is back from holidays.
Yes, I'm having the same problem when I try to update English (GB).
Using MuseScore 2.0 Nightly Build (d65c722) - Mac 10.7.5.
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: "http://extensions.musescore.org/languages/mscore_en_GB.qm"
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:
![1.png]( "1.png")
![2.png]( "2.png")
![3.png]( "3.png")
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?
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
Thanks, works now.
Automatically closed -- issue fixed for 2 weeks with no activity.