How to start localizing your software: A practical first guide for product teams

Most software teams that decide to localize don't fail because they chose the wrong tool or the wrong language. They fail because they skip the groundwork: no i18n foundation, no defined workflow, no ownership, and no way to measure whether it's working.

This guide covers the four decisions you need to make before you start, and what "starting well" actually looks like in practice.

If you want the full strategic picture, see the Localization Strategy Guide for SaaS. This post focuses specifically on the practical starting point.

Why the beginning matters more than the tooling

The most expensive localization mistake is translating before you're ready to localize. These sound similar but they're not.

Translating means converting your strings into another language.

Being ready to localize means your product is built so that those translations can be integrated, maintained, updated, and deployed without heroic engineering effort every time.

Teams that skip readiness often find themselves:

• Retranslating the same strings every time the UI changes, because strings weren't externalized properly
• Shipping localized builds weeks behind the main product, because there's no automated pipeline
• Dealing with broken layouts in German or Japanese because text expansion wasn't accounted for
• Losing translation work when someone edits a hardcoded string directly in the codebase

The fix isn't a better translation tool, it's building the right foundation first.

Check out our Localization Readiness Checklist for a step-by-step guide to getting your product ready for localization.

Step 1: Check whether your product is i18n-ready

Internationalization (i18n) is the technical work that makes localization possible. Without it, you can translate strings but you can't ship a localized product reliably.

The core question is: are your user-facing strings externalized from your code?

If text is hardcoded directly into components or templates, every translation requires a code change. That's unsustainable at more than one or two languages. Proper i18n means all user-visible text lives in translation files: JSON, YAML, PO, or similar formats, that can be updated independently of the codebase.

Beyond string externalization, i18n-readiness includes:

• Locale handling

  Can your app detect and switch locale at runtime? Is there a fallback language when a translation is missing? These aren't edge cases, missing locale logic causes users to see raw translation keys or broken UI when a string hasn't been translated yet.

• Format handling

  Dates, numbers, currencies, and units all need to be locale-aware. A hardcoded new Date().toLocaleDateString() without a locale parameter will render differently across browsers and regions. JavaScript's Intl API and libraries like FormatJS handle this correctly; ad-hoc formatting doesn't.

• Text expansion

  German text is typically 20–35% longer than English. Finnish can run even longer. Russian and French also expand significantly. If your UI was designed purely around English string lengths, buttons will overflow, labels will truncate, and layouts will break. This needs to be tested before you commit to supporting a language.

• Pluralization

  Many languages have plural rules that don't match English's simple singular/plural split. Polish has four plural forms; Arabic has six. If your codebase handles plurals with a ternary operator (count === 1 ? "item" : "items"), it will produce incorrect output in most non-English languages. The correct solution is ICU message format or a library that handles plural rules per locale. See our pluralization guide for details.

• RTL support

  If you plan to support Arabic, Hebrew, Persian, or Urdu, your layout needs to mirror horizontally. This is a CSS and component architecture concern, it can't be easily bolted on after the fact.

If your product has gaps here, address them before starting translation work. Retrofitting i18n into a mature codebase is significantly more expensive than building it in from the beginning. We cover the cost implications in detail in our i18n guide.

Check also: Best i18n libraries for React and Next.js

Step 2: Decide which language (just one) to start with

The instinct is often to launch with as many languages as possible. Resist it.

Starting with one language forces you to build and validate the entire localization pipeline: extraction, translation, review, integration, deployment, before you multiply the workload. It also gives you real data on whether localization is driving the outcomes you expect.

How to choose your first language:

Look at where you already have users, not where you'd theoretically like to have them. Check your analytics for international traffic, sign-ups, and trial activations by country. If a non-English market is already sending you users who aren't converting as well as your core market, language friction is a likely cause, and that's your first language.

If you don't have international traffic yet, prioritize by market size and competitive landscape. European SaaS products typically start with German, French, or Spanish. Products targeting Asia-Pacific often start with Japanese. The right choice depends on your category and go-to-market motion.

What to avoid: choosing a language because it feels prestigious, because a single enterprise prospect requested it, or because a team member speaks it. These are poor signals for prioritization.

See our full decision framework in How to plan localization for your first 5 languages.

Step 3: Define your workflow before you translate anything

The workflow question isn't which tool to use but how strings will move from your codebase to translators and back, on every release, without manual intervention becoming a bottleneck.

For a deeper dive on choosing the right process, see how to pick a translation workflow for small teams.

A minimal viable localization workflow has four stages:

• Extraction. Translation keys are pulled from your source code into a centralized location. This can be done manually with CLI tooling, automatically via CI/CD, or through IDE integrations. The goal is that no string ever gets translated directly from the codebase, it always goes through the pipeline.
• Translation. Strings are translated in a dedicated environment where translators have context: what screen is this on, what comes before and after this string, what's the character limit? Translation without context produces lower-quality output and more revision cycles. This is one of the core reasons to use a translation management system (TMS) rather than sending spreadsheets.
• Review. For most product types, machine translation alone isn't sufficient for production use. A review step, even a lightweight one with a bilingual team member rather than a professional linguist, catches errors before they reach users. The level of review needed scales with the stakes: consumer-facing copy needs more rigor than internal admin labels.
• Integration and deployment. Translated strings need to make it back into the product on every release, ideally without a manual hand-off step. The gold standard is a CI/CD-integrated pipeline where translation files are pulled automatically as part of the build or deploy process.

If your workflow requires a developer to manually export, email, and re-import translation files for every release, that friction will accumulate until localization starts slipping.

Check also: What is a localization workflow?, Step-by-step localization workflow for developers, Continuous localization guide

Step 4: Assign ownership before you need it

Localization breaks down most often not because of bad tooling or bad translations, but because no one owns it.

In small teams, it typically falls between product, engineering, and marketing, each assuming one of the others is handling it. The result is inconsistent terminology, missed strings, and releases that ship without translations being updated.

Ownership doesn't mean one person does all the work. It means one person or role is accountable for the localization pipeline being healthy: strings are extracted, translations are complete and reviewed, and releases ship in sync across languages.

At minimum, define:

• Who extracts and manages translation keys
• Who coordinates with translators or manages the translation tool
• Who reviews translations before they ship
• Who decides when to add a new language

In a team of two or three, this is often one person wearing multiple hats. In a larger team, it should be explicit in job scope or sprint ownership. The key is that it's explicit, not assumed.

What "starting well" looks like in practice

Here's a before/after to make this concrete.

Before (common anti-pattern)

A SaaS team decides to add French support.
A developer manually copies their English JSON file, sends it to a freelance translator, gets it back two weeks later, pastes it into the repo, ships it.
Three months later, half the strings are outdated because the product has been iterated on and no one updated the French file.
The French version of the app is now a patchwork of old translated strings and new English fallbacks, which is worse UX than just showing English.

After (sustainable approach)

The same team spends a week on i18n groundwork: externalizing hardcoded strings, setting up a locale switcher, configuring fallback logic.
They set up a TMS and connect it to their repo via CLI or GitHub Actions.
When a developer adds a new string, it gets flagged as untranslated in the TMS.
A translator works in the TMS with context screenshots and character limits.
Before each release, the CI pipeline pulls the latest approved translations.
The French build is always in sync, and the translation backlog is visible and manageable.

The second approach takes more setup upfront. It saves significant time on every subsequent release, and it scales to additional languages without proportionally increasing the maintenance burden.

Common first-time mistakes to avoid

• Translating before i18n is in place. You end up with translations you can't reliably integrate. See above.
• Starting with too many languages. Spreading effort across five languages before you've validated that even one is driving the outcomes you expect burns budget and creates maintenance debt.
• Using spreadsheets as your permanent workflow. Spreadsheets work for a first pass. They break down at any scale: version conflicts, lost context, no integration with your codebase, no way to track review status. Plan to move to a proper TMS early, not as an emergency.
• No context for translators. A string like "Save" or "Action" means different things depending on where it appears. Translators who can't see context produce less accurate translations. A good TMS lets you attach screenshots, notes, and character limits to keys. Use them.
• Skipping QA. Machine translation has improved significantly, but it still produces errors — especially with idioms, technical terms, placeholders, and UI-specific phrasing. A minimal review pass before shipping catches most of the critical issues.

Check also: 11 common localization mistakes and how to avoid them and What is localization QA.

Where to go from here

Starting well creates compounding returns. A clean i18n foundation and a working pipeline make every subsequent language faster and cheaper to add. Skipping the groundwork creates debt that compounds in the opposite direction.

Once your first language is shipping cleanly, the next steps are measurement (is this language driving the outcomes you expected?), prioritizing the next language based on that data, and gradually maturing your workflow — more automation, more structured QA, more governance as the number of languages grows.

The Localization Maturity Model maps out what each stage of that evolution looks like in practice. The Localization Readiness Checklist is a useful tool to evaluate where you stand before committing to a timeline.

For the complete framework — markets, ROI, team structure, tooling decisions — the Localization Strategy Guide covers all of it in one place.