A bot recently approved one of my Pull Requests (PRs) with the cleanest possible verdict: “No Issues Found — Recommendation: Merge.” The story did not end there.
Weeks later, a maintainer finally reviewed the contribution. By then, the parts of the repository targeted by the localization work had been removed as the project evolved. The PR was closed, not because the translation was incorrect, but because the review arrived after the underlying code structure had changed.
That outcome highlights a broader challenge in open source internationalization (i18n). The problem is often not translation quality. It is the absence of processes that allows language contributions to be evaluated, routed, and integrated before project evolution overtakes them.
Translation is Not the Hard Part
When people hear “i18n,” many maintainers think it means “drop a JSON file in.” That is not what it involves. Internationalisation is a system: stable keys, defined fallback behaviour, plural rules, date formatting, and ICU (International Components for Unicode)–style placeholders that must survive runtime interpolation. A six-character English label can easily expand to fourteen characters in Hindi or German, breaking UI layouts.
Hindi introduces a script layer that many English-centric projects rarely encounter. Devanagari vowel signs (matras) reshape preceding consonants, and conjunct consonants can expose limitations in font support. Tone also matters: “आप” reads as respectful, while alternative forms can feel too casual for a developer tool.
When a contributor submits a Hindi PR, maintainers often have no practical way to evaluate whether the translation is correct, complete, safe to merge, or maintainable across releases. That is the gap. Not goodwill. Not bandwidth. Infrastructure.
Four Projects, Four Signals
A few months of work across AI and developer tooling makes the pattern legible:
Open WebUI provides a positive example of how language contributions can be integrated when review pathways are clear. A Hindi localization correction PR (#23745) was merged on April 15, 2026, after addressing a set of erroneous interface translations. The contribution involved no architectural changes—just improved language quality—but still made a widely used self-hosted AI interface more accessible to Hindi-speaking users.
Kilo Code — what review latency looks like: PR #8377 received extensive automated review and multiple rounds of contributor fixes. Automated checks eventually reported no remaining issues, but maintainer review arrived only after the repository had evolved and the targeted application paths had been removed. The PR was closed with an invitation to resubmit against the current architecture. The translation itself was not the blocker; the review cycle outlasted the relevant code paths.
Hoppscotch illustrates a different pattern. Hindi localization PR #6025 remains active after multiple rounds of automated review, contributor updates, and community language feedback. Bots identified missing keys, fallback behaviour, and consistency issues, while contributors iteratively refined the translation. The process demonstrates both the value of automated review and its limits: tooling can identify structural problems, but language maintenance still depends heavily on human review and maintainer capacity.
OpenClaw highlights a different challenge: maintainer capacity. In issue #3460, maintainers acknowledged multiple requests and pull requests for localization support but stated that they lacked the bandwidth to support multilingual contributions properly. They cited the need for a formal i18n architecture, translation review processes, and ongoing maintenance before accepting language additions. The issue attracted volunteers offering support in Spanish, Japanese, Portuguese, Korean, Chinese, Vietnamese, and other languages, illustrating that contributor interest already exists. The bottleneck was not willingness from the community—it was the infrastructure required to support that willingness sustainably.
The maintainer position: insufficient bandwidth for multilingual support. New translation PRs would be closed. The community was already at the door; the project hadn’t yet built a doorway.
The `hermes-webui` maintainer captured the meta-pattern best in a Chinese localization review: “The translations themselves are the hardest part and you’ve already done that. The infrastructure to make it work safely is the remaining piece.”
OpenStatus — what collaborative review looks like: A Hindi localization PR was reviewed using a combination of automated tooling and language-specific feedback from community participants. Translation issues were discussed openly, refinements were made, and the contribution was merged. The project illustrates that maintainers do not necessarily need to be language experts if a review pathway exists for community validation.
If AI developer tooling remains English-first, English fluency becomes a de facto requirement for participation. The tooling choices maintainers make early on determine whether language contributions can scale. Most teams frame this as a library selection problem. It is, in practice, a governance problem.
Consider three commonly used localisation workflows:
- gettext is mature and handles plurals well. But in fast-moving web applications where locale files change frequently, its operational weight can become a bottleneck. Contributors face non-trivial setup costs, and maintainers must review large .po file diffs.
- i18next is widely used in React and Node ecosystems because its JSON-based approach makes diffs easy to review without a build step. However, without enforced key naming conventions or CI checks for missing keys, localisation can become inconsistent. Untranslated strings may propagate without clear visibility.
- FormatJS addresses more complex requirements such as plurals, gendered strings, and runtime interpolation. However, its ICU syntax—{count, plural, one {# item} other {# items}}—introduces a steep learning curve. Without supporting tooling, contributions may become difficult to review or modify safely.
None of these libraries, in isolation, resolves the underlying issue. What enables sustained internationalisation is the addition of a governance layer: documented key conventions, defined fallback policies, CI checks for structural correctness, and a clearly identified reviewer role.
Mozilla’s Pontoon platform provides a useful reference point. It does not replace localisation files; it makes them maintainable at scale by embedding them within a structured workflow.
What “Maintainer-Safe” Looks Like
Three concrete CI/CD and governance moves address most of the gap:
Add a CONTRIBUTING-i18n.md: Treat it as seriously as CONTRIBUTING.md. Cover locale file structure, key naming, machine translation policy, screenshots, and placeholder safety so interpolation does not break at runtime.
Make CI carry the mechanical risk: Missing-key checks, invalid JSON detection, malformed ICU messages, and untranslated fallback diffs are all detectable. CI cannot assess tone, but it can allow maintainers to merge with confidence.
Credit language contributors: Use release notes, contributor graphs, and attribution metadata. If a Hindi locale ships, the contributor should not disappear behind “updated translations.”
The most frustrating part of open-source localisation is not translating large locale files. It is watching valid contributions stall because projects lack a safe way to accept them.
If you maintain an OSS (Open Source Software) project, audit your contribution workflow this week. Could a new contributor add a language without asking basic questions? If not, the next merge is not blocked by translators. It is constrained by the project’s current design.
Author’s Note: This piece is an expanded follow-up to my essay ‘Open Source’s Hidden Language Gap,’ published by Communications of the ACM (CACM) on May 8, 2026.