Changes between Version 1 and Version 3 of Ticket #6451
- Timestamp:
- Mar 9, 2022, 1:27:14 AM (2 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #6451
- Property Patch → phab:D4530
- Property Component Internationalization & Localization → Core engine
- Property Summary Em-dash sprinf combination crash → Single word wrapping infinite loop
-
Ticket #6451 – Description
v1 v3 1 Currently (r26604) when I select the en_GB language and open the replay menu, the game will hang, eat up all RAM and crash. This behaviour is confirmed by marder while not reproducible by Freagarach.1 Currently (r26604) when I select the en_GB language and open the replay menu, the game will hang, eat up all RAM and crash. 2 2 3 Trisecting the issue lead to the following string `"%(min)s - %(max)s min"` in the durationFilters of the replayMenu. In en_GB this is translated as `"%(min)s–%(max)s min"`. Notice the em_dash directly between two sprintf variables, both of which will be replaced by a number. 4 So after doing the sprintf, we will end up with a translated string like `"30\u201345 min"`. Here `\u2013` is the unicode for the em-dash and 30 and 45 are the numbers plugged into the string. 3 Trisecting the issue lead to the following string `"%(min)s - %(max)s min"` in the durationFilters of the replayMenu. In en_GB this is translated as `"%(min)s–%(max)s min"`. Notice the em_dash directly (no spaces) between two sprintf variables, both of which will be replaced by a number. 5 4 6 Our poor textRenderer fails miserably at interpreting `30\u201345`. Yielding the behaviour as described.5 The resulting string is too long for the textbox, however since there are no spaces, we cannot word-warp either. 7 6 8 This issue can easily be fixed by changing the translation and adding some spaces around the em-dash, but that is nowhere near a permanent solution. 7 Since r26522 we have the crash as described. 9 8 10 Seeing that Freagarach doesn't have this issue, this potentially is a platform depended bug. This might as well be a bug in a third party dependency. 9 Before r26522 this issue was hided by blindly adding a full width of the word in case of failure. Notice this is wrong because we could end up with wrapping "too late" (there could be a short word following the long word which stays on the same line this way). 10 11 Instead we should not process the line on the first word of the line (unless it is the last word of the string). 12 13 This issue could also be fixed by changing the translation and adding some spaces around the em-dash, but that is nowhere near a permanent solution.
