Three issues: say the right thing, to the right reader, in their language

[peopleworks]

Three issues from the open list, all of the same family: what the product says to the person reading it. None moves the published number, none needs the committee.

#62 — Turkish is not a disguise

U+0131 DOTLESS I sat in the lookalike table and flagged Fazıl, Kıbrıs, Rıza, Komandoları — spelled correctly — in a Spanish article about a Turkish organisation. The one check this project presents as a fact rather than a judgement was stating a false one, about proper names from a third language.

Measured before changing anything, as the rule pack policy requires: U+0131 occurs in 1 of the 371 texts we hold, and that one is Turkish names. The three IPA entries occur in none. With a base that thin, the issue's proposed three-signal heuristic would have been fitted to a single document.

So instead this applies the principle the table's own comment already stated — accented Latin letters are absent because á and ñ are ordinary Spanish — which had only ever been applied to the two languages we ship. The line is not "Latin or not" but is this a letter of some living alphabet. The remaining three survive it as IPA symbols, which no orthography writes prose with.

The cost, stated plainly: a substitution swapping i for ı is no longer caught. Never observed, and this check errs toward a missed artifact over a false accusation — the direction IsEmojiLike already states.

#88 — the scan speaks to the reader

U+00A0 is U+00A0 in every language, and "ask the writer how this document was produced" is an instruction, not commentary. Both the character scan and the citation cross-check took the analysed text's pack, so an English teacher opening a Spanish essay got the chrome in English and the body in Spanish. #36 settled this for the evidence report in August; these two kept the older behaviour everywhere — web, desktop, Word pane, CLI.

Analyze() gains an optional readerLanguage. Null follows the text, so every existing caller is unchanged. Findings are deliberately untouched: a finding quotes the text and argues about it.

#77 — a Spanish report, and one that is actually Spanish

Two defects, and only the first was in the issue.

1. The CLI never set InterfaceLanguage, so report.es.json was unreachable from a command line. It now follows --reader-lang.
2. The report then came out half English. report.es.json carried 39 of 76 blocks — the mandatory core was current and tested, but completeness never was. The other 37 are translated here, in the register the file already uses.

Worth flagging: the existing test asserted the fallback markers were present. It had pinned the symptom as the specification, which is why nothing failed while half the report was English. It now asserts the opposite, keeps the announcement invariant for whenever a block does fall back, and a new guard requires every printable block to exist in Spanish.

Verification

• The character scanner reads Turkish dotless i as an artifact #62: the issue's own command now reports 0 occurrences; the new test fails with the table entry restored.
• The character scan explains itself in the analysed text's language, not the reader's #88: same Spanish document, --reader-lang en → English summary, default → Spanish. Unchanged by default.
• The CLI cannot write the evidence report in Spanish #77: the issue's own command produces a report with zero fallback markers.
• 441 tests (Linux solution + the Windows desktop job's 31), all builds clean including Word, desktop and MCP.

One deliberate deviation: #77 proposed --report-lang. Since #88 gave the CLI a second thing that needs the reader's language, two flags that must always agree would be a trap — there is one, named for what it means.

🤖 Generated with Claude Code

https://claude.ai/code/session_015PEbbiYSNPw7jE3LrPNhyF