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

lassoan
Mon, 24 Jan 2022 23:18:17 +0000
Development

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

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

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

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

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)

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

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.

7 posts - 6 participants