1.7.1 — finish the Persian: Advanced, the exit chain, the scanner - #30
Merged
Conversation
The last release translated the connect screen and stopped there, which left everything behind the Advanced tab in English -- and Advanced is where the settings live. Someone who does not read English could open the app but not configure it. Translated at the primitives rather than at the call sites. Every control on that screen passes its label and help text through Row, Seg, TextField, NumberField or RulesField, so five changes cover roughly two hundred strings, and a control added later is translated by construction rather than by remembering. The rest -- section headings, buttons, the paragraphs between cards -- is wrapped where it is rendered. Module-level data keeps its English and is translated at the point of use, because it is built once before any component exists and would otherwise never follow a language change. Left in English on purpose: the command-line preview, the diagnostics report body, and the third-party notices. The first two are literal text someone pastes to a developer, and the third is a legal document that only means what it says in the language it was written in. The settings search now matches both languages at once. Someone reading a Persian interface types Persian; someone who learned these settings by their English names types English. Checking only one makes half the search useless. Two checks were wrong and are now right: - The pattern finding wrapped strings rejected a trailing comma, which is exactly how a sentence long enough to be split across lines is formatted. Six of the longest paragraphs were invisible to it and reached a screenshot still in English. - Labels the settings index carries reach the translator as a variable, so no static check saw them. There is now one that reads the index directly and fails on a setting findable only in English. A proper noun that reads the same in both languages is left out of the dictionary entirely rather than mapped to itself, so the fallback does the work and the check stays strict. Verified by walking every settings section in a running build and reporting any line still in Latin script: none, outside the three deliberate exceptions.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
1.7.0 translated the connect screen and stopped there, which left everything behind the Advanced tab in English — and Advanced is where the settings live. Someone who does not read English could open the app but not configure it. This finishes it.
Translated at the primitives, not at the call sites
Every control on the Advanced screen passes its label and help text through
Row,Seg,TextField,NumberFieldorRulesField. Translating inside those five covers roughly two hundred strings — and a control added later is translated by construction rather than by someone remembering.The rest — section headings, buttons, the paragraphs between cards — is wrapped where it is rendered. Module-level data (
SECTIONS,BLURB,PROTOCOLS) keeps its English and is translated at the point of use: it is built once before any component exists, so at()there would never follow a language change.Search works in both languages at once
Someone reading a Persian interface types Persian. Someone who learned these settings by their English names, or who is reading a forum post, types English.
searchSettingsnow scores against both, so neither is a dead end.Left in English on purpose
Two checks were wrong
Both were found by walking the running app rather than by reading the source, which is why they are worth calling out:
The pattern finding wrapped strings rejected a trailing comma. That is exactly how a sentence long enough to be split across lines gets formatted:
Six of the longest paragraphs were invisible to the check and reached a screenshot still in English.
Labels in the settings index reach the translator as a variable (
t(entry.label)), so no static check saw them. There is now one that reads the index directly and fails on any setting findable only in English.A proper noun that reads the same in both languages is left out of the dictionary entirely rather than mapped to itself — the fallback does the work, and the check stays strict enough to be worth having.
347 dictionary entries. 45 frontend tests, 112 Rust tests, clippy clean.
Verified by clicking through every settings section in a running build and reporting any line still in Latin script: none, outside the three deliberate exceptions above.
🤖 Generated with Claude Code