If your roadmap includes anyone who does not use English as a first language, you will internationalize eventually. The choice is whether you pay incrementally or in one painful lump when sales, compliance, or store visibility finally forces the issue.
Across more than 3,000 projects, we keep seeing the same split: teams that wire in a second language from day one ship safer UI, fewer release-week fire drills, and smoother handoffs to translators. Teams that wait often end up untangling string concatenation while marketing is already live in three countries.
Foundation: start with English as a localization hub
Even if your office works in another language, English is still the easiest language to scale localization from: bigger translator pools, tools that default to English as the source, and translation vendors who translate from English into other languages every day. Keep master strings for the product in English so you are not asking tools and translators to jump straight from your office language to many customer languages when deadlines tighten.
Concrete example: Japanese → Portuguese is hard to staff and schedule until English sits in the workflow: English is the bridge most teams and agencies actually use for uncommon source–target pairs. Ship deliberate English as the shared reference, then branch other locales from it.
Quality: sloppy English becomes expensive with every new locale
With English as the hub, strong source strings matter even more: glossaries, tone notes, and downstream LQA carry that baseline into every locale. Invest there first: clear English upstream saves rework everywhere else.
Technical founders who still ship code often think like developers: copy feels minor, yet hundreds of dollars go to an icon or a polished layout. The language your app speaks is part of the design—the words on screen are as much UX and UI design as anything in Figma.
Weak English multiplies cost: you export inconsistency into every locale you add later. Translators pause, open bugs, or quietly reinterpret ambiguity — and each fix drifts a little further from what product intended.
Treat English source like an API: ambiguous contracts cost everyone downstream. Budget time for terminology and string review alongside feature work.
Master English—and still ship a second locale in the build
English as hub lives in source; the stress test lives in a build where a second locale runs.
Before localization enters the picture, single-locale development feels fast: most people experience the product in one language, QA is busy with features and regressions, and copy can stay draft-quality (often still in code or spread across docs) while the team tells itself “we’ll clean this up once we stabilize.”
The breaking point is scaling. Few roadmaps stay single-locale forever: as your product finds traction, promising new markets and buyer groups tend to show up. And when localization joins the release, teams learn what one interface must still support across locales:
- Different scripts (character sets and rendering).
- Different string lengths (layout and truncation).
- Number and date formats.
- Reading direction (e.g. RTL vs LTR).
- Voice and register—including politeness or social distance where grammar encodes it.
Tickets start to surface when German compounds spill out of buttons, plural rules break lines like “items left” once numbers and grammar have to match another language, or a right-to-left locale breaks spacing and icons laid out for left-to-right only.
Of course, that pressure still feels distant when scaling is not on this quarter’s roadmap. The good news is you do not need a multi-market launch to become global-ready: start as small as one additional locale or one focused surface (onboarding, billing, your storefront hero). This way, you learn where strings, fonts, layout, and handoffs to translators might break before expansion turns those gaps into deadline debt—for example, discovering only after the brand and layouts have shipped that your hero typeface cannot render Japanese.
If you ever think that in the future your product will be localized, start with internationalization. The best piece of advice I could give to someone developing software is to start with two languages from the very beginning — it's basically a guarantee that you will do the internationalization.
The checklist: what “two languages on day one” actually means
Treat this checklist as MVP internationalization: your first i18n milestone is done when the mechanics work, not when every string reads like marketing copy, and not when you have built out your entire localization operation.
1. Externalize strings and kill concatenation
Keep translatable text out of source code. Avoid “Hello, + userName + !” patterns that assume English word order. Use resource files, ICU message format, or your framework’s equivalent, and pass variables into whole sentences so translators can reorder clauses for their language.
Hard-coding text is something that will take a lot of effort to fix in the future if you want to do localization. From the very start, make sure your texts are in a separate file so they can be updated and localized files can be added — so localization will be smooth from the technical point of view.
2. Give translators context, not only keys
A string key without UI context is a guessing game. Document whether a phrase is a button, a title, a tooltip, or an error — and whether tone should be formal or playful. Your TMS or repo workflow should carry screenshots, comments, or design links so linguists do not ship the right words for the wrong place.
3. Plan for length and plural rules early
Pseudo-localization and a real second language in the build quickly expose truncation. Allow layouts to flex where you can (expandable containers, sensible font scaling) and document hard character limits only where the design truly cannot move.
4. Fonts, scripts, and RTL
That decorative headline font you approved from the English brand deck may lack CJK coverage (games hit this constantly when pixel fonts meet glyph-heavy languages like Japanese, Chinese, and Korean). If Arabic or Hebrew matters for your roadmap, RTL cannot be a plug-in six months later; navigation patterns, mirroring, and asset alignment need ownership from the start.
5. Wire collaboration: TMS and CI
Pick a translation management platform that fits your stack (Crowdin, Phrase, Lokalise — each has trade-offs). Connect it to Git so new strings become translation tasks and finished locales return as pull requests. Some teams fear a TMS will tie them to one vendor, but the operational payoff is moving string handoffs out of email threads and one-off spreadsheets that quietly gate releases.
6. Reserve time for in-app review (or in-game, if you ship titles)
Strings that look fine in a grid can still break in production. Schedule short LQA passes on builds for both locales, even if the second language starts as machine-translated placeholder copy. Those passes should catch layout and wiring problems—like truncation, placeholders, locale switching—not whether every line reads like finished marketing copy on day one.
What changes when AI enters the picture
Machine translation and LLMs can cut cost per word — we run hybrid workflows daily — but they do not replace structure. Models still need glossaries, UI context, and consistency checks. When keys are vague, you get polite wording in the wrong tone, or three different translations for the same button on adjacent screens.
Two locales plus disciplined keys make machine translation post-editing (MTPE) and automation predictable. One locale plus messy strings makes automation costly: humans burn hours fixing ambiguity that keys could have prevented.
If you are already late
Retrofitting internationalization is normal — many successful products started US-only. The honest plan is extraction, prioritization, and incremental coverage: ship what global users touch first (store presence, onboarding, paywalls), then deepen narrative or secondary screens. The payoff for adding that second engineering locale early is that you stop debating whether localization is “creative” work and start treating it as part of release hygiene.
Whether you build consumer software or ship an indie title, the principle is the same: two languages force the architecture that later scales to twenty. Start there, keep English intentional when it is your hub, and treat copy with the same rigor as visual design — your future translators (human or assisted) will thank you.
Frequently Asked Questions
Why two languages instead of one “proper” English launch?
Which two languages should we pick?
Does “day one” mean translating everything immediately?
How does this connect to localization QA (LQA)?
What if we already shipped English-only with hard-coded strings?
Alexander founded Alconost after years building and shipping software for global markets. He works with product teams that want localization baked into how they ship — not parked at the end of the roadmap as someone else’s problem.
