[Complex Text Layouts: 4/4] Editor and general UI improvements for implementing BiDi aware apps.

[bruvzg]

This proposal is follow up to #4, to get some community feedback/preferences on a specific parts of CTL support implementation.

Describe the project you are working on:
The Godot Engine

---

Describe the problem or limitation you are having in your project:

🔹 Godot editor layout is designed for L-to-R only.

🔹 Short English string directly used in TTR() can be identical in multiple parts of the engine, but aren't always translated to the same string.

🔹 Is there anything else need to change for the BiDI UI?

---

Describe the feature / enhancement and how it helps to overcome the problem or limitation:

🔹 Mirrored UI, see: https://www.chromium.org/developers/design-documents/ui-mirroring-infrastructure
Note: Some parts (e.g directional alignment, snap-to buttons), should not be mirrored.

🔹 Use tags instead of plain English strings as translation ids.

---

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

Mirrored UI implmentation:
🔹 Separate manual RichTextLabel UI layout for the controls, mirror only order container (with override option).
🔹 Mirror UI coordinate system for child controls.
🔹 Mirror UI coordinate system globally.

How to expose it to the users for faster BiDi UI development?

Translation IDs:
🔹 Use tags only as translation ids.
Cons: no English fallbacks for untranslated strings, less readable code.
🔹 Use English string + optional tag (as second TTR argument?).
Preserves compatibility, English fallback and provide way for more customization.
🔹 Something else? Is there some special gettext API for this?

---

If this enhancement will not be used often, can it be worked around with a few lines of script?:
It will be used by editor UI and exported apps with BiDi aware interface, most of the stuff can be done by scripts, but this will involve developing separate UIs for R-to-L and L-to-R languages.

Is there a reason why this should be core and not an add-on in the asset library?:
Editor and container controls are part of core API.

[Calinou]

🔹 Use tags instead of plain English strings as translation ids.

I'm afraid gettext's PO file format was never designed for this 🙁
It also tends to make the source code less readable in my experience. I'd prefer having an optional "context" argument instead that could be used to distinguish from multiple copies of the same string.

Using translation tags would likely mean moving to XLIFF or a custom format.

I think gettext supports translation contexts (as well as other niceties we don't use currently, such as comments visible for translators directly in translation editors).

[khaledhosny]

When adding context, it should also be added only when the same string really have different uses. For example, Open when used as a menu name should use a different context than when used as a menu entry, but all menus named Open should use the same context. This avoid adding unnecessary work to translators and ensures consistency by decreasing the likelihood of having different translations for the same usage (common when translation is done by several people over the span of many years).

[bruvzg]

Translation context is added in this PR - godotengine/godot#40443

[akien-mga]

Yeah I can confirm that gettext translation context is the way to go, using IDs as proposed here is not a good option. It would add a lot of overhead in the translation workflow (and editor development) for no gain compared to using gettext translation context for the few strings where it's relevant (e.g. "Project Manager" as the project list, and as my job title).

[bruvzg]

Proposal is implemented in godotengine/godot#41100 and godotengine/godot#42595.