Text is translated using GlotPress. The process of getting original strings into GlotPress and the translations back into the app is fully automated as part of the release process.
The set of supported languages is defined by supportedLocaleNames in
packages/common/lib/locale.ts. To add a new language:
- Add a
studio-<locale>.jed.jsonfile inpackages/common/translations/. - Import it and register it in
localeDataDictionaryinpackages/common/translations/index.ts. - Add a
supportedLocaleNamesentry (its display name) inpackages/common/lib/locale.ts.
The supportedLocales array is derived automatically from supportedLocaleNames,
so it does not need to be edited by hand.
The <locale> slug must match the language's slug in the
Studio GlotPress project — the
automated export (see below) downloads from …/<locale>/default/export-translations/
and fails if that locale does not exist there.
- During code freeze, the
code_freezeFastlane lane extracts all translatable strings and commits the resultingi18n/bundle-strings.potfile to the release branch. - A wpcom cron job (
import-github-originals.php) periodically fetches the.potfile from trunk (via the backmerge PR) and imports it into GlotPress.
No manual steps are needed for string extraction or import.
During each beta release, the new_beta_release Fastlane lane downloads translations
from GlotPress in Jed 1.x JSON format (which @wordpress/i18n understands) and commits
them directly to the release branch before bumping the version. It's ok if some translations
are missing — they will be left as English in the app.
The lane discovers locales by globbing the existing studio-*.jed.json files in
packages/common/translations/ (e.g. studio-ckb.jed.json → ckb) and downloads each
one from GlotPress. There is no separate allowlist — adding a translation file is what
opts a locale into the automated download.
No manual steps are needed for translation export. The standalone fetch_glotpress_translations
lane can be used to manually download translations if needed.