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

[zJaaal]

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: Edit Page: "Create New Language Version?" dialog appears when switching to existing language translation #35647
• Original PR (merged then reverted): Issue 35647 translate content on page not working #36231
• Revert PR: Revert "Issue 35647 translate content on page not working" #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

[zJaaal]

Spike Results

Demo video:

Screen.Recording.2026-06-29.at.1.10.58.PM.mov

What was prototyped

On a throwaway branch, the language-switch flow was changed to auto-create the language version programmatically instead of opening the legacy confirmation dialog + edit-contentlet iframe:

• Both triggers (toolbar onLanguageSelected and the editor $translatePageEffect) now fire a workflow NEW action via DotWorkflowActionsFireService.newContentlet(...).
• The new version copies all of the source page's primitive field values, preserves identifier and contentType (same page, same type), overrides languageId, and uses indexPolicy=WAIT_FOR.
• On success it shows a toast ("A new page version was created in {language}") and reloads via pageLoad({ language_id }).

Findings

1. For a normal page, auto-create is technically feasible. The workflow NEW action with the same identifier + new languageId creates the language version, and pageLoad re-renders it. Building blocks already exist (DotWorkflowActionsFireService, content-type/field services, pageLoad).

2. Auto-create removes two things users rely on:

• The opt-in / Cancel — switching language is a navigation gesture; auto-create turns it into a silent write with no way to back out. A casual language switch starts creating versions nobody intended.
• The edit-at-creation moment — no form opens, so custom per-language fields (SEO tags, meta, title) can't be set at creation; the user must go to page properties afterwards. The toast mitigates awareness but not the lost edit step.

3. URL-content-map (detail) pages are broken end-to-end — and it's pre-existing, not caused by the spike. Filed as #36355. On a detail page:

• Detection checks the page's languages (getLanguagesUsedPage), not the content's (getAvailableContentLanguages / ?contentInode=).
• The action translates the detail page, not the urlContentMap content.
• The "Edit URL Content Map" button opens the source/English version, not the selected language.
• Even after translating the content, the page API returns the bare detail page and does not bind the translated content (backend URL-map resolution per language). → This makes it FE + BE.

Suggested follow-ups:

• Prioritize UVE language switch on detail pages checks/translates the page, not the urlContentMap content #36355 (detail-page translation) — it's the higher-impact, genuinely-broken case.
• Capture this decision in an ADR.

Posted by Claude on behalf of @jalinson.diaz.

[github-actions]

PRs linked to this issue

• feat(uve): auto-create page language version on language switch (#36348) by @zJaaal