Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Support second line for "AUDIO / ZOOM OPTIONS" message #345
The translation of the sidetext "AUDIO / ZOOM OPTIONS" is too long in
Note that the message's translation must not begin or end with "\n",
Partial output of
The attached ZIP file contains
As a paragraph separator for campaign mission briefings, the string " "
Apr 30, 2019
Thinking about this a bit more, adding an "empty" translation string to permit a second line for this particular entry in the translation file just doesn't strike me as the right approach.
A solution for this problem is definitely warranted, but I'm not sure heading down this path is the right one.
While this is true, we probably don't have the resources to ensure every
Even far better-run open source games like 0 A.D. do not manage to avoid
If users want to set a custom font, that's up to them.
I think that the way forward is to improve the GUI layout gradually.
Of course, an alternative is to rewrite the GUI layout from scratch, and
In gettext, translator comments are supposed to provide context.
I think that any good translation platform displays translator comments,
I would appreciate a better solution, yet your complaint seems like
I have been working off-and-on on proper script detection and multi-line / paragraph shaping support for the text engine. No idea when it'll be in shape to review, but it's at least (tentatively) being worked on. (No guarantees, though, of course.)
This is also ultimately the goal. Nothing to review yet.
The issue is proximity. I am not aware of a way to guarantee that the second line is tied to the first line in those various online translation platforms, as the way they display and sort translation strings is different from that of a flat .po file (and also allows filtering / sorting / etc).
This, in my opinion, makes the way this PR is currently structured very problematic. Ultimately, the benefits of a translation platform outweigh this specific downside.
Since the ultimate, exhaustive fix (an improved text layout / shaping / splitting engine) is not likely to be ready soon, here are some alternatives:
If we want a stop-gap patch for now, that enables a second line for all side-text, I'm leaning towards 2. Yes it requires a translation comment to inform translators, but so does this current PR. And sure, it isn't exhaustive escape sequence parsing, but the specific problem you identified is "how do we split side-text into a second line", and it solves that without the disadvantages of the currently-proposed .po solution.