On Linux and macOS encoding seems to be set to UTF-8 in general. No problems with internationalization here (at least to my knowledge as a Linux user). But on Windows things are different. On my local machine encoding is set to windows-2151 and a couple of file actions relying on the current OS encoding via QString::toLocal8Bit do fail if characters outside of Latin-1 are encountered. This seems to be the case for some users too.
Things failing:
Rendering artifacts in console output
Log file is stored with system encoding instead of UTF-8 and non Latin-1 characters are lost
Song export to WAV/FLAC.., MIDI, and LilyPond fails if non Latin-1 characters are part of the resulting file path
Drumkit import fails if non Latin-1 characters are part of the resulting file path or contained files
Drumkit export fails if non Latin-1 characters are part of the resulting file path or contained files
Point 1., 2., and 3. were fixed by both enforcing UTF-8 encoding for all text files and refactoring code to use Qt's methods and classes for file writing whenever possible.
In addition, 4. does also seem to work properly. 5., however, could not be fixed. There seem to be severe problems in upstream libarchive resulting in segfaults (!) when attempting to use UTF-8 pathnames for archive entries in some library version - like 3.7.2 and 3.6.2. That's too hot to touch and we should be very careful to make future exported drumkits backward compatible as well.
In case drumkit exporting failed due to encoding issues, a dedicated dialog will tell the user what went wrong.
On Linux and macOS encoding seems to be set to UTF-8 in general. No problems with internationalization here (at least to my knowledge as a Linux user). But on Windows things are different. On my local machine encoding is set to
windows-2151and a couple of file actions relying on the current OS encoding viaQString::toLocal8Bitdo fail if characters outside of Latin-1 are encountered. This seems to be the case for some users too.Things failing:
Point 1., 2., and 3. were fixed by both enforcing UTF-8 encoding for all text files and refactoring code to use Qt's methods and classes for file writing whenever possible.
In addition, 4. does also seem to work properly. 5., however, could not be fixed. There seem to be severe problems in upstream
libarchiveresulting in segfaults (!) when attempting to use UTF-8 pathnames for archive entries in some library version - like 3.7.2 and 3.6.2. That's too hot to touch and we should be very careful to make future exported drumkits backward compatible as well.In case drumkit exporting failed due to encoding issues, a dedicated dialog will tell the user what went wrong.
Fixes #1957
Supersedes #1961