koala73 / koala73/worldmonitor
chore(i18n): fa.json ships as an English placeholder — 571/582 values are the untranslated English source
- Dominant language
- TypeScript
- Stars
- 86.6k
- Forks
- 13.1k
- Avg merge
- 8h 4m
- Merged PRs (30d)
- 825
Description
Found while doing the #5633 translation pass.
`pro-test/src/locales/fa.json` is registered as a supported language (`fa_IR` in
both `OG_LOCALE` and `ogLocaleMap`, RTL-enabled in `pro-test/src/i18n.ts`), but
it is not a translation — **571 of its 582 values are the English source string
verbatim**. The only Persian strings in the file were the `pricing.tiers.api` /
`apiBusiness` block, and those were stale: `api.highlightFeatures[0]` read
"بدون استفاده تجاری" ("No commercial use") — the exact contradiction the Pro
Business restructure removed — until #5633 retranslated them.
Net effect: a user who picks فارسی gets an English page with RTL layout applied.
This is why #5633's issue body reported fa as already-clean: it matches the
English schema exactly, so every key-existence check passes.
### Why the new freshness gate can't fix it
The EN baseline added in #5633 tracks *provenance* (which English string a value
was translated from), not *translatedness*. fa's English values are legitimately
"translated from the current English", so they read as fresh. The gate does pin
the problem in place — `tests/pro-locale-freshness.test.mjs` carries an explicit
`ENGLISH_PLACEHOLDER_ALLOWANCE` ceiling for fa that may only be lowered, and any
*other* locale that is >50% English fails outright — but it cannot translate it.
### Fix
Run the translator against fa with the placeholder values treated as
untranslated. The keys are present, so neither the missing-key path nor the
staleness path picks them up; this needs either a one-off `--force-locale=fa`
pass or deleting fa.json's English values first and letting the backfill refill
them. Then lower the allowance in the test to the real remaining count (brand
names, tier names, acronyms).
Note the pre-commit Unicode gate had to be fixed first (#5633) — Persian ZWNJ
(U+200C) in `pro-test/src/locales/` was being rejected as suspicious hidden
Unicode, which is likely why the file was left in English.
Contributor guide
Research direction
Start with pro-test/src/locales/fa.json, the translator or backfill path described in the issue, and tests/pro-locale-freshness.test.mjs; also review the Unicode gate fixed in #5633. Treat the English values as untranslated, refill the Persian locale, then lower fa's allowance to the remaining legitimate English names and verify the freshness and Unicode checks pass.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- internationalization, localization
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 58/100