How MiQ Turned a 2-Week Localization Bottleneck into a 15-Minute Config Change

Based on an engineering case study by Pranav Shrivastava, UI Engineer 2 at MiQ.

For engineering teams, internationalization (i18n) has a way of quietly turning into a delivery bottleneck. At MiQ, a global, data-driven programmatic advertising platform, it did exactly that. MiQ’s distributed front end spans 15+ micro-frontends, and their legacy localization process required heavy engineering involvement, manual code releases, and up to two weeks of lead time to ship even a simple copy update.

By moving to Lingui and Crowdin, MiQ decoupled localization from their development sprints. With Over-the-Air (OTA) content delivery and an AI-assisted translation workflow, they removed engineers from the translation loop entirely.

The Problem: A Hardcoded Stack That Blocked Releases

"

We wanted a system where updating a translation never required a deployment.

MiQ’s initial i18n setup was standard for many mid-sized React codebases: i18next combined with static JSON files. It technically supported multiple languages, but the operational workflow around it was fractured.

The key pain points:

• Copy was hardcoded everywhere. Any text change or copy edit required a developer and a fresh production deployment.
• Keys drifted out of control. Managing translation keys by hand meant dead keys piled up and duplicate keys slipped through unnoticed.
• No automation layer. There was nothing handling string extraction, deduplication, or syncing files with the localization team.
• Two sources of truth. Translators worked in spreadsheets while developers worked in JSON, and the two were constantly drifting apart.
• Adding a language was a full dev cycle. Simple copy changes and urgent localized sales-demo requests took days to a week, sometimes up to two, to reach production.

The Solution: Rebuilding the Stack with Lingui and Crowdin

MiQ’s goal was to treat translations as dynamic content rather than static code. After evaluating the common approaches to React i18n, they made two strategic bets.

1. Code-first translations with Lingui

Despite other frameworks having larger communities, they chose Lingui to automate string extraction and simplify the developer experience. Instead of manually tracking abstract keys like t('home.welcome.back.v2'), developers write natural code:

<Trans>Welcome back</Trans>

Lingui handles extraction automatically and de-duplicates identical strings across components so the codebase stays clean and keys stop drifting.

2. A single source of truth with Crowdin

MiQ needed one translation management system (TMS) that designers, translators, and engineers could all work from. They chose Crowdin over the alternatives for three enterprise capabilities:

1. Over-the-Air (OTA) delivery – native web support for publishing versioned, cached translation catalogs to a CDN.
2. API ecosystem – integration hooks that drop cleanly into a modern CI/CD pipeline.
3. Context-aware AI tooling – the ability to run brand- and glossary-aware AI translation models.

Implementation: An Automated Localization Pipeline

The new architecture automates everything from a developer’s local machine to the end user.

The end-to-end workflow now looks like this:

1. Automated extraction. A developer adds a string with <Trans>. On commit, lingui extract pulls it into a localized .po catalog with no manual key management.
2. Continuous integration. CI pushes new source strings into Crowdin via the Crowdin API, creating a fully automated continuous-localization loop.
3. AI translation. New strings enter a multi-step workflow built on GPT-4o:
   • An auto-translation step that uses MiQ’s glossary, past human translations, and corporate brand voice.
   • A QA pass that checks for syntax preservation, formatting consistency, missing variables, and length constraints.
4. Human-in-the-loop proofreading. Reviewers log into Crowdin to tweak and approve the pre-processed, QA-checked strings. Shifting linguists from writing to verifying is what delivers the 5x–10x turnaround speedup.
5. Over-the-air delivery. Once approved, Crowdin compiles and publishes the updated catalogs to a global CDN.
6. Runtime lookup. Rather than bundling heavy translation files into the static build, the React app fetches only the catalogs it needs at runtime via OTA.

Performance and Scale

• Fast catalog loads. Catalogs are served from the CDN with integrity checks; cached fetches land in ~200ms (p95, cached). [Confirm p50/p95 and cold vs. cached numbers before publishing.]
• O(1) lookups, kept small. Translation lookups are constant-time by nature; the real win is per-route lazy-loading, which keeps each catalog small so they never fetch or parse strings the user won’t see.
• Defensive caching. If an OTA request fails, the UI instantly falls back to the native source locale without blocking rendering.
• Architecture independence. Each micro-frontend owns its own catalog, keeping bundles lean and teams decoupled.

Architectural Considerations

Moving to a runtime localization stack required deliberate guardrails to protect production stability:

• Fluid UI layouts. MiQ swapped fixed-width buttons for flexible layouts to absorb the ~30% text expansion common in languages like German and French.
• Fast, focused tests. Unit and component tests run only against the source locale to keep CI fast, with visual regression handled in a separate layer.
• Isolated catalogs. MiQ prohibits sharing keys across MFEs so individual bundles stay lean.
• Bulletproof fallbacks. Client-side caching plus an automatic fallback to English ensures a network or OTA failure never blocks the UI.
• The tradeoff they accepted. Runtime OTA means user-facing copy depends on a CDN fetch. They considered this acceptable because of the English fallback, but it’s a real design choice [note here any SSR/SEO implications for server-rendered surfaces, if applicable].

Results: Localization as a Product Capability

Moving localization out of the codebase removed the engineering bottleneck entirely.

• From up to 2 weeks to 15 minutes. What used to require an engineering sprint, code reviews, and a production deploy is now a translation config update.
• Zero engineering friction. Engineers write code in their native language and ship features. Product managers and localization teams own the copy, fully outside the release loop.
• Scale without cost. The system comfortably handles 100,000+ source strings across their distributed architecture with no impact on performance or build times.

Lessons Learned

• The org change mattered as much as the tech. The biggest unlock wasn’t Lingui or Crowdin individually, it was redrawing ownership so translators verify instead of authors, and PMs ship copy without engineering.
• Isolate early. Enforcing one catalog per MFE from day one avoided a class of coupling problems that would have been painful to unwind later.
• Design for failure first. Building the English fallback and caching before enabling OTA meant MiQ could adopt runtime delivery without fear of a CDN hiccup taking down the UI.

Conclusion

By pairing Lingui with Crowdin’s automated extraction and Over-the-Air delivery, MiQ decoupled localization from the core release cycle. Engineers now focus on features, writing code in their native language without managing translation keys or waiting on copy. And localization is autonomous: product managers and translators update production text, fix typos, and launch locales through Crowdin, no deploys, no sprint dependencies.