The Knowledge API and JS Client provide respectively an endpoint and a method that make it possible to detect the language of a user query. If your Inbenta solution includes multiple Inbenta instances in different languages, this allows you to suggest which one of these instances appears to be the best suited to provide results to this query. If you only have one instance, it obviously becomes the best and only option. With this, you can then suggest which one of your Inbenta instances would be the best suited to provide results to this question. If you have only one instance, it becomes the best one.
Inbenta's language detection can only recognize the languages associated with your instances. If you need other languages to be detected as well, you may need to use another language detection system from a third-party provider.
There are several ways you can use the language detector functionality. The diagram below illustrate the two solutions more frequently used by Inbenta clients:
There are two factors to consider when you decide to adopt one solution over the other:
You must take into account that if you use the first option, all user question, including the ones in unexpected languages, are registered in the system as user questions.
The solution that perform less requests to the API, and thus is more cost effective, depends on the number of user questions that you receive that are in an unexpected language. This is why Inbenta recommends the first option: if you get very few of these questions, then the second option is very expensive for minimal gains. It only becomes cheaper if you typically receive roughly a third or more of your user questions in an unexpected language.