Discussion during Dallas Meeting

Create a structure containing
{
ResourceId String
Data Array of Variant
}

Each Event Field that needs to be localized need a counterpart with that structure. Each Variable need a counterpart with that structure. We should define a best practice for names (e.g. Message + MessageResourceId).

In addition, server provides StringTable with the templates for resources clients can access.

That should solve the direct communication part. Could potentially also be used for Publisher, putting string tables into the Metadata.

Another issue that came up during discussion: What is the big picture? How is localization managed in a system with many servers? What about aggrgating servers.
General idea: We should define a global server interface where applications can ask for string templates in many languages based on ResourceIds. Here, we need to consider, that different servers might use the same ResourceId for different resources, so somehow the server context (e.g. ServerUri) need to be considered as well. Similar issues occure in aggregating servers, where they might aggregate servers using the same ResourceId for different resources.
This needs to be worked out in more detail.

Notes from 2020-07-28 Telecon:

We had a long discussion and think we came to an elegant solution that will work in all places the LocalizedText datatype is used. We will define our own locale for "UA machine readable" and store a Uuencoded UA binary structure in the Text string that contains all of the data necessary for the Client to constrict the final string based on the string fragments and replaceable parameters in the UA binary structure. Further details need to be worked out and discussed further.

discuss this issue in UA working group call - proposed a solution using a specific locale - attached slides help illustrate it

Thinking about this a bit more I think we can introduce this as follows:
In Part 3 expand the definition of LocalizedText and LocaleId to describe the specific use of the Locale code we will use to return multiple languages.
In Part 6 describe the format to be used to return the multiple languages as a JSON array of LocalizedText objects (i.e. localeId and text).

With this approach it is not limited to events and would apply to all uses of LocalizedText in all parts. Specifically if a session is established with the special multiple language LocaleId as the first priority then all LocalizedText will be returned by the server as JSON encoded arrays of all available languages for that LocalizedText Variable. Existing client are not affected as they will be requesting specific localeIds.

These notes outline 2 different mechanisms for providing localized text messages.

We should consider the pros and cons of each - events-only vs all localized text, performance, efficiency, scalability, complexity, resource requirements, etc.
Use cases: embedded versus desktop, standalone vs aggregating, client-side vs server-side costs, etc.

Commit Date 2023-09-01

All text in Part 3 and Part 4 has been reviewed and accepted. Cloning this issue to both Parts for final integration into editor drafts.

Added following text received as input:

5.4 Locale Negotiation
A number of Services expect an array of LocaleIds which are used by a Server to determine in what language or languages LocalizedText should be returned.
The array of LocaleIds is in the preferred order the Client would like the Server to use when selecting the locale of the LocalizedText to be returned. The first LocaleId in the list is the most preferred. If the Server returns a LocalizedText to the Client, the Server shall return the translation which is the most preferred that it can. If it does not have a translation for any of the locales identified in this list, then it shall return the LocalizedText that it has. See OPC 10000-3 for more details on LocaleIds. If the Client fails to specify at least one LocaleId, the Server shall return any one that it has.
Multi-language LocalizedText can be requested using the special ‘mul’ or ‘qst’ locales as the first entry of the list. If there are no further entries, the Server shall return all languages available. If there are more languages included after ‘mul’, the Server shall return only those languages from that list. If the Server doesn’t have a translation for any of the locales included in the list, then it shall return the LocalizeText that it has. See OPC 10000-3 for detail of the special locales and how LocalizedText is used with them.
If a Client requests ‘mul’ it shall be prepared to receive a ‘mul’ or another locale, but not ‘qst’ depending on what the Server can provide for a particular LocalizedText.
If a Client requests ‘qst’ it shall be prepared to receive a ‘qst’, ‘mul’ or another locale depending on what the Server can provide for a particular LocalizedText.

Agreed to changes edited in Dallas F2F.