Add translation domain

[timothyqiu]

• Closes Add translation domain godot-proposals#9501
• Closes Allow editor plugins to add translations and modify project settings when enabled/disabled godot-proposals#1262
• Closes Allow to add translations for user editor plugins godot-proposals#6885
• Supersedes Add custom methods for adding editor translations #77104
• Supersedes i18n: Expose editor's translation via EditorInterface. #82158

This PR is separated into 3 commits to make it easier to review.

1. Add TranslationDomain

l10n features like add_translation() and translate() are all moved from TranslationServer into the new TranslationDomain class.

Users can add/remove custom translation domains with get_or_add_domain()/remove_domain(). It's "get or add" because getting a null TranslationDomain is practically never desired.

Existing TranslationServer methods are kept as wrappers around the main translation domain.

2. Allow configuring which translation domain Object.tr() uses

This adds {get,set}_translation_domain() virtual methods on Object. It's by default a simple getter/setter, only affects later tr() calls on that object.

For a Node, its translation domain is inherited from the parent node by default. Once set_translation_domain() is called, the node's translation domain is fixed (calling set_translation_domain_inherited() makes it parent-dependent again).

3. Make editor use translation domains

The components from Weblate are all translation domains now: godot.editor, godot.properties, and godot.documentation. Note that tool translations and extractable translations are loaded into the same godot.editor domain.

EditorNode and ProjectManager are set to use the godot.editor translation domain. Nodes in the current edited scene don't do translation, so translation domains do not matter.

Nodes like EditorFileDialog should automatically fix their translation domain to godot.editor so they have the right translation when used by plugins.

How editor plugins do l10n

1. Pick a unique translation domain name, e.g., com.example.my-plugin-name.
2. Plugin _enter_tree(): load translations into that translation domain.
3. Call set_translation_domain("com.example.my-plugin-name") on its root UI node.
4. Plugin _exit_tree(): remove that translation domain.

Sample dock panel plugin to demonstrate the usage: test-4.zip

[KoBeWi]

I'm confused on how to add translations for plugins. E.g. I have a plugin with custom strings that need to be translated, but it also has a file dialog. When I set a domain for the plugin, the dialog will lose translations. I have to either set a domain for every node, or modify an existing domain. The first option sounds rather cumbersome, the latter has the conflict problem this PR tries to fix.

Also, for whatever reason, when adding translation to godot.editor domain, the plugin will not be translated on launch. It needs to be disabled and enabled.

[Mickeon]

I am to assume it works like this

Suggested change

	Returns the name of the translation domain used by [method tr] and [method tr_n]. See also [TranslationServer].
	Returns the name of the translation domain used by [method tr] and [method tr_n], as registered on the [TranslationServer]. See also [TranslationDomain].

[timothyqiu]

I think this creates an ambiguity: what is registered on the TranslationServer?

• "which translation domain this object uses" is registered
  • It's not registered on the translation server.
• "the name of a translation domain" is registered
  • It's technically not required that a translation domain with the specified name exists.

[timothyqiu]

@KoBeWi I made a sample dock panel plugin to demonstrate the usage: test-4.zip

The plugin has zh_CN and ja translations.

I only partially translated FileDialog strings. Uncomment the set_translation_domain() line in the script to make the file dialog use editor translation.

[KoBeWi]

Uncomment the set_translation_domain() line in the script to make the file dialog use editor translation.

It would be more convenient if editor translation was a fallback.

[timothyqiu]

It would be more convenient if editor translation was a fallback.

Plugins should use EditorFileDialog instead as it uses editor translation by default. The FileDialog in the example serves as a comparison.

Currently, all plugin translations fall back to editor translations. It's also technically not hard to add fallback domain support for a TranslationDomain. But I think this falls into the category of sacrificing correctness for temporary convenience.

• Editor translation is created for the editor itself. Strings are added and removed (and even change meaning) based on how the editor needs them to be. Falling back to editor translation creates an assumption that the editor does provide the strings the plugin needs. It's the similar reason why we don't automatically fallback missing Godot editor translations to Blender editor translations :P Although there may be a correlation in content, they are two different domains.
• Falling back could easily make the plugin partially translated, which is usually not desired.
• Authors have to deliberately exclude strings found in editor translation in order to not translating them. But why? This takes much more effort than including extractable strings in the POT.

[KoBeWi]

Plugins should use EditorFileDialog instead as it uses editor translation by default.

Unfortunately EditorFileDialog is not easily available. Most people don't even know that you can use it. Though I guess it's a separate issue.

[akien-mga]

We should probably do the same for EditorSpinSlider?
I didn't check if it has translatable strings but I assume maybe some tooltips at least.

[timothyqiu]

EditorSpinSlider currently does not use auto translation. Text translations, including tooltip translations, are done via TTR macros (always use the godot.editor domain).

[akien-mga]

I read through the proposals and the PR discussion, it makes sense to me.

I haven't checked the implementation in depth nor tested but overall the exposed API seems pretty good.

[akien-mga]

Thanks! Great work 🎉