Internationalization Consultation: Fix What's Breaking, Plan What's Next
You already know i18n is hard. I've seen the symptoms: RTL layouts that collapse, German text overflowing buttons, API responses in the wrong language, and translations that drift out of sync within weeks of launch. I don't sell silver bullets. I help you untangle the specific mess your team is in—and build systems that won't break the same way twice.
"We Should Have Planned This Earlier"
The Architecture Tax You're Paying Now
You launched in English. It worked. Then you added French "just for the landing page." Now you're here because:
Your codebase has lang= checks scattered across 47 files
Product managers ask "can we A/B test copy?" and engineering says "not without a rewrite"
You have three different translation workflows and none of them work reliably
What I've seen break:
- Teams spending 6+ months retrofitting i18n into a Next.js app because strings were hardcoded in components
- Translation files falling out of sync because developers don't know which file to update
- "Localization freeze" periods before releases because nobody trusts the translation pipeline
- Resistance to changing any translated content because the workflow is so painful
What I help with:
- Refactoring strategies that let you incrementalize i18n adoption (I don't demand "stop everything and rewrite")
- Process design for keeping translations in sync without blocking development
- Architecture reviews to identify where your current approach will break at 10+ languages
i18n is architecture, not a feature. Trying to add it later is like deciding your house needs a basement after you've already built it.
I help you dig that basement—or decide if you actually need one.
RTL Breaks Everything
Your UI Wasn't Designed for Arabic, Hebrew, or Urdu
You switched dir="rtl" and watched your layout explode:
What I've seen:
- Design systems with 200+ components where only 12 properly handle RTL
- Teams using float: left instead of logical properties, creating RTL bugs in every new feature
- Popovers and modals that require component-specific RTL overrides
- Frameworks claiming "RTL support" that only flip the layout direction but break placement logic
What I help with:
- CSS logical properties migration (margin-inline-start instead of margin-left)
- Design system audits to find RTL landmines before they ship
- Framework-specific guidance (Tailwind, shadcn, MUI) for RTL-first styling
Manually fixing RTL bugs in every component is unsustainable. I make RTL support systematic, not a constant firefight.
"The German Text Broke Our Button"
UI That Wasn't Built for Translation
English fits. German doesn't. Your design assumed:
Then you translated to German, Finnish, or Thai and discovered:
Buttons cut off mid-word
Tables with horizontal scroll on every row
Text that wraps into unreadable blocks
Non-Latin text getting truncated because containers have fixed widths
What I help with:
- Elastic UI patterns that flex for content length
- Character budget planning (knowing German expands 30%, Thai doesn't use spaces)
- Typography systems that handle CJK, Arabic, and Devanagari without breaking
I help you build UI that survives translation—before you've paid for 10,000 words that don't fit.
You don't need a lecture on why i18n is important. You need someone who's debugged RTL popovers at 2 AM, argued with product about character budgets, and designed translation pipelines that actually work.
The Gotchas Nobody Warned You About
War Stories from Teams Who've Been There
These aren't theoretical. These are things that broke in production:
Pluralization Hell
English: "1 item" vs "2 items"
Polish: "1 przedmiot" / "2 przedmioty" / "5 przedmiotów" (3 plural forms)
Arabic: 6 plural forms
Your count === 1 ? 'item' : 'items' logic doesn't work anymore.
Date/Time Chaos
You formatted dates with toLocaleDateString(). Then users in Japan saw "2025年2月9日" in your CSV exports and Excel choked.
API Language Mismatch
Your frontend requests French. Your API returns English because the auth token doesn't carry locale. Now you have mixed-language UI and users think it's a bug.
Pseudo-Locale Testing
You didn't test with [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30%] before going to production. Now your Polish site is unusable.
The Invisible Assumption
You assumed strings are the only thing that needs translation. Then you hit dates, numbers, currencies, sorting, search—everything has locale-specific behavior.
What I help with:
- ICU MessageFormat implementation (handles plurals, gender, context)
- API i18n patterns (language negotiation, fallback strategies)
- QA processes that catch these issues before translation agencies do
Workflow is the Hard Part
How Do You Keep 8 Languages in Sync When You Ship Daily?
You've figured out the tech. Now you're stuck on process:
Developers merge code with new English strings. Translations lag by 2 weeks. Users see half-translated UI.
You don't know which strings are safe to delete (are they used? translated? in flight with an agency?)
Product wants to update copy. Nobody knows if changing "Submit" to "Send" will break 12 languages.
Translation files sit out of sync with production for weeks at a time
Questions teams ask me:
What I've seen break:
- Translation files checked into git that diverge from the production strings
- "Don't touch the Spanish file" warnings because nobody knows what's safe to change
- Features launched in English, then translated 6 months later (if ever)
What I help with:
- Translation pipeline design (when to use i18n libraries, when to use TMS, when to use AI)
- Git workflows for keeping source strings and translations in sync
- Automation that blocks PRs if new strings aren't marked for translation
The tech is solvable. The workflow is the blocker. I design workflows that don't require heroics to maintain.
Teams I've Worked With
Global Products, Regional Expertise
LINE (Japan, Taiwan, Thailand)
Messaging platform operating across 3 primary East Asian markets. Worked on challenges specific to CJK character handling, platform ecosystem integration, and user experience expectations that differ across Japan, Taiwan, and Thailand.
KakaoTalk (South Korea)
Korea's dominant messaging platform. Addressed Korean market-specific product requirements including language formality expectations in UI and platform integration needs.
Change.org (196 countries, 20+ priority languages)
Global petition platform where content speed and quality both matter. Helped navigate translation workflow for user-generated political/social content across diverse markets.
Airbnb (220+ countries, 60+ languages)
Global marketplace with complex i18n requirements. Consulted on challenges around trust/safety in multiple languages and cultural adaptation of platform concepts across markets.
Intercom (30+ languages, global B2B SaaS)
Customer communication platform serving global enterprise clients. Worked on product internationalization for real-time support tooling and knowledge base localization.
Lilith Games (China, Japan, Korea, US, EU)
Mobile game publisher with titles distributed globally. Addressed market-specific challenges around content localization and regional platform requirements.
Markets I've Launched In:
East Asia (Japan, Korea, China):
CJK typography, platform ecosystem integration, vertical text support
Southeast Asia (Thailand, Vietnam, Indonesia):
Multi-script support, mobile-first user expectations
MENA (Arabic-speaking regions):
RTL layout requirements, formal vs. colloquial language expectations, cultural content adaptation
Europe:
24 official languages, multi-country product launches
Americas:
Regional language variations (LATAM Spanish vs Spain, Brazilian Portuguese), bilingual markets
I've seen what works and what fails in these markets—not from theory, but from shipping products that real users depend on.
Let's Fix What's Breaking
You don't need a lecture on why i18n is important. You need someone who's debugged RTL popovers at 2 AM, argued with product about character budgets, and designed translation pipelines that actually work.
Architecture & Strategy Review (1-2 weeks):
I tell you what will break when you add your next 3 languages, and what it will cost to fix
Market Launch Support (4-8 weeks):
You're launching in Japan/MENA/EU and need experts who've done it before
Ongoing Partnership:
Embedded consulting as you scale from 2 languages to 20
I don't do theory. I do triage, roadmaps, and shipping.