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.

Part 4 changes are complete and accepted in the 1.05.04 draft.

fixed with related issue.