Page MenuHome

Translated text NOT display
Open, Confirmed, MediumPublic

Description

System Information
Operating system:
Linux, Kernel: 4.15.0-20-generic x86_64 bits: 64 compiler: gcc v: 7.3.0 Desktop: Cinnamon 4.0.8
Distro: Linux Mint 19.1 Tessa base: Ubuntu 18.04 bionic

Graphics card:
Device-1: Intel 4th Gen Core Processor Integrated Graphics vendor: Hewlett-Packard driver: i915 v: kernel
Device-2: NVIDIA GK208M [GeForce GT 740M] vendor: Hewlett-Packard driver: nouveau v: kernel bus ID: 01:00.0
Display: x11 server: X.Org 1.19.6 driver: modesetting,nouveau unloaded: fbdev,vesa
resolution: 1920x1080~60Hz, 1920x1080~60Hz
OpenGL: renderer: Mesa DRI Intel Haswell Mobile v: 4.5 Mesa 18.0.5 direct render: Yes

Blender Version
Blender 2.80 (sub 75)
build date: 2019-07-29
build time: 17:17:04
build commit date: 2019-07-29
build commit time: 14:47
build hash: f6cb5f54494e
build platform: Linux
build type: Release

Short description of error
During the process of translating vi.po today, I stumbled upon this incident where the text resembled what is on display at this screen:

I was unable to capture the 'tooltips'

and the image of translated text is here:

and when turning to Vietnamese, I discovered the translated text is NOT visible, so I went through and examined the rest of tooltips and recorded the session:

the next instance is this translated text:

The only thing I could spot is the 'full stop' punctuation at the end of the text on the screen vs the text in the PO file, but even after inserted the full stop (.) and recompiled the PO to MO file, I was unable to see the translated text. I felt completely helpless here, don't know what's going on.

Here is my blender.mo for the Vietnamese

Please drop it into the following directory:
2.80/datafiles/locale/vi/LC_MESSAGES

Details

Type
Bug

Event Timeline

Bastien Montagne (mont29) lowered the priority of this task from Waiting for Developer to Reproduce to Confirmed, Medium.

Nearly all new UI code (new panels, tools stuff, etc.) was not doing any translations. At all. Even worse, it has not been designed thinking about it, which means we sometimes have to make very twisty stuff to get it partially working, and sometimes there is just no proper solution currently.

Have already fixed a lot of those issues recently, but looks like that one is using yet another code path, grrrrr.....

OK, so i'm tired of hacking things around here, think it's time to do what should have been done from the start: add proper support for i18n to the tools system.

IMHO, the way to go here would be to add two callbacks to ToolDef, e.g ui_label() and ui_description(), that would roughly do what description_from_id() is currently doing... ToolDef being a named tuple though, it can only have 'static' functions I think, like the from_fn and from_dict ones?

@Campbell Barton (campbellbarton) assigning to you to get your input here, am fine implementing whatever we come up with, but you are the original designer of the whole system, so better you chime in first.

My little observation (probably redundant) is that translated text needed to go to 'pgettext_tip' (renamed as 'tip_' on import)

as found in this example, which is working (at the moment):

So properties of 'wmOperatorType' instance (ie. ot->description) must be output to GUI using 'pgettext_tip':

That’s more a UI code design issue than a Translations one really…