Identify active language and channel

Mix projects can support multiple languages and multiple channels.

Multiple languages allow the same application to cater to users based on their language and locale, both in the content of the dialog and in the UI of the application. For example, a customer service application could support English, French, and Spanish.

A channel in a Dialog application defines the user input and system output modalities that are presently supported. A Mix application can (though it does not necessarily have to) support multiple channels.

For example, a single customer service conversational UI application could support:

• Text-based web chat messaging
• Speech-based web chat
• IVR (telephony using voice and DTMF)

The active language and channel are important to know because they impact the UI elements that are presented to the user and also because they impact the input/output modalities enabled within the interface between the app and the user.

At runtime during a session, only one of the languages and channels defined for the Dialog application can be selected as the active language and channel at any given time. The current active language is tracked in a Dialog predefined variable, language, and the current active channel is tracked in the predefined session variable, channel.

The langage and channel can be updated at runtime from either the client-side and the backend side. They can also be read from different places in the API responses.

Client side language and channel update

The client side might want to set or change the language and channel based on the user’s selections for the language and type of chat session in the UI. For example, the user wants to use a text-based chat session rather than either of the voice-based chat options.

On the client-side, you can set the language and channel via a selector message in a StartRequest or ExecuteRequest.

Backend language update

The session language can be updated on based on logic in the dialog flow. For example, the user might be asked to select a language at the start of the session, or the language might be changed based on the user’s selections in the flow of the dialog.

Handling backend language updates

If you have a multi-language project with language changes within the flow of the dialog, it is possible for the active language to change within a message or a Question and Answer node. In this case you will need to handle the language change in your client application.

Include logic to check the language field within each of the message objects in the payload and keep track of the language for each message in relation to playing the messages.

Also include logic to check the language field within the QAAction object in the payload and keep track of this language setting in relation to collecting user input.

Backend channel update

The Dialog flow might need to change the channel based on conditional business logic. For example, it might make sense to fall back to a text-based chat if noise in the environment is causing too much NO_MATCH for the user’s speech inputs. Another example would be to switch from an IVR speech channel to an IVR DTMF channel for the same sort of reason, or if the user has to enter sensitive information like a credit card number. This sort of logic can be configured in Mix.dialog.

Handling backend channel updates

If you have a multi-channel project with channel changes within the flow of the dialog, it is possible for the active channel to change from one turn to the next, and even between messages in the same turn. In this case you will need to handle the channel change in your client application.

Include logic to check the channel field at the top level of the ExecuteResponsePayload message and handle any relevant actions related to changing the channel for the turn.

Also include logic to check the channel field within each of the message objects in the payload and keep track of the channel for each message in relation to playing the messages.