fix(typst-book): localize orange-book running header when lang is set

[cderv]

When rendering a Typst book with lang: set to a non-English locale, the orange-book running header keeps the English Chapter N. prefix instead of the locale's word (e.g. Chapitre N. for lang: fr).

Root cause

The orange-book book(...) exposes a supplement-chapter parameter (default "Chapter") consumed by a show heading.where(level: 1): set heading(supplement: ...) rule that drives the running header. The Quarto-side typst-show.typ never passed this parameter to book.with(...), so the English default applied regardless of lang:.

The localized value lives in format.language["crossref-ch-prefix"] (loaded from _language-<lang>.yml). languageFilterParams exposes it to Lua filter params, but no code wrote it into Pandoc YAML metadata where the $crossref-ch-prefix$ template variable would resolve.

The same gap affected the existing list-of-figure-title and list-of-table-title pipes in the same template — they silently rendered as empty strings when the user enabled lof: true / lot: true.

Fix

crossref/meta.lua now surfaces crossref-ch-prefix, crossref-lof-title, and crossref-lot-title from filter params into Pandoc metadata via a new surfaceParamToMeta(meta, key) helper in common/meta.lua. The orange-book typst-show.typ gains a supplement-chapter: "$crossref-ch-prefix$" pipe; the two list-title pipes start working as a side effect.

User precedence is preserved: surfaceParamToMeta only writes when meta[key] is unset, so explicit metadata wins.

Documentation

A new llm-docs/localization-architecture.md maps the full localization pipeline across HTML, LaTeX/PDF, and Typst, and documents the design split between crossref: block (per-document overrides for a subset of keys) and language: block (translations for the full set, including crossref-ch-prefix / crossref-apx-prefix).

Fixes #14524

Checklist

I have (if applicable):

• referenced the GitHub issue this PR closes
• updated the appropriate changelog in the PR
• ensured the present test suite passes
• added new tests
• created a separate documentation PR in Quarto's website repo and linked it to this PR

AI-assisted PR

• AI tool used: Claude Code
• Codebase grounding: local clone, DeepWiki MCP
• Human review: I have reviewed, tested, and verified the AI-generated content before submitting.

[posit-snyk-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[gordonwoodhull]

This is the right fix! But currently it needs to be made on:

https://github.com/quarto-ext/orange-book

Then once it’s on main on that repo, run

quarto dev-call pull-git-subtree orange-book

to update the subtree.

Modifying it directly will “work”, but only until the next time that repo is updated. (And won’t help anyone who might have forked that repo for their own changes.)

It’s debatable whether that repo needs to be a subtree extension instead of fully built-in. My rationale is that it is somewhat independent of Quarto; could get forked; we could switch to another fork or another extension. Glad to discuss.

https://github.com/quarto-dev/quarto-cli/blob/main/dev-docs/subtree-extensions.md

For that matter it’s also possible to push your changes back to the repo with git subtree push but I haven’t tried that.

[cderv]

How did I forgot !! 🤦 We discussed it. Sorry for this and thanks for the reminder.

[gordonwoodhull]

You’ll also find that you can’t rebase the subtree & will get weird path errors if you try. So you’ll need to merge the branch without rebasing.

(The complexity has to go somewhere I guess. Subtrees are still less confusing than submodules IMO.)