02/23/2023
Hello, I am an OPC UA newbie. I would like to have an enum, where the values have different names, based on the current locale.
My understanding of the enums is this: Enum Data Types have an EnumString property, containing a list of LocalizedTexts. Using the enum variable’s numeric value as the index of this list, the variable’s named value can be found. E.g. EnumString = [“en|On”, “en|Off”, “en|Starting”] and the variable’s value is 1, then the named value is “en|Off”.
Questions:
a) Can the values of the EnumString contain texts for multiple locales somehow? E.g. [“en|On;de|Ein”, “en|Off;de|Aus”, “en|Starting;de|Startet”] and if the variable’s value is 1, then the named value is “en|Off” or “de|Aus” depending on the current locale?
b) If this is not possible, what is the point of having localized texts in the enum’s definition?
c) Is the sitation the same when using EnumValues instead of EnumStrings?
Thanks!
05/30/2017
When a session is created the client provides its preferred locales.
All LocalizedTexts returned use the preferred locales for the Session.
So a Session that asked for “de” would get “de” LocalizedTexts if they are available.
The value of the enum is not affected by the exact text that is returned for EnumString and no programmatic comparisons can be done with LocalizedTexts. The numeric value must always be used.
02/23/2023
Thank you for your response. What you describe is exactly what I expected and what I need.
The problem is, that the LocalizedText seems to be a single locale-text pair, one locale and one text, not various translations of the given string. And if the LocalizedText can only hold a single string, how would the server know what are its translations?
Or did I miss something, and can a LocalizedText hold multiple translations?
02/23/2023
In the meanwhile I realized the root of my confusion. I mixed together client and server side representations.
– LocalizedText is meant for the client, who only needs 1 string and the additional information, which language does it have.
– How exactly the various translations are configured and stored in the server, that is a server specific detail, and does not need to follow the LocalizedText’s structure.
05/30/2017
https://reference.opcfoundatio…..s/5.10.4.1
If a Server allows writing of Attributes with the DataType LocalizedText, the Client can add or overwrite the text for a locale by writing the text with the associated LocaleId. Writing a null String for the text for a locale shall delete the String for that locale. Writing a null String for the locale and a non-null String for the text is setting the text for an invariant locale. Writing a null String for the text and a null String for the locale shall delete the entries for all locales. If a Client attempts to write a locale that is either syntactically invalid or not supported, the Server returns Bad_LocaleNotSupported. The Write behaviour for Value Attributes with a LocalizedText DataType is Server specific but it is recommended to follow the same rules.
1 Guest(s)