Sync path never applies applyTypography() — every sync strips the French non-breaking spaces the seed inserted

[mmcky]

applyTypography() runs in the translate init seed path but not in the action's sync path, so every sync silently strips the non-breaking spaces the seed inserted. The French edition degrades a little with each merged sync PR.

Evidence

QuantEcon/lecture-python-programming.fr#6 (merged) synced numba.md from source PR #550. Thirteen lines changed only their whitespace — U+00A0 became a plain space:

-Voici une solution\xa0:	+Voici une solution :
-Chronométrons-le maintenant\xa0:	+Chronométrons-le maintenant :
-*Symptôme 1\xa0: le résultat n'est plus reproductible.*	+*Symptôme 1 : le résultat n'est plus reproductible.*

Counting U+00A0 in lectures/numba.md across its only two commits:

Commit	Path	U+00A0
697b904 — seed (translate init, Opus 4.8)	init	27
82d62aa — sync PR #6 (action mode: sync, Sonnet 5)	sync	14

Thirteen lost in one sync of one lecture. The file now mixes both conventions, and the loss is permanent once merged — a later sync only rewrites lines the source touched.

Root cause

applyTypography() has exactly one caller:

• src/cli/commands/init.ts#L296 — const translatedContent = applyTypography(result.translatedSection, options.targetLanguage);

src/index.ts, which is what the action runs for mode: sync, never imports it. The sync path therefore relies solely on the prompt instruction at src/language-config.ts#L53:

Insert a non-breaking space before the high punctuation marks ; : ! ? as required by French typography

That instruction is exactly the one #79 was opened to replace, because the model does not follow it. From the seed PR's own write-up: "The translation prompt has always instructed the model to place a non-breaking space before ; : ! ?. It doesn't — a measured translation came back with zero of them. That's now applied deterministically in code instead (#79); 331 non-breaking spaces were inserted here."

So #79 fixed the seed path and left the sync path on the mechanism #79 itself proved does not work. Every subsequent sync regresses whatever lines it touches back to pre-#79 behaviour.

Why it matters

The seed inserted 331 non-breaking spaces across 26 lectures. Sync is the ongoing path — it runs on every upstream merge, forever — so this is a slow erosion of the seed's work, one merged PR at a time, on exactly the lines an editor is least likely to re-read. It is invisible in review: the diff renders as unchanged text, and both automated review comments on #6 scored formatting 9/10 and 10/10 while missing it entirely.

Correctness, not just style: a plain space before : lets the colon wrap to the start of the next line.

Shape of the fix

Call applyTypography() on translated content in the sync path, at the same point init does — before anything derives from the text. hasTypographyRules() already exists to gate it, and the transform is documented as idempotent and spacing-only, so applying it to sync output should be safe.

Two things worth deciding alongside:

1. Should the prompt rule stay? With deterministic post-processing on both paths, additionalRules asking for nbsp is dead weight at best, and at worst invites the model to produce inconsistent spacing the transform then has to normalise. The guillemets rule on the line above may deserve the same question.
2. Backfill. Existing editions already carry drift from syncs merged before the fix. scripts/typography/apply.mjs --lang fr is the existing repair tool (it produced .fr#4); a one-off run per edition after this lands would reset the baseline. numba.md needs it today.

Note on scope

I checked whether the seed itself was inconsistent and it was not — a naive "space before :" scan flags many false positives (MyST directives like :class:, code cells, URLs), which is what the transform's masking logic exists to avoid. The seed path is working as designed. This issue is specifically that the sync path never got the same treatment.

Only French currently declares typography rules, so fr is the only affected edition today. Any future language with hasTypographyRules() inherits the same gap.

[mmcky]

Confirmed the diagnosis against the code at v0.16.1 — applyTypography() has exactly one production caller, and the four sync-path sites that produce translated content (sync-orchestrator.ts:323, :332, :395, :414) never reach it. Everything in the evidence section holds up.

One thing to flag before anyone implements this, because the obvious fix is worse than the bug.

Where you apply it is load-bearing

"Call applyTypography() on translated content in the sync path, at the same point init does — before anything derives from the text" is the right instruction, but the natural reading of it — wrap translatedContent in the sync orchestrator — does the opposite of what it says, because by that seam something already has derived from the text.

Both processSectionBased and processFull return injectHeadingMap(...) — content with the heading map already written into frontmatter. And applyTypography deliberately skips frontmatter. So wrapping the orchestrator's translatedContent typesets body headings while leaving the map values untouched.

That matters because heading matching is exact === on raw strings. The only normalization is cleanHeading, which strips the # prefix, strips MyST roles, and trim()s — there is no interior-whitespace or U+00A0 handling anywhere in the matching path. A map value of Exemple : le chaos therefore never matches a body heading of Exemple\xa0: le chaos. The ID fallback compares an English ID against a French one and fails; the position fallback is skipped whenever the section count changed. What is left:

Section classification	Consequence of a map/body mismatch
unchanged	silently dropped from the output
modified	"Could not find target ... treating as new" — existing translation and any human edits discarded, retranslated from English

That is data loss, and strictly worse than the whitespace erosion this issue is about.

init avoids it only because line 296 runs before line 299 builds the map — the ordering is doing real work, not just tidiness. scripts/typography/apply.mjs avoids it by re-typesetting the map and title separately at lines 94-95.

The invariant currently holds, so a careless fix is what breaks it

Worth recording, since it is easy to misread: the seed's map and body are in sync today. The map stores the non-breaking space YAML-escaped as \_, which js-yaml round-trips back to a real U+00A0 — so a grep for U+00A0 in frontmatter returns zero and looks like drift, but isn't. Parsing the frontmatter properly across all 26 lectures of the .fr edition:

map values containing ; : ! ?	31, across 14 of 26 lectures
non-breaking-space body headings in sync with the map	30 of 30

(Checked with js-yaml + stripMystRoles, matching what the matching path actually does — a raw string compare produces one false "desync" in getting_started.md, where the body heading carries an {index} role the map value has stripped.)

Recommended shape

Apply the transform inside file-processor, on the model's raw output, before the map is built or updated — before :615 in processFull, and before :473 in processSectionBased. That reproduces init's actual ordering rather than its apparent one, and keeps map and body derived from the same typeset string.

Related trap worth naming explicitly: do not implement this by mapping applyTypography over result.translatedFiles. That array also carries TOC files copied verbatim from English (sync-orchestrator.ts:483) and state files that are bare YAML with no --- delimiter (translate-state.ts:203) — the frontmatter skip will not protect those, and mode: UPDATE would become mode\xa0: UPDATE, corrupting the key.

On the two questions raised

1. The prompt rules are not symmetric — drop the nbsp rule, keep guillemets. Once both paths post-process deterministically the nbsp instruction is dead weight, as you say. But guillemets should not get the same treatment: applyTypography is spacing-only and has no guillemets transform at all, so dropping that rule would lose the behaviour outright rather than making it deterministic. (Separately — French guillemets want a non-breaking space inside them, «\xa0mot\xa0», which the transform also does not do. Probably its own issue rather than scope creep here.)

2. Backfill — there is a design decision hiding in it. Applying per-section touches only new and modified translations: minimal diffs, no backfill. Applying to the reconstructed document before the map update also repairs drifted lines in untouched sections — drift becomes self-correcting on the next sync of each file, at the cost of sync PRs carrying whitespace-only changes on lines the source PR did not touch. Since the transform is documented and tested as idempotent, I lean toward the document-scoped version. Either way a one-off apply.mjs --lang fr is still wanted to reset files that will not be synced soon, and numba.md needs it regardless.