One screen says “Save,” another says “Store.” A plan is “Professional” on pricing but “Pro Plan” in billing email. These inconsistencies may not break the product, yet they make users hesitate, create support work, and make every later release harder to maintain.
AI can make translation much faster, but it does not know whether a string is a button, a permission setting, an error message or a contract clause. Sending an entire JSON, CSV or spreadsheet to a model often produces copy that is individually fluent and collectively inconsistent. A reliable localisation workflow fixes terminology and rules first, uses AI on lower-risk text in batches, then checks the result inside the real interface.
Separate translation from product language
Localisation is not word replacement. It includes the name users see for product objects, the available UI space, and local conventions for date, currency, address and compliance language. “Workspace” could mean a workspace, team space or project in a given product; only the product owner can decide whether those are actually the same concept.
Before starting, list what AI must not decide: brand names, feature names, plan names, roles and permissions, billing units, legal text, error codes, variables and links. These either stay untouched or receive one approved translation. Treat this as a “do not guess” list and include it in every prompt.
A small glossary that people can execute
The first glossary may need only 30–80 terms. What matters is context. Keep these columns in a shared table:
- Source term
- Approved target term
- Part of speech and location — button, menu, heading, billing or system message
- Meaning note — what it means, what it does not mean, and whether shortening is allowed
- Example — a real sentence or page key
For example: Workspace → 工作区; noun; used in navigation and collaboration scope; do not translate as “space”; example: Switch workspace. This is much more useful than a word pair because both a model and a new teammate can see when to use it.
Split source files into reviewable batches
Do not translate 5,000 strings at once. Divide work by UI area or risk: navigation and core actions, sign-up and onboarding, settings and permissions, payment and billing, notifications and errors, and help content. Batches of 80–200 strings are easier to sample and make prompt failures easier to detect.
Export each row with its key, source text, existing translation, variable note and maximum length. Variables such as {name}, {{count}} and %s, HTML tags, Markdown, URLs and code fragments must not be altered. Flag variable-bearing strings for risk review before translating.
Give AI a translation contract
You are a SaaS product-localisation editor. Translate the table from English to Simplified Chinese. Use the approved glossary exactly. Do not alter brand names, product names, plan names, variables, HTML tags, Markdown, URLs, number formats or keys. Use short action verbs for buttons. For errors, state the problem and then the next step. If source context is missing, a term has multiple product meanings, or the translation exceeds the maximum length, mark “needs review” rather than guessing. Keep four columns: key, source, translation, needs review.
For English localisation, define audience, tone and constraints too: enterprise administrator or end user, US or UK spelling, imperative or neutral buttons. Put these rules at the top of the glossary rather than deciding them one string at a time.
Three text types always need human review
First, text with real consequences: delete, cancel subscription, payment, export, permission grants and privacy consent. One mistranslated negative can create a complaint. Second, short context-sensitive words such as Open, Close, Invite, Share, Plan and Member. Third, dynamic text with plurals, money, dates, names and error details. A model may preserve a variable while making the grammar unusable for other counts.
Do not review only in a table. In a test environment, complete a real task: create an account, invite a member, upgrade a plan, trigger a failure, and view an email or in-app notification. Width, modal headings and connected steps expose issues that a spreadsheet cannot.
Use AI for reverse QA, not self-grading
Review this product-localisation table. Do not rewrite every translation. Find glossary inconsistencies, changed variables or tags, inconsistent money or units, buttons that are too long, misleading negative or permission wording, and different translations for the same feature across keys. For each item return the key, issue type, source evidence and suggestion. Mark uncertain cases for human review.
A separate review pass is more useful than asking the same generation to approve itself. A knowledge base can retrieve approved terms before translation, but preserve the table and source evidence for each release.
Minimum release checklist
- Do keys, variables, links, tags and placeholder counts match the source?
- Are plan, role, permission and feature names consistent with the glossary?
- Have high-consequence actions, amounts, timing and limits been reviewed by a person?
- Do mobile and narrow screens avoid clipping and button wrapping?
- Is the glossary version linked to the product release for rollback and accountability?
If you do not yet have a dedicated localisation platform, a Notion or Google Sheets glossary plus AI-assisted extraction and QA is enough to start. For export cleanup, see the AI spreadsheet cleanup workflow. The time saver is not asking AI to translate everything at once; it is making sure the next release does not reopen the same terminology debate.