Add-ons not translated to English #86405

New Issue

linkoid Polirend · 2021-03-08T20:15:41+01:00

linkoid Polirend commented

2021-03-08 20:15:41 +01:00

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 960M/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.55

Blender Version
Broken: version: 2.91.2, branch: master, commit date: 2021-01-19 16:15, hash: 5be9ef4177
Worked: version 2.82a

Short description of error
Non-English add-ons are not translated.

Details of issue
Due to the changes in commit 968619d03626c7e4d92d4cb383ac304b72595af3 in blt_translation.c.
Third-party add-ons that are not natively in English are no longer translated to English because
the translation function is skipped when the U.language == ULANGUAGE_ENGLISH.
968619d036 (diff-1c7accf2310d1192a8b63817067a46296db29258cf0837ef99ee2a87c841efe0L1127-R1127)

Exact steps for others to reproduce the error
Use a 3rd-party add-on that is not natively in English, while Blender's language is set to 'en_US' (not 'DEFAULT')

Additional Comments
This behavior does not seem intended, but if this behavior is preferred, then it should be made uniform
as this does not occur when the language is set to 'DEFAULT', even if the 'DEFAULT' is 'en_US'.
Additionally, if the assumption is that all add-ons should be written in English, then this should be
noted somewhere in the Add-on Wiki.
Either way, this behavior is inconsistent, undocumented, and rather confusing.

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce GTX 960M/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.55 **Blender Version** Broken: version: 2.91.2, branch: master, commit date: 2021-01-19 16:15, hash: `5be9ef4177` Worked: version 2.82a **Short description of error** Non-English add-ons are not translated. **Details of issue** Due to the changes in commit `968619d03626c7e4d92d4cb383ac304b72595af3` in `blt_translation.c`. Third-party add-ons that are not natively in English are no longer translated to English because the translation function is skipped when the `U.language == ULANGUAGE_ENGLISH`. https://github.com/blender/blender/commit/968619d03626c7e4d92d4cb383ac304b72595af3#diff-1c7accf2310d1192a8b63817067a46296db29258cf0837ef99ee2a87c841efe0L1127-R1127 **Exact steps for others to reproduce the error** Use a 3rd-party add-on that is not natively in English, while Blender's language is set to 'en_US' (not 'DEFAULT') **Additional Comments** This behavior does not seem intended, but if this behavior is preferred, then it should be made uniform as this does not occur when the language is set to 'DEFAULT', even if the 'DEFAULT' is 'en_US'. Additionally, if the assumption is that all add-ons should be written in English, then this should be noted somewhere in the Add-on Wiki. Either way, this behavior is inconsistent, undocumented, and rather confusing.

linkoid Polirend commented

2021-03-08 20:15:41 +01:00

Added subscriber: @linkoid-Polirend

Harley Acheson commented

2021-03-08 22:42:14 +01:00

Added subscriber: @Harley

Harley Acheson commented

2021-03-08 22:42:14 +01:00

Do you have an example of a non-English addon that was translated into English in prior versions? I just can't think of a mechanism that would allow that to occur.

linkoid Polirend commented

2021-03-09 17:52:29 +01:00

The attached file (F9881484) is an example add-on written in Japanese that translates itself to
English via bpy.app.translations.register(). Everything is in the add-on's preferences.
It translates generic text, properties, operators, and tool-tips. It also translates dynamic strings
using bpy.app.translations.pgettext_iface().

It works as expected in Blender 2.82 and doesn't do anything particularly strange to achieve this.
However, in Blender 2.91, translation simply does not occur when the language in
"Preferences > Interface > Translation" is set to "English (English)," which is the default value.

Add-on-ja_JP.py

The attached file ([F9881484](https://archive.blender.org/developer/F9881484/Add-on-ja_JP.py)) is an example add-on written in Japanese that translates itself to English via `bpy.app.translations.register()`. Everything is in the add-on's preferences. It translates generic text, properties, operators, and tool-tips. It also translates dynamic strings using `bpy.app.translations.pgettext_iface()`. It works as expected in Blender 2.82 and doesn't do anything particularly strange to achieve this. However, in Blender 2.91, translation simply does not occur when the language in "Preferences > Interface > Translation" is set to "English (English)," which is the default value. [Add-on-ja_JP.py](https://archive.blender.org/developer/F9881484/Add-on-ja_JP.py)

Harley Acheson commented

2021-03-09 18:42:53 +01:00

Sorry, but still a bit confused.

The only translations going on in that script are the ones contained in it. So it looks like if you are in any language except for English it will show strings in Japanese. So shows Japanese strings when the language is set to Spanish. And if you have English selected it will show those Japanese strings in English because it is adding those Japanese phrases as keys and the English as values.

But since this script needs to contain both sets of strings, why is it done this way? Why not use the English strings and then extend "ja_JP" instead? Then it would show in English for every language, except when the language is set to Japanese when it would show Japanese. Or am I missing something?

Sorry, but still a bit confused. The only translations going on in that script are the ones contained in it. So it looks like if you are in any language except for English it will show strings in Japanese. So shows Japanese strings when the language is set to Spanish. And if you have English selected it will show those Japanese strings in English because it is adding those Japanese phrases as keys and the English as values. But since this script needs to contain both sets of strings, why is it done this way? Why not use the English strings and then extend "ja_JP" instead? Then it would show in English for every language, except when the language is set to Japanese when it would show Japanese. Or am I missing something?

linkoid Polirend commented

2021-03-09 19:28:46 +01:00

I suppose that for native English speakers that would not be a problem.
However, that solution is not ideal for an add-in maintained by developers who speak a foreign language.

As an individual translating an add-on maintained by Japanese developers, the idea of rewriting and then
maintaining the project in a foreign language is not appealing to them, especially when this was not a problem
prior to Blender 2.83. There is also nothing I could find that suggests all add-ons must be maintained in English.

I'm not asking for a solution that I can use within these foreign add-ons; I'm merely reporting a change in behavior,
where I believe a change in behavior was un-intended as it is undocumented and enforces something that
is not publicly enforced (that all add-ons be written in English). I'll have to come up with a workaround for this
anyways since it is already in a published version of Blender.

The reason this no longer works is when use_international_fonts was removed, BLT_translate() was changed
such that instead of checking if U.transopts & USER_DOTRANSLATE,
it now checks if U.language != ULANGUAGE_ENGLISH.
A side-effect of this (that I believe to be un-intended) is that foreign add-ins must be written in English,
as this change prevents them from being translated to English.

The commit where this change occurred:
968619d036 (diff-94f148fd9611efaa1cd069117fa75654fb84e4ac7dc8afb6ea828f9a1505a138L84-R84)

Thank you for taking your time to try and understand this matter.

I suppose that for native English speakers that would not be a problem. However, that solution is not ideal for an add-in maintained by developers who speak a foreign language. As an individual translating an add-on maintained by Japanese developers, the idea of rewriting and then maintaining the project in a foreign language is not appealing to them, especially when this was not a problem prior to Blender 2.83. There is also nothing I could find that suggests all add-ons must be maintained in English. I'm not asking for a solution that I can use within these foreign add-ons; I'm merely reporting a change in behavior, where I believe a change in behavior was un-intended as it is undocumented and enforces something that is not publicly enforced (that all add-ons be written in English). I'll have to come up with a workaround for this anyways since it is already in a published version of Blender. The reason this no longer works is when `use_international_fonts` was removed, `BLT_translate()` was changed such that instead of checking if `U.transopts & USER_DOTRANSLATE`, it now checks if `U.language != ULANGUAGE_ENGLISH`. A side-effect of this (that I believe to be un-intended) is that foreign add-ins must be written in English, as this change prevents them from being translated to English. The commit where this change occurred: https://github.com/blender/blender/commit/968619d03626c7e4d92d4cb383ac304b72595af3#diff-94f148fd9611efaa1cd069117fa75654fb84e4ac7dc8afb6ea828f9a1505a138L84-R84 Thank you for taking your time to try and understand this matter.

Harley Acheson commented

2021-03-09 20:18:51 +01:00

Added subscribers: @mont29, @brecht

Harley Acheson commented

2021-03-09 20:18:51 +01:00

@linkoid-Polirend - not ideal for an add-in maintained by developers...translating an add-on maintained by Japanese developers...

Ah. So the difference here is really about one person writing an addon in a non-English language that is then translated by a different person? I can certainly see it would be easier to extend 'en_US' in one place as shown in that example, rather than replace all the strings in place.

Although this still gives the less-than-ideal result that people set to Spanish or Italian will see the Japanese strings, while all other strings that are not properly translated for those languages would be in English. Although that might be fixed by changing that hard-coded 'en_US' to the user's currently-selected locale instead?

Wouldn't this solution also require that English users select "English" rather than "Automatic"? Just a bit unclear what you mean by "as this does not occur when the language is set to 'DEFAULT', even if the 'DEFAULT' is 'en_US'."

The reason this no longer works is when use_international_fonts was removed...

Yes, it used to be that we shipped with a large font containing most of the worlds characters, but only used it when English was not selected. Now we use that font all the time.

BLT_translate() was changed such that...The commit where this change occurred...

Yes, I know - that was me. LOL.

I'm merely reporting a change in behavior, where I believe a change in behavior was un-intended

Yes, and I can't think of a nice solution to be honest. It would be a bit odd to send everything though the translation system, even if English is selected. To keep the "Tooltip", "Interface", and "New Data" checkboxes enabled, yet they would have no effect in almost every case except for this one, which would be quite confusing. But might be okay to leave those disabled.

Interesting. I wonder if @brecht or @mont29 have any thoughts.

> @linkoid-Polirend - not ideal for an add-in maintained by developers...translating an add-on maintained by Japanese developers... Ah. So the difference here is really about one person writing an addon in a non-English language that is then translated by a different person? I can certainly see it would be easier to extend 'en_US' in one place as shown in that example, rather than replace all the strings in place. Although this still gives the less-than-ideal result that people set to Spanish or Italian will see the Japanese strings, while all other strings that are not properly translated for those languages would be in English. Although that might be fixed by changing that hard-coded 'en_US' to the user's currently-selected locale instead? Wouldn't this solution also require that English users select "English" rather than "Automatic"? Just a bit unclear what you mean by "as this does not occur when the language is set to 'DEFAULT', even if the 'DEFAULT' is 'en_US'." > The reason this no longer works is when `use_international_fonts` was removed... Yes, it used to be that we shipped with a large font containing most of the worlds characters, but only used it when English was not selected. Now we use that font all the time. > `BLT_translate()` was changed such that...The commit where this change occurred... Yes, I know - that was me. LOL. > I'm merely reporting a change in behavior, where I believe a change in behavior was un-intended Yes, and I can't think of a nice solution to be honest. It would be a bit odd to send everything though the translation system, even if English is selected. To keep the "Tooltip", "Interface", and "New Data" checkboxes enabled, yet they would have no effect in almost every case except for this one, which would be quite confusing. But might be okay to leave those disabled. Interesting. I wonder if @brecht or @mont29 have any thoughts.

linkoid Polirend commented

2021-03-09 20:48:15 +01:00

Although that might be fixed by changing that hard-coded 'en_US' to the user's currently-selected locale instead?

That is probably a good idea, I'll probably end up doing that for other latin-like languages
until they are translated as well. Thanks for the suggestion.

...as this does not occur when the language is set to 'DEFAULT', even if the 'DEFAULT' is 'en_US'

What I meant is if the language is set to "Automatic" ('DEFAULT' in python) then
BLT_translate() will return true because 'DEFAULT' != 'en_US'. I saw this as an oversight and was
hesitant to use it as a workaround lest it is fixed in a future version. That workaround would also create
problems for users whose operating systems are not in English yet prefer using Blender in English.

Thanks again for your contributions toward making Blender accessible to more people all over the world.

> Although that might be fixed by changing that hard-coded 'en_US' to the user's currently-selected locale instead? That is probably a good idea, I'll probably end up doing that for other latin-like languages until they are translated as well. Thanks for the suggestion. > ...as this does not occur when the language is set to 'DEFAULT', even if the 'DEFAULT' is 'en_US' What I meant is if the language is set to "Automatic" (`'DEFAULT'` in python) then `BLT_translate()` will return true because `'DEFAULT' != 'en_US'`. I saw this as an oversight and was hesitant to use it as a workaround lest it is fixed in a future version. That workaround would also create problems for users whose operating systems are not in English yet prefer using Blender in English. Thanks again for your contributions toward making Blender accessible to more people all over the world.

Bastien Montagne commented

2021-03-10 12:33:14 +01:00

IMHO for sake of sanity we should just have a DISABLED option here (either as an enum entry, or a separate bool flag), and actually use proper translation mechanism for any valid local (either set by user or taken from OS settings), including en_US.

When DISABLED is set, if an add-on is in Japanese, I would expect to get in in that language yes.

Generally speaking, writing extensions for Blender in English as primary language is a good idea, but we obviously cannot enforce that on third party add-ons.

IMHO for sake of sanity we should just have a `DISABLED` option here (either as an enum entry, or a separate bool flag), and actually use proper translation mechanism for any valid local (either set by user or taken from OS settings), including `en_US`. When `DISABLED` is set, if an add-on is in Japanese, I would expect to get in in that language yes. Generally speaking, writing extensions for Blender in English as primary language is a good idea, but we obviously cannot enforce that on third party add-ons.

Brecht Van Lommel commented

2021-03-10 14:01:22 +01:00

What would be the purpose of a DISABLED option? Seems like something for developers, I'm not sure why users would choose that.

From the user point of view, I think the correct behavior is to show text in the chosen language if available, and if not show English. And that doesn't properly work in either 2.83 or master.

I guess the proper solution would be to add an argument to bpy.app.translations.register specifying a source language or default language, but I don't know how practical that is.

I also think it's pretty reasonable to document that the source language is expected to be English. It's not that strange to me to recommend add-ons to follow the same implementation conventions as the rest of the Blender UI they are integrating with.

What would be the purpose of a `DISABLED` option? Seems like something for developers, I'm not sure why users would choose that. From the user point of view, I think the correct behavior is to show text in the chosen language if available, and if not show English. And that doesn't properly work in either 2.83 or master. I guess the proper solution would be to add an argument to `bpy.app.translations.register` specifying a source language or default language, but I don't know how practical that is. I also think it's pretty reasonable to document that the source language is expected to be English. It's not that strange to me to recommend add-ons to follow the same implementation conventions as the rest of the Blender UI they are integrating with.

Bastien Montagne commented

2021-03-10 14:14:53 +01:00

DISABLED would disable UI translation.

Otherwise, we would always use translation mechanism, even when en_US is the selected locale.

That would not prevent different languages in the UI though, when a translation is missing code can't do anything but show the original messages.

Agree about documenting expected default language for add-ons.

`DISABLED` would disable UI translation. Otherwise, we would **always** use translation mechanism, even when `en_US` is the selected locale. That would not prevent different languages in the UI though, when a translation is missing code can't do anything but show the original messages. Agree about documenting expected default language for add-ons.

Brecht Van Lommel commented

2021-03-10 15:37:34 +01:00

I think it's fine to always use translation even when en_US is selected, if that's what is needed to make things behave as users expect?

If performance is an issue I guess it could still skip it if there are no add-ons that need it.

I think it's fine to always use translation even when `en_US` is selected, if that's what is needed to make things behave as users expect? If performance is an issue I guess it could still skip it if there are no add-ons that need it.

Harley Acheson commented

2021-03-11 17:37:28 +01:00

@brecht If performance is an issue

I'm assuming that performance wouldn't be an issue, since we don't have complaints from users running Blender in English, and not their native language, because it was faster or more responsive.

But...

From my (very possibly wrong) understanding of this particular usage, it looks like this is an addition or replacement of the 'en_US' translation dictionary, not an extension. So a user could only have one addon installed at a time that uses this technique. Am I correct here @linkoid-Polirend ?

I can imagine that there might be some cool uses for addons being able to extend those dictionaries, but if that is not the case then this feature could be problematic. I write an addon using the same techniques that I see here, but it does not appear to work - because this one is also installed. That sounds like a worse thing to document than just "write the addon in English".

> @brecht If performance is an issue I'm *assuming* that performance wouldn't be an issue, since we don't have complaints from users running Blender in English, and not their native language, because it was faster or more responsive. But... From my (very possibly wrong) understanding of this particular usage, it looks like this is an **addition or replacement** of the 'en_US' translation dictionary, not an *extension*. So a user could only have one addon installed at a time that uses this technique. Am I correct here @linkoid-Polirend ? I can imagine that there might be some cool uses for addons being able to extend those dictionaries, but if that is not the case then this feature could be problematic. I write an addon using the same techniques that I see here, but it does not appear to work - because this one is also installed. That sounds like a worse thing to document than just "write the addon in English".

linkoid Polirend commented

2021-03-11 22:43:40 +01:00

The translation dictionary is registered using bpy.app.translations.register(__name__, translations_dict), the same way any other third-party add-on would register translations for any other language. Therefore, I'm assuming that it is in fact an extension and not a replacement based on the documentation which states:

If a message is already present in main Blender translation, it won’t be added to the addon’s ones

The only abnormal part about what I'm doing API-wise is this:

def register():
    # ...

    # Work around for disabled translations when language is 'en_US'
    if bpy.app.version >= (2, 83, 0) and bpy.app.version <= (2, 91, 2): # might be fixed in some future release
        preferences_view = bpy.context.preferences.view
        if preferences_view.language == 'en_US':
            preferences_view.language = 'DEFAULT'
            - This hack is required because when language is changed to 'DEFAULT'
            - all the options will be set to false next time Blender updates
            def _set():
                preferences_view.use_translate_tooltips     = True
                preferences_view.use_translate_interface    = True
                preferences_view.use_translate_new_dataname = True
            bpy.app.timers.register(_set, first_interval=0)
    
    # ...

from:
Add-on-ja_JP-2.py
But that's just a work-around for the issue itself. Otherwise, I'm just using the API completely normally. It just so happens that one of the keys in the translations_dict happens to be 'en_US', which is accepted just fine by the API, and works as expected until Blender 2.83.

The translation dictionary is registered using `bpy.app.translations.register(__name__, translations_dict)`, the same way any other third-party add-on would register translations for any other language. Therefore, I'm assuming that it is in fact an **extension** and not a *replacement* based on the [documentation](https://wiki.blender.org/wiki/Process/Translate_Blender#Translating_non-official_addons) which states: > If a message is already present in main Blender translation, it won’t be added to the addon’s ones The only abnormal part about what I'm doing API-wise is this: ``` def register(): # ... # Work around for disabled translations when language is 'en_US' if bpy.app.version >= (2, 83, 0) and bpy.app.version <= (2, 91, 2): # might be fixed in some future release preferences_view = bpy.context.preferences.view if preferences_view.language == 'en_US': preferences_view.language = 'DEFAULT' - This hack is required because when language is changed to 'DEFAULT' - all the options will be set to false next time Blender updates def _set(): preferences_view.use_translate_tooltips = True preferences_view.use_translate_interface = True preferences_view.use_translate_new_dataname = True bpy.app.timers.register(_set, first_interval=0) # ... ``` from: [Add-on-ja_JP-2.py](https://archive.blender.org/developer/F9885650/Add-on-ja_JP-2.py) But that's just a work-around for the issue itself. Otherwise, I'm just using the API completely normally. It just so happens that one of the keys in the `translations_dict` happens to be 'en_US', which is accepted just fine by the API, and works as expected until Blender 2.83.

Harley Acheson commented

2021-03-11 23:25:15 +01:00

@linkoid-Polirend - it is in fact an extension and not a replacement based on the documentation...

Oh, well that is a good sign! That would be a great reason to enable translations always. And it would have some nice symmetry. We'd be showing almost all the world's glyphs no matter what language selected, allowing IME input no matter the displayed language, and also allowing translation no matter the language.

Sorry, but I am being completely let down by my own lack of understanding of python and our addons. I realize that your script is meant demonstrate something obvious, but I am unable to see its effect and therefore compare old and new behavior. Can you assume I am really dumb and walk me through what it is meant to show me?

> @linkoid-Polirend - it is in fact an **extension** and not a *replacement* based on the [documentation](https://wiki.blender.org/wiki/Process/Translate_Blender#Translating_non-official_addons)... Oh, well that is a good sign! That would be a great reason to enable translations always. And it would have some nice symmetry. We'd be showing almost all the world's glyphs no matter what language selected, allowing IME input no matter the displayed language, and also allowing translation no matter the language. Sorry, but I am being completely let down by my own lack of understanding of python and our addons. I realize that your script is meant demonstrate something obvious, but I am unable to see its effect and therefore compare old and new behavior. Can you assume I am really dumb and walk me through what it is meant to show me?

linkoid Polirend commented

2021-03-14 01:37:48 +01:00

I am unable to see its effect and therefore compare old and new behavior.

That would be because in this one they merely appear to operate the same.

The # Work around for disabled translations when language is 'en_US' section detects if the blender version is 2.83 or above
and if it is then it changes the user's language preferences (for the entirety of Blender) from 'en_US' to 'DEFAULT', and since translation is only disabled when the language is
'en_US' ('DEFAULT' doesn't count), it will cause BL_TRANSLATE() (on the C side) to return true whenever Blender checks if it should do a translation. But then the next time Blender updates (which happens outside the scope of python), since 'DEFAULT' is set, I suppose something in C checks what the default language of the operating system is, realizes that it's English, and then sets use_translate_interface, use_translate_tooltips, and use_translate_new_dataname to false. But that happens after the addon is registered, outside of python's control. So to work around that I had to register a function that the C side of Blender would execute after a set amount of time using bpy.app.timers.register(). In this function, I set the three aforementioned settings to true.

All that will only happen if Blender is 2.83 or above though because it works fine in earlier versions. It wasn't exactly obvious what was happening. It was more to present
the absurdity that I had to go through to trick Blender into getting it to work. It abuses the Blender API like a middle school bully to do it, but it does it. Who knows what kind of issues that would cause though down the road. Add-ons changing user's preferences that affect all of Blender is kinda taboo itself, let alone fighting over them with the C API.

> I am unable to see its effect and therefore compare old and new behavior. That would be because in this one they merely appear to operate the same. The `# Work around for disabled translations when language is 'en_US'` section detects if the blender version is 2.83 or above and if it is then it changes the user's language preferences (for the entirety of Blender) from 'en_US' to 'DEFAULT', and since translation is only disabled when the language is 'en_US' ('DEFAULT' doesn't count), it will cause `BL_TRANSLATE()` (on the C side) to return `true` whenever Blender checks if it should do a translation. But then the next time Blender updates (which happens outside the scope of python), since 'DEFAULT' is set, I suppose something in C checks what the default language of the operating system is, realizes that it's English, and then sets `use_translate_interface`, `use_translate_tooltips`, and `use_translate_new_dataname` to `false`. But that happens after the addon is registered, outside of python's control. So to work around that I had to register a function that the C side of Blender would execute after a set amount of time using `bpy.app.timers.register()`. In this function, I set the three aforementioned settings to `true`. All that will only happen if Blender is 2.83 or above though because it works fine in earlier versions. It wasn't exactly obvious what was happening. It was more to present the absurdity that I had to go through to trick Blender into getting it to work. It abuses the Blender API like a middle school bully to do it, but it does it. Who knows what kind of issues that would cause though down the road. Add-ons changing user's preferences that affect all of Blender is kinda taboo itself, let alone fighting over them with the C API.

blender-admin commented

2021-03-22 11:48:31 +01:00

This issue was referenced by 7a05ebf84b

This issue was referenced by 7a05ebf84b35cb9af0f6618db489204f2adc3c60

Bastien Montagne commented

2021-03-22 11:50:31 +01:00

Changed status from 'Needs Triage' to: 'Resolved'

Bastien Montagne closed this issue

2021-03-22 11:50:31 +01:00

Bastien Montagne self-assigned this 2021-03-22 11:50:31 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Add-ons not translated to English #86405