Add translation domain

[timothyqiu]

Describe the project you are working on

Inspecting editor translation proposals like #6885 and #1262

Describe the problem or limitation you are having in your project

The current proposal solution (godotengine/godot#77104) still has the problem that translations from different plugins interfering with each other.

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

Add "domain" concept to TranslationServer.

Different components use different domains. So the translations won't interfere with each other.

We already have similar hardcoded concept of tool translation, doc translation, property translation, etc.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Default domain is empty &"".

Related methods in TranslationServer receive a new domain: StringName parameter. For example:

add_translation(translation: Translation, domain := &"") -> void
remove_translation(translation: Translation, domain := &"") -> void
translate(message: StringName, context := &"", domain := &"") -> StringName

Keep Object.tr() function the same. But add virtual methods to control the domain it uses:

get_translation_domain() -> StringName
set_translation_domain(domain: StringName) -> void

Node overrides these two methods. By default, nodes use the same domain as their parent, or the default domain when it has no parent.

func get_translation_domain() -> StringName:
    if translation_domain_override is not null:
        return translation_domain_override
    if parent:
        return parent.get_translation_domain()
    return &""  # default domain

An addon use TranslationServer.add_translation(translation, "com.example.my_addon") to add translations.

• If it adds a new dialog to the editor, it sets translation_domain_override on the dialog node to com.example.my_addon.
• If it adds a new menu entry to some editor menu:
  • Use TranslationServer.translate("My Menu Item", "", "com.example.my_addon")
  • Or call set_translation_domain("com.example.my_addon") on the plugin script, and use tr("My Menu Item").

Editor translations (tool, property, doc, etc) can also be changed to use different translation domains instead of using hardcoded methods. Domains editor uses are well-known. Addons should generally avoid modifying these domains. But it's not forbidden in case addons want to do some customization.

If this enhancement will not be used often, can it be worked around with a few lines of script?

No API to implement this behavior.

Is there a reason why this should be core and not an add-on in the asset library?

It's a core feature.

[RedMser]

Would it not be possible to use translation context for this, instead of a new domain concept? Context could simply be a concatenated string consisting of the domain + [tool/doc/prop] + other custom context defined by the user.

[timothyqiu]

Context is used to remove possible ambiguities in the source language. For example, there can be Mail and Character contexts for the message Letter. It will be extracted by POT generator and read by translators.

And the node auto translation mechanism does not support context.

Sure, you can technically implement domain by concatenating strings as context. But that grows the overall memory / disk usage.