Skip to content

docs(intent): a render's language selects the data, not only the template (#6945, #6947) - #220

Merged
delchev merged 1 commit into
masterfrom
docs/render-language-governs-data
Aug 27, 2026
Merged

docs(intent): a render's language selects the data, not only the template (#6945, #6947)#220
delchev merged 1 commit into
masterfrom
docs/render-language-governs-data

Conversation

@delchev

@delchev delchev commented Aug 27, 2026

Copy link
Copy Markdown
Contributor

Documents the two fixes merged on 2026-08-27: #6946 (interactive print dialog, issue #6945) and #6948 (server-side snapshot and notify renders, issue #6947).

Why this page needed correcting, not just extending

printing.md stated the opposite of what now happens, in the one sentence someone debugging this would land on:

Because it loads through the repositories and is called by the browser as the signed-in user, it inherits the multilingual translation overlay (the document prints in the caller's language) ...

The caller's language is the UI locale, not the language chosen for the render. That is exactly the defect #6945 reported - a Bulgarian template over Bank transfer / ISSUED - and the Print flow now pins the feeder call's Accept-Language to the chosen language instead.

Changes

  • printing.md
    • the feeder sentence now says the overlay resolves in the render language, not the UI locale, and how;
    • a tip under the Print button: the chosen language selects the template and the data, so a document rendered in one language is in that language throughout;
    • in The issued copy and its language, why the server-side renders needed a separate fix - a process step carries no Accept-Language, so a snapshot minted by a workflow (and a notify attachment, which runs in the same caller-less place) rendered a translated template over base-language values until the generated delegates began binding the render language around the feed and the render, cleared in a finally so a pooled worker never leaks it.
  • glue.md - the notify render language is no longer described as "the print-template language", and now states what it does not govern: the mail's subject and body, which are the covering message rather than the document.

Notes

House rules observed: plain hyphens (no em/en dashes), VitePress admonition, absolute cross-links. npx vitepress build docs is clean, and because ignoreDeadLinks masks broken links at build time the new /help/intent/printing#the-issued-copy-and-its-language anchor was verified against the heading by hand.

The vendor-neutral half is intent-specification#59 (proposal 0029) with its site page intentfile.github.io#43.

…late (#6945, #6947)

The printing page said the opposite of what now happens, in the one sentence
someone debugging this would read: "it inherits the multilingual translation
overlay (the document prints in the caller's language)". The caller's language
is the UI locale, not the language chosen for the render - which is exactly
the defect #6945 reported, and the print flow now pins the feeder call's
Accept-Language to the chosen language instead.

- printing.md: correct the feeder sentence; a tip under the Print button that
  the chosen language selects the template AND the data; and, in "The issued
  copy and its language", why the server-side renders needed their own fix -
  a process step carries no Accept-Language, so a snapshot minted by a
  workflow (and a notify attachment, which runs in the same caller-less
  place) used to render a translated template over base-language values.
- glue.md: the notify render language is no longer "the print-template
  language", and says what it does not govern - the mail's subject and body,
  which are the covering message rather than the document.

Tracks specification proposal IntentFile/intent-specification#59 and the
neutral page IntentFile/intentfile.github.io#43.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@delchev
delchev merged commit 6c5e29f into master Aug 27, 2026
@delchev
delchev deleted the docs/render-language-governs-data branch August 27, 2026 16:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant