Merge pull request #4 from IntentFile/spec/print-language-and-partition-sources

spec: print render language — language / languageFrom on snapshot children and notify attachments

Author: delchev

docs/spec/entities.md

@@ -196,6 +196,18 @@ Two `function` roles attach **files** to a record. Both are composition children
 
 A snapshot requires a **document** master (only a document has a print template to render from). Minting a copy is wired into the workflow: bind the generated snapshot handler (named `<Master>SnapshotGenerator`) as the `delegate:` of a [service task](/spec/processes#service-tasks) at the step that finalises the document — typically right after *issue*. Re-issuing after an amendment keeps the document's number and mints the next version, which pairs naturally with [`immutableWhen`](#immutablewhen-immutable-user-write-immutability) and an issue-stamped [document number](#document-numbering).
 
+The **language** a copy is minted in is a knob on the snapshot child — `language: <code>` fixes the print-template language, or `languageFrom: <relation>.<field>` reads it per record from a one-hop path on the document master (a to-one relation and a string field of its target holding the code — the customer decides the language their invoice is issued in; the path may cross model boundaries like any other reference):
+
+```yaml
+- name: SalesInvoiceCopy
+  function: Snapshot
+  languageFrom: customer.language
+  relations:
+    - { name: SalesInvoice, kind: manyToOne, to: SalesInvoice, composition: true, required: true }
+```
+
+The two knobs are mutually exclusive. Absent both — or when the resolved value is blank — the mint falls back to the first entry of the application's configured language set, resolved at mint time. An unresolvable `languageFrom` path is a generation error, never a silent wrong-language copy. Interactive printing is a separate concern: the print action always renders **live** current data in the language the user picks, while the snapshot panel serves the frozen issued copies — the two coexist on the document's page.
+
 ## Setting entities
 
 ```yaml

docs/spec/glue.md

@@ -51,13 +51,16 @@ notifications:
 
 Add **`attach: print`** and the message carries the record's **own document** — the record rendered through its [print template](/spec/presentation#printable-documents) and attached. This is the declarative form of the most common outbound action a business document has: the invoice to its customer, the payslip to its employee, a reminder that carries the invoice it is about.
 
+The **render language**: `language:` fixes the print-template language; `languageFrom: <relation>.<field>` reads it per record from a one-hop to-one path of the entity the message is about (mutually exclusive with `language:`). Absent both — or when the resolved value is blank — the render falls back to the first entry of the application's configured language set at send time.
+
 ```yaml
     notify:
       to: Customer.email                 # literal / direct field / one-hop relation.field
       subject: "Invoice {number}"        # {field} and {relation.field} interpolation
       body: "Dear {Customer.name}, please find invoice {number} attached."
       attach: print                      # render THIS record's print template and attach it
-      language: bg                       # optional print-template language
+      language: bg                       # optional FIXED print-template language
+      # or per record: languageFrom: Customer.locale  (a one-hop relation.field holding the code)
 ```
 
 `attach`'s only value is `print`, and the entity must be a **document** (a header with a line-items child) — that is the shape a print template exists for. Attaching the print of a plain entity is rejected up front rather than silently sending a message without the document it promised. The 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.