Skip to content

Translation workflow

This page covers production translation assets. Runtime localization semantics are documented separately; the build files and translation workflow are authoritative here.

Source-to-runtime pipeline

  1. C++ strings use the translation helpers; supported JSON types use translation fields.
  2. lang/update_pot.sh and the JSON extractor build the source template.
  3. Translators work in the configured CCB Transifex project.
  4. .github/workflows/build-translations.yml pulls PO files, rejects invalid entries, updates statistics, compiles MO files, and publishes a translation artifact.
  5. platform builds consume that artifact; src/translations.* selects and caches a language.

Contributor rules

Use context for ambiguous English and plural helpers for counted messages. Keep placeholders, markup tokens, newlines, and semantic context stable. Do not hand-edit files explicitly marked as generated or replace CCB project identity with an upstream resource name.

Local checks

The repository's focused compilation entry is:

make -C lang -j2

Extraction and full catalog refresh can touch many files and external translation state; run the exact workflow required by the change, review the resulting PO/POT diff, and do not claim a Transifex pull occurred without credentials and logs.

Validation

Check extraction, invalid PO handling, MO compilation, placeholder parity, plural/context behavior, a localized build, and representative UI at narrow width. Android resource strings and Lua i18n are additional pipelines and need their own validation when changed.

Attribution and maintenance

Preserve translator credits and source provenance. Translation service credentials remain in repository secrets. A failed external pull must not be hidden by publishing empty or stale artifacts; trusted default-branch artifact reuse must remain explicit in CI logs.