Content Workspace: Add variant sync when switching app culture (closes #16853)

[engijlr]

Summary

Adds a check in the appLanguageCulture observer in document-workspace-editor.element.ts. When the culture changes, if the user is on a single-variant view and the document has a variant for the new culture, it updates the URL to the new culture.

Test plan

• Create two languages (e.g. English and Spanish)
• Create a document type with "Allow vary by culture" enabled
• Create content with values in both languages
• Open the content node
• Switch the language in the sidebar picker
• Verify the workspace content switches to the selected language

Fixes #16853

[claude]

Claude finished @engijlr's task in 2m 45s —— View job

---

PR Review

Target: origin/main · Based on commit: 37b25a38

Fixes the language-switch UX bug (#16853): when the app language context changes and the user is viewing a single-variant document route matching the previous culture, the URL is synchronously updated via history.replaceState to the new culture — provided a variant for the new culture exists.

---

Suggestions

• document-workspace-editor.element.ts:44: The replaceState call preserves window.location.search but omits window.location.hash. The existing fallback in #generateRoutes() (line 150) also omits it, so this is consistent with the existing code — but since you're already threading through the query string, it would be worth rounding this out with + window.location.hash for correctness in edge cases where a fragment is present.

• document-workspace-editor.element.ts:40–45: The new lines use + string concatenation (this.#workspaceRoute + '/' + previousCulture) while the equivalent line already in #generateRoutes() uses a template literal (\${this.#workspaceRoute}/${path}...``). Consider switching to template literals for consistency with the surrounding code:

  const expectedOldPath = `${this.#workspaceRoute}/${previousCulture}`;
  // ...
  history.replaceState(null, '', `${this.#workspaceRoute}/${appCulture}${window.location.search}`);

• No tests added. Per project conventions, new behavior should have accompanying tests. This is a browser-routing concern (making it hard to cover with a pure unit test), but if there's an existing workspace-editor or router test harness, it would be worth adding a case that verifies the URL is updated on culture change and is left unchanged on split-view paths.

---

Notes

Ordering: #generateRoutes() is called before history.replaceState. Because Lit batches re-renders as microtasks, both the _routes update and the URL update complete synchronously before any re-render occurs. The router slot sees the correct routes and URL together — no timing issue here.

Split-view paths are correctly left alone: currentPath === expectedOldPath will not match a culture1_&_culture2 URL.

Media Workspace Editor: The TODO comment on line 10 notes that this element is "fully identical" with the Media Workspace Editor. However, UmbMediaWorkspaceEditorElement does not consume UMB_APP_LANGUAGE_CONTEXT at all, so this fix is not needed there.

No breaking changes detected. The change modifies internal behavior only — no public API surface, no exported types, no custom element interface changes.

---

Approved with Suggestions for improvement

Good to go, but please carefully consider the importance of the suggestions.

[AndyButland]

I was just looking to tackle the testing part of this @engijlr. Looks a nice addition and editor friendly update. It mostly works fine, but I found a few edge cases.

• Go to a variant page, switch language - the document language switches. ✅
• Go to an invariant page, switch language - no change. ✅
• Go to a variant page, click to the "Info" view, switch language - this now doesn't work. It also doesn't work when I switch back to the "Content" view. I have to click to another page for it to start working again. ❌
• Go to a page that varies by culture and segment, open the default segment in one language, switch language - the document language switches. ✅
• Go to a page that varies by culture and segment, open a non-default segment in one language, switch language - no change. I'd expect to go to the same segment, or at least the default segment, on the selected language ❌

[nielslyngsoe]

Great