Skip to content

docs: a render's language governs its data, not only its template - #43

Open
delchev wants to merge 1 commit into
mainfrom
docs/render-language-governs-data
Open

docs: a render's language governs its data, not only its template#43
delchev wants to merge 1 commit into
mainfrom
docs/render-language-governs-data

Conversation

@delchev

@delchev delchev commented Aug 27, 2026

Copy link
Copy Markdown
Contributor

The site page for specification proposal intent-specification#59 (proposals/0029-render-language-governs-its-data.md).

The gap the site already carried

Both halves were on the site and nothing joined them:

  • data.md — "Every read of a translatable property of a multilingual: true entity is served in the caller's requested language."
  • presentation.md / glue.md — a render's language selects the print template.

A render is not a read by a caller. The interactive print has one, but the reader's browsing language is not the language they just chose in the print dialog; a copy minted by a workflow, or a document attached by a scheduled or event-driven message, has no caller at all. So a Bulgarian sales invoice comes out reading ФАКТУРА and ПАДЕЖ over Bank transfer, E-mail and ISSUED — and it is worst in the two renders nobody re-reads before they leave: the archived copy an audit is answered from, and the copy the counterparty receives.

Changes

  • data.md — a new #### The language of a render subsection under Multilingual data, ending in the normative block: the render's language is the requested language for every read that produces it (including where there is no caller to ask); the per-property fallback is unchanged, so a render language with no translations produces a default-language document rather than an error; what a render selects stays evaluated against the stored values, the rule reports already follow; and a render's language applies to that render alone.
  • presentation.md — the add-a-language line now says the chosen language selects the template and the data, linking to the new subsection and naming the two declared cases (a versioned copy, a notify language: / languageFrom:).
  • glue.md — the notify render language is no longer described as "the print-template language", and now says explicitly what it does not govern: the message's own subject and body. An attachment is a contractual document and belongs in the document's language; the covering message belongs in the recipient's. That question is left open in the proposal rather than settled by accident.

Notes

No construct is added, so no reference-table row. All four cross-links use anchors the site already uses (/spec/presentation#printable-documents, /spec/glue#the-notify-block-and-attach-print, /spec/presentation#lifecycle-scope) plus the new /spec/data#the-language-of-a-render. Normative prose is in the site's ::: info Normative form, not the spec repo's blockquote. npx vitepress build docs is clean.

Left open for the maintainer, per the usual policy for this repo.

The site carried both halves of the gap and never joined them: data.md said
every read of a translatable property is served in the caller's requested
language, while presentation.md and glue.md said a render's language selects
the print TEMPLATE. A render is not a read by a caller — and the two renders
that matter most, the minted copy and the mailed attachment, have no caller
at all — so a Bulgarian invoice reads ФАКТУРА over `Bank transfer`.

- data.md: a new "The language of a render" subsection under Multilingual
  data, with the normative rule — the render's language is the requested
  language for every read that produces it, the per-property fallback is
  unchanged, and what a render SELECTS stays evaluated against stored values.
- presentation.md: the add-a-language line now says the chosen language
  selects the template AND the data.
- glue.md: the notify render language is no longer "the print-template
  language", and says explicitly that it does not govern the message's own
  subject and body — an attachment belongs in the document's language, the
  covering message in the recipient's.

Tracks specification proposal 0029. `vitepress build docs` clean.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
delchev added a commit to dirigible-io/dirigible-io.github.io that referenced this pull request Aug 27, 2026
…late (#6945, #6947) (#220)

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>
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