Page MenuHome

Translation failure bug of menu registered with Quick Favorites
Confirmed, LowPublicBUG


System Information
Operating system: Windows 10 Home 64-bit (10.0, Build 17763)
Graphics card: Intel(R) UHD Graphics 630

Blender Version
Broken: version: 2.80 (sub 74), branch: master, commit date: 2019-06-26 19:03, hash: 155c62d070a9
Worked: (optional)

Short description of error
If you register the Quick Favorites menu with ranslation enabled, it will appear as □□□ when you turn off translation and it will not be readable.

-Japanese (automatic), verified in Arabic
-In case of multiple languages, there is no problem because they are not translated

Exact steps for others to reproduce the error

  1. Preferences → Interface → Enable "Translation" , and register Quick Favorites menu in another language condition
  2. Disable Translation and switch language
  3. The language registered with Quick Favorites is not translated, displayed as □□□, and can not be read

Event Timeline

Sebastian Parborg (zeddb) lowered the priority of this task from 90 to Low.

I guess we don't currently refresh the text strings in the quick fav menu.

That’s not really for me, guess the task is for @Campbell Barton (campbellbarton). Issue being, in many cases this menu just stores the final draw string as entry name, this is doomed to fail when using/switching between UI translations.

The boxes reported by @Bookyakuno (Bookyakuno) are merely because by fully disabling translation, he reverts to the basic ASCII font we use in Blender, which does not have all the complex scripts like Japanese/Chinese/Arabic/etc. That issue is same with e.g. data names and so on, not really a bug, just a known limitation of current system.

@Bastien Montagne (mont29), to solve this, I think we would need a way to request the untranslated string from a button, and it's translation context, then store this in the quick-favorites menu.

Given how the UI works - translations happen at different levels (when getting enums, the text argument from Python... etc),
I don't think this is practical, eg: menu would need to redraw without translations.

An alternative could be to have a reverse lookup on translations, and store this.

Note, once we have a menu editor this may not be so important since users can customize the names themselves.

Brecht Van Lommel (brecht) changed the subtype of this task from "Report" to "Bug".Feb 11 2020, 6:02 PM

If we do D3705: Translation: always enable Use International Fonts, default to English., at least the text will be displayed correctly even if it won't be all in the same language. That may be considered a sufficient solution.