Influxx's README doesn't exist in one language — it exists in six, sitting side by side in the repository, each one a full document with its own screenshots, its own feature walkthrough, and its own install instructions. That's a normal thing for an open-source-adjacent project to attempt and an easy thing to get quietly wrong, because a translated README isn't graded on how good it reads in isolation. It's graded on whether a developer in São Paulo or Seoul who follows it end up with a working install — the same install an English reader would get. As part of the Influxx 1.2 release wave, keeping those six documents honest with each other was treated as its own piece of release discipline, not a side project.
Six Documents, One Product
The repository carries an English README.md at the root, and Spanish, Japanese, Korean, Portuguese, and Simplified Chinese versions living together under docs/readme/ — README.es.md, README.ja.md, README.ko.md, README.pt.md, and README.zh-CN.md. Every one of the five translations opens with the same language switcher — a row of links to English and to each of the other four languages — so a reader who lands on the wrong version is one click from the right one. That switcher only works as a piece of infrastructure if it's present and correct in all five files at once; a switcher that links to four languages instead of five, or points at a stale filename, is worse than no switcher at all, because it looks trustworthy right up until it fails.
What Actually Has to Match
Not every sentence in a README carries the same risk if it drifts. Marketing copy going slightly stale is a readability problem. A factual line going stale — a download link, a supported-platform claim, an install command — is a reliability problem, because a reader has no way to tell a confidently wrong instruction from a correct one until it fails on their machine.
The clearest example of a fact that has to travel identically across every version is the direct download link. The English README's primary call to action points at https://github.com/etapx/influxx/releases/latest/download/influxx-macos-arm64.dmg — and that exact URL, character for character, is what each of the five translated documents uses for their own equivalent "download Influxx" link at the top of the page. Alongside it, the platform claim it's paired with — macOS Apple Silicon (arm64) only — appears as the same badge text in the English document and in every translation. That's not a coincidence; it's the one line in the whole document where "translated" and "wrong" are separated by a single stale word, so it's treated as a fact to be copied precisely, not prose to be adapted.
Why Prose Gets More Latitude Than Facts
A tagline or a feature description can be translated with some interpretive freedom — a phrase that lands naturally in Japanese doesn't need to be a literal word-for-word mirror of the English. A URL, a version number, a supported-platform list, or a CLI command has no such latitude. The discipline that matters here is knowing which category a given line falls into before touching it.
The Shape Is the Same, Language by Language
Beyond the one link that has to match exactly, the five translations share a structural skeleton that makes it possible to compare them at a glance: the same badge row, the same feature table with a mobile-companion section, a parallel-worktrees section, and the same pattern of an App Store link followed by a docs link (https://www.etapx.us/docs/mobile) pointing at the same mobile documentation page. That shared shape is what makes staleness detectable in the first place — if every translator were free to restructure their own document, a missing section or a swapped-out link would blend into "stylistic difference" instead of standing out as a gap.
"Structural parity is what makes a diff review possible at all. If the Korean doc and the Spanish doc don't have sections in the same order, you can't scan them side by side and ask 'did this line get updated everywhere' — you have to read all five in full every single time. Keeping the skeleton identical is what turns a full re-read into a targeted check."
— Hana Beckett, Documentation Engineer at ETAPX
Where Drift Sneaks In
None of this is automatic, and the five translations aren't in perfect lockstep at every moment — that's the honest version of this story, not the tidy one. The Portuguese README, for instance, currently carries an extra TestFlight link and a version-tagged Android APK reference in its mobile-companion section that the other four translations don't have. Nothing about that is broken or misleading on its own; it just means one contributor updated their own language file with information the other four haven't picked up yet. That's precisely the kind of small, low-stakes drift the process exists to catch before it turns into something a reader actually trips over — a stale install command or a dead download link left unfixed in four out of five languages because only the English source got touched.
The failure mode worth guarding against isn't dramatic. It's mundane: someone updates the English README because a command changed or a link moved, ships it, and the five translations sit untouched until someone notices — usually a reader, not a maintainer.
"I read the Korean README because it's just faster for me, and I've been burned before by docs where the translated version was three releases behind the English one — different commands, broken links, the works. I went looking for a mismatch here on purpose and the install instructions matched what the English doc said, including the exact download link. That's a low bar, but most projects don't clear it."
— Ji-hoon Baek, backend developer, independent contractor, Influxx user
Sync as a Release Habit, Not a Translation Project
The distinction that matters is between translating a document once and maintaining five documents forever. A one-time translation project treats the non-English versions as a deliverable that ships and is then done. Treating it as a release habit means every change to a factual line in the English README — a new download shape, a changed install command, an updated link — is supposed to generate a corresponding check across the other five, the same way a schema change generates a migration. It doesn't mean every release touches every translation; most releases don't change any fact that needs propagating. It means the question gets asked every time something factual does change, instead of assuming someone will eventually notice.
"Publishing a README in five extra languages is the easy part — it's a translation pass, and you do it once. Keeping it honest is the part that actually costs something, because it means every future change to the English doc has a tax: five more files to check. We pay that tax on purpose, because the alternative is a non-English reader following instructions that were true six months ago and aren't anymore, and they have no way to know that from inside the document."
— Renata Solis, Head of Developer Relations at ETAPX
Frequently Asked Questions
Are all six README versions perfectly identical right now?
No, and we're not going to pretend otherwise. Structural elements and factual lines like the download link and platform claim are kept in sync deliberately, but smaller gaps exist — the Portuguese version currently has a TestFlight link and an APK version reference the other four don't carry yet. That's a minor, honest example of drift, not evidence the process doesn't matter.
Are the translations done by machine translation?
We're not going to detail the internal translation workflow here. What we can say is that the documents are reviewed for factual accuracy against the English source, which is the part that actually determines whether a reader's install works.
Which languages does the README ship in besides English?
Spanish, Japanese, Korean, Portuguese, and Simplified Chinese, each as a full standalone document under docs/readme/, linked from a language switcher at the top of every version.
What happens if a translation falls behind the English source?
In the worst case, a reader in that language follows an instruction — a command, a link — that was accurate when it was translated but has since changed in English. That's the specific failure this discipline is meant to prevent, and it's why factual lines get checked across all five languages whenever they change in the source.
Does every release update all six README files?
No. Most releases don't touch a factual line in the README at all, in which case there's nothing to propagate. The habit is asking the question every time something factual does change, not touching every file on every release regardless of need.
Why not just link non-English readers to a translation tool instead?
A machine-translated page done at read-time doesn't know which lines are marketing copy and which are commands that need to be copy-pasted exactly. A maintained, reviewed translation can preserve exact syntax for the parts where precision matters, which an on-the-fly translation can't guarantee.
Is this something only Influxx does, or is it a common practice?
Plenty of larger open-source projects maintain translated docs with real rigor — this isn't a novel idea. It's a discipline that's easy to state and consistently harder to keep up than it sounds, which is exactly why it's worth writing about instead of assuming it happens by default.
A README in five languages that quietly drifts apart is worse than a README in one language, because it looks complete right up until someone trusts it and it isn't. The goal here was never six perfect documents forever — it was six documents that get checked, honestly, every time the facts underneath them change.
