# 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[​](#how-wcpos-translations-work-now "Direct link to 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`](https://github.com/wcpos/translations) repository (and, for the docs, this [`wcpos/docs`](https://github.com/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[​](#where-to-contribute "Direct link to 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](https://github.com/wcpos/translations)**. *Basic GitHub familiarity helpful.*

#### These docs

The documentation site you're reading right now. Translated MDX files live in the **[wcpos/docs](https://github.com/wcpos/docs)** repo under `i18n/<locale>/`. *Helpful to know Markdown.*

## Improving app and plugin translations[​](#improving-app-and-plugin-translations "Direct link to Improving app and plugin translations")

All app and plugin translations live in the [`wcpos/translations`](https://github.com/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](#adding-a-new-language).

## Improving these docs[​](#improving-these-docs "Direct link to 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`](https://github.com/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[​](#adding-a-new-language "Direct link to Adding a new language")

The apps and plugin already ship translations for **50+ locales** (see [`locales.json`](https://github.com/wcpos/translations/blob/main/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[​](#locale-codes "Direct link to 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[​](#translator-tips "Direct link to 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](/receipts/customise.md) for the gallery.

## Where to ask for help[​](#where-to-ask-for-help "Direct link to Where to ask for help")

* **WCPOS Discord** — for translation discussions and questions ([invite](https://wcpos.com/discord)).
* **GitHub issues** — file against [`wcpos/translations`](https://github.com/wcpos/translations/issues) for the apps and plugin, or [`wcpos/docs`](https://github.com/wcpos/docs/issues) for the docs.