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

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.

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?

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.

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..

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).

Is it too late to rebase this on 3.6?

@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 ;)

Cool, thanks! I’ve rebased.

> @pioverfour no think these kind of changes are fine still for 3.6 ;) Cool, thanks! I’ve rebased.

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.

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?

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.

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.

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!

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!

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.

 @ -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");

 @ -142,6 +142,7 @@ typedef struct bNodeSocket {
   /** Custom dynamic defined label, MAX_NAME. */
   char label[64];
   char description[64];
   char label_translation_context[64];

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

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

Reviewers