Spike: prototype auto-creating a page language version on language switch in UVE

Research Question

When a user switches a page to a language that has no page version yet, UVE today shows a confirmation dialog ("Page does not exist in the selected language. Create a new version in [language]?"). A customer wants this friction removed.

Can we — and should we — replace that dialog by auto-creating the page's language version on the fly (fetch the content type, read the required fields, copy the current page's data, fire a workflow action to create the version in the selected language, then switch the store to that language) without breaking the multilingual UVE feature surface?

Going-in recommendation: keep the confirmation dialog as a guardrail. The dialog is not just friction — it is the user's opt-in to a write. Switching the viewing language is a read/navigation action; making it silently create content is a behavior change for every customer to satisfy one. This spike exists to prototype the auto-create flow and record a video so the team can make the call with eyes open rather than in the abstract.

Timebox

8h

Acceptance Criteria

• Prototype the auto-create flow in UVE: on switching to an untranslated language, fetch the page's content type, resolve required fields, copy the current page's field values, trigger the workflow create/translate action to create the version in the target language, then switch the store's language so UVE re-renders.
• Record a video demonstrating the prototype end-to-end, including the contrast that makes the decision concrete:
  • Auto-create path: a language switch silently produces a new page version.
  • Current path: the confirmation dialog, and the Cancel branch that produces no page version.
• Exercise the multilingual UVE feature surface against the prototype and note any breakage: Experiments, Style Editor, Quick Edit Form, Time Machine, GEO/SEO, and basic content add/edit on the newly created version.
• Document findings: what works, what breaks, and the edge cases (e.g. required fields with no source value, page-specific properties like custom SEO tags not being editable at creation time).
• Provide a recommendation comparing the two options:
  • Option A — Silent auto-create on switch (Will/Freddy's "create on the fly"): loses the explicit edit-at-creation moment and the cancel safety.
  • Option B — Keep the confirmation dialog (recommended): preserves the opt-in, lets the user cancel, keeps UVE's "pages always have a language version" invariant intact.
• Feed the decision into an ADR so the rationale is captured and not re-litigated by the next customer request.

Context

This is the return of a previously-fixed behavior. UVE was architected around the assumption that a page always has a language version before content is edited in that language. Years of multilingual features (Experiments, Style Editor, Quick Edit, Time Machine, GEO/SEO) grew on top of that invariant.

A customer that recently upgraded from a very old dotCMS version doesn't have per-language pages — they author everything in English, and when they switch language they expect the content to "just work" without being asked to create a page version. That request produced #35647 and PR #36231, which removed the forced page-version creation. The PR merged and was then reverted (#36256) before release because:

1. The change is architecturally sensitive — UVE never accounted for pages with content in a language but no page version in that language.
2. There was no realistic QA runway (a ~2-day window before release) to validate the full multilingual feature surface.

Important nuance from testing: the current flow already works correctly. If the user accepts the dialog and creates the version, nothing extra is required — it just works. The customer's complaint is rooted in not understanding why the step exists, which is a UX/education problem, not a functional defect. Removing the guardrail product-wide to solve one customer's misunderstanding risks breaking more customers than it helps, and removes a safety the cancel branch provides (users who switch language just to look, and don't want a version created).

The proposed auto-create approach is the middle path Will/Freddy raised ("create the lang on the fly"). This spike is to find out whether it is safe and whether it is actually the right product behavior — or whether the confirmation dialog should stay.

Links

• Original issue: dotCMS/core#35647
• Original PR (merged then reverted): dotCMS/core#36231
• Revert PR: dotCMS/core#36256
• Current confirmation/translation flow: core-web/libs/portlets/edit-ema/portlet/src/lib/edit-ema-editor/edit-ema-editor.component.ts — createNewTranslation() (~L1691), translatePage() (~L1713), #goBackToCurrentLanguage() (~L1722)
• Store language/page-load: core-web/libs/portlets/edit-ema/portlet/src/lib/store/features/page-api/withPageApi.ts