Contributing Translations

WCPOS is translated by AI, guided by a carefully tuned set of rules — and made better by people like you. The machine produces a complete, consistent first pass in every supported language soon after a string changes; people catch the nuance, context, and local convention that a machine misses. You don't have to translate a whole app, and you don't have to be a developer to help. This page explains how it works and where to suggest a change.

How WCPOS translations work now

Every translatable string — the cashier-facing app, the desktop app, the WordPress admin screens, the plugin's PHP strings, and these docs — flows through one automated pipeline:

1. Source strings are extracted automatically from the apps, plugin, and docs into the central wcpos/translations repository (and, for the docs, this wcpos/docs repo).
2. AI translates them into every supported locale, following a strict rule set that preserves placeholders, code, brand names, and menu paths while localising the visible text.
3. A daily completeness check scans for missing or outdated strings and automatically queues them for translation, so new and changed strings don't sit untranslated.
4. Every batch lands in a pull request for human review before it ships. Approved translations are then released and delivered automatically — to the apps over a CDN, and to the plugin through its built-in translation updater.

Because the whole loop is automated, your job as a contributor is rarely to translate from a blank file — it's to improve a translation that's already there. Spot an awkward phrase, a term that should match what your locale's WooCommerce uses, or a label that reads wrong in context? Suggest a fix and it ships to everyone.

We no longer use translate.wordpress.org

WCPOS used to rely on the WordPress translation site (GlotPress) for plugin strings. We've moved off it entirely. That workflow is slow and dated, and — most importantly — it doesn't permit machine translation, so most languages never got finished. A tuned AI pipeline covers far more languages, stays in sync automatically, and produces better results in practice. If you've translated WCPOS there before, thank you — but that's not where contributions go anymore.

Where to contribute

There are just two places, depending on what you want to improve:

Apps & plugin

Everything in the POS app, the desktop app, the WordPress admin screens, and the plugin itself — both the JavaScript UI strings and the PHP strings. All of it lives in one repo: wcpos/translations. Basic GitHub familiarity helpful.

These docs

The documentation site you're reading right now. Translated MDX files live in the wcpos/docs repo under i18n/<locale>/. Helpful to know Markdown.

Improving app and plugin translations

All app and plugin translations live in the wcpos/translations repo. You'll find:

• source/ — the extracted English strings. Don't edit these — they're generated automatically from the apps and plugin.
• translations/js/<locale>/<project>/<namespace>.json — the translated UI strings. This is what you edit to fix the apps and admin screens.
• translations/php/<locale>/ — the translated plugin strings. Edit the .po file; the .mo and .l10n.php files next to it are generated, so leave them alone.

The JavaScript strings are split into four <project> folders:

Project	What it covers
monorepo	The POS app the cashier uses — buttons, cart, checkout, dialogs, errors.
electron	The desktop (Windows/macOS) app shell.
woocommerce-pos	The free plugin's WP Admin React screens — Settings, Templates, Logs, etc.
woocommerce-pos-pro	The Pro plugin's WP Admin React screens — Stores editor, Pro settings.

To suggest a fix:

1. Find the string in the file for your locale and project — for example translations/js/de_DE/monorepo/core.json for a German app string, or translations/php/de_DE/woocommerce-pos-de_DE.po for a German plugin string.
2. Edit the translated value. Leave the JSON keys, PHP msgid, and any {{interpolation}}, %s, %d, or <tag> placeholders exactly as they are.
3. Open a pull request. For a one-line fix you can use the pencil icon on GitHub and it'll open the PR for you. Reviewers check the change and merge it.

If your language isn't there yet, see Adding a new language.

Improving these docs

The docs site uses Docusaurus's standard i18n setup. The English source lives in versioned_docs/, and the AI-translated copies live in wcpos/docs under i18n/<locale>/docusaurus-plugin-content-docs/. Each English page has a counterpart in every active locale.

To suggest a fix:

1. Open the page in your language and click Edit this page at the bottom — that takes you straight to the translated MDX file on GitHub.
2. Edit the translation. Leave Markdown/MDX syntax, links, code spans, and frontmatter keys intact — translate the prose, headings, and visible labels.
3. Open a pull request. Don't edit the English source under versioned_docs/ to "fix" a translation — only the file under i18n/<locale>/.

For a larger contribution — a whole section, or starting a brand-new locale — open an issue first so we can coordinate.

Adding a new language

The apps and plugin already ship translations for 50+ locales (see locales.json for the full list). The docs ship a smaller set, listed below. If your language is missing — or only partly covered — open an issue on the relevant repo and we'll wire up the locale. The AI pipeline can fill in a new language quickly; from there it's a matter of the community polishing it.

Locale codes

These docs are currently published in the following languages:

Code	Language
ar	Arabic (right-to-left)
de	German
es	Spanish
fr	French
hi-IN	Hindi (India)
it	Italian
ja	Japanese
ko	Korean
nl	Dutch
pt-BR	Portuguese (Brazil)
zh-CN	Chinese (Simplified)

A note on locale code formats: the apps and plugin (wcpos/translations) use the underscore form for folders and filenames — de_DE, pt_BR, zh_CN — and include both base languages (de, fr, es) and regional variants (de_AT, fr_CA, es_MX). The docs and web language tags use the hyphen form — pt-BR, hi-IN, zh-CN. Use whichever form matches the repo you're editing.

Translator tips

These mirror the rules the AI pipeline follows, so they're the same things a reviewer will look for:

• Keep placeholders intact. Strings often contain {{variable}}, %s, %d, or <strong> tags — translate the surrounding text but leave the placeholders exactly as they are. WCPOS substitutes real values into these at runtime.
• Keep brand and product names exact. WCPOS, WCPOS Pro, WooCommerce, WordPress, Stripe, Stripe Terminal, and SumUp stay as-is. Use WCPOS in customer-facing text — not "WooCommerce POS", which only belongs in technical identifiers like slugs and URLs.
• Do localise visible UI labels. Menu labels, settings labels, and button text should read naturally in your language — match what your locale's WordPress and WooCommerce already use (for example, a WP Admin > Settings > Payments breadcrumb should use your locale's WordPress menu names).
• Match the existing tone. WCPOS docs and UI are deliberately practical and direct, and use a formal/neutral register. If the English says "Add Coupon", use the verb form your locale puts on similar buttons — not a literal noun.
• Don't translate code, URLs, or technical IDs. Coupon codes, gateway IDs, locale codes, file paths, and shortcodes stay in English. If you're unsure, leave it untranslated — that's safer than mangling something the system relies on.
• Test in context if you can. Set your site or app to your locale and check the string on the actual screen. A phrase that fits one screen can wrap awkwardly on another.
• Right-to-left (RTL) languages — Arabic, Hebrew, Persian, Urdu — also need the receipt templates flagged as RTL. WCPOS ships bundled RTL receipt templates; see Customise your receipt for the gallery.

Where to ask for help

• WCPOS Discord — for translation discussions and questions (invite).
• GitHub issues — file against wcpos/translations for the apps and plugin, or wcpos/docs for the docs.