blender
/
blender
128
395
Fork 567
Code Issues 6.2k Pull Requests 751 Projects 19 Wiki Activity

WIP: I18n: add per-label translation contexts for nodes #105690

Draft
Damien Picard wants to merge 3 commits from pioverfour/blender:dp_add_i18n_context_socket_label into blender-v3.6-release
pull from: pioverfour/blender:dp_add_i18n_context_socket_label
merge into: blender:blender-v3.6-release

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Conversation 12 Commits 3 Files Changed 6 +30 -4
Damien Picard commented 2023-03-12 15:56:15 +01:00
Member
Copy Link

In order to properly translate UI messages, they sometimes need to be
disambiguated using translation contexts. Until now, node sockets
using custom labels had no way to specify contexts and a collision
occurred in at least one known instance.

This commit adds a way to declare contexts for each socket with
labels, by adding a label_translation_context field to the
bNodeSocket struct, as well as a translation_context argument to the
node_sock_label() function.

If no context is specified, the default null context is used.

The use of a context enables us to fix part of #105113.

This PR contains three commits:

  • The first extends the node system to enable per-label context;
  • The second one adds two such contexts to actually fix #105113;
  • The third one adds regexes to the i18n message extraction script, to actually extract those strings.
In order to properly translate UI messages, they sometimes need to be disambiguated using translation contexts. Until now, node sockets using custom labels had no way to specify contexts and a collision occurred in at least one known instance. This commit adds a way to declare contexts for each socket with labels, by adding a `label_translation_context` field to the bNodeSocket struct, as well as a `translation_context` argument to the `node_sock_label()` function. If no context is specified, the default null context is used. The use of a context enables us to fix part of #105113. ----- This PR contains three commits: - The first extends the node system to enable per-label context; - The second one adds two such contexts to actually fix #105113; - The third one adds regexes to the i18n message extraction script, to actually extract those strings.
Damien Picard added this to the User Interface project 2023-03-12 15:56:49 +01:00
Damien Picard added the
Module
User Interface
Interest
Nodes & Physics
 labels 2023-03-12 15:57:12 +01:00
Damien Picard requested review from Bastien Montagne 2023-03-12 15:59:24 +01:00
Damien Picard requested review from Jacques Lucke 2023-03-12 15:59:24 +01:00
Damien Picard requested review from Hans Goudey 2023-03-12 15:59:25 +01:00
Damien Picard added the
Interest
Translations
 label 2023-03-12 16:47:03 +01:00
Bastien Montagne commented 2023-03-13 12:14:59 +01:00
Owner
Copy Link

Not sure about defining i18n contexts at such a fine grained level tbh, wouldn't it make more sense to add an optional i18n context to the NodeType, and when defined, use it for all of its UI strings?

Not sure about defining i18n contexts at such a fine grained level tbh, wouldn't it make more sense to add an optional i18n context to the NodeType, and when defined, use it for all of its UI strings?
Bastien Montagne commented 2023-03-13 12:23:41 +01:00
Owner
Copy Link

I realize this is actually in the continuity of !105195 now... But still, feels a bit odd/over-specific to me.

I realize this is actually in the continuity of !105195 now... But still, feels a bit odd/over-specific to me.
Damien Picard commented 2023-03-13 15:21:30 +01:00
Author
Member
Copy Link

I realize this is actually in the continuity of !105195 now... But still, feels a bit odd/over-specific to me.

To me, too, but then again I find the use of labels a bit odd and overly specific in the first place.

When I first tried adding contexts to sockets in D15869, @HooglyBoogly explained that “[he]'d like to avoid storing the context per socket”. This is once more what I’m doing and I do think it’s not ideal, but the labels are a different system from ordinary socket names: they are not declared at the node level. So I’m not sure how to do it better..

> I realize this is actually in the continuity of !105195 now... But still, feels a bit odd/over-specific to me. To me, too, but then again I find the use of labels a bit odd and overly specific in the first place. When I first tried adding contexts to sockets in [D15869](https://archive.blender.org/developer/D15869), @HooglyBoogly explained that “[he]'d like to avoid storing the context per socket”. This is once more what I’m doing and I do think it’s not ideal, but the labels are a different system from ordinary socket names: they are not declared at the node level. So I’m not sure how to do it better..
Damien Picard commented 2023-04-19 14:46:18 +02:00
Author
Member
Copy Link

Another bad issue fixable with this PR was reported at #43295.

Another bad issue fixable with this PR was reported at [#43295](https://projects.blender.org/blender/blender/issues/43295#issuecomment-924983).
Damien Picard force-pushed dp_add_i18n_context_socket_label from cb716fd007 to 1b31dd9a28 2023-05-07 16:11:11 +02:00 Compare
Damien Picard force-pushed dp_add_i18n_context_socket_label from 1b31dd9a28 to e566a26026 2023-05-10 12:00:02 +02:00 Compare
Bastien Montagne requested changes 2023-05-15 18:59:56 +02:00
source/blender/nodes/intern/node_util.hh Outdated
@ -31,3 +31,3 @@
/**** Updates ****/
void node_sock_label(bNodeSocket *sock, const char *name);
void node_sock_label(bNodeSocket *sock, const char *name, const char *translation_context = "\0");
Bastien Montagne commented 2023-05-15 18:59:53 +02:00
Owner
Copy Link

Would rather have default value be BLT_I18NCONTEXT_DEFAULT (aka nullptr). Also means node_sock_label code changes need an update.

Would rather have default value be `BLT_I18NCONTEXT_DEFAULT` (aka `nullptr`). Also means `node_sock_label` code changes need an update.
pioverfour marked this conversation as resolved
Damien Picard force-pushed dp_add_i18n_context_socket_label from 97a79c8e11 to d57e8c278a 2023-05-15 19:51:18 +02:00 Compare
Damien Picard commented 2023-05-18 00:45:10 +02:00
Author
Member
Copy Link

Is it too late to rebase this on 3.6?

Is it too late to rebase this on 3.6?
Damien Picard requested review from Bastien Montagne 2023-05-18 14:58:31 +02:00
Bastien Montagne commented 2023-05-22 11:34:17 +02:00
Owner
Copy Link

@pioverfour no think these kind of changes are fine still for 3.6 ;)

@pioverfour no think these kind of changes are fine still for 3.6 ;)
pioverfour changed target branch from main to blender-v3.6-release 2023-05-22 12:50:08 +02:00
Damien Picard force-pushed dp_add_i18n_context_socket_label from d57e8c278a to 11ce69e58f 2023-05-22 13:06:17 +02:00 Compare
Damien Picard commented 2023-05-22 13:47:47 +02:00
Author
Member
Copy Link

@pioverfour no think these kind of changes are fine still for 3.6 ;)

Cool, thanks! I’ve rebased.

> @pioverfour no think these kind of changes are fine still for 3.6 ;) Cool, thanks! I’ve rebased.
Jacques Lucke requested changes 2023-05-22 14:07:18 +02:00
source/blender/makesdna/DNA_node_types.h Outdated
@ -142,6 +142,7 @@ typedef struct bNodeSocket {
/** Custom dynamic defined label, MAX_NAME. */
char label[64];
char description[64];
char label_translation_context[64];
Jacques Lucke commented 2023-05-22 14:07:02 +02:00
Member
Copy Link

Adding 64 byte to every socket for this is not really acceptable. Better move this to run-time data if possible (bNodeSocketRuntime).

Adding 64 byte to every socket for this is not really acceptable. Better move this to run-time data if possible (`bNodeSocketRuntime`).
Damien Picard commented 2023-05-22 14:30:36 +02:00
Author
Member
Copy Link

Thanks, it makes a lot more sense!

Thanks, it makes a lot more sense!
Jacques Lucke commented 2023-05-22 14:35:45 +02:00
Member
Copy Link

In run-time data you can also use e.g. std::string which in this case would also be smaller usually.

In run-time data you can also use e.g. `std::string` which in this case would also be smaller usually.
Damien Picard requested review from Jacques Lucke 2023-05-22 14:30:52 +02:00
Jacques Lucke approved these changes 2023-05-22 15:07:58 +02:00
Damien Picard force-pushed dp_add_i18n_context_socket_label from d7c1753f30 to 29830181ca 2023-05-22 15:11:30 +02:00 Compare
Bastien Montagne requested changes 2023-05-22 18:14:24 +02:00
Bastien Montagne left a comment
Owner
Copy Link

I strongly disagree with the suggested change (moving translation context into runtime data).

Translation context should not be split away from the string it affects, either all UI strings move into runtime, or everything stays into DNA struct.

I strongly disagree with the suggested change (moving translation context into runtime data). Translation context should not be split away from the string it affects, either all UI strings move into runtime, or everything stays into DNA struct.
Damien Picard commented 2023-05-22 18:23:18 +02:00
Author
Member
Copy Link

Translation context should not be split away from the string it affects, either all UI strings move into runtime, or everything stays into DNA struct.

I can try to move the label and description into runtime data then. Would that be all right?

> Translation context should not be split away from the string it affects, either all UI strings move into runtime, or everything stays into DNA struct. I can try to move the label and description into runtime data then. Would that be all right?
Hans Goudey requested changes 2023-05-24 16:47:27 +02:00
Hans Goudey left a comment
Member
Copy Link

On a conceptual level, I really think this should be stored in the socket declaration, not the socket. The declaration describes all sockets in all nodes. Storing the same data for every socket instance just shouldn't be necessary, whether it's in runtime data or DNA.

The node Python API hasn't really caught up to this design with declarations yet, but exposing it the general future plan anyway.

On a conceptual level, I really think this should be stored in the socket **declaration**, not the socket. The declaration describes all sockets in all nodes. Storing the same data for every socket instance just shouldn't be necessary, whether it's in runtime data or DNA. The node Python API hasn't really caught up to this design with declarations yet, but exposing it the general future plan anyway.
Damien Picard commented 2023-05-24 16:59:59 +02:00
Author
Member
Copy Link

On a conceptual level, I really think this should be stored in the socket declaration, not the socket.

I agree that this data is very redundant, but since the label system was designed in this redundant way I figured it made sense to apply the same logic to translations, at least until a better system was implemented.

The node Python API hasn't really caught up to this design with declarations yet, but exposing it the general future plan anyway.

I see! I’ll wait a while to see how things evolve before returning to this, then.

> On a conceptual level, I really think this should be stored in the socket **declaration**, not the socket. I agree that this data is very redundant, but since the label system was designed in this redundant way I figured it made sense to apply the same logic to translations, at least until a better system was implemented. > The node Python API hasn't really caught up to this design with declarations yet, but exposing it the general future plan anyway. I see! I’ll wait a while to see how things evolve before returning to this, then.
Damien Picard changed title from I18n: add per-label translation contexts for nodes to WIP: I18n: add per-label translation contexts for nodes 2023-05-24 17:00:10 +02:00
Hans Goudey commented 2023-05-24 17:21:32 +02:00
Member
Copy Link

I figured it made sense to apply the same logic to translations

Memory usage cost aside, I'd agree, but that aspect means there a real reason to avoid redundancy.

I see! I’ll wait a while to see how things evolve before returning to this, then.

Well, this doesn't need to be exposed to the Python API to be useful. Whether to wait is obviously your call though!

>I figured it made sense to apply the same logic to translations Memory usage cost aside, I'd agree, but that aspect means there a real reason to avoid redundancy. >I see! I’ll wait a while to see how things evolve before returning to this, then. Well, this doesn't need to be exposed to the Python API to be useful. Whether to wait is obviously your call though!
Damien Picard commented 2023-05-24 17:49:05 +02:00
Author
Member
Copy Link

Well, this doesn't need to be exposed to the Python API to be useful. Whether to wait is obviously your call though!

I mean, maybe there’s something I’m missing, but I don’t see how to attach translation contexts to labels using the socket declarations, in the current state of things. The labels are an ad-hoc name override that is never the same as the name from the socket declaration.

See for instance the Separate Colors node: its third input has "Blue" for its name, but its label can be any of "Blue", "Value", "Lightness", "Cr" or "V". So this label must have its own translation context, distinct from that of the name.

So unless I’m mistaken, in order for this to work with declarations the label system would need to be redesigned, and I don’t think I can pull that off!

> Well, this doesn't need to be exposed to the Python API to be useful. Whether to wait is obviously your call though! I mean, maybe there’s something I’m missing, but I don’t see how to attach translation contexts to labels using the socket declarations, in the current state of things. The labels are an ad-hoc name override that is never the same as the `name` from the socket declaration. See for instance the Separate Colors node: its third input has "Blue" for its `name`, but its `label` can be any of "Blue", "Value", "Lightness", "Cr" or "V". So this label must have its own translation context, distinct from that of the name. So unless I’m mistaken, in order for this to work with declarations the label system would need to be redesigned, and I don’t think I can pull that off!
Hans Goudey commented 2023-05-24 17:55:00 +02:00
Member
Copy Link

The translation context could be a callback like make_available, that wouldn't probably be pretty straightforward. But yeah, understandable to wait.

The translation context could be a callback like `make_available`, that wouldn't probably be pretty straightforward. But yeah, understandable to wait.
This pull request is marked as a work in progress.
This branch is out-of-date with the base branch
View command line instructions.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u dp_add_i18n_context_socket_label:pioverfour-dp_add_i18n_context_socket_label
git checkout pioverfour-dp_add_i18n_context_socket_label
Sign in to join this conversation.
Reviewers
No reviewers
Jacques Lucke
Bastien Montagne
Hans Goudey
Labels
Clear labels   
Interest
Alembic

  
Interest
Animation & Rigging

  
Interest
Asset Browser

  
Interest
Asset Browser Project Overview

  
Interest
Audio

  
Interest
Automated Testing

  
Interest
Blender Asset Bundle

  
Interest
BlendFile

  
Interest
Collada

  
Interest
Compatibility
This issue affects/is about backward or forward compatibility

  
Interest
Compositing

  
Interest
Core

  
Interest
Cycles

  
Interest
Dependency Graph

  
Interest
Development Management

  
Interest
EEVEE

  
Interest
EEVEE & Viewport

  
Interest
Freestyle

  
Interest
Geometry Nodes

  
Interest
Grease Pencil

  
Interest
ID Management

  
Interest
Images & Movies

  
Interest
Import Export

  
Interest
Line Art

  
Interest
Masking

  
Interest
Metal

  
Interest
Modeling

  
Interest
Modifiers

  
Interest
Motion Tracking

  
Interest
Nodes & Physics

  
Interest
OpenGL

  
Interest
Overlay

  
Interest
Overrides

  
Interest
Performance

  
Interest
Physics

  
Interest
Pipeline, Assets & IO

  
Interest
Platforms, Builds & Tests

  
Interest
Python API

  
Interest
Render & Cycles

  
Interest
Render Pipeline

  
Interest
Sculpt, Paint & Texture

  
Interest
Text Editor

  
Interest
Translations

  
Interest
Triaging

  
Interest
Undo

  
Interest
USD

  
Interest
User Interface

  
Interest
UV Editing

  
Interest
VFX & Video

  
Interest
Video Sequencer

  
Interest
Virtual Reality

  
Interest
Vulkan

  
Interest
Wayland
Issues relating to Wayland windowing support.

  
Interest
Workbench

  
Interest: X11

Issues relating to Xorg/X11 support.

  
Legacy
Blender 2.8 Project

  
Legacy
Milestone 1: Basic, Local Asset Browser

  
Legacy
OpenGL Error

  
Meta
Good First Issue

  
Meta
Papercut

  
Meta
Retrospective

  
Meta
Security
Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports

  
Module
Animation & Rigging

  
Module
Core

  
Module
Development Management

  
Module
EEVEE & Viewport

  
Module
Grease Pencil

  
Module
Modeling

  
Module
Nodes & Physics

  
Module
Pipeline, Assets & IO

  
Module
Platforms, Builds & Tests

  
Module
Python API

  
Module
Render & Cycles

  
Module
Sculpt, Paint & Texture

  
Module
Triaging

  
Module
User Interface

  
Module
VFX & Video

  
Platform
FreeBSD

  
Platform
Linux

  
Platform
macOS

  
Platform
Windows

  
Priority
High

  
Priority
Low

  
Priority
Normal

  
Priority
Unbreak Now!

  
Status
Archived

  
Status
Confirmed

  
Status
Duplicate

  
Status
Needs Info from Developers

  
Status
Needs Information from User

  
Status
Needs Triage

  
Status
Resolved

  
Type
Bug

  
Type
Design

  
Type
Known Issue

  
Type
Patch

  
Type
Report

  
Type
To Do

No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
User Interface
Assignees
Clear assignees
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#105690
No description provided.
Delete Branch "pioverfour/blender:dp_add_i18n_context_socket_label"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?