How to Build a Translation Workflow for Your Product Team

Most teams don't design a translation workflow on purpose — it accumulates. Someone exports a JSON file, emails it to a translator, gets it back a week later, and manually merges it in. That works exactly once. Here's a workflow that holds up as you add languages and contributors.

1. Extract and key your strings

Every piece of user-facing text should live behind a key, not be hard-coded inline. Group keys by the screen or component they belong to (settings.notifications.title) so translators can infer context from the key structure alone, and so two unrelated "Save" buttons don't accidentally share a translation that only fits one of them.

2. Give translators a real editor, not a spreadsheet

Spreadsheets and raw JSON files are hard to review, don't show translation status, and make it easy to break JSON syntax with a stray comma. A dedicated editor should show the source text, any context notes, the character or length limit if relevant, and let a translator submit a suggestion without touching the underlying file format at all. This is also where machine translation suggestions help most — a translator reviewing and correcting an AI draft is faster than typing every string from scratch, as long as a human still signs off before anything ships.

3. Separate contribution from approval

Anyone can submit a translation; not everyone should be able to publish one straight to production. A two-step status model works well in practice:

• Needs review — a translation has been submitted but not checked by a second person.
• Approved — a reviewer has confirmed it's accurate and ready to ship.

This catches typos, tone mismatches, and outright mistranslations before they reach users, and it gives new or public contributors a safe way to help without needing full trust from day one.

4. Automate delivery back into your codebase

Once translations are approved, they need to get back into your build without manual copy-pasting. Export in whatever format your app already consumes — JSON for a web app, .strings for iOS, Android XML resources, or gettext .po files for a Python backend — and wire that export into your CI pipeline so a merge to your translation project can trigger a fresh string bundle for your next deploy.

5. Keep a glossary once you have more than one translator

The moment a second translator joins, terminology drift becomes a real risk: one person translates "workspace" one way, another translates it differently three screens later. A shared glossary of approved terms — product names, key nouns, anything that should never vary — keeps translations consistent without every translator needing a live conversation about word choice.

None of this requires enterprise tooling to start. A two-person team can run this entire workflow with a single shared project and a simple review step; the same structure just keeps working as you add more languages, more contributors, and eventually a public community of translators.