Hello,

You can use the setDescription and setDisplayName methods of com.prosysopc.ua.server.nodes.BaseNode to set multiple Descriptions and DisplayNames in different Locales. Although the methods are named setX, they actually add LocalizedTexts to a LocalizedTextMap which can contain one LocalizedText per LocaleId. When reading Descriptions and DisplayNames, the Server will attempt to return a Value that matches the list of Locales provided by a Client in ActivateSession request.

When you say definition, I’m assuming you mean the Definition Property of DataItemType. If I’m wrong, please correct me. The OPC UA specification states the following about Definition: “Definition is non-localized and will often contain an equation that can be parsed by certain clients” (https://reference.opcfoundation.org/Core/Part8/v105/docs/5.3.1). Therefore, you should not localize Definitions.

EnumValues can be localized but there is no built-in support for this in the SDK and we don’t have any examples of how to do this. In theory, you could either replace the IoManager of the NodeManager that handles reading the EnumValues with your own IoManager or add an IoManagerListener to the default IoManager of the same NodeManager and have the listener handle reading the EnumValues. In either case, you would be able to use ServiceContext to get a Session and then use that to get a list of Locales and return different values depending on the listed Locales.

Hello,

I’m not quite sure what you mean with “we were asked to publish all the translations we have for each node”. Who is asking for this?

In OPC UA, Clients provide Servers with lists of Locales ordered from the most preferred to the least preferred. The Servers are then expected to use this list and attempt to provide localized DisplayNames, Descriptions and so on if they have localized versions available for the specified Locales or use their default Locale if they do not support any of the listed Locales. There is no concept of the Server returning multiple different localized versions of an Attribute such as Description when a Client reads its value. Neither is there a standardized way of exposing different translations in the Server’s AddressSpace.

Part 19: Dictionary Reference specifies how Nodes can be connected to DictionaryEntry Nodes that provide additional semantics for a Node. For example, a Node representing a flow transmitter could reference a DictionaryEntry Node that represents flow transmitters with a HasDictionaryEntry Reference. For more examples, see https://reference.opcfoundation.org/Core/Part19/v105/docs/9

In short, Part 19: Dictionary Reference has nothing to do with translating values of Attributes. It simply allows providing more semantics to Nodes using external standardized dictionaries such as International Registration Data Identifiers (IRDI).

If you need to expose all the translations in the Server’s AddressSpace, you will most likely need to add them as Values of additional Nodes. For example, you could use Property Nodes with LocalizedText Arrays that contain all the translations as their Values. Do note that this is a non-standardized solution so Clients would not automatically understand the purpose of the Property Nodes containing the translations.