proposal: a render's language governs its data, not only its template

[delchev]

Adds proposals/0029-render-language-governs-its-data.md. No versions/ change, per the proposal-first process.

The gap

Two rules the specification already states never meet:

• Multilingual data — "every read of a translatable property of a multilingual: true entity is served in the caller's requested language".
• A render's language — language: / languageFrom: on a notify block, the language a versioned copy is minted in, the language a reader picks in the print action — "names one of the document's print-template languages".

A render is not a read by a caller, and nothing joins the two clauses. So an implementation is free to answer "which language is the data in?" differently at every render — and does:

• the interactive print runs as a caller, so values resolve in the language the reader happens to be browsing in, not the one they just chose in the print dialog;
• a minted copy and a mailed attachment are produced by a workflow step, a schedule or an event handler. There is no caller to ask, so the translated read has no requested language and falls back to the stored values.

A Bulgarian sales invoice comes out with ФАКТУРА / ПАДЕЖ over Bank transfer, E-mail, ISSUED. Everything the author wrote by hand is in the right language and every value the model supplies is in the wrong one — and it is worst in the two renders nobody re-reads before they leave: the archived immutable copy an audit is answered from, and the copy the counterparty receives with no application around it.

What the proposal states

No new key — every one of these renders already names a language. The rule is that the language a render declares is the requested language for every read performed to produce that render, so the template and the data are one decision made once.

Unchanged and stated explicitly: the per-property fallback (a property untranslated in the render language reads its stored value, so a render language with no translations is not an error), and that what a render selects — a print template's row filter, an attached report's filter: / scope: — stays evaluated against the stored values, the rule reports already follow.

This is also what makes the existing normative sentence true, that an attachment "comes from the record's own data through the same path the interactive print takes, so a document mailed and a document printed are the same document". Today the two paths differ in exactly the language of their data.

Deliberately left open

Whether a notify block's language: also governs the translatable values interpolated into its own subject and body. That has a different answer: an attachment is a contractual document and belongs in the document's language, while the covering message belongs in the recipient's. Settling it by accident inside this proposal would be the wrong way to decide it.

Sections

Specification text carries two anchors — a normative paragraph after the existing block in Multilingual data > Data, and an author-facing paragraph in Printable documents after the add-a-language line. No DSL index row: the proposal adds no construct. All four cross-reference anchors resolve against versions/1.5.md.

Reference implementation

Eclipse Dirigible, both halves of the same defect on two code paths: #6945 (interactive print dialog, fixed in #6946) and #6947 (server-side snapshot and notify renders, fixed in #6948).