docs: a render's language governs its data, not only its template - #43
Open
delchev wants to merge 1 commit into
Open
docs: a render's language governs its data, not only its template#43delchev wants to merge 1 commit into
delchev wants to merge 1 commit into
Conversation
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 amultilingual: trueentity 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ПАДЕЖoverBank transfer,E-mailandISSUED— 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 rendersubsection 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 notifylanguage:/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 ownsubjectandbody. 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 Normativeform, not the spec repo's blockquote.npx vitepress build docsis clean.Left open for the maintainer, per the usual policy for this repo.