Alternatives attribute not coming on Detect endpoint

[10260268]

Hi, can you please provide an example of the predict API where the "alternatives" object is returned in the results? I haven't seen that attribute in a while and I'm not sure if was just removed and the documentation hasn't been updated, or it is just that the algorithm changed and we are getting it in exclusive scenarios.

I used to get "alternatives" in "es" language when I tried to detect "Hotel" which is a valid word in English and Spanish,

I use this service within Azure bots, where some of them uses translator to make them available worldwide across the organization without the need of creating and maintaining QnA Maker KBs in every language,

The solution implemented the Microsoft Translator API for that, depending on the alternatives to maintain the user language if there was an alternative with his previous activity language with high score, but now since I'm not getting alternatives I had to disable that feature,

For example, in a bot developed for helping on FAQs regarding corporative travel and expenses, with English as primary language we can have the below transcript

User says: "Hola"

• [Bot passes user message to translator api to detect user language]
• [detected language returned is "es"]
• [the bot compares the detected result ("es") to the default language ("en")]
• [since the user detected language is different of the current one used for the conversation we also translate the response (from QnA Maker or dialog file) from "en" to "es"]

Bot says: "Hola, mucho gusto, como puedo ayudarte?" User says: "Hotel"

• [Bot passes user message to translator api to detect user language]
• [detected language returned is "en"]
• [the bot compares the detected result ("en") to the default language ("en")]
• [since no alternative is returned, the bot assumes user language changed to "en"]

Bot says: "Hotel expenses are defined for country, please go to (link)[https://myintranetkb.com]

In the example above the expectation was to get an alternative language as "es" which could be used by the bot to maintain the language in the conversation but since I'm not getting that data anymore the bot just checks the main result which in this case makes the conversation change to "en" when it should be maintained in "es" Below is the curl example

curl --location --request POST 'https://api.cognitive.microsofttranslator.com/detect?api-version=3.0&textType=html&' \
--header 'Ocp-Apim-Subscription-Key: XXXX' \
--header 'Content-Type: application/json' \
--header 'Ocp-Apim-Subscription-Region: XXXX' \
--data-raw '[{"text":"Hotel"}]'

The request above returns

[
    {
        "language": "en",
        "score": 1.0,
        "isTranslationSupported": true,
        "isTransliterationSupported": false
    }
]

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 43893926-c1b5-5794-d1d2-0c0e0a558664
• Version Independent ID: 9546a20a-c5b2-6f01-5847-8adcabd14050
• Content: Translator Detect Method - Azure Cognitive Services
• Content Source: articles/cognitive-services/Translator/reference/v3-0-detect.md
• Service: cognitive-services
• Sub-service: translator-text
• GitHub Login: @laujan
• Microsoft Alias: lajanuar

[RohitMungi-MSFT]

@10260268 Thanks for the feedback. We are investigating the issue and will update you shortly.

[RohitMungi-MSFT]

@10260268 I can see that the input to the detect API is a single word. As per guidance:

The language auto-detection works better with longer input text.

I have just tried to use the word "Hotel" with a name like "Hotel Madrid" and the detect API returns "es" as detected language. It is possible that the model updates could detect a single word like "Hotel" as English only without any additional context.

In your scenario since you have already detected the first input as Spanish and responded back in Spanish, is it possible to set the language to "es" for rest of the conversation instead of checking or using the detect API for every input of the user?

I also checked the response from other scenarios and the API is returning alternatives as detected.

[10260268]

Hi @RohitMungi-MSFT thank you for the quick response! I understand the recommendations for translating long text for better results, but my issue comes when the users click on QnA follow-up prompts which are basically keywords, And the think with maintaining the first recognized language is that we have seen in the past that many users starts the conversation in english (default used language within our corp) but at some point they switch to their native language because they feel more comfortable, so only detecting the first message and keep that language for the entire conversations doesn't really solves the problem, Is there a way to force alternatives even in this scenarios? I tried using the parameter in you screenshot "alternatives=true" but got the same results,

I'm struggling to find the proper solution without adding more work to the bot owners asking them to recreate all their KBs for all the other languages

[RohitMungi-MSFT]

@10260268 In this case the response from API will provide alternatives based on the response from the model on which it is trained. End user will not have an option to force the response with a filter. I could pass the feedback to the product team to check if future iterations of the model can provide alternatives for such scenarios.

[10260268]

Hi @RohitMungi-MSFT,

Would be great if that could be added, basically bringing back old functionality, where when we provided too ambiguous data like keywords as input, the response would gave you a full list of alternatives with their scores, so that way it's our decision how the application should behave in every scenario, for example continuing with same language in a conversation if the current language is part of the alternatives and has a high score, or ask the user to confirm if they are switching languages and to which one if some alternatives have a very close score.

Please let me know if there is anything I can do to put this into the table, ticket, git issue, etc

Really appreciate all your help!

[RohitMungi-MSFT]

@10260268 You can add a feedback item/idea on this page. It would be helpful if you could add the example that you mentioned previously worked with multiple alternatives in the item.

[RohitMungi-MSFT]

@10260268 I will go ahead and close this issue since there is no documentation update pending. Will also pass the feedback to the service team about your use case. Thanks a lot for sharing these details.