Support for localization in the protocol

[nirmalnr]

There can be many use cases especially in a diverse country like India to support catalogs in multiple languages. Wanted to start a discussion in the working group to understand if this has been thought of or solved. Essentially I feel this feature should enable the following:

1. Allow a BAP to declare their preferred language for the catalog/any forms that may be involved in the order.
2. Allow a BPP to declare the languages of for catalog/any form they may send.
3. Allow a BPP to declare the languages supported by them.

[nirmalnr]

Proposed solution 1
Adding these in context object
Here we will add two properties in context object as below:

        language:
          description: Language in which the descriptor objects in the API are in
          type: object
		  properties:
			name:
				description: Name of the language
				type: string
			code:
				description: Language code in ISO639-1:2002 
        supported_languages:
          description: The language codes supported by the entity. This can be used by BAP/BPP to declare it supports these languages.
          type: array
          items:
            $ref: '#/components/schemas/Context/properties/language'

[nirmalnr]

Proposed solution 2
Adding these as tags

For this tag group named localization with tags language and supported_language in them can be used. These tags will be supported in the following objects:

• Intent
• Order
• Catalog (Currently does not have tags property in schema)

[ravi-prakash-v]

Localization is an experience layer functionality. Conventionally, the standard language for communication is English. BAP or BPP may convert the data from English into whatever language they need to. Why would we need localization during transmission?

[vbabuEM]

There are a couple of reasons where direct language support is better than translation. One could be that many a times the intent gets lost in translation and direct communication in local language is better. Second is that it reduces cost of operation if we do not need translation. Having said that the encoding of JSON allows transmission in local language. So the support at one level is already built in. What might help is some method to convey preferences, negotiation on language during requests/responses etc. I think most objects that need these have tags through which this can be achieved.

[ravi-prakash-v]

To avoid information loss, every message object can have a root level descriptor property that allows raw data to be transmitted as text, audio, docs, video or any other format. This is especially useful when LLMs are involved.

I propose a new property called message.descriptor that can be set in all message packets.

[nirmalnr]

Can you give an example of this? Having trouble understanding how this works.

[ravi-prakash-v]

Another thing to be considered is which properties allow for localization. As mentioned earlier, descriptor objects can allow localization. But for properties that allow only enumerated value, localization should not be allowed.

Also, it's important for the NP to know beforehand what languages are supported by the other NP. Maybe a meta API like supported_languages implemented by every NP, or an additional field in the registry lookup response.

Once the communicating parties know which NPs support what languages, we could have a context.lang property that specifies which language needs to be used in the descriptor objects during a specific interaction.

Also, NPs will need to continuously watch the context.lang property in case it changes in the middle of the transaction.

@pramodkvarma your thoughts would be appreciated on this.