'Editor Settings','Project Settings','Property Name' display translation

[magian1127]

(English from Google Translate)

'Editor Settings','Project Settings','Property Name' display translation
.po add msg

'set_tooltip' is added to show the original text

把原来没翻译的地方,让其可以翻译.
添加了几个set_tooltip,用来显示英文原文
编辑器设置中添加了'property_name_translation'属性,用来开启是否翻译这些英文
extract.py现在可以提取 _initial_set 和 GLOBAL_DEF 的文本了
3.2 #45383

[Calinou]

TTR() shouldn't be used with variable names as there will be no way for the PO file generation script to pick up strings to generate. TTR() should only contain string literals, optionally using vformat() to replace placeholders.

[Calinou]

Also, it's debated whether property names should be translated as it will make it more difficult for newcomers to find which properties to edit when reading tutorials.

[magian1127]

Also, it's debated whether property names should be translated as it will make it more difficult for newcomers to find which properties to edit when reading tutorials.

Add a switch to solve the problem
// Editor
_initial_set("interface/editor/property_name_translation", false);

[magian1127]

I edit extract.py
all text can be extracted

[akien-mga]

I think this is a useful feature that we should support to be more accessible to users who are not comfortable with English. There are drawbacks as any translation means departing away from something which is easy to match with the scripting API (which should not be translated), but I think the gains outweigh the drawbacks, at least as long as this is optional (for users who would want the interface in their language but the property names matching the scripting API). I'm just mentioning this for context, I see the PR already implements this as an option.

TTR() shouldn't be used with variable names as there will be no way for the PO file generation script to pick up strings to generate. TTR() should only constrain string literals, optionally using vformat() to replace placeholders.

Indeed, the current extract.py reads the source code directly and will not process it to get strings which are defined at runtime.

I see that you started modifying extract.py to use regular expressions to try to extract property names in ADD_PROPERTY, etc., but I'm not sure this is the best approach. At least right now it doesn't seem to work:

$ make update
Updating the editor.pot template...
Wrapping template at 79 characters for compatibility with Weblate.
editor.pot:13431: duplicate message definition...
editor.pot:11: ...this is the location of the first definition
msgmerge: found 1 fatal error

# Template changes compared to the staged status:
#   Additions: 0 msgids.
#   Deletions: 2888 msgids.

If we want to go this route, it might be better to add relevant macros to define the English names that should be extracted and can be translated, e.g.:

ADD_PROPERTY(PropertyInfo(Variant::VECTOR3, "size", TTR("Size")), "set_size", "get_size");

GLOBAL_SECTION("node", TTR("Node"));
GLOBAL_DEF("node/name_num_separator", TTR("Name Num Separator"), 0);
GLOBAL_DEF("node/name_casing", TTR("Name Casing"), NAME_CASING_PASCAL_CASE);

GLOBAL_SECTION("rendering", TTR("Rendering"));
GLOBAL_SECTION("rendering/vram_compression", TTR("VRAM Compression"));
GLOBAL_DEF_RST("rendering/vram_compression/import_s3tc", TTR("Import S3TC"), true);

The last one shows examples where the automatic capitalization of property paths done by the editor can also give bad results in English, and where having the possibility to set the name explicitly can improve the experience even in English (currently that last one shows as "Rendering > Vram Compression > Import S 3 Tc"). That's something that #32734 tries to improve with a hardcoded list of exceptions, but if we want full translation support, we might as well specify all names explicitly and remove the need for exceptions.

Note that the API proposed above is only for discussion, I don't expect you to implement it now, we should first agree on what's the best approach.

[magian1127]

I see that you started modifying extract.py to use regular expressions to try to extract property names in ADD_PROPERTY, etc., but I'm not sure this is the best approach. At least right now it doesn't seem to work:

I run it on windows “extract.py", They did

My scheme has met my own needs at present
I also think your scheme is better. Add default English names to them respectively. In this way, just need to extract TTR
I won't revise this PR for the time being

我是在"windows"下执行的"extract.py", 他们确实生效了
我这个方案目前已经满足我自己使用了.
我也认为您的方案比较好, 给它们分别加上默认英文名称.这样就还是只需要提取TTR就好.
这个PR我暂时不会去修改了

[magian1127]

Implemented with plug-in. This PR is not required.
https://slgongfang.coding.net/public/SLGFopen/SLGFopen_HanHua/git/files
已用插件实现. 这个PR不需要了.

[akien-mga]

Thanks for the link! I still think this might be interesting to implement in the engine, but I want to have a closer look at it myself to evaluate the impact and how to do it properly. I'll keep this PR and your plugin as reference.

[magian1127]

You're welcome. I didn't write this plugin. I just found it.
I also hope to translate all texts in the future.
不客气,另外这个插件不是我写的,我只是发现了他.
我也希望将来可以实现所有文本的翻译.