Contributing Translations

WCPOS currently ships translations for 10 locales, and there's room for many more. Contributions are very welcome — you don't have to translate everything, and you don't have to be a developer. This page covers what to translate and where.

The four places that hold translations

WCPOS spreads translatable strings across four repositories, each with its own contribution flow. You can contribute to any one of them independently.

WordPress plugin (PHP strings)

Admin notices, settings page labels, error messages, and WP Admin UI. Translated on translate.wordpress.org using GlotPress — the standard WordPress translation flow. No coding required.

POS app (React/i18next)

Everything the cashier sees at the till — buttons, dialogs, error messages, the cart and checkout UI. Translation files live in the wcpos/monorepo repository; contributions go via pull request. Basic GitHub familiarity helpful.

WP Admin React screens

The newer React-based settings, Stores editor, Templates, Extensions, and Logs pages. Translations live in wcpos/woocommerce-pos (and woocommerce-pos-pro for Pro screens) as JSON files. Basic GitHub familiarity helpful.

These docs (Docusaurus)

The docs site you're reading right now. Translated MDX files live in the wcpos/docs repository under i18n/<locale>/. Contributions go via pull request. Helpful to know Markdown.

WordPress plugin strings (the easiest place to start)

If you've never translated a WordPress plugin before, this is the path with the least friction:

1. Find your language at translate.wordpress.org/projects/wp-plugins/woocommerce-pos/ — every locale WordPress supports has a sub-project.
2. Sign in with your WordPress.org account (the same one you use to comment in support forums). Create one for free if you don't have it.
3. Pick a sub-project — typically you'll see:
   • Stable (latest release) — strings shipped in the current public version. Translations here go live on every site that updates the plugin.
   • Development (trunk) — strings in the next release. Translate these to be ready before the next version ships.
   • Stable Readme / Development Readme — the plugin description that appears on WordPress.org.
4. Submit translations one string at a time through the GlotPress UI. They start as Suggested until a Project Translation Editor (PTE) approves them.
5. Become a PTE by asking on the WordPress polyglots Slack after a handful of approved translations. PTEs can approve translations directly without waiting for review.

Once your translations are approved, they ship automatically to every WCPOS user in your locale — no code changes, no PR.

POS app translations (the React UI)

The cashier-facing UI is a React app that uses i18next for translations, rebuilt in v1.8.8. Translation files live as JSON in the wcpos/monorepo repository (the cross-platform POS core).

The setup has two helpful features:

• On-demand loading — only the active locale is fetched at runtime (from jsDelivr's CDN), so adding a language doesn't bloat downloads for everyone else.
• Regional fallback — i18next JSON filenames use underscores: pt_BR falls back to pt, es_MX falls back to es, etc. Docs and web language tags use hyphens instead, such as pt-BR or es-MX. Use the underscore form for translation JSON files and the hyphen form where language tags are required.

To contribute:

1. Find the en source file in wcpos/monorepo under the translation packages directory (the exact path varies — easiest is to start a fresh translation by opening an issue on the repo and asking which file to copy).
2. Copy en.json to <your-locale>.json following the i18next JSON locale convention (fr.json, de.json, pt_BR.json, etc.; use underscores for regional filenames).
3. Translate the values, leaving the keys and any {{interpolation}} placeholders intact.
4. Submit a pull request against the monorepo. The CI will validate the JSON structure.

For minor edits to an existing translation, you can edit the JSON file directly on GitHub via the pencil icon — GitHub will open a PR for you.

WP Admin React screens

The WordPress admin settings, Stores editor, Templates page, Extensions catalog, and Logs all use the same translation pattern as the POS app but live in two separate repositories:

• Free admin screens — wcpos/woocommerce-pos repository, at packages/settings/src/translations/locales/<locale>/wp-admin-settings.json (and similar paths for other admin packages; use underscore locale folders like pt_BR for regional JSON locales).
• Pro admin screens — wcpos/woocommerce-pos-pro repository, with the same pattern (e.g. packages/store-edit/src/translations/locales/<locale>/wp-admin-store-edit.json, with underscore locale folders like pt_BR).

The contribution flow is the same as the POS app: copy en.json to <your-locale>.json, translate, open a PR.

Documentation (these pages)

The docs site uses Docusaurus's standard i18n setup. Translated MDX files live in the wcpos/docs repository under i18n/<locale>/docusaurus-plugin-content-docs/current/. Each English page in versioned_docs/version-1.x/ has a counterpart in every active translation locale.

The site already has automated translation tooling — there's a pnpm translate script that uses the OpenAI / Anthropic APIs to draft translations from English, which a human reviewer then polishes. So the typical contribution flow is:

1. Pick a page that needs translating or improving. The site footer language selector shows which languages are active.
2. Edit the corresponding MDX file under i18n/<locale>/... directly on GitHub via the Edit this page link at the bottom of every page.
3. Submit a pull request. Reviewers will check translation accuracy and merge.

For larger contributions (translating a whole section or starting a new locale), open an issue first to coordinate with the team.

Locale codes WCPOS uses

WCPOS currently ships these 10 locales. The docs table uses hyphenated language tags for regional locales; use the equivalent underscore form for i18next JSON files, such as pt_BR for pt-BR and zh_CN for zh-CN.

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

If your language isn't on the list, open an issue on whichever repo you want to start with and we'll wire up the locale.

Translator tips

• 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.
• Match the existing tone. WCPOS docs and UI are deliberately practical and direct. If the English says "Add Coupon", the translation should be the verb form your locale uses on similar buttons — not a noun.
• Test in context if you can. Set your WordPress site to your locale, install the plugin, and verify the strings look right on the actual UI. Context matters — a string that fits one screen can wrap awkwardly on another.
• 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.
• 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

• WordPress.org polyglots Slack — for Glotpress-related questions
• WCPOS Discord — for WCPOS-specific translation discussions (invite)
• GitHub issues — file against the relevant repo (woocommerce-pos, woocommerce-pos-pro, monorepo, or docs) for repo-specific questions