Topics discussed:

• Graham Grieve had asked whether ViewDefinitions should take a language parameter, so he can build IG pages in several languages. John Grimes argued a parameter is the wrong tool: the runner isn't the thing that knows about language, so if you want a view in Spanish you need a Spanish view definition, and the runner can pick the best match the way an Accept-Language header does. Arjun Sanyal made the same point from the other end — nobody in the room could say what a language parameter would actually do to a column name, which makes it sound like an ETL job rather than a view.
• Translating coded values is the part that genuinely belongs to this group. John noted Pathling already has a designation function that takes a language and passes it to the terminology server, so you can get Spanish display terms out of SNOMED CT or LOINC — but it is not standard FHIRPath. Pathling bolted on translate, designation and property because the standard set stops at memberOf and subsumes and the %terminology mechanism is awkward for this. Nikolai's caveat: none of it is cheap, since you need the full terminology, language packs and concept maps.
• Nikolai's sketch: hand the server a view definition and a destination — Postgres, ClickHouse, Parquet files on a bucket — and say "keep this up to date", with the replication machinery hidden. Arjun couldn't think of a better name than $materialise; he had considered "replicate" but that leans too far towards the remote case.
• Steve Munini had already built this and called it "continuous" — a parameter on a view, not a separate endpoint. His warning was that it dragged scheduling in behind it, because people then wanted cron, and that pushes a scheduling engine into the server whether the server wants one or not. In his design the view definition stays put and a separate export job carries the status, the record counts and the enable/disable switch.
• John Grimes named the real cost: a materialisation is state, so you need more than an API to ask for one — you need APIs to list what currently exists, check status and tear it down, much the way Subscription does. Nikolai liked the Kubernetes shape, where you post a resource and the server writes status back into it, and deleting the resource stops everything. John was wary: if status lives in the resource, every status change makes a new version of the thing you are authoring. They settled on starting with extensions and seeing whether anyone uses them.