Hi,
Thanks for the detailed follow-up!
On point 2 — base detection on System.Activity.Text:
If your flow already reads `System.Activity.Text` to detect the language, that's great. The key question is: does this detection run *only once* at conversation start, or does it re-run on *every* user message? If it only runs once, the variable will stay stuck on the first detected language even when the user switches. Could you confirm this? That would help narrow things down.
On point 3 — re-evaluating language on every turn:
Here's a concrete way to implement this. In Copilot Studio, you can use the **"On Unknown Intent"** system topic (or a custom global topic set to intercept all messages) to run a small language check at the start of every turn:
- Add a **Set Variable** node that reads `System.Activity.Text`.
- Add a **Condition** to detect the language of that text (e.g. via a Power Automate flow or a regex/keyword check for your three languages).
- If the detected language differs from the current language variable, update it.
This can be a separate lightweight topic that runs before your main topics, or you can embed this logic at the top of your existing "Dynamic language switching" topic if it's already structured as a global one. I'd recommend a separate topic to keep things clean.
On point 4 — web interface and Windows app both affected:
This is actually useful information. Since both the browser and desktop versions of Copilot Chat show the same behavior, it confirms the issue is tied to the M365 session context (which both clients share), not a rendering quirk. This makes it even more likely that the Dutch M365 account language is being injected as the session locale. Test #1 (with an English M365 account) becomes the most important next step.
In general
Yes, starting a new conversation *would* reset the session state completely, including any locale context injected by the M365 profile. So for purely single-language conversations, this would work reliably.
That said, I wouldn't recommend it as your primary solution for this deployment. Given that your users naturally speak Dutch, French, and English — and may switch within a single chat — a workaround that asks users to restart the conversation every time they change language would be frustrating and impractical. The "Dynamic language switching" topic remains necessary.
The new-conversation advice is worth documenting as a *fallback* for users who experience unexpected language behavior, but the real fix is getting per-turn re-evaluation working correctly in the published channel.
Looking forward to hearing your test results!
