Hi,

I think you are the first to ask anything translation-related. I’m not sure have they been used in practice at all (but we do see somewhat limited view of the world from our perspective).

Currently we only support reading one Description per node from a NodeSet, so the last one read is the one we use. This is because internally we do read the data to NodeAttributes objects, which are the same as used in the AddNodes service call: https://reference.opcfoundation.org/v104/Core/docs/Part4/7.19.1/ (that a Client could use to add nodes, assuming server supports and allows that). This makes it so that SDK can handled node additions in similar fashion regardless the origin of the addition (i.e. the NodeSet is transformed internally to AddNodes and AddReferences constructs). Those can only contain a single translation/LocalizedText per Attribute.

Also seems we do not support the Translation XML element at all in our parser, so this must be the first model ever that tries to use it.

In OPC UA 1.04 there was some new Attributes added and as a result the GenericAttributes NodeAttributes sub-Structure type had to be defined (as you cannot add more fields to an existing Structure type without breaking the binary encoding). We do not yet support the GenericAttributes, but with that there would be at least a technical way to pass more than one value to an Attribute (since the base NodeAttributes type only has a single field for the LocalizedText Attribute types, thus you can only fit one localization there, but the GenericAttributes has an array of GenericAttributeValue which maybe could be used to add more, though I’m not sure is that intended).

Once you have the model loaded and can access the nodes as UaNodes, you could set the extra translations via UaNode.setDescription(LocalizedText), it will keep them LocalizedTextMap per the rules defined in the specification. The same way a Client could write to those Attributes and it should work as specified.

So I’ll have to conclude that, sorry, currently the support is relatively poor on this NodeSet-wise. But we can probably improve on this in a future SDK version, how critical this would be for you?

I do see the use-case, just that I do not remember anyone asking so far (or maybe they didn’t use NodeSets, but just created the instances in the code e.g. from a backing database etc.). In general the more a feature is asked the more likely it is to be implemented.

In general the feature set of OPC UA is almost too large, not sure if anyone has implement all of it (and more stuff is being added almost constantly).

Anyway, I think the Description and DisplayName parts i.e. non-Value Attributes localization should be relatively easy to implement. I did make an issue to the OPC UA Specification’s issue tracker would the GenericAttributes usage be as intended (https://apps.opcfoundation.org/mantis/view.php?id=6090, requires credentials), though regardless internally we can probably handle it anyway like that.

The Translation element does not work like that, assuming I have understood it correctly, https://reference.opcfoundation.org/v104/Core/docs/Part6/F.10/. It is only intended for Value Attribute values that are Structures that could contain a LocalizedText type fields. Implementing these currently might be a real pain or impossible. An example of this type would be the EnumValueType which is one way to defined Enumerations (the EnumValues Property of an enumeration DataType node would have an array of those; though note that there is also EnumStrings).

For non-Value, the schema at https://github.com/OPCFoundation/UA-Nodeset/blob/v1.04/Schema/UANodeSet.xsd would indicate that you just repeat the Description or DisplayName elements for additional localizations.

We do offer 2 ways to deal with Structures currently, either the codegen is used to make equivalent java classes or alternatively the DynamicStructure class is used. Codegen does currently generate a simple LocalizedText field, thus any generated Structure class can only have a single translation. You could intercept any Value reading and change the text, but I do not have any ready solution how our SDK would load these values currently.

Like in theory you could of course parse the model manually in parallel to get the info, but that is not very practical solution with all the complexity of the model loading (e.g. you need to translate every NodeId and QualifiedName from Model namespace-indexes to the server’s NamespaceArray indexes recursively for everything such as Structure field values etc.).

For the DynamicStructure we could maybe make some changes that it could handle more than one LocalizedText value, but it’s APIs (nor Structure’s) is not designed to accommodate passing a Locale.

So as a small summary, for non-Value Attributes the issue is “just” loading the NodeSet, the Description/DisplayName Attributes should work as-is just getting the data from the NodeSet is the problem. For Value Attributes and especially Structures that have LocalizedText fields it is way more complicated, basically you would need to handle it completely custom with the IoManagerListeners for example and get the data also manually i.e. non-SDK-code ways (though if you do this, it should just work, but is basically you checking which locale the client did specify for the Session and returning suitable value).

In general there has been sort of the feeling that we do need to update our core APIs at some point. There is OPC UA 1.05 on the horizon so that will most likely be an option to do SDK 5.x which might have better solutions for these situations.

On the short term we can probably try to at least implement the non-Value part in some future 4.x release (though do not take this as a guarantee of that; but I did add an issue to our internal issue tracker about this).