You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a user wants to split their Translation resources by topic or want to be able to access two Translations of the same locale, then they can use TranslationDomains. However, currently, they can only set a Node to use a specific domain through code, which may be inefficient for some workflows.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
If it is able to be set in the inspector, then that would save the user from having to do it in code since it would be accessible in the inspector.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
There is already _translation_domain, but that can't be used directly, of course. Therefore, if translation_domain is added, then it can be set whenever _translation_domain is changed and it would automatically be seen in the inspector.
If this enhancement will not be used often, can it be worked around with a few lines of script?
You can use _get_property_list for this, but it would be too complex for some workflows.
Is there a reason why this should be core and not an add-on in the asset library?
TranslationDomains were originally created for editor plugins to use, but I think it could be useful outside of there, too.
The text was updated successfully, but these errors were encountered:
Describe the project you are working on
I am using
Translation
s as a resource in my project.Describe the problem or limitation you are having in your project
This was inspired by godotengine/godot#99258.
If a user wants to split their
Translation
resources by topic or want to be able to access twoTranslation
s of the same locale, then they can useTranslationDomain
s. However, currently, they can only set aNode
to use a specific domain through code, which may be inefficient for some workflows.Describe the feature / enhancement and how it helps to overcome the problem or limitation
If it is able to be set in the inspector, then that would save the user from having to do it in code since it would be accessible in the inspector.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
There is already
_translation_domain
, but that can't be used directly, of course. Therefore, iftranslation_domain
is added, then it can be set whenever_translation_domain
is changed and it would automatically be seen in the inspector.If this enhancement will not be used often, can it be worked around with a few lines of script?
You can use
_get_property_list
for this, but it would be too complex for some workflows.Is there a reason why this should be core and not an add-on in the asset library?
TranslationDomain
s were originally created for editor plugins to use, but I think it could be useful outside of there, too.The text was updated successfully, but these errors were encountered: