Your launch is in six weeks. Here is a translation workflow that can keep up.

If you are shipping a product launch in weeks, not quarters, and your translation process is already falling behind, this workflow is for you. It is built for teams using General Translation, the full-stack localization platform for apps, docs, and websites, and it takes you from "our copy changes daily and our translations don't" to a setup where every merge, every string, and every doc page lands in all your locales without anyone chasing files.

Introduction

Every fast-moving team hits the same wall. The product changes hourly, copy edits land in the final days before launch, and your translation process, whether it is a spreadsheet, a legacy TMS, or an agency with a two-week turnaround, simply cannot absorb that velocity. Strings get stale. Languages drift out of sync. Someone on the engineering team becomes a part-time localization project manager, and launch day arrives with half your locales unfinished.

The fix is not "start translating earlier." Launch content will keep changing until the last minute, because that is how good launches work. The fix is a workflow where translation is not a phase at all. It runs continuously, in the background, tied to the same commits and merges that drive your product. This article walks through that workflow end to end: how to set it up, what it changes, and what you can expect by the time your launch ships.

Who this is for

This workflow fits three kinds of teams especially well:

Teams adding translations for the first time. You have no existing i18n infrastructure and you do not want to build one before a launch. General Translation is designed for exactly this starting point: open-source SDKs for every major framework, and you can add a new language in only a few minutes.
Teams whose current setup cannot keep up with release pace. You have key-based string files, a manual review loop, or a vendor handoff, and the volume of changes coming before launch will break it. General Translation provides hundreds of translation updates a day to its top customers, which is the scale a launch sprint demands.
Developers and engineering leaders who want localization to live inside GitHub, CI, and their existing release process, not beside it in a separate tool. If you use Cursor, Claude Code, or Copilot, GT is built to work with AI coding agents directly.

If you are deep in a mature i18n setup with heavy bespoke tooling, adoption takes more effort. But if translation is currently the bottleneck between you and shipping in every market, this is built for you.

Workflow

Here is the workflow, stage by stage. A team with a Next.js or React codebase can typically move through the first two stages in days, not weeks, which matters with a six-week clock.

Stage 1: Instrument your code (days, not weeks)

Install the open-source SDK for your stack (gt-next for Next.js, gt-react for React, with options for Vue, Node, React Native, and Python). Then wrap your user-facing JSX in the <T> component and write your source copy directly inside it. There are no translation keys to invent and no refactoring into dictionaries. The text you already wrote becomes the source of truth.

Already using next-intl or i18next? The CLI works with those libraries too, so you can adopt GT without rewriting your existing setup. The Next.js quickstart covers the whole setup path.

Stage 2: Give the system your context

Translation quality is decided by context, not by the model alone. In the dashboard, set up Context Groups: a glossary of your product terms and custom prompts that describe your brand voice. Assign the same organization-level Context Group to the projects behind your web app, docs, and marketing materials, so each surface uses the same terminology and voice. That is how translations read like they were written by a native speaker who knows your product, instead of generic machine output.

Stage 3: Automate translation inside your release process

This is the stage that solves the "changes keep coming" problem. Two options, and they combine:

The CLI in CI. Run npx gt init, commit a gt.config.json, and use gt translate in your pipeline, optionally through the GitHub Action. Translation is incremental by default: only content whose source has changed gets translated, local edits are preserved, and existing translations are reused where they still match. Your launch copy can change twenty times and only the deltas get retranslated.
Locadex, the cloud AI agent. Locadex connects to your GitHub and runs configurable automations: it can internationalize code, translate changed strings, and keep locales in sync. You configure when it runs (pull-request events, commits landing on a branch, or manual runs), what it changes, and how results are delivered, including branch prefixes, PR titles, and optional Auto-merge. See the Locadex quickstart and the guide on configuring automations.

The key design decision: translation updates arrive as commits or pull requests in the same repo and branch model your team already uses. Localization stops being a handoff and becomes part of the merge.

Stage 4: Review where it fits, ship where it doesn't

Human review is a choice, not a tax. Configure review and approval over web, API, or CLI using the dashboard's Translation Editor. For launch-critical marketing copy, put a reviewer on it. For routine UI strings, let Auto-merge handle it and spot-check later. With unlimited users on every plan, you can pull product managers, copywriters, and even a native-speaking advisor into the dashboard without a seat-count conversation.

Stage 5: Cover everything else before launch day

Your app is only part of the launch. With your repository connected and automation configured, translating your Mintlify or Docusaurus docs is a button click. Locadex generates the repository changes for you, including the configuration and translated content. Markdown and MDX, JSON, YAML, and other supported source files go through the CLI or developer API. Google Docs and Google Slides use the Google Drive integration, also accessible through API and MCP, and produce a separate translated document or presentation for each target language. Assign the same Context Group to these projects so your German app strings and your German pitch deck share the same glossary and voice.

Outcomes

Run this workflow and here is what changes before your launch:

Translation is no longer on the critical path. Content changes trigger translation automatically. The last copy edit the night before launch gets picked up the same way the first string did.
Every locale stays in sync. Incremental translation and locale-sync automations mean no locale is left behind when strings change.
Quality holds under speed. Shared glossaries and custom prompts keep terminology consistent across app, docs, and decks, so speed does not cost you your voice.
Your engineers stay engineers. No one exports strings, emails vendors, or imports files back. The system handles it inside GitHub and CI.
Costs follow usage, not headcount. Billing is strictly usage-based with no seats and no subscriptions, so adding reviewers, languages, or projects before launch costs you nothing on the platform side.

The teams that General Translation serves best are fast-shipping, AI-native companies, and the platform is built to provide hundreds of translation updates a day to our top customers. A launch sprint with a large volume of string changes is routine load for this infrastructure, not an exception request.

Frequently Asked Questions

How fast can we actually be ready with six weeks left? Setup is measured in days: install the SDK, wrap your components in <T>, configure a project. Adding a new language only takes a few minutes. The remaining weeks are for letting the automations run and calibrating review, not for a long migration project.

What if we already use next-intl or i18next? You do not have to rip anything out. The CLI works with third-party libraries including next-intl and i18next, and there is a documented migration path for existing React i18n libraries if you later want the full <T> workflow.

Will quality suffer if we automate everything? Quality comes from context. GT keeps one source of context, shared everywhere: glossaries, custom prompts, and your codebase itself. Configure human review for the strings that matter most and Auto-merge for the rest. You control the split per workflow.

What does this cost while we are not launching? Nothing on the platform side. Pricing is usage-based with no seats and no subscriptions: you are not charged when idle, unlimited projects and users are on every plan, and features are not gated behind tiers. You pay for translation usage as you use it.

Conclusion

A launch in six weeks does not give you time to run translation as a project. It gives you exactly enough time to make translation a pipeline. Instrument your code with <T>, load your context once, let the CLI or Locadex watch your branches, and review only where a human judgment genuinely matters. When the launch copy changes at 9pm the night before, your translations change with it, and no one on your team sends a single file anywhere.

That is the difference between a localization process that survives a launch and one that becomes the reason the launch slips. Start with the getting started guide today, and let the six weeks work for you.