Defining a scheme for trans-unit ids

Continuing the discussion from Backend translations current state:

For the UI translation, a lot of labels need to be created. We need a scheme to address them and will have to find the right compromise between re-using labels and spot-on translations.

Having the exact same string in two labels is not a big problem, as Crowdin will hide those by default and re-use the translation of one for the duplicate(s). And of course when translating the translation memory will suggest things that have been translated already.

But when adding translate VH calls to templates, it would be helpful if one could reuse labels that exist (like cancel or clickToDelete) instead of having to add them to the XLIFF files again and again.

Right now it is too hot here for me to come up with a suggestion, but at least the topic has been brought up now.

I have no idea, but just to get something started:

First of all the backend translations are now split in different files, that gives some context already (like which NodeType the translations are for).

Just to give some examples for NodeType labels as the state is in the change I am working on:

  • Label for the NodeType itself: label
  • Label for inspector tab in that NodeType: tabs.meta
  • Label for inspector group in that NodeType: groups.visibility
  • Label for a property “title”: properties.title
  • Values for a select box editor for property “layout”: properties.layout.selectBoxEditor.values.<someValue>
  • Button label for CodeEditor for property “html”: properties.html.codeEditor.buttonLabel

Note that this are the defaults that you would have to declare in the matching package for the NodeType in a file .../Translations/<locale>/NodeTypes/NodeTypeName.xliff

all other labels we have so far seem pretty much simple: “close” => close etc.

No idea how a good schema could look like. Guess we should have a look at other projects?

1 Like

What I wonder, should we extend the label parts so an actual label path is never a subpart of another label part?

lets say the property “layout” of my node type is a select box, I would currently end up with the following labels:

Now properties.layout is at the same time an actual label but is also a segment of another label. That could be avoided with having properties.layout.label. Don’t know if we ever need this but would result in s a schema that allows creating associative arrays of all the label paths.

1 Like

I like what Christian suggested.

However we also have labels for a lot of things besides node types where we also need to come up with a good strategy. Currently it’s a bit of a mess with the labels AFAIK and it varies between implementors.