Title of the cutscenes book is badly broken

[Wuzzy2]

The name of the book “Cutscenes” is currently translated “Zwischensequenzen” in German. This is correct. However, if you look inside the book, the word is broken up poorly because of a linebreak:

https://i.imgur.com/W3onCyA.png

German does not permit a word to be broken up like this, it is ungrammatical. I am betting this is not a problem exclusive to German, probably any language with long words will fail.

Possible solution 1: Make the word “cutscenes” translatable twice, depending on context: One for the tooltip, and one for the title inside the book. This will allow translators to deal with the line-breaking correctly, if one is needed.

As a translator, I would translate this:

• Tooltip: “Zwischensequenzen” (no change)
• Book title: “Zwischen-\nsequenzen” (\n = newline)

Possible solution 2: Automatically shrink the text as needed, avoiding the newline altogether.

[dorkster]

We could try making the size of that font style smaller when the language is set to German. This would be done by adding

style=de,TexturaLiberaTenuisX-Bold.otf,20,1

after this line in engine/font_settings.txt. Here's how it would look:

[Wuzzy2]

Adding a special case only for German is not a good solution, as it is not generic at all and will likely fail for various other languages. A real solution should be generic which works with arbitrary input strings.

[dorkster]

I don't think there is a "generic" solution...

• Like English, German delimits words with spaces and can split words with a hyphen if they wrap. Yet there are other languages (East-Asian languages for example) where there are no spaces, so wrapping does not involve hyphens. So we take the "generic" route here and wrap in the least obtrusive way (no added hyphen character).
• Let's say we can flag a language to enforce keeping "words" (delimited by spaces) on a single line, and dynamically resize the text if a word is too big. We'd have to have a minimum text size to remain legible. What if the word at the minimum text size still doesn't fit into its designated area? Then we're back where we started.
• Our translation engine does not support treating the same word as separate based on context. So without re-writing all of that (and ensuring our tools can distinguish between them), this option is a no-go.

Localization issues like this are so tricky that I think it's best to handle them on a case-by-case basis.

[Wuzzy2]

I still think resizing is the simplest and most straight-forward solution. Automatic resizing could be done by first rendering the text in a single line with a fixed font size. If it fits, place it into the book directly. If not, resize the rendered text to a fixed width (preserving aspect ratio, of course), then insert the resized text into the book. That way, it will always fit. This will work unless the translation is extremely long; I think it's safe to rule this possibility out. Anyway, you can easily test by entering long dummy texts.

Our translation engine does not support treating the same word as separate based on context.

Are you sure? At least Gettext supports context (Look up “context” in your Gettext manual.).

[dorkster]

Are you sure? At least Gettext supports context (Look up “context” in your Gettext manual.).

We wrote our own GetText engine, so we'd have to implement support for msgctxt ourselves.

Between resizing and hyphens, I'd prefer the latter. Both would require a way to flag to enable/disable handling of long "words" on a per-language basis. I don't think there's a standard way to define that in PO files, so we could extend engine/languages.txt to support language properties.

---

In the specific case of this specific book, I think I made the font size too big in general. I wouldn't mind decreasing the default size of this text for all languages.

[Wuzzy2]

We wrote our own GetText engine, so we'd have to implement support for msgctxt ourselves.

Ouch.

Between resizing and hyphens, I'd prefer the latter. Well, trying to hyphenate words automatically will be a complete nightmare. You would have to know exactly how syllables and/or hyphenation rules in each language work. In German and English, you can't just break words at any random letter. And it's probably worse in many other languages. This is definitely not worth the effort.

That's why I suggested resizing, because it's more reliable and less of a clusterfuck.

Between resizing and hyphens, I'd prefer the latter. Both would require a way to flag to enable/disable handling of long "words" on a per-language basis.

Not for resizing. Just measure how long the rendered text would become in pixels. It it fits, take it. If not, shrink it. No need for any special treatment.

In the specific case of this specific book, I think I made the font size too big in general. I wouldn't mind decreasing the default size of this text for all languages.

That's also a valid solution. Yes, the default font size is indeed very large. I would suggest to make it so large that at least three times the word length of the original string “Cutscenes” would snugly fit in. Then it should be relatively safe.

[McSinyx]

Not for resizing. Just measure how long the rendered text would become in pixels. It it fits, take it. If not, shrink it. No need for any special treatment.

If this can work without reducing the text quality, I'll vote for this solution.

[Wuzzy2]

OR: Use a big font for English, and a small font for everything else.

[McSinyx]

That wouldn't be a fix but a deprecation of a feature though. From what I can see, it seems that we can pre-calculate the width if we consider the font is monospace which IMHO is a good idea since there will be additional spacing at both ends of the page. Not related, but I'm a little worried about CJK languages: does the current font provide the same style?

[dorkster]

@Wuzzy2 I agree with your point about hyphenation being complicated.

But resizing shouldn't be applied to all languages in this manner. Consider a sentence in Japanese which contains no spaces. To the engine, the sentence is considered one token, but it can be split at the character level for wrapping. We don't want to shrink the sentence so it can fit on one line. If we want to resize long tokens, we'd need to implement:

• A per-language flag to allow over-sized tokens to be broken for wrapping. Maybe this would only apply to areas of text where wrapping is allowed in the first place. Single line text could probably be resized no matter the language.
• A minimum size setting per-font. If a token still doesn't fit at the minimum size, it will be broken and wrapped like the current behavior. At that point, it will be up to the modder to make things fit.

I'm fine with the idea of resizing. It could even lead to a fix for this.