Optimizing your language detection volumes

The purpose of this article is to help developers make sure that they employ best practices when they design API calls, most notably (but not limited to):

• Calling the language detection function
• Ensuring correct detection
• Reducing latency to a minimum

As a rule, you should aim to create requests that minimize language detection volumes. Minimizing detection volumes avoids both extra latency and extra cost. It also limits the risk of hitting the API's throttling or rate limits prematurely.

Calling the language detection function

The language detection function uses the Locale API Route. Its purpose is to detect what language the end user is using to speak to your agents, so that you can translate the conversation from and to this language. 

When you develop your integration, you should ideally only set it to detect the language once, rather than with each translation request. You can then store the response as a variable value, and refer to it for your translation calls.

It is possible to build your solution to request language detection with each translation request but it is not recommended: It can increase the translation turn around time, especially with longer pieces of content, and it incurs additional billing costs because both language detection calls and translation requests are billed. If you think that your use case requires a language detection call for each translation call, submit a support request. 

Alternate methods

There are also alternate methods to language detection such as creating a selection menu for the end user, or detect the browser locale of the end user (for example, detecting the Accept-Language HTTP header of the browser, that contains the user's browser language preference) to set the translation language. In such cases, you can use the user-selected value or the detected header value to use in your translation calls. 

You can build the detection function to act as a backup in case these values are empty.

Ensuring correct language detection

Make sure that the source locale is correctly detected and set before sending requests. 

For faster and more accurate language detection, use a partial translation (for example, up to 150 characters) rather than a full message.

You should be familiar with the list of supported languages and their corresponding language codes.

Using the wrong language code can lead to quality issues and increased latency (due to the necessary re-detection). 

Examples of inaccurate language detection

• Through automated detection: the system could inaccurately mix up Danish and Norwegien, for example with the phrase "Min bestilling er sen" ("My order is late") being identical in both language.
• Through human error: If a Slovak end user were to mistype "Dobrý den" instead of "Dobrý deň" ("Good day"), the initial detection will identify the language as Czech, especially if they follow up with "Mám problém s objednávkou." ("I have a problem with my order") as the sentence is the same in both languages.

Calling the language detection function to re-detect the language when it changes or the detection was inaccurate

You can build a way for your agent to use the language detection function to re-detect the language if an end user switches to another language mid-conversation, or if the detected language is not accurate. 

Reducing latency to a minimum

As a rule, you should try to reduce latency to a minimum.

This can be achieved by a careful selection of the features that you actually want to use, and an understanding of each feature's advantage and cost/benefit ratio. In the next article, you can explore a comprehensive list of all the Language IO features available with the API includes, why they should or should not be used in a given scenario, and their cost and benefit:

Features available with the Language IO API