This module allows users to build an entire application in their default language and to then give the end-user the ability to set the active language for a call when there are multiple language options.
There is no need to clone the application or design additional branching to accommodate additional languages because the audio prompts differ. All available languages follow the exact same call-flow. The Audio Manager automatically creates prompt fields for every language added to an application that map onto the existing prompts of the call-flow. You can then fill-in those fields with language-appropriate text prompts or pre-recorded audio. Prompt content for alternative languages can be edited, managed, and modified in the application’s global Audio Manager section.
Each language has its own unique set of prompt for all modules in the application. Changes in one language do not push to the other languages available, they will have to be managed individually under each language tab. See Languages for more information.
To change the order in which language options are presented to end-users, use the up and down arrows next to the language name in the module.
English (USA, UK, Australia)
Portuguese (Brazil, Portugal)
If you need to know which language the caller has selected, accessing the variable will return the language that has been selected.
For example, sample_language should have a value of “en-US” if English was selected, or “es-US” if Spanish (US) was selected.
With this module, in addition to the user prompt text ( ex: “Please select your language.”), a built-in prompt () entry (ex: “For English, press 1.” ) will be automatically created in the Prompt Table.
The built-in prompt can be changed to a different text, or blank out completely if the entire menu audio resides with the user prompt text.
To see the prompt in other languages (ex: “For French, press 2” equivalent in French), go under the that corresponding language's tab.
This setting allows callers to interrupt a prompt before it finishes playing. When enabled, DTMF input interrupts the prompt and progresses the call forward in the call-flow. If speech recognition is enabled on the ensuing module in the call-flow, then end-users can also interrupt the prompt with a spoken utterance, too. Disabling barge-in forces callers to listen to the entire prompt. A barge-in enabled module will have a dashed line on top of the text box. See example here.
Enabling this setting overrides the default, global error options set in the Application Settings > User Input Settings. This allows users to establish custom error handling in order to act on errors in a specific way in that module. Instead of progressing to the next module in the call-flow, custom error handling allows users to re-prompt the same module, to provide a custom error message, to re-direct the call based on the error, or any other desired behavior. Adding multiple errors () to a module functions behave the same way as a counter. The first error follows the path for the first error listed, if a second error occurs in the same module it follows the second listed error, and so on until all errors are exhausted or an error directs the end-user away from that module. No Input occurs when the caller does not provide an input based on the timeout settings. This is based on the “Initial input timeout” in User Input Settings No Match occurs when the caller input does not match the module's criteria for the input module.
Advanced Fuse users may want to use shadow variables that are available with input modules. For more information on this functionality, please visit the Shadow Variables page.