French guillemets interior NBSP is prompt-only — needs a deterministic transform

[mmcky]

The French guillemets rule is prompt prose, and #81 already measured that this mechanism does not work for invisible characters. Filing it as its own issue, as proposed in #97's thread on 2026-07-16 ("probably its own issue rather than scope creep here") and never actually filed.

The rule as it exists today

src/language-config.ts carries it as instruction text in additionalRules for fr:

Use French guillemets « » (with a non-breaking space inside each, e.g. « citation ») for quotations rather than straight or curly double quotes

That is the entire enforcement. applyTypography() handles spacing around high punctuation but does not produce the interior form « mot », so nothing deterministic ever writes or checks it.

Why prompt prose cannot carry this rule

Closed #81 measured the analogous NBSP-before-high-punctuation rule and found 0% compliance across two models, identical on Sonnet 5 and Opus 4.8. The finding generalises: the model cannot perceive whether it emitted U+00A0 or U+0020, so no amount of prompt refinement fixes it and no model upgrade will either. This is the same class as #182 — a correctness rule expressed in prose to a component structurally unable to verify its own compliance.

Proposed fix

A deterministic transform: normalise « + optional whitespace → « , and optional whitespace + » →  », on French output.

Implementation home is #172's write-path choke point, and the placement constraints recorded there are load-bearing — apply on raw model output before the heading map is built (heading matching is exact ===, so a post-map transform desynchronises map from body and silently drops or retranslates sections), and never map the transform over translatedFiles wholesale (it carries verbatim-English TOC files and bare-YAML state files that a frontmatter skip will not protect).

Notes

• Scope is fr only for now, but the transform belongs in a per-language typography rule list rather than a French special case — that gets cheaper after tech-debt T5: Widen LanguageConfig and build rule lists once #174 widens LanguageConfig.
• Worth a deterministic reviewer check alongside it, so existing French content can be audited rather than only new output being corrected.
• The prose rule should stay in the prompt as a hint; the transform is what makes it true.

Refs #97 (origin thread), #81 (why the prompt-side mechanism cannot work), #172 (implementation home), #182 (same failure class).

[mmcky]

A second-language data point for the "belongs in a per-language typography rule list rather than a French special case" note, plus an observation that the French sync-path transform now appears to be firing.

Chinese hits the same wall by a different mechanism

Source PR QuantEcon/lecture-python-programming#604 included a pure English typography fix: its numpy.md line had `np.loadtxt` ---see [the documentation] (space before the marker, none after), and the fix added the missing space after it.

The Chinese line was already correct — 使用 `np.loadtxt`——详情请参阅, with the full-width —— closed up on both sides, which is what Chinese typography takes. The sync mirrored the source edit structurally and emitted `np.loadtxt` ——详情: a space before the dash and none after, i.e. precisely the asymmetric hybrid that #604's own analysis had just identified as the defect in English, reproduced in a language where neither side should have a space.

The estate convention is unambiguous — 100 of the 102 —— occurrences under lectures/ in .zh-cn have no preceding space, and the line in question was one of them before the sync. Corrected by hand in .zh-cn dbb47f5 before merge.

Why this is a different failure mode from #81's

Worth separating, because it changes what a fix has to do. #81 measured a model that cannot perceive what it emitted — U+00A0 versus U+0020 is invisible to it, hence 0% compliance and no prompt fixing it. Here the model emitted exactly what it was asked to: it faithfully transferred a diff. The defect is that a typography edit in the source language was treated as translatable content rather than as a source-language-specific artifact that the target may already satisfy, satisfy differently, or need to ignore.

So a deterministic normalising transform of the kind proposed here would catch it — a zh rule of "no space adjacent to ——" would have repaired the output — but the underlying trigger is upstream of that, in the sync path treating source typography edits as changes to mirror. Both language rules are needed; a per-language list with fr and zh entries would have caught both instances.

Checked and not applicable in the sibling editions, for the record: .fa and .fr both already had --- spaced on both sides at that line, so there was nothing to mis-mirror. This one was specific to the full-width dash.

Unrelated but relevant: the French transform does appear to fire on sync now

On .fr#29, a python_by_example.md diff line renders identically on both sides. The only difference is at character 130, where the + side carries U+00A0 and the - side a plain space — the non-breaking space before a colon. That is the sync path adding French typography rather than stripping it, which is the opposite of the behaviour #97 described. If that is #97's fix working in production, it is worth confirming, since this issue's framing assumes the sync path applies no typography at all.