Specific Locale passed into webchat is not being sent to Bot service. (HealthBot)

Screenshots

Version

https://cdn.botframework.com/botframework-webchat/latest/webchat-es5.gzip.js

To determine what version of Web Chat you are running, open your browser’s development tools, and paste the following line of code into the console.

[].map.call(document.head.querySelectorAll('meta[name^="botframework-"]'), function (meta) { return meta.outerHTML; }).join('\n')

If you are using Web Chat outside of a browser, please specify your hosting environment. For example, React Native on iOS, Cordova on Android, SharePoint, PowerApps, etc.

Describe the bug

Looks as though if I pass in a locale “es-US”, it will send “es-ES” to the HealthBot service when posting activities. It seems the chatbot js only supports es-ES as a locale for it’s strings and then therefore sending on this locale to the service. It’d be ideal that the locale passed in to the chatbot can translate to es-ES for the chatbot strings however respect the intention and forward on the locale that was passed in.

Steps to reproduce

1. Pass in locale “es-US” to store.dispatch({ type: ‘DIRECT_LINE/POST_ACTIVITY’, meta: { method: ‘keyboard’ }, payload: { activity: { type: “invoke”, name: “InitConversation”, locale: “es-US” …
2. Bot text is based on “es-ES” locale.

Expected behavior

Would like to see that the culture passed in is respected to forward on to botsvc.

Additional context

This was found using the HealthBot service as we created localization files for “es-US”.

[Bug]

[compulim]

We have this fallback logic in-place already in normalizeLanguage.js.

But we do this fallback too early, so the bot is not receiving he-IL, but only he. I have a PR up, so we are passing the locale as-is to the bot, even it is an invalid locale.

[beyackle]

I think the standard way to do a fallback is to just drop the country code entirely. If we don’t support es-US, then the next language we should look for is just es, not necessarily es-ES. If it can’t find es without a country code, then that’s a problem - I don’t know if there’s a policy about this, but I’d expect every language to have a sensible default when the country code is unspecified. Similarly, he-IL isn’t in the list, but the fallback should find he, which is.