Localisation workbench

Coroid translates your product with the same engine it uses for its own thirteen languages. Your catalogues stay files in your repository. Every change to them arrives as a task and a pull request, and only strings that are new, changed or broken are sent to a model.

Localisation is the second part of Globalisation in the main menu. Opening a project there shows its workbench: the sections on the left, the open section beside them. Projects that are not multilingual yet start with the Internationalisation wizard.

The workbench#

Suggestions, Contributors and Automations are covered in Maintain translations with suggestions. Above these sections, under Internationalisation, the rail holds World readiness and Culture.

The workbench reads the catalogues on your default branch. When they change, Coroid reads them again the next time someone opens the project; until then the Overview says it is reading them. Coroid never runs your repository's code to do this. Catalogues that use a custom adapter are not shown; their strings are still checked in tasks.

Overview: one line per language#

The Overview starts with four totals: strings, languages, how much is translated, and how many strings need work. Under them, each language runs along a line through three stages:

1. Internationalise. The language's catalogue exists and holds strings.
2. Localise. Every string is translated from the current source text.
3. Verify. No string is broken: every one parses, keeps the source's placeholders and has the plural forms its language needs.

A language's next step is wherever its line stops. A green stop is done, a teal ring is the stop that needs work, and an amber one has broken strings.

The bar under Localise reads from the start: dark green for strings reviewed by people, light green for strings written by a model, amber for strings that need attention, and the empty part for strings that are missing. The text under the bar names the gap, such as 42 strings missing, and opens exactly those strings.

Languages derived from another language by rules, such as British English from American English, show Derived and up to date when their rules have been applied to every string.

Translate what is missing#

Owners and admins see one action at the top of the Overview, Translate with the number of strings that need work: missing, changed in the source, or broken. It translates them in the workbench, in two passes:

1. Translation memory. A string that another project of your organisation already translates, with exactly the same source text, reuses that translation. People's translations win over machine ones. This makes no model call and costs nothing.
2. The Translator model. The engine pinned in your repository translates the rest through the translation gateway, checking every reply against the placeholders and plural forms.

While it runs, a panel under the totals shows how many strings are written and what the run has spent, and each language's bar fills with striped ink as its strings arrive. Stop translating ends the run; what it wrote stays.

The translations don't go straight to your repository. They wait for Commit with your other changes, marked as machine translations, so you can check them in Strings first. A string someone has already edited, or a contributor has suggested, is left to them.

Strings#

Strings lists every string with its source text and its value in one language. It opens on Needs work: the strings that are missing, whose source changed, that are broken, or that are still the same as the source. Choose another language, a catalogue, or search keys and text.

Select a string to see it in every language. Placeholders and markup appear as locked chips, because they must survive translation exactly. For the language you chose, the details also say who wrote the value, what is wrong with it, and, for a plural message, which plural forms the language needs.

Edit and commit#

Owners and admins correct translations in Strings. Select a string, choose Edit in a language, and save the change. The editor shows the source's placeholders as chips you can insert, and checks the change as you type: the placeholders, the plural forms the language needs, terms from your glossary, and length. Coroid checks it again against the default branch when you save.

Suggest in the editor proposes a translation for that one string: from the translation memory when another project has it, otherwise from the Translator model. Choose Use this to put it in the editor; nothing is saved until you save the change.

Saved changes wait in a bar under the strings, where you can review or discard each one. Commit turns all of them, together with approved contributor suggestions and machine translations, into one task. The task applies exactly those values with the pinned engine and opens one pull request. One commit takes up to 5,000 changes; the rest wait for the next. Until that pull request is merged, the strings show Not committed or Being applied.

A committed machine translation stays a machine translation in the engine's cache, so it still counts as Machine until a person reviews it.

Editing needs contributions turned on in the configuration file; the Internationalisation wizard turns them on by default. Contributors can also suggest a better wording on your own site.

Exchange files#

Under Exchange, download the strings for an agency, a translation tool or a spreadsheet, and import their translations back.

An export holds the strings that need work, or all strings. Placeholders and plural messages travel exactly as written.

An import shows every row before anything is kept. New translations and changes can be accepted. Coroid leaves out a key the project doesn't have, a translation made from a source that has changed since, broken placeholders, and plural messages missing a form the language needs. Accepted rows become changes waiting for Commit, like edits made in Strings.

JSON, .strings and Android files don't say which language they hold. Coroid takes it from the file name, such as storefront-de.json, or asks.

Check every change#

The Globalisation check runs on task QA and on pull requests. It checks the strings a change touched in every language, and the code the change adds. On the Overview, View the last check under Verify opens the newest run. When a translation finding blocks a task, the developer agent repairs it through a translation session for the task; it never edits other languages' catalogues by hand.

The Translator model#

Translation has its own role in AI profiles, Translator, next to Architect, Developer, QA and Reviewer. By default it uses Hy-MT2, a translation model, with GPT-6 Luna as the fallback, where your organisation policy allows them. Change the mapping in an AI profile like any other role.

The engine also batches strings by size, validates every reply against your placeholders and plural rules, and retries or escalates a string that fails.

Costs#

Translations are available on every plan. Translation calls go through Coroid's translation gateway and are billed as model usage to your organisation, the same as agent runs. Translation tasks count toward your plan's agent hours like any other task.

With the default Translator route, translating costs about two cents per 1,000 strings per language. Translating a 2,000-string catalogue into ten languages cost about $0.33 when we measured it.

• Only changes cost money. The engine keeps a cache keyed by the source text, so unchanged strings are never sent again.
• Each task and each run has a translation limit. A task's session stops at its spend limit, $1 by default; a Translate run in the workbench stops at $5. A project can set a lower limit under Settings → Access and spend.
• The translation memory costs nothing. Strings your organisation already translates elsewhere are reused without a model call.
• Reading costs nothing. The workbench and the Globalisation check read your catalogues; they make no model calls.

Translating outside Coroid#

The engine is a command-line tool, coroid-i18n. Your own CI can run the same pinned version with its own OpenRouter key. Inside Coroid, tasks always use the translation gateway, so spend and limits stay in one place.

Related#

• Globalisation
• The Globalisation check
• Internationalise a project
• Maintain translations with suggestions
• Quality policies and gates
• Checks, runs and findings
• AI profiles