That would be very hard to pull off. The layout part of the code that decides where to place line breaks is after the token processing code. You would need to change it so that the space is actually a non breaking space.

would it be an idea to use the UNICODE non-breaking space ( U+00A0) as opposite of the normal space (U+0020)

not sure you can add that as character in the localisation in an easy way (U00A0 as seperator)

If Unicode is an option, then using NBSP as mentioned would be an easy way to specify spaces that should not be broken across lines. In fact, for reference, Unicode comes with a line breaking algorithm, specified in UAX#14. So even if you had to write your own Unicode-aware line breaker (as opposed to using some library that figures it out for you), you at least wouldn't have to figure out an algorithm by yourself.

If the Unicode (or some other) non-breaking space character is supported, then it's a gotcha for translators, but at least the user-facing issue can be resolved. Are non-breaking spaces supported & respected in the game currently?

Yes, they are. I fixed that to allow for French-style punctuation (which similarly puts a non-breaking space before ! and ?).

If you change it in Localisation, could you also update the other language files that have a space for a thousands separator?

I just tried giving it a go with a single U+00A0 for STR_5151, but the same behaviour still happens - the two segments of the number are still split onto two lines... 😕

I'm running 0.3.3 (3f65f282d) if that makes a difference.

I noticed that my previous attempt was thwarted by my IDE trying to be "helpful" by converting my non-breaking spaces to regular spaces.

I now added a proper U+00A0 for STR_5151 in OpenRCT2/Localisation#2832 - however, I had to close that PR, because in-game this seems to corrupt any parent string that needs a thousands separator, by truncating the rest of the string:

I'm assuming the same character works fine for punctuation in fr-FR (albeit it looks like they also use a regular space for STR_5151?). Is there something extra that needs to be fixed or enabled to make non-breaking spaces work for fi-FI in this context?

If I had to hazard a guess: the symbol is represented by two bytes in UTF-8, and our code probably makes an assumption somewhere that the symbol is ASCII.

@groenroos A fix is pending, are you able to check that out?

@Gymnasiast Thanks - built it locally, and that does indeed seem to fix the issue! 🎉

As for OpenRCT2/Localisation#2832, given that we probably wouldn't want to distribute those strings unless your patch was also merged, would it be safe to re-open that PR now, or wait for later?