Emulator Issues #12502
open
[Windows 10] Invalid character when displaying image file size
Added by karolst over 3 years ago.
Updated 9 months ago.
Relates to performance:
No
Relates to maintainability:
No
Description
Operating system: Windows 10 x64
System locale: Polish (although it should be replicable in some other locales too)
Dolphin version: 5.0-14097
Revision: 19580c38410f0c83c94e000dba0164bf54f088ef
The issue manifests itself on the main screen of the GUI, in the disk image list, in the size column.
When the size of the disk image is between 1000 MiB and 1 GiB, the thousands separator is rendered incorrectly as a diamond with a question mark.
The thousands separator is U+00A0 NO-BREAK SPACE in my locale.
See the attached screenshot.
Files
- Status changed from New to Accepted
- Operating system Windows added
- Operating system deleted (
N/A)
The locale defines the thousands separator as the single character \xA0
(NO-BREAK SPACE
).
We assume the fmt::format
result can be interpreted as a utf-8 sequence but unfortunately NO-BREAK SPACE
is represented as \xC2\xA0
in utf-8.
\xA0
is just invalid in utf-8.
There is probably more code that assumes fmt::format
produces valid utf-8 sequences. Numbers and strings will have to be handled separately? 🙁
I've got the same problem in 5.0-21088 when Windows 11's system language is nb-NO, as Norway's official number formatting uses a space to separate thousands (resulting in, for example, "1 037,41 MB"), as well as commas for decimals, like the Polish screenshot in the OP.
I wonder if it'd be possible to simply replace "No-break space" with a standard "Space" in Dolphin's code for situations like these; I give 40:60 that I'd be able to submit a pull request for it.
DandelionSprout wrote in #note-3:
I wonder if it'd be possible to simply replace "No-break space" with a standard "Space" in Dolphin's code for situations like these; I give 40:60 that I'd be able to submit a pull request for it.
It's easy enough to replace ASCII NO-BREAK SPACE with UTF-8 NO-BREAK SPACE to fix just the number formatting in question, but that's not necessarily the cleanest fix. Potentially other locales have similar problems with other characters, and potentially in other places in dolphin. Ideally we'd have a more generic fix to deal with all of our formatted strings being assumed as valid UTF-8.
I wonder if it'd be possible to simply replace "No-break space" with a standard "Space" in Dolphin's code for situations like these; I give 40:60 that I'd be able to submit a pull request for it.
The no-break space isn't defined in Dolphin's code, it's defined in the locale.
Also available in: Atom
PDF