How to Internationalize a Product: Beyond Translation

I build products that serve users across Europe. Aviation Infinity has students from over 30 countries. Babonbo operates in multiple European cities. New Pilot Shop ships pilot uniforms internationally. Each product has forced me to think about internationalization differently, and most of what I've learned contradicts the standard engineering advice.

The Translation Trap

When most developers think about internationalization, they think about translation. Extract all strings into locale files, hire translators, ship multi-language support. The standard i18n libraries make this mechanically straightforward.

But translation is maybe 20% of actual internationalization. I learned this the hard way with Babonbo. I translated the entire platform into four languages before launching in new markets. The translations were accurate. And the product still felt foreign to users in each new market.

The problem wasn't the words. It was everything around the words. The date formats were wrong for some markets. The currency display didn't match local conventions. The address input forms assumed Italian address formats. The payment methods didn't include the options that users in other countries expected.

Real internationalization is about adapting the entire product experience to local expectations, not just translating the interface text.

What Actually Matters

After internationalizing several products, I've ranked the elements of i18n by their actual impact on user experience and business outcomes.

Payment methods come first. This surprised me. I assumed that credit card support was sufficient for European markets. It's not. In the Netherlands, iDEAL dominates. In Germany, direct debit (SEPA) and Sofort are preferred. In Poland, BLIK is widely used. If you don't offer the payment method your users expect, many of them will abandon the checkout. This isn't a preference; it's a dealbreaker.

For Babonbo, adding local payment methods in each new market increased checkout completion by 25% to 40% depending on the market. No translation improvement could match that impact.

Currency and pricing display comes second. Users need to see prices in their local currency, formatted according to their local conventions. In most European countries, the currency symbol comes after the number with a space (10,00 EUR). The decimal separator varies: comma in most of Europe, period in the UK and Ireland. Getting this wrong makes your product look careless.

Date and time formats come third. European countries can't even agree on date format. Day/month/year is the most common, but even within that standard, the separators and abbreviations vary. Aviation Infinity had a particularly fun challenge: aviation uses UTC time universally, but study session timestamps should be in the student's local time. Managing the display of both time references without confusion required careful UX work.

Translation comes fourth, after all of the above. Yes, translating your interface is important. But a product with perfect translations and wrong payment methods will perform worse than a product in English with the right payment methods.

The Technical Architecture

I've evolved my approach to internationalization architecture over several products. Here's where I've landed.

Locale detection happens at the edge. I use Vercel's geo headers to detect the user's country and infer their likely locale. This is supplemented by browser language preferences and, once the user has an account, their explicit preference. The locale cascades: explicit preference overrides browser preference overrides geo detection.

Translations are stored in JSON files organized by locale and namespace. Each product area (navigation, study dashboard, checkout, emails) has its own namespace. This keeps the translation files manageable and allows different areas to be translated independently. Not every area needs to be translated with the same priority.

Number, currency, and date formatting uses the Intl API that's built into modern JavaScript. This is dramatically better than using formatting libraries, because the Intl API uses the operating system's locale data, which is more comprehensive and accurate than any library can be.

Content localization is separate from interface localization. For Aviation Infinity, the exam questions and explanations are educational content that needs expert translation, not just linguistic translation. A meteorology question that's perfectly translated but uses weather examples irrelevant to the student's training region is poorly localized. Content localization is a product effort, not an engineering effort.

The Right-to-Left Consideration

None of my current products serve right-to-left (RTL) language markets, but I've built the foundation for it because I've seen how painful it's to retrofit. The key decisions are using logical CSS properties (margin-inline-start instead of margin-left), using flexbox and grid for layouts (which handle direction switching naturally), and avoiding absolute positioning for anything that's directionally dependent.

Tailwind CSS makes this manageable with its RTL/LTR variants. If you're building a product that might eventually serve Arabic, Hebrew, or Farsi-speaking markets, building RTL support into your CSS from the start costs almost nothing. Adding it later costs a lot.

Cultural Adaptation Beyond Language

The most underappreciated aspect of internationalization is cultural adaptation. This goes beyond language and formatting into how users expect to interact with your product.

Trust signals vary by culture. In Southern European markets, personal brand and relationships matter more than institutional credibility. In Northern European markets, data privacy and security certifications matter more. Babonbo's trust page in Italy emphasizes the founder story and personal guarantee. In Germany, it emphasizes GDPR compliance and data protection measures. Same product, different trust narratives.

Communication tone varies significantly. The casual, friendly tone that works in English-speaking markets can feel unprofessional in German-speaking markets. I maintain separate copywriting guidelines for each major language, and my translators aren't just translating words, they're adapting tone.

Support expectations differ. Users in some markets expect immediate chat support. Users in other markets are perfectly happy with email support that responds within 24 hours. Matching your support offering to market expectations avoids both over-investing in low-expectation markets and under-serving high-expectation ones.

The Solo Founder's i18n Strategy

If you're a solo founder considering internationalization, here's the practical approach I'd recommend.

Start with English and one additional language. English for the global baseline, and one language for your primary non-English market. Do this well before adding more languages.

Invest in payment localization before translation. Add the payment methods that your target market expects. This will have a bigger revenue impact than any language work.

Use professional translators, not machine translation. For interface text, machine translation has gotten surprisingly good, but it still makes mistakes that native speakers notice. For educational or trust-critical content, professional translation is non-negotiable.

Build the i18n infrastructure (locale detection, formatting, string externalization) early, even if you're only serving one language. Retrofitting i18n is one of the most tedious engineering tasks. Having the infrastructure in place from the start makes adding new languages incremental rather than transformational.

Don't try to localize for markets you don't understand. I only expand into markets where I have enough cultural understanding (through personal experience, local contacts, or extensive research) to do it well. A poorly localized product is worse than an English-only product, because it signals effort without quality.

The Compound Benefit

Internationalization is one of those investments that compounds over time. Each new market you enter has a lower marginal cost than the last because the infrastructure, processes, and institutional knowledge already exist. The first market expansion is expensive and slow. The fifth is relatively quick and cheap.

For my portfolio of products, the internationalization work I did for Babonbo directly benefited Aviation Infinity's expansion, which in turn made New Pilot Shop's international shipping much easier to implement. Shared patterns, shared knowledge, shared infrastructure.

As a solo founder building for European markets, internationalization isn't optional. It's a core competency. And like most core competencies, it gets easier and more valuable the more you practice it.