Skip to content

1.7.1 — finish the Persian: Advanced, the exit chain, the scanner - #30

Merged
DarkPoesidon merged 1 commit into
mainfrom
release/1.7.1
Sep 2, 2026
Merged

1.7.1 — finish the Persian: Advanced, the exit chain, the scanner#30
DarkPoesidon merged 1 commit into
mainfrom
release/1.7.1

Conversation

@DarkPoesidon

Copy link
Copy Markdown
Collaborator

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, NumberField or RulesField. 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 a t() 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. searchSettings now scores against both, so neither is a dead end.

Left in English on purpose

why
The command-line preview literal text someone pastes to a developer
The diagnostics report body same — it is meant to be read by whoever debugs it
Third-party notices a legal document only means what it says in the language it was written in

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:

t(
  "Every measurement here travels the tunnel, so a figure means…",
)

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

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.
@DarkPoesidon
DarkPoesidon merged commit 0785c8a into main Sep 2, 2026
7 checks passed
@DarkPoesidon
DarkPoesidon deleted the release/1.7.1 branch September 2, 2026 08:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant