Skip to content
This repository was archived by the owner on Dec 4, 2023. It is now read-only.
This repository was archived by the owner on Dec 4, 2023. It is now read-only.

port: Localization: fix bugs around inconsistent locale + first step to centralize locale resolution (#5218) #988

@github-actions

Description

@github-actions

The changes in Localization: fix bugs around inconsistent locale + first step to centralize locale resolution (#5218) may need to be ported to maintain parity with microsoft/botbuilder-dotnet.

Fixes #5101

Description

Current locale resolution is inconsistent and can lead to scenarios where different components honor different locales. We want to get to a point where 1) locale resolution is centralized and 2) locale resolution is configurable. We are not doing that here. The aim of this PR is to have all components receive locale first from a single location (dialogContext.GetLocale()). This location is not ideal but it is public surface and we have to support it. The result after this pr is:

  • DialogContext.GetLocale() prioritizes turn.locale > turn.activity.locale > default language
  • Dialogs and LG use DialogContext.GetLocale as main locale source
  • Locale is honored consistently in SDK
  • Locale change works smoothly

Testing

Regression testing passed and new tests added. Working on a e2e multilanguage sample with language selection based on this code (which is currently impossible to build without this PR).

What happens if we don't take this?

  • Broken scenario 1 - locale consistency: Most of the bot takes the turn.locale as source of truth. Other components (confirm input, choice input, multi language generator) will take activity locale as source of truth. Result: the bot mixes 2 locales.

  • Broken scenario 2 - Language selection: I'm a bot author. I support english and spanish. Current locale is en-us. If the user says 'espanol', I have a SetProperty that will set turn.locale=es-ar, and the bot should speak in spanish. Result without this PR: the bot will not change language.

Next steps

  • Create design for users to provide their own locale resolution logic, both code-first and declarative (ordered list of memory scopes)
  • Deprecate public area that is not consistent and / or intuitive: TurnContext.Locale, DialogContext.GetLocale(), ChoiceInput.DefaultLocale, ConfirmInput.DefaultLocale, etc

Please review and, if necessary, port the changes.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Area: SDKGeneral SDK issues that don't clearly map to other areas (e.g.: helper methods)ExemptFromDailyDRIReportUse this label to exclude the issue from the DRI report.P1Painful if we don't fix, won't block releasingparityThe issue describes a gap in parity between two or more platforms.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions