Translation of "scene" and "node" to different languages

Development
1

Moving a discussion that we started on crowdin to this forum for better visibility and to include more people.

Andras Lasso

Andras Lasso

2 days ago

We have found it difficult to translate “scene” and “node” to Hungarian. The problem is that the English terms are not the best. Scene and node are computer graphics terms, referring to the scene graph and nodes in this graph. These are not terms that our model user (medical student) would know or understand.

What do you think about using these terms as basis of translations?

  1. Use workspace instead of scene

Examples:

  • Close scene → Close workspace
  • Save scene and unsaved data → Save workspace and unsaved data
  • Add data into the scene → Add data into the workspace
  • Save the entire scene, with all data and display settings embedded in private fields → Save the entire workspace, with all data and display settings embedded in private fields
  1. Use item instead of node

Examples:

  • Select views in which to show this node. → Select views in which to show this item.
  • Resample a curve and optionally constrain the points to a node → Resample a curve and optionally constrain the points to another item
  • Overwrite current node → Overwrite current item
  • Select views in which to show this node. → Select views in which to show this item.
  • Output node: → Output item:
  • Color node: → Color item: and even considering changing this in the English user interface.

If we all agree that these terms work well then we may even change them in the English user interface.

Andrey Fedorov

Andrey Fedorov (andrey.fedorov)

3 hours ago

If the English user interface is changed, would this mean names of the classes that use “Scene” will also need to be changed?

Andras Lasso

Andras Lasso

2 hours ago

It would only affect the user interface for now.

I don’t know how much of a problem it will cause for developers that words on the user interface are not the same as in the source code. We would probably still talk about “nodes”, because “items” are just not too specific. I can imagine replacing “scene” by “workspace” in a few years in the source code, too, because “workspace” just so much better describes what it is.

Andrey Fedorov

Andrey Fedorov (andrey.fedorov)

an hour ago

I know I have a tendency of over-complicating things, but I don’t think it’s an easy decision. Yes, maybe for the existing developers it is not a big deal, but for new developers - it might be. There is also a consideration for the variety of known and unknown learning materials that will not be possible to update. I would be very very cautious with changing terminology in the interface. I agree the choices may not have always been optimal, but maybe it is better to deal with that legacy than with the consequences of renaming. I wonder what other developers and users think about this.

Attila Nagy

Attila Nagy (acetylsalicyl)

an hour ago

“Workspace” and “item” are both very good substitutions for the terms currently used in Slicer. Better describe what they are, and are easier to translate.

Andrey has a point too. On the other hand, software, the people who use them, and the world, in general, is constantly changing.

We could document this transition in the Slicer documentation, and move forward. I do know from my own experiences how hard it is to describe what a node or a volume is. We can just create a “glossary” of new and old terms, and point users to that. It even could make sense in retrospect. (ie where they see “node” they can think "aha, that’s not some technospeak, it’s just an “item”)

Andras Lasso

Andras Lasso

27 minutes ago

I would not worry about developers, as we already deal with many equivalent terms (model=surface=mesh=polydata, etc). For users, it may take some effort to unlearn some some “Slicerisms”, but if we switch to simpler, commonly used terms then this should be easy.

Of course we would need to hear opinion from more users before making any sweeping changes.

1 Like
2

We have been struggling with this for many years when we train biologists. Our solution was to say that a Slicer scene is equivalent to a workspace or a project in other programs, and it may consist of many nodes of different types.

I will wholeheartedly agree to this change.

1 Like
3

I absolutely agree that “workspace” is a better term. It more closely aligns to terms some academic researchers see such as MATLAB having “workspace” area. It also has made its way as a term for developers since it is used in IDE code workspace areas.

“Node” is the most egregious term that regular people do not know what it means. We’ve attempted to strip all usage of it in our custom application that regular biologists use. We have in the Slicer GUI tried to avoid using this term by saying “Create Point List” instead of “Create Point List Node”. When the specific term is used, it is unnecessary to also say the general term afterwards. Be succinct. Also, saying “Overwrite current item” is fine, however when there is only 1 type of item we should be specific and say “Overwrite current Volume” or whatever type it may be. Be specific.

Using the general term “item” is definitely easier to understand for regular people and Slicer should aim to cater to these people to increase the number of users and therefore funding. I have often told people “node” meant the same as an “object”, but “item” can probably work too.

I will point out one weird location where “Subject Hierarchy Node” becoming “Subject Hierarchy Item” with this terminology change will have conflict with the already used “Subject Hierarchy Item” which is its own thing. See Script repository — 3D Slicer documentation.

4

+1 for workspace to replace scene. Much better term and no downsides that I can think of.

I realize this seems to be a minority opinion, but I like the term node much better than item. To me “item” sounds like a thing on a list. I like that the MRML thing is always called a “node”, and I think of it as like a container for the kind of thing it is for. So, a scalar volume node is the MRML container for a scalar image volume. A “scalar image item” sounds like a sub-part of a scalar image, not a thing which contains a scalar image. And, a “display node” would need to become a “display item”? That seems much worse. “Node” correctly carries the connotation that it can be connected with other nodes, like an image or model node with a display node.

I would prefer object to item in essentially all cases. I can see where object would be a more meaningful generic term to many people than node.

5

Workspace, absolutely.

Item is also good, especially considering that in the Data tree (i.e. Subject hierarchy) we already call the “entries” items, and this way the correspondence would be complete, and confusion less. Also, everybody knows what an item is, but node is something that some people have never heard of (I probably only did because of my university math classes).
The problem with “node” is that although it is concise and sounds cool in English, in other languages (Hungarian definitely) it is almost impossible to translate in a way that people could make sense of.
I understand the points of @mikebind , and for example display item is quite bad. So object may actually be better than item considering everything (the SH terms are mostly technical and there is usually a 1:1 correspondence between item and node so it’s not a big problem).

6

Node is arguably the technically correct term, in the sense that MRML references form graph structures and the word node has a long history for things like lymph nodes and nodes in a transportation system. I know we are trying to make concepts simpler for new users, but part of goal should also be to suggest to them important concepts about Slicer, like the fact that nodes are part of references networks. Of the two alternatives I do like object better than item.

7

I agree that “object” seems to work better overall than “item”, because “object” is a bit more specific, but still understandable.

“Node” of a “scene graph” are proper but very specialized computer graphics terms. Such implementation details should not leak to the user interface that is intended for clinicians. Even ParaView, which is an engineering software, uses simpler, generally understandable terms - “data objects” and “geometric shapes” - to refer to items in their data tree.

The main goal is not to change the English GUI now, but at least we should not make the same mistakes again when choosing the terms in other languages.

1 Like