OSS Infrastructure Initiative

Open-source localization review and language inclusion

Translation quality is only part of localization. Maintainers also need review infrastructure that detects defects even when nobody on the review team reads the language.

Status: published on PyPI Tool: i18n-security-lint Case studies: 6, verified 25 Sep 2026 Repository: oss-language-inclusion

The infrastructure gap

Open source has standardized infrastructure for code contribution — linters, continuous integration, code owners — but no equivalent for language contribution. We call this the language inclusion gap: whether a translation is reviewed well depends on local process and on whether a maintainer happens to read the language.

Locale files often receive less review than source code. A translated string can preserve the intended meaning and still introduce a bidirectional-text override, unsafe markup, a changed format placeholder, or broken interpolation. These are mechanical defects, so a reviewer should not need language fluency to detect them.

The workstream studies real localization contributions and the conditions under which maintainers accept, delay, or reject them. The research is used to define a bounded tool rather than a general claim that automation can evaluate translation quality.

Case studies

Each case study follows one real contribution through upstream review, using the public record. All were re-verified against GitHub on 25 September 2026; corrections are logged in the repository’s corrections file. Pull-request states change, and each linked source is authoritative.

All case studies

What the tool checks

  • Bidirectional control characters
  • Markup introduced into translated strings
  • Format-string drift
  • Broken interpolation placeholders

What it does not claim

  • It does not judge translation quality.
  • It does not replace native-language review.
  • It does not prove a locale is complete.
  • It does not infer contributor intent.

Use it

Install from PyPI with pip install i18n-security-lint, then add the command to the same continuous-integration workflow that reviews source changes. It reads JSON, GNU gettext .po, XLIFF, and Fluent files; with --strict it exits non-zero on findings, so it can gate a pull request.

In GitHub Actions: uses: ecogetaway/oss-language-inclusion/tools/i18n-security-lint@v0.2.1 with path: locales/.

Install from PyPI Read the research and source

Standards context

Unicode Technical Standard #55, Source Code Handling, addresses bidirectional-ordering spoofs and confusable characters in source code. Locale resource files, which are reviewed as translation artifacts rather than as code, have no equivalent security review checklist: GNU gettext, ICU MessageFormat 2.0, and XLIFF specify message syntax, not review criteria. The workstream publishes that checklist as an openly licensed specification.

Shipped, draft, and planned

Evidence behind the work

Help with this workstream

Native-language review for Hindi and other Indic locales is the capacity the roadmap names as missing. A standing volunteer role covers the localization pipeline and new case studies, at about four to five hours a week.

Offer language review Localization and case-study volunteer role

Continue exploring