Architecting Multilingual Platforms: Lessons from Building a 45+ Language System

Photo by Sigmund on Unsplash

Introduction

One years ago, I faced one of the biggest challenges of my career: building a content management system that would need to support over 45 languages, including right-to-left scripts, complex character sets, and region-specific content variations. I quickly learned that multilingual support goes far beyond simple translation. It requires rethinking your entire architecture from the ground up.

In this article, I’ll share the key lessons I learned while building this system — insights that can save you significant time and headaches if you’re embarking on a similar journey.

The Multilingual Trap: Why Translation Plugins Aren’t Enough

Many developers approach multilingualism as an afterthought — adding a translation plugin or service to an existing application. While this approach works for simple use cases, it fails spectacularly when building global-scale platforms.

Here’s why:

1. Translation is just the beginning. True multilingual support encompasses content workflows, user interfaces, data validation, and search functionality.
2. Each language brings unique challenges. Arabic and Hebrew flow right-to-left, requiring layout inversions. Some Asian languages lack word spacing, complicating search. German compounds words, resulting in longer strings that break UI layouts.
3. Regional content variations matter. Even within the same language, regional differences (British vs. American English, Brazilian vs. European Portuguese) can affect content relevance and meaning.

Architectural Patterns That Scale Across Languages

After much trial and error, here are the architectural patterns that proved most effective:

1. Content-First Data Modeling

Rather than treating translations as properties of a primary language object, design your data model around language-agnostic content IDs with language-specific manifestations:

// Instead of this:
{
  title: "Breaking News",
  title_ar: "أخبار عاجلة",
  title_fr: "Dernières Nouvelles",
  // And so on for 45+ languages...
}

// Use this approach:
{
  contentId: "news-article-12345",
  language: "en",
  title: "Breaking News",
  // Other fields...
}

This approach:

• Makes adding new languages straightforward
• Enables language-specific content workflows
• Simplifies content queries by language

2. Microservices by Content Function, Not Language

A common mistake is creating separate services for each language. Instead, organize microservices by function, with each handling multilingual support internally:

• Content Management Service
• User Authentication Service
• Search Service
• Notification Service

Each service implements language-aware processing while maintaining a consistent API contract across languages.

3. Centralized Translation Management

Build a dedicated translation service that:

• Stores all translations in a consistent format
• Provides versioning for translations
• Caches common translations for performance
• Handles fallbacks when translations are missing

This creates a single source of truth for translations while enabling specialized processing for different content types.

Technical Implementation: The Stack That Worked

After experimenting with various technologies, here’s what proved most effective for our multilingual platform:

Backend

• NestJS: We used it in some microservices where its modular architecture allowed us to implement language-specific modules while maintaining consistency
• PayloadCMS: We leveraged PayloadCMS as our headless content management system, which provided excellent support for localization patterns and content relationships across languages
• MongoDB: The flexible schema accommodated varying content structures across languages
• Redis: Critical for caching translations and improving performance

Frontend

• Next.js: Provided the foundation for our frontend application with server-side rendering capabilities
• React with i18next: Provided robust internationalization capabilities
• CSS Modules with RTL support: Enabled automatic layout switching for right-to-left languages
• Custom font loading: Optimized for various character sets

Infrastructure

• AWS Lambda: For language-specific processing functions
• AWS ECS/EC2: For hosting our core application services and microservices
• CloudFront: With geo-targeting to serve region-appropriate content
• S3: For language-specific assets with appropriate character encoding
• Other AWS services: Leveraged additional services such as Route53, VPC, WAF, and Elemental for a complete cloud infrastructure

Lessons in Internationalization (i18n)

Beyond architecture, these practical i18n lessons proved invaluable:

1. Dates and Time Formats Are More Complex Than You Think

Different cultures represent dates differently. “5/4/2023” is May 4th in the US but April 5th in Europe. Our solution:

// Use a consistent ISO format in your database
storedDate = "2023-04-05T14:30:00Z"

// Format on the client based on user locale
displayDate = new Intl.DateTimeFormat(userLocale, {
  day: 'numeric',
  month: 'long',
  year: 'numeric'
}).format(new Date(storedDate));

2. Test with Native Speakers, Not Google Translate

Automated translation services miss cultural nuances. We implemented:

• A network of native language reviewers
• A feedback mechanism within the CMS
• A staging environment where content could be reviewed before publication

3. Plan for Text Expansion and Contraction

Text length varies significantly between languages. German can be 30% longer than English, while Chinese is often more compact. Our UI addressed this by:

• Using flexible containers that adapt to content length
• Testing layouts with the longest possible translations
• Implementing responsive design principles at the component level

Performance Considerations

Multilingual support can significantly impact performance. These strategies kept our platform responsive:

1. Intelligent caching of language-specific content based on user preferences
2. Lazy loading translations only when needed
3. Server-side rendering with language detection for faster initial loads
4. Content delivery networks optimized for global distribution

Final Thoughts: Start Multilingual, Don’t Retrofit

The most important lesson? Plan for multilingual support from day one. Retrofitting an existing application is exponentially more difficult than building with internationalization in mind.

In our case, rebuilding certain components with multilingual support added two months to our development timeline. Had we considered these requirements from the start, that additional time could have been avoided.

What’s Next?

As we continue expanding our platform, we’re exploring how AI can improve multilingual content creation and management, particularly for low-resource languages where professional translators are scarce.

I hope these insights help you on your own multilingual development journey. Have you faced similar challenges? Or do you have different approaches to multilingual architecture? I’d love to hear your experiences in the comments.

Abdullah Obaid is a Senior Full-Stack Engineer specializing in multilingual platforms and AI integration. He currently works at TRT, where he contributed to architecting a content management system supporting 45+ languages.