Review AI translations before adding them to your app

Review an AI translation in two passes: first check the message contract, then assess the wording in its application context. A translation can preserve every placeholder and still give a user the wrong instruction.

The workflow below is for application catalogs such as JSON and Flutter ARB. It ends with a specific reviewed file in your app, so the wording you test is the wording you release.

Give the translator useful context

Before starting a job, identify the source language and intended target locales. Add the product context you have: terminology, audience, tone, and the purpose of ambiguous messages. In ARB files, message descriptions can explain what a label or parameter means.

For example, “Archive” may label a place where records are stored or an action that moves a record there. Describe the screen and expected action. Keep brand names and terminology consistent across messages instead of correcting each occurrence independently after translation.

In TransLocale, inspect the translation plan and its usage estimate before starting a capped job. Planning and file checks do not themselves translate the catalog. Keep authoring credentials in the dashboard, developer tooling, or CI.

Check the message contract

Compare the source and target for missing keys and changed parameters. A source message such as Hello, {name} still needs the name parameter in its translated form; changing it to {firstName} changes the contract with the application.

Use the adapter for the actual format. i18next plural suffixes, ICU expressions, Vue I18n message syntax, and Flutter ARB metadata have different rules. For the flat JSON example below, run a local comparison:

npx translocale check --source locales/en.json --target locales/fr.json --format json

Install @translocale/cli first and use Node.js 22.16 or later. The CI validation guide contains complete source and target fixtures, including a failing example.

A passing structural check is one review input. It does not certify the meaning or quality of the translation.

Read the wording as a user would

Ask a reviewer familiar with the target language to assess the actual message and its surrounding interface. Useful questions include:

• Does the translation describe the same action, including whether it can be undone?
• Are product terms and levels of formality consistent?
• Does the wording distinguish states such as pending, completed, and failed?
• Do singular, plural, and empty states make sense with realistic values?
• Does an instruction still make sense beside the button or field it refers to?

Avoid approving a message solely because it reads well in isolation. A fluent sentence can still be wrong for a destructive button, an empty state, or an error message.

Save and select an exact revision

Review and correct the generated wording in TransLocale, then save the revision you intend to use. Revision 0 is the original generated output. Use the saved revision number shown for that language when downloading; each language can have a different revision number.

For an initialized Next.js integration, the pull command can select that revision explicitly:

npx translocale-next pull --job JOB_UUID --locale fr --revision 1

Replace JOB_UUID with the completed job ID and 1 with the revision you actually reviewed. The download requires the appropriate project access. If a target file already exists, use the package's candidate-output or sync workflow to inspect the change before applying it. See the Next.js integration guide for setup and the installed package's command help for its options.

Test the exported catalog in the app

Run the catalog check again after applying the reviewed file. Build the app and inspect the relevant screens in the target language. Try long labels, empty values, several plural counts, and right-to-left layouts where applicable.

Record which revision and catalog files were tested. If wording changes afterward, review that change and repeat the relevant checks before releasing it. This keeps an earlier review from being mistaken for approval of a later export.

For assistant-assisted review, the MCP guide explains read-only validation and explicit approval before translation or publication. The source checker is a useful starting point when you have not connected a project yet.