Build1 publisher3 min readPublished
A survey found roughly 660 user-facing text nodes across 53 files and no i18n at all. What decides whether thirteen unreviewed locales survive is a plural-rules polyfill and the choice to store locale per user.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
The argument for doing this before launch is a calendar slot, not a cost model. Google Play holds a build in closed testing for fourteen days regardless, and the author's judgement in the CannyCart build log is that fourteen days of real people on translated builds beats fourteen days of them on English [2][18]. Nothing in the post prices the after-launch alternative. If your release path does not force a wait you cannot compress, the retrofit competes with launch work rather than hiding inside it, and the survey numbers are what you are actually buying down: no i18n infrastructure, roughly 660 user-facing text nodes, 53 files [1].
Those nodes came out as 568 English keys at launch [5]. Against the rounded 660, extraction removed about 92 duplicate strings, near 14 percent, which is the reuse you only find by reading every alert and toast in one pass [1]. The machine tier then inherits that surface: thirteen locales at 568 keys is 7,384 generated strings, from a diff-only pipeline that had to be forced into structured output because free-form JSON kept breaking on quotes [15][2]. That is a lot of copy whose first reader is a user.
The plural-rules polyfill is therefore load-bearing rather than tidy. The author reports that the Hermes engine ships a real `Intl` on some platforms and a stub on others, and that Arabic needs six plural categories [4]. A stub does not throw. It hands back a category anyway, and the Arabic dual reads as a fluent sentence that is wrong about how many items you have. Thirteen of the nineteen shipped locales get no human review, so nothing downstream catches it [3]. The same class of trap already hit this codebase once, on thousands separators [19].
First paint is the other place the design shows. Resources are bundled statically so the first frame already has copy instead of raw keys, `dayjs` switches locale alongside so dates move with the words, and a per-user AsyncStorage cache resolves the language before the profile query returns [3][6][8]. `UserProfile.locale` is the durable value that roams; on account switch the language resets to the device default and is then restored from the incoming profile [8][9].
Arabic is in the launch tier precisely because right-to-left finds every layout assumption, and the flip only lands at the next launch [16][12]. The one-shot restart prompt is mounted inside the onboarding gate, so a first-run Arabic choice finishes onboarding before the app asks to relaunch [12]. Onboarding also gained a language step ahead of currency, pre-selecting the device language [11].
What transfers here is ordering. The cache resolves before the profile query, and the polyfill lands before the unreviewed locales do.
Ranked by verification strength, evidence, and original report placement.
A codebase survey found zero i18n infrastructure, roughly 660 user-facing text nodes across 53 files, a dozen alert dialogs, forty toasts and screen titles scattered across layout files, with English load-bearing everywhere.
The reason to retrofit i18n before launch rather than after was the closed-test window: Google Play makes you sit in testing for fourteen days regardless, and fourteen days of real people using translated builds was judged worth more than fourteen days of them using English.
The library layer is i18next plus react-i18next with the intl-pluralrules polyfill, eight feature namespaces, and static resources bundled with the app so the very first frame already has copy and there is no flash of keys.
The Hermes engine ships a real Intl on some platforms and a stub on others, and correct CLDR plural rules become essential once Arabic, with six plural categories, is in the mix.
dayjs switches locale alongside the UI language so dates translate with the words.
Publishers with included, body-backed reporting in this cluster.
1 article · September 6, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
product
Pennsylvania's Snap case makes an App Store questionnaire the alleged lie1 publisher
build
Axonius runs one agent per tenant on AgentCore, and tracks model cost the same way1 publisher
build
AWS's one-minute test for agent access is really a test of where the answer lives1 publisher
build
Cognito rejects RFC 8707, so it cannot be the authorization server for an MCP client1 publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One first-person build log
Every figure traces to one developer describing his own repository: 660 text nodes, 568 keys, 33 mirrored layouts, nineteen raw font strings. None of it can be checked from outside, and dev.to adds no editorial verification. What keeps the score off the floor is that the technical spine is independently testable by any reader who has fought the same libraries, since Hermes builds really do differ on Intl and Arabic really does carry six CLDR plural categories.
Pre-launch, one app
The nineteen locales exist inside a build sitting in a Google Play closed test, which is the entire deployment record. No install counts, no tester reports from the translated builds, no other project picking up the pattern. The score sits near the floor because usage begins and ends with the author's own unlaunched app.
Nineteen locales, six reviewed
Nineteen is a locale count, not a quality count. Thirteen of those locales come out of a diff-only model pipeline, which by our arithmetic is around 7,384 strings at the launch key count that no fluent reader has seen, and Arabic plural handling is precisely the judgement a pipeline handles worst. The gap stays modest because the post labels the extended tier as machine-translated and explains the polyfill work that keeps the reviewed languages' plural forms correct.
Build diary with a launch pending
A numbered public build diary rewards decisions that read as prescient, and the two spare lines writing Cognito's locale attribute are told exactly that way, with the follow-up episode trailed in the same paragraph. Against that pull: no sponsor, no vendor relationship, no product being sold to the reader, and the machine-translated tier is named as such instead of folded into the language count.
Single account, exact numbers
One author, one post, and nobody else who has run these builds. The precision cuts both ways: figures this specific are falsifiable the moment the app ships and behaves otherwise, but a self-published engineering diary caps how far any of it can be relied on today.