Emulator Issues #12502
open
[Windows 10] Invalid character when displaying image file size
0%
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
Updated by JosJuice over 3 years ago
- Status changed from New to Accepted
- Operating system Windows added
- Operating system deleted (
N/A)
Updated by Billiard26 9 months ago
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? 🙁
Updated by DandelionSprout 9 months ago
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.
Updated by Billiard26 9 months ago
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.
Updated by JosJuice 9 months ago
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.