Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
Translation of Descriptions/DisplayName etc (NoEnumConstant)
September 29, 2020
13:01, EET
Avatar
araisch
Member
Members
Forum Posts: 3
Member Since:
September 29, 2020
sp_UserOfflineSmall Offline

Trying to provide translations in my custom information model.

<UAObjectType NodeId="ns=2;i=1000" BrowseName="2:TemperatureZoneType">
<DisplayName Locale="en">TemperatureZoneType</DisplayName>
<Description Locale="en">The TemperatureZone describes one control loop for an heating</Description>
<References>
<Reference ReferenceType="HasSubtype" IsForward="false">i=58</Reference>
</References>
</UAObjectType>

That is working so far, but how to add another language?

<Description Locale="en">The TemperatureZone describes one control loop for an heating</Description>
<Description Locale="it">TemperatureZone descrive un circuito di controllo per un riscaldamento</Description>

This just shows the latest one (italian so far) but ignores set localeId (even if it’s unset, should be “en” by default)

..snip..
<Description Locale="en">The TemperatureZone describes one control loop for an heating</Description>
</UAObjectType>
<Translation>
<Description Locale="de-DE">Die TemperaturZone beschreibt einen Regelkreis einer Heizung</Description>
</Translation>

This leads to a
Error in ModelParser2.startElement: localName=Translationjava.lang.IllegalArgumentException: No enum constant com.prosysopc.ua.ModelParserBase.c.Translation
Same like different other versions.

Is that possible and how?

September 29, 2020
13:37, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 579
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

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?

September 29, 2020
14:46, EET
Avatar
araisch
Member
Members
Forum Posts: 3
Member Since:
September 29, 2020
sp_UserOfflineSmall Offline

Hi Bjarne,
thanks for your very fast reply.
There is very few information about this translation stuff and I am not sure this is the reason nobody is using it.
OPC UA provides huge support in storing all meta data in one place (the model/server) to avoid maintaining several sources of data. For visualization you need e.g. the unit, value range, precision and so on (all provided by an AnalogItemType). But also the customers ask for translated visualizations, most production machines have translated HM-Interfaces due to the fact, that people working with them seldom possess foreign language skills. So it is hard for everyone to match the parameters and values on the HMI with the English stuff on dashboards, apps, etc. For all the data sinks (apps/dashboards/etc) using data from the opc ua source you have to maintain separate translation files. This is quite an effort to maintain all of them and keep them updated, especially if they run in highly protected enterprise networks and/or are from third-party-providers. That’s why we want to use the great abilities of OPC UA.
I don’t know how others solving this, most likely they prefer plain English or are just not aware that it could be a nice solution using different localized texts.

As far as I understood the Foundation it should work like this:

<DisplayName>
<Text>This is the Name</Text>
</DisplayName>
<Description>
<Text>This is the Description</Text>
</Description>
<Translation>
<Field Name="DisplayName">
<Text Locale="de-DE">[German Translation for Name]</Text>
<Text Locale="fr-FR">[French Translation for Name]</Text>
</Field>
<Field Name="Description">
<Text Locale="de-DE">[German Translation for Description]</Text>
<Text Locale="fr-FR">[French Translation for Description]</Text>
</Field>
</Translation>

And the server manages that the right Text is shown by given localeId while opening connection (or fall back to default).

But I see, there is some work to do to bring all features of OPC UA on the road..

September 29, 2020
15:44, EET
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 579
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

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

September 29, 2020
16:02, EET
Avatar
araisch
Member
Members
Forum Posts: 3
Member Since:
September 29, 2020
sp_UserOfflineSmall Offline

Bjarne Boström said
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.

Hmm ok, like I said: Docs are not that precise about this.. but that

<Description Locale="en">The TemperatureZone describes ..</Description>
<Description Locale="it">TemperatureZone descrive ..</Description>

is pretty straight forward and a nice way in my opinion.

So thanks for your effort so far, I will wait and see 🙂

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 267

Currently Online:
13 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

hbrackel: 103

pramanj: 86

ibrahim: 70

kapsl: 57

gjevremovic: 49

TimK: 41

Fransua33: 39

fred: 38

Rainer Versteeg: 32

Thomas Reuther: 31

Member Stats:

Guest Posters: 0

Members: 1160

Moderators: 15

Admins: 1

Forum Stats:

Groups: 3

Forums: 15

Topics: 1048

Posts: 4416

Newest Members:

jonas.rahm, sophiekohler, zqecortney, adeletoscano947, forestgenders23, auroratrumper, ericmclain04, rblu, starlowery23194, dakotadalgety82

Moderators: Jouni Aro: 853, Otso Palonen: 32, Tuomas Hiltunen: 5, janimakela: 0, Pyry: 1, Terho: 0, Petri: 0, Bjarne Boström: 579, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Teppo Uimonen: 21, Markus Johansson: 24, Matti Siponen: 72, Lusetti: 0

Administrators: admin: 1