# From 2 to 20 languages

Scale a project from a handful of languages to broad coverage: decisions to make first, a phased rollout, and quality signals that do not depend on hand review.

Canonical: https://comvi.io/docs/platform/recipes/scaling-languages

Three decisions compound with the language count, so make them before the first wave.
No plan limits how many languages a project has, and a key counts once against the key
limit however many languages it is translated into. What grows with every language is
machine-translation credit use and review work; see [Languages](/docs/platform/languages).

## Decide first

**Source text discipline.** Keep one source string in one place. Editing a source string
touches every target: with a machine-translation provider enabled, a 100%
[translation-memory](/docs/platform/translation-memory) match is written straight in and
every other language is queued for machine translation, both landing as `Needs Review` in
place of the old approved wording. With no provider enabled nothing fires and the stale
targets stay `Translated`. Either way a source edit needs a reviewer pass you schedule, so
batch source edits into their own release.

**Key naming.** Use stable, descriptive keys (`checkout.payment.card_number`, not
`label_42`) and split feature areas into [namespaces](/docs/platform/namespaces) before the
key count grows; a namespace that holds keys cannot be deleted, and the dashboard cannot
rename one. Fill in both key context fields: **Internal notes (not sent to MT)** for your
team, **AI translation context (sent to MT)** for the provider.

**Terminology.** Create a [glossary](/docs/platform/glossaries) with product terms marked
**Correct** or **Forbidden**, and leave **Translatable** unchecked on brand names so the
**Non-translatable Modified** check flags any target that changes them. Switch on the
shared [translation memory](/docs/platform/translation-memory) from the **Entries** tab; it
serves every project in the organization with the same source language.

## Phase the rollout

**Launch languages.** Four or five targets, such as `de`, `fr`, `es`, `it`, or `ja`,
`zh-Hans`, `ko`. One human translator per language plus a reviewer, using the
[translator and reviewer workflow](/docs/platform/recipes/translator-review-workflow).
Machine translation is a draft only; a human reads every string.

**Expansion.** Mid-size markets: `pt-BR`, `nl`, `pl`, `sv`, `da`, `tr`, `ar`, `ru`, `vi`,
`th`. Bring in an agency ([Onboarding agencies](/docs/platform/recipes/onboarding-agencies)).
The translation memory pays off in the editor's side panel, and a newly created key
with a 100% match is filled from memory instead of calling a provider. Bulk translation has
no such shortcut and bills every key it sends. Consider an AI provider for drafts, since
glossary terms reach it through the prompt; see
[Machine translation](/docs/platform/machine-translation).

**Long tail.** Smaller markets and regional variants. Machine translation first, then a
five to ten percent review sample per language. Fix what you find in the glossary and in the
AI context (per key, per language or per project) rather than string by string. Watch the
deploy result under **Settings → Content Deploy** after each wave.

## Run many languages day to day

- **Restrict by language.** Give each translator and reviewer a language restriction on the
invite (the checkboxes appear once a project is selected) or later under
**Settings → Project Access** with **Change role & languages**.
- **Read the Languages page as a dashboard.** Each language's bar splits into `Translated`,
`Needs Review` and `Not Translated`, and the table sorts by progress. A language at 80%
with a growing `Needs Review` count has a reviewer bottleneck, not a translator one. The
same numbers come from [`GET /v1/projects/:id/locales/stats`](/docs/api/languages).
- **Deploy a language or leave it out.** The **Locales** list under **Settings → Content
Deploy** is checkboxes, not a readiness threshold. If half-translated Portuguese is worse
than missing Portuguese, leave `pt-BR` unticked until it is ready.
- **Give a new feature its own namespace** so translators can filter to the new work.

> **Right-to-left and canonical codes**
>
> Locale codes are canonical BCP-47 (`pt-BR`, `zh-Hans`, `sr-Latn`). The editor lays out
> values right-to-left for the language subtags `ar`, `he`, `fa`, `ur`, `yi`, `ps` and `sd`,
> including regional variants such as `ar-EG`.

## Quality signals that scale

- **Glossary check.** Runs as a translator types and asks for confirmation before saving a
value with an error; a prompt, not a wall.
- **Translation memory matches.** Shown from 50% similarity upwards. A 100% match is a
phrase already agreed elsewhere.
- **Review sampling.** Five percent per language, rotating which reviewer does it.

Placeholder parity is not checked. Comvi saves a target that lost its `{count}`, so check it
in CI against your own source files if that matters.

## What changes at twenty languages

- **Source edits become a release of their own.** One change re-translates twenty languages
back to `Needs Review`, or leaves twenty silently stale when no provider is enabled.
- **The glossary decays without an owner.** It keeps "Cart" the same word across a year of
contributors only while someone maintains it.
- **One bad language can stop the deploy.** A deploy aborts when more than 5% of its files
fail, which at twenty languages is one file. The files that uploaded are already on the
CDN, so the edge holds a mix until the next good deploy. See
[Content Deploy / CDN](/docs/platform/cdn).

## Next steps

- [Translator and reviewer workflow](/docs/platform/recipes/translator-review-workflow): The two-stage flow for the first phase.
- [Onboarding agencies](/docs/platform/recipes/onboarding-agencies): External teams for the expansion.
- [Machine translation](/docs/platform/machine-translation): AI and traditional providers at scale.
- [Glossaries](/docs/platform/glossaries): Terminology discipline across languages.
