Report wizard preview: cover-letter date caption uses the UI language beside a report-language date

[steilerDev]

[product-owner]

Priority: Could Have
Parent Epic: none — part of the parent-less Bank Report Wizard cluster (#1876–#1879, #1898–#1901, #1923).
Found during: PR #1924 round-2 verification (t-usage audit). Pre-existing on beta — not a regression from #1923/#1924.

Problem

The report wizard's editable preview renders the cover-letter date line as a UI-language label next to a report-language value, producing a single visually-joined line that mixes two languages. The same line has no counterpart in the exported PDF at all, so the preview also implies a label the artifact does not contain.

This is the same defect class that PR #1924 fixed for the inline Deposit badge, found while auditing the remaining t() call sites in the same component.

Actual

client/src/components/reports/ReportContentEditor.tsx L79–83:

<div className={styles.dateLineField}>
  <span className={styles.dateLineLabel}>
    {t('sourceReports.coverLetter.dateLabel')}:
  </span>
  <span className={styles.dateLineValue}>{content.coverLetter.dateLine}</span>
</div>

• The label comes from the component's UI t — ReportWizardPage.tsx L905 passes the useTranslation('budget') instance (L61), i.e. the interface locale.
• The value content.coverLetter.dateLine is built in buildReportContent.ts L255 via reportFormatters.formatDate(...), i.e. the report locale.

With UI language de and report language en, the preview renders:

Datum: February 15, 2026

Meanwhile client/src/lib/reportPdf/coverLetterPdf.ts L37 emits { text: coverLetter.dateLine } with no label whatsoever — the date stands alone (the conventional business-letter treatment in both en and de). So the exported PDF is correct and unaffected; only the preview is wrong.

Expected

No single rendered line in the preview mixes interface language and report language, and the preview does not present as artifact content anything the exported PDF does not contain.

Reproduction

1. Set the application interface language to German.
2. Go to /budget/reports and start the report wizard.
3. Step 4 (Settings): set report language to English, leave "include cover letter" on.
4. Step 5 (Preview & Export): read the date line above the reference/subject fields → Datum: February 15, 2026.
5. Export the PDF → the cover letter shows the bare date with no Date:/Datum: prefix.

(Reverse the two languages for the mirror-image case: Date: 15. Februar 2026.)

Product decision

The exported PDF is the artifact of record, and it deliberately carries no date label. Therefore the preview's Date: text is editor chrome, not artifact content — it exists only to tell the user what that value is. The fix should treat it as such rather than promoting it into the content model.

Recommended resolution: keep the label in the UI language (correct for chrome, consistent with the #1909 ruling on edit affordances) but present it with the same visual treatment as the other editor field captions, so it reads unambiguously as an editor caption rather than as part of the letter body. The exact styling is ux-designer's call.

Rejected alternative: moving dateLabel into ReportContentLabels via reportT and adding a matching label to the PDF. This would fix the language mismatch but changes the exported letter's layout for no user benefit, and departs from standard letter convention in both locales. Do not do this without an explicit product decision to redesign the letter head.

Acceptance Criteria

• 1 Given interface language de and report language en (and the mirror case), When the Step 5 preview renders the cover letter, Then the date line contains no string that mixes the two languages — the caption and the value are either both interface-language or both report-language, per the chosen resolution.
• 2 Given any interface/report language combination, When the cover letter preview renders, Then the date caption is visually distinguishable as editor chrome, consistent with how the other non-editable captions in the same panel are presented.
• 3 The exported PDF cover letter is unchanged — the date still renders as a bare, report-language-formatted date with no caption or prefix (coverLetterPdf.ts L37).
• 4 content.coverLetter.dateLine remains report-language-formatted via reportFormatters.formatDate — the value side of this defect is already correct and must not regress.
• 5 A unit test in ReportContentEditor.test.tsx pins the date-line rendering, and the PDF's label-free date line is pinned in coverLetterPdf.test.ts, so neither side can drift back.
• 6 Locale parity holds: sourceReports.coverLetter.dateLabel is present in en and de (or removed from both, if the chosen resolution drops it).

Notes

• Fold into the cover-letter overhaul if that lands first. There is planned cover-letter work coming out of user feedback on formatting, signature, and sender handling (not yet filed as an issue as of 2026-08-02). This defect sits squarely inside the letter head that the overhaul will touch. If that work item is created and scheduled before this one is picked up, close this as a duplicate and carry AC1–AC6 into it rather than fixing the same lines twice.
• Cross-reference — the reportT threading rule established in PR feat(reports): report table cleanup — shared footnotes, deposit labels, claim metadata, total-only summary, usage area (#1923) #1924. feat(reports): report table cleanup — shared footnotes, deposit labels, claim metadata, total-only summary, usage area (#1923) #1924 moved the inline Deposit label out of per-consumer t() calls and into the shared content model as ReportContentLabels.deposit, resolved once via reportT in buildReportContent.ts and consumed by both ReportContentEditor.tsx and overviewPdf.ts. The rule that came out of it: anything rendered as report artifact content must be resolved through reportT / the ReportContent model, never through the editor's UI t; only edit affordances (field labels, reset aria-labels, edited-suffix) use the UI t. That boundary was first drawn in PR feat(reports): editable HTML report preview with on-demand PDF export #1909 ("artifact content vs. edit affordance") and is regression-pinned in realRender.test.ts ("content.labels.deposit resolves via the report-language reportT…", UI en / report de → Abschlagszahlung, pinned through to the rendered PDF). This issue is the remaining case where the boundary is ambiguous rather than violated — hence the product decision above classifying it as chrome.
• Priority is Could Have: the exported artifact is unaffected, the defect is only visible when the interface and report languages differ, and it is likely to be subsumed by the cover-letter overhaul.
• Related open follow-ups in the same area: Report preview: mark report-language content with lang attribute for screen readers #1910 (lang attribute on report-language preview content), Report wizard: code-quality follow-ups from the Round-2 review chain #1912 (report wizard code-quality follow-ups), Wiki debt: budgetLines[] scope correction, ADR-034 fixes, locale-decoupling note #1914 (wiki debt incl. locale-decoupling note).

[steilerDev]

[product-owner] The cover-letter overhaul anticipated in this issue's Notes now exists: #1932. ACs 1–6 here have been carried forward verbatim as section 6 of that issue.

Per the fold-in note already recorded here, close this as a duplicate of #1932 when #1932 lands. Leaving it open until then so the ACs stay independently traceable.