If you want to contribute to ethereum.org's localization work right now, the path has changed. Full-page translation through Crowdin is paused, and new translation submissions are not being accepted there. The stated replacement is ETHGlossary, a shared, community-reviewed glossary of Ethereum terms in 24 languages. So the practical question for a contributor is no longer "which page do I translate?" but "how do I check a glossary term before I approve it?"
The stakes are concrete. Per the program, the terms you approve are the terms ethereum.org uses in your language, and reviewed terms are published through the ETHGlossary API so wallets, apps and documentation teams can use them too. A rushed approval travels further than one page.
What changed, and what did not
Three statuses are worth separating. First, announcement and implementation: reviewing terms on ETHGlossary is described as the way to contribute in the meantime, while full-page translation through Crowdin is paused. Second, availability: ETHGlossary covers 24 languages — Arabic, Bengali, Chinese (Simplified and Traditional), Czech, French, German, Hindi, Indonesian, Italian, Japanese, Korean, Marathi, Polish, Portuguese (Brazil), Russian, Spanish, Swahili, Tamil, Telugu, Turkish, Ukrainian, Urdu and Vietnamese. Third, continuity: work by past community translators remains live on the site, and recognition on the acknowledgements and contributors pages stays in place.
The underlying goal has not changed. The program's stated aim was to make Ethereum accessible to everyone by translating ethereum.org and other Ethereum content into as many languages as possible, on the argument that much Ethereum content only caters to English speakers.
Verification checklist for a single term
The program states that every language has the same set of Ethereum terms, each with a draft translation, and that reviewing a single term takes a couple of minutes. That short window is the point: the check is small enough to do properly each time.
- Read the draft as a native reader, not a translator. The stated goal is that Ethereum should read naturally in every language. If the draft reads as a literal transfer from English, that is your first flag.
- Ask how your community actually says it. The offered actions include proposing a better alternative or adding context on how the term is used in your community. Community usage is part of the input, not an afterthought.
- Check whether the term already has an established local form. Wallets, apps and documentation teams can consume reviewed terms through the glossary's open API. A term that clashes with what local products already display creates downstream inconsistency.
- Decide between the three allowed responses. You can approve the draft, propose a better alternative, or add usage context. Approving is a positive decision, not a default when you are unsure.
- Escalate rather than guess. Questions and feedback go to the ethereum.org Discord; errors in existing translations are reported as an issue on GitHub.
Worked example (Hypothetical)
Suppose you are reviewing a draft term in Spanish and you are unsure whether the draft matches how wallets in your region label the concept. A disciplined sequence: read the draft, search how local products phrase it, then either approve or propose an alternative plus a one-line usage note. Under the program's own estimate of a couple of minutes per term, the whole sequence stays inside a single short sitting. The example is illustrative, not a report of any specific term's status.
Now scale the consequence rather than the effort. If the same disputed term appears across the 24 listed languages and each review is treated as a two-minute box-tick, the review time is small while the reach of a poor approval is large. The ratio is the argument for doing the small check carefully.
Why this matters beyond ethereum.org
For readers who follow how crypto organizations sustain contributor programs, this is a useful case. The program did not simply stop; it narrowed the contribution surface from full-page translation to term-level review, and it kept the output machine-readable through an open API. The people doing the work are still described as the key part of the program, and their past work remains live.
That structure has a commercial edge. Teams building wallets, apps and documentation can adopt the same approved vocabulary instead of inventing their own, which reduces the mismatch a non-English user meets when moving between a site and a product. Nothing here implies any token value, funding outcome or financial return, and none should be read into it.
What the source does not say
The source does not state when Crowdin page translation will resume, or whether it will. It gives no review quotas, no deadlines, no per-language reviewer counts, and no schedule for publishing glossary updates. It does not say how disagreements between reviewers are resolved, or who holds final authority over a disputed term.
It also does not quantify the claimed English-language gap, describe the glossary's licence terms, or specify which wallets and apps currently consume the API. And it does not claim that any individual review is verified by the program before it takes effect; the described model is community review, so treat an approval as a community decision rather than a certified one.