Respect configured TypeScript diagnostic locale

[Copilot]

The native extension always used VS Code’s display language for diagnostics, ignoring explicit js/ts.locale and legacy typescript.locale overrides.

• Locale resolution

  • Prefer js/ts.locale, then typescript.locale.
  • Use the editor display language when set to auto.

• Configuration updates

  • Restart the running language server when either locale setting changes.

{
  "js/ts.locale": "en"
}

[Copilot]

Pull request overview

Adds support for configured TypeScript diagnostic locales in the native extension.

Changes:

• Resolves unified and legacy locale settings.
• Restarts the language server when locale configuration changes.

Show a summary per file

File	Description
_extension/src/client.ts	Applies configured locale during client initialization.
_extension/src/extension.ts	Restarts active sessions after locale changes.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Medium

[jakebailey]

Maybe it's cleaner to just have a Client hook that sets the current locale, and we update that on user pref change and plumb it that way?

[DanielRosenwasser]

Sure, @copilot do what Jake suggested.

[Copilot]

Sure, @copilot do what Jake suggested.

Done. Client.start() now resolves the locale once from config and passes it to NativePreviewLanguageClient as a constructor argument. getLocale() just returns the stored value rather than reading config on every call. The restart on locale change in extension.ts ensures a new Client is created and picks up the updated locale at start time.

[jakebailey]

It didn't understand what I said, I meant the Client in the server, as in project.Client

[DanielRosenwasser]

@copilot sounds like you need to make some adjustments.

[Copilot]

@copilot sounds like you need to make some adjustments.

Done. Here's what changed:

• project.Client (internal/project/client.go): added GetLocale() locale.Locale
• *Server (internal/lsp/server.go): implements GetLocale() returning s.locale; handleDidChangeWorkspaceConfiguration now also calls localeFromSettings() to update s.locale when the user's locale preference changes — "auto"/missing falls back to s.initLocale (the locale negotiated in initialize, which already resolved "auto" to the editor display language on the extension side)
• session.publishProjectDiagnostics: injects locale.WithLocale(ctx, s.client.GetLocale()) so push-diagnostic messages are correctly localised even when running on the background context (which has no locale set by the dispatch loop)
• Extension (extension.ts): removed the locale-change restart handler — locale updates are now handled server-side via workspace/didChangeConfiguration

[jakebailey]

@copilot This is still wrong. There should be no client side element. There should be a UserPreference that reads the locale, and Project should call back through Client to set a new locale, if present.

[Copilot]

@copilot This is still wrong. There should be no client side element. There should be a UserPreference that reads the locale, and Project should call back through Client to set a new local...

Addressed in e83a1d7. Locale is now parsed as a UserPreferences value, Session.Configure calls project.Client.SetLocale when present, and all extension-side locale handling has been removed.

[jakebailey]

@copilot This is new; do we have an existing bug? Should we have attached the locale somewhere else above? What's the deal?

[Copilot]

Yes, this fixes an existing push-diagnostics bug. Pull diagnostics use request contexts decorated with the current locale, but push diagnostics run from the session background context, which has none. Localization happens here during DiagnosticToLSPPush, and attaching the locale to the background context at session creation would freeze it and miss later preference changes, so reading the current client locale at this conversion boundary is intentional.

[jakebailey]

@copilot Perhaps Session should have a func that returns the background context + this that everyone can use instead of accessing backgroundCtx directly? This seems like a very easy mistake to make

[Copilot]

Implemented in 2f11d43, with the queued-locale follow-up in 992a6cf. Session.backgroundContext() now centralizes locale decoration for all background-context access, and diagnostic publication refreshes the locale at conversion time so queued work cannot use a stale preference.