Simplify TranslationDomain Workflow

[MrJustreborn]

This PR introduces the ability to configure translation_domains in the project settings and assign a translation_domain per Node.

This is useful in scenarios where, for example, a player may prefer different languages for subtitles and voice-over. It simplifies the localization workflow for developers.

You can define translation domains in the Project Settings:

And assign a custom translation domain per Node:

All child nodes will inherit the same translation domain, unless explicitly overridden.

For instance, if you want to use English voice-over with German subtitles, you can set the main language to English and override the subtitles domain to use German.

The changes are split across multiple commits for easier review.

Closes: godotengine/godot-proposals#11610
Closes: godotengine/godot-proposals#6254

[MrJustreborn]

Rebased on master to resolve conflict

[MrJustreborn]

A small test-project to show this setup:
https://github.com/MrJustreborn/godot_langdomain_test

[timothyqiu]

Hi, thanks for your work. There are several changes in this PR:

Adding the is_translation_domain_inherited() method

This is good and completes the API.

Exposing TranslationDomain.get_loaded_locales()

This completes the API, but it's not related to this PR.

Make calling TranslationServer.add_translation() add the translation to all known domains

No, you should not do that.

TranslationServer methods like this are proxies for the main domain plus potential scene tree operations.

Adding the translation_custom_domain property

The current implementation confuses the translation domain name being empty (i.e., the main translation domain) and the translation domain inherting from the parent node. Therefore, it's impossible to change a node to use the main domain via this property if it's a child of a node that uses a non-main domain. I think an extra editor-only boolean property is needed to toggle inheritance.

But in the end, translation domains are meant to be used by external content, such as custom plugins and game mods. The main game should almost always use the main translation domain.

• Developers of the main game don't know about plugins beforehand, so they won't know what to add in the Project Settings.
• Translation domains are meant to be set at runtime. Plugin authors still design their UI in the main translation domain so that their translations can be previewed like regular scenes. The translation domain is set before registering the UI node with the main game (or Godot Editor).

Making a configurable list of translation domains and adding a property in the inspector give users the false impression that they should make use of translation domains. But it's not true, translation domains are not for regular users.

I'm not against using translation domains for other purposes. It's very smart. However, I believe that we should not start making UX improvements for these uses until there is a significant demand and we rethink whether translation domains should be used to solve the problem in question.

This is useful in scenarios where, for example, a player may prefer different languages for subtitles and voice-over. It simplifies the localization workflow for developers.

I'm afraid there might be a misunderstanding. Your problem won't be solved by translation domains.

Resource remapping is global. It's unaffected by translation domains and always uses TranslationServer.get_locale().

You might be tempted to use the main translation domain for voice-over and repurpose a custom translation domain as the main translation domain. However, the engine has not considered this usage, which may lead to other bugs.

Resolved

[MrJustreborn]

Make calling TranslationServer.add_translation() add the translation to all known domains
No, you should not do that.
TranslationServer methods like this are proxies for the main domain plus potential scene tree operations.

So it would be better added in the void TranslationServer::load_translations() method instead of add_translation. Maybe also add a checkbox like prefill domains with translation or something like that.

The current implementation confuses the translation domain name being empty (i.e., the main translation domain) and > the translation domain inherting from the parent node. Therefore, it's impossible to change a node to use the main > domain via this property if it's a child of a node that uses a non-main domain. I think an extra editor-only boolean property is needed to toggle inheritance.

Yes, I didn't think of a scenario on which a child node should use the main domain if the parent has a custom one. But with a toggle, you have to go through every child node, it should be default to inherit the domain from the parent. But a force_main_domain toggle could also be misleading.

Developers of the main game don't know about plugins beforehand, so they won't know what to add in the Project Settings.

And they don't need to, plugins can still add there own domains.

I'm afraid there might be a misunderstanding. Your problem won't be solved by translation domains.
Resource remapping is global. It's unaffected by translation domains and always uses TranslationServer.get_locale().

While treating the main domain as the asses domain for voice etc, it'll work. But yes the ResourceLoader is not aware of any translation domain. I had a look into it but came to the conclusion, that it's nearly impossible without rewriting the whole scene loading logic.

I'm not against using translation domains for other purposes. It's very smart. However, I believe that we should not start > making UX improvements for these uses until there is a significant demand and we rethink whether translation domains should be used to solve the problem in question.

Understandable, technical everything can currently be done in code without any new UI, it just makes it simpler. Having different translation for eg voice and subtiles is something I use very often in games and want to support such a feature in mine too.