globalize.now translates with large language models and reviews every translation with a second AI pass. Four tools shape the result, and all of them live in your project.
Glossary
Project → Glossary. Add a source term, its required translation, and the languages it applies to. Glossary terms are protected during translation, so product names, feature names and legal wording stay exactly as you decided. You can import a glossary in bulk instead of typing entries.
Style guides
Project → Style Guides. One per target language: tone, formality (for example du vs Sie, tu vs usted), terminology preferences, what to leave in English. If a language has none yet, the dashboard offers to draft one from your own source content in one click; edit it and save.
Translation memory
Project → Translation Memory. Every approved translation is stored. When the same source string appears again — another push, another component, another project file — the stored translation is reused and not billed. Translations you edit by hand and push back are treated as approved and win over ours.
QA review
Every job runs a quality-review pass on each target language after translation. It checks the translation against the source for meaning, placeholders and variables, glossary compliance and style-guide fit, and flags anything that doesn't pass. Each language's results are summarised on the project dashboard in three buckets — good, passable, and needs attention — and you can send QA issues to a webhook from project settings.
Editing translations after they're generated
Translations arrive in a pull request that changes only your locale files. Edit them there like any other code change, or later in your repository. To make your edits authoritative, set Existing translations → Every string, on every push in project settings: your files win, and the translation memory is updated from them.
Length limits
Some strings have to fit a fixed space: a button label, a menu entry, an SMS. If your XLIFF file declares a maximum length (XLIFF 1.2 maxwidth with size-unit="char" or "glyph", or XLIFF 2 slr:sizeRestriction under the xliff:codepoints profile), globalize.now gives the limit to the translator and asks again when a translation comes back too long. Nothing is cut off: if it is still too long after two more tries, it ships as it is and QA reports a lengthLimit finding.
Placeholders and tags don't count toward the limit, and an ICU plural counts its longest form. The review panel shows a counter next to each translation and never stops you saving. A string with a limit keeps its own translation memory, so a translation written for a wide layout isn't reused where it won't fit. Pixel widths are ignored. On Markdown pages, a max-length comment on a front-matter field works the same way.
Which models
Translation and review run on Anthropic's Claude models, and you choose which one, separately for translation and for the review pass:
- Claude Haiku 4.5: fastest and cheapest.
- Claude Sonnet 5: a balance of quality and cost.
- Claude Opus 5: highest quality, and the most expensive.
Set your organisation's defaults in Settings → Models (admins only); each model shows its cost relative to the others. A project can override either choice in Project → Settings → Models, so a high-stakes marketing catalog can translate on Opus while bulk UI strings stay on Haiku. Clear a choice to go back to our default. Model choice is the biggest single driver of what a job costs.
Text is sent to the model provider for translation only and is not used to train models.
How good is it?
Better than phrase-based machine translation because the model sees the whole string, its placeholders and your glossary and style guide at once; cheaper and faster than a human translator; not a replacement for a native review where the stakes demand one. The QA pass exists to make the cases that need a human visible rather than silent.