Improving editor's auto-translation

[KoBeWi]

Tested versions

4.5 after 68d9833

System information

W10

Issue description

With #102562 merged, we can now change editor's language without restarting. However the option is still marked as requiring restart, because it's not complete. The editor needs to properly utilize Godot's auto-translation system to allow full language switching. There is lots of legacy code that prevents that, with the main culprit being TTR method that translates strings in place, thus preventing auto-translation to occur.

Here are some guidelines that should be used from now on, and applied to old code, to have proper auto-translation in the editor:

• For static translateable strings, i.e. Labels that are assigned once etc., TTRC should be used.
• For dynamic translateable strings, TTR should be used with combination of vformat (e.g. vformat(TTR("%d times greater"), times)).
  • If the strings are being re-created every time they display, e.g. in context menus that are usually cleared on each popup, nothing more needs to be done.
  • For strings that don't update every time they are shown, NOTIFIACTION_TRANSLATION_CHANGED should be used. I don't think we are doing that already somewhere, so this needs to be established.

You can use the above guidelines to find code that needs to be updated, if it doesn't follow them. Alternatively you can open editor, change language and look for strings that didn't change (best tested with translations that have high completion percentage, as some texts won't translate otherwise). Feel free to open pull requests referencing this issue.

I'm opening this issue as a pseudo-tracker. I don't know every area that needs changes, but the issue is going to be open until there is no more strings that need updating.

Steps to reproduce

1. Open editor with non-English language
2. Change language
3. Look for text that still uses previous language

Minimal reproduction project (MRP)

N/A

[BrotherShort]

I tried to improve auto-translation code. I did not success. I made some mistakes. But I got some worthwhile questions.

What's our purpose?

Finish auto-translation.

How to achieve the purpose? How to modify the code?

It's easy to think of two ways we can do this.

See once, modify once.

Every time we see the text that can not be auto-translated, we change the text.

This way is cumbersome and unstable.

Create a set of rules, then modify the all code following rules.

This way is better. You came up 3 guidelines, but they are not enough.

For static translatable strings, Should we modify less or more?

The less means that we only modify the TTR function calls that blocking the auto-translation.

The more means that we not only modify the TTR calls blocking, but also modify the TTR function calls that whether the change is made or not does not affect the auto-translation.

If static translatable strings are being re-created every time they display, both TTR and TTRC are OK, should we change TTR to TTRC?

If a method uses static translatable strings at some places, and uses dynamic translatable strings at other places, what should we do?

Example code:

...
accept->set_text(TTR("No parent to instantiate a child at."));
...
accept->set_text(vformat(TTR("Error loading scene from %s"), p_files[i]));
...

For dynamic strings, we should use vformat and TTR following guidelines. For static strings, we should use TTRC following guidelines. But the vformat and TTR's presence indicates that TTR supports auto-translate here. So should we change TTR to TTRC for static strings?

If a dock uses NOTIFIACTION_TRANSLATION_CHANGED to update everything, should we use TTRC for the static translatable strings?

if a dock have dynamic strings that don't update every time they are shown, I would decide to use NOTIFIACTION_TRANSLATION_CHANGED to update everything, so dynamic strings would be updated. At the same, static strings would be updated too. Then should we change TTR to TTRC for static strings?

[KoBeWi]

If static translatable strings are being re-created every time they display, both TRR and TRRC are OK, should we change TRR to TRRC?

When a Control is subject to auto-translation, TTR will make it translated twice. First the TTR itself will translate the string, then the built-in auto-translation system will attempt to translate it (and fail, because the string was already modified). But this is more pedantic than anything; while technically double translation is more expensive, it won't have noticeable effect on performance. I'd prefer TTRC, but TTR is fine too.

But the vformat and TTR's presence indicates that TTR supports auto-translate here. So should we change TRR to TRRC for static strings?

Formatted strings need to use TTR. Auto-translation works on the final string, so if you use vformat(TTRC("Some string %d"), 1), the final string will be "Some string 1", which does not exist in the Translation file. Most dynamic strings are not "persistent" though. Persistent here means that if you change the language, you risk seeing the old translation of the string. Many context menus will update their items before opening, so they are not persistent; you can't see the dialog changing, because it's updated every time it appears. For cases that don't update automatically, you need to use NOTIFICATION_TRANSLATION_CHANGED and force updating the labels.

Then should we change TRR to TRRC for static strings?

See point 1. While it's not required, it will avoid double translation.

tbh this issue turned out a bit more tricky than I previously expected. While my original guidelines cover the general cases, there are many cases that require specific handling. You need to be aware of various translation system features to properly decide how to tweak the texts. You can use the pull requests listed above as a reference.