[digitalerdude]

Summary

Fixes #540: Tools/i18n_audit.py's Android regex only matched a literal sitting immediately after Text(/title=/etc, so Text(if (saved) "Saved" else "Save") slid straight past and the audit reported "clean" while shipping English regardless of device language.

While fixing this I checked the Apple side for parity and found the identical blind spot — and there it's a real functional bug, not just a tooling gap: Text(cond ? "a" : "b") resolves to SwiftUI's non-localizing Text<S: StringProtocol> overload, so those sites are always-English on-device too, independent of this audit.

What changed

Both scanners now walk each call's/kwarg's own argument span instead of matching a literal at a fixed position:

• Transparent through (/[ always (so ternaries and nested calls are visible).
• Transparent through { only for the Kotlin idioms this codebase actually uses to conditionally pick a string (if/when/catch/else/try/finally, and .let {} as a null-coalescing ternary substitute paired with ?:). Opaque for everything else, so an unrelated nested composable slot lambda (e.g. AlertDialog(text = { Column { /* a separate, unrelated subtree */ } })) doesn't get swept into the same scan — that nested content is still found, just on its own independent pass when the file-wide scan reaches it directly.

An early draft that didn't distinguish those two cases produced 489 spurious findings instead of the real backlog. Two more bugs surfaced along the way, fixed in the same pass since they'd otherwise produce un-actionable noise:

• Kotlin's ${...} string-template interpolation (the "${if (n==1) "day" else "days"}" pluralization idiom) corrupted the naive quote-matching.
• title=/text=/etc. also matched a plain local val text = when {...} declaration, not just an actual call argument.

Deliberately does not flag +-concatenated literals (typically uiString(R.string.x) + "hardcoded suffix") — found 86 of those across 28 files, but it's a different, larger bug (partial localization via an engineered prefix, needs real new translation content per site rather than reusing an existing value) — filed separately as #557.

The backlog problem, and the baseline

The corrected scanners find real, previously-invisible findings: 170 distinct Android literals, 64 distinct Apple ones. Far more than one PR should close with rushed translations (see #543 on what that produces when strings get "fixed" without native review).

Since i18n-coverage.yml's --ci is a whole-tree gate (not diff-scoped), the fix and some resolution of what it newly surfaces have to land together or every subsequent PR breaks. Rather than rush ~234 translations, this ships with Tools/i18n_audit_baseline.json: a snapshot of the pre-existing findings, keyed by (path, literal) so it survives unrelated line-number drift. --ci now only fails on a new hardcoded literal from this point forward; the baseline backlog is closed incrementally in separate, appropriately-sized follow-up PRs, chipped away by area. --update-baseline regenerates the file — an entry that stops appearing in a fresh scan is simply inert, not an error, so it naturally shrinks as follow-ups land.

Testing

• Tools/test_i18n_audit.py (new): the conditional shapes above (ternary, block-if/else, when, .let), the nested-slot-lambda non-explosion regression guard, the interpolation and local-declaration fixes, comment/format-spec false-positive exclusion, and the baseline diff logic (missing file, round-trip, line-number-drift resilience).
• python3 -m unittest test_i18n_audit -v — 22/22 pass.
• python3 Tools/i18n_audit.py --ci origin/main — exit 0 (clean against the new baseline).
• Manually verified a genuinely new hardcoded literal (not in the baseline) fails --ci with a clear message, then confirmed the repo is unaffected (temporary local-only edit, reverted, git status clean before this PR).
• No app-target Swift/Kotlin source touched (Tools/i18n_audit.py isn't part of any Xcode/Gradle target) — only the Python audit tool, its new baseline snapshot, and its test file. xcodebuild/./gradlew compile* weren't needed for this change.

Follow-ups tracked separately

• Android: uiString(...) + "hardcoded suffix" — partial localization via engineered prefix (86 sites / 28 files) #557 — the 86-site uiString(...) + "hardcoded suffix" concatenation bug found while investigating this.
• Closing Tools/i18n_audit_baseline.json's 234 pre-existing entries, screen/area by screen/area.

[ryanbr]

Reviewed, and since this is a Python tool I could run it end-to-end rather than read it — which I did, including driving the real scan path directly on crafted inputs. It genuinely fixes #540, and this is the fix for a blind spot I hit three separate times reviewing other PRs this session, so I'm glad to see it land.

Verified working (not just claimed)

• 22/22 tests pass, --ci origin/main exit 0 against the new baseline.
• The exact i18n audit is blind to conditional literals — Text(if x "a" else "b") reports clean #540 site is now caught — HrvSnapshotScreen.kt:290 Text(if (saved) "Saved" else "Save") → both "Saved" and "Save" are in the baseline. I confirmed this through the real scan_android() path (span-walk + extract), not only the test helper.
• when (subject and bare) and .let {} ?: conditional shapes are caught with realistic copy. My first probe missed when (n) { … "one" … "many" } and I thought it was a gap — it wasn't: is_probably_ui_text correctly filters lowercase single-word tokens like "one"/"many". Re-run with "Awake now"/"Still asleep" and it flags them. Good call keeping that filter.
• No 489-explosion: AlertDialog(text = { Column { … } }) is not swept; the opaque-vs-transparent brace split does what the description says.
• Baseline mechanism: exactly 170 Android / 64 iOS as claimed, keyed [path, literal] so it survives line drift. ci_check fails only on a (path, literal) not in the baseline; a baseline entry that stops appearing is inert (informational "run --update-baseline"), never a failure — so a fix can never break the gate and the backlog only shrinks. That's the right design, and the reason to trust shipping a baseline rather than rushing 234 translations (String Catalog: Russian counts wrong (2-form hand-roll), plus several translation defects #543 already showed what rushed translations produce).

The baseline-not-rush decision is the correct one and well-executed.

Two residual gaps — neither blocks this, both are follow-up material

1. A kwarg set inside a lambda is still invisible — including the standard Compose a11y idiom. Modifier.semantics { contentDescription = if (hr) "Recovery ready" else "Recovery, no data yet" } is NOT flagged, because semantics {} is an opaque brace and the contentDescription = kwarg inside it is never scanned (I verified: the same contentDescription = if/else as a plain (-arg IS caught; only the lambda form is missed, and the strings pass is_probably_ui_text, so it's not the filter). This is exactly the CoupledScreen.kt a11y strings I flagged earlier — they stay invisible after this PR. It's genuinely outside #540's "conditional literal" axis (this is "kwarg inside a lambda", a different axis), so not a defect here — but the a11y idiom is common enough that a targeted rule ("scan contentDescription = even inside a trailing lambda") would be worth a follow-up. Otherwise the baseline will read "clean" for a11y text that's English-only on-device.

2. The extraction tests bypass span-detection. The literals() helper calls _extract_literals(text, 0, len(text)) over a pre-trimmed snippet, so every headline test (ternary, if/else, when, .let) exercises extraction but never _argument_span_end — the trickiest function here, and the one that decides where a Text(...) argument actually ends in real code. A regression in the brace/paren balancing would pass all 22 tests. I confirmed span-detection works today by driving the real path directly, but the suite doesn't guard it. One test that runs scan_android() (or _argument_span_end) on a multi-arg call — Text(if (x) "a" else "b", style = Foo, modifier = Bar) — would close that, and it's cheap.

Minor (mention-only)

• Baseline is keyed (path, literal) without line, so a third occurrence of an already-baselined literal in the same file wouldn't register as new. Rare, low-severity.
• is_probably_ui_text drops lowercase single words, so a lowercase one-word UI label would be missed. Pre-existing heuristic, not this PR.

Solid, correct, honestly scoped, and it closes a real recurring hole. The two follow-ups (semantics-lambda a11y; a span-detection test) are worth filing but shouldn't hold the merge — the backlog is already tracked and the gate is sound.