Making a SaaS platform truly multi-language is one of the most underestimated engineering challenges. It touches every layer of the application — from the database schema to the CSS layout to the JavaScript date picker.
Beyond String Translation
The naive approach is wrapping every string in a translation function and calling it done. But real internationalization (i18n) involves:
- Right-to-left (RTL) layout support for Arabic, Hebrew, etc.
- Date and time format localization (DD/MM vs. MM/DD)
- Number formatting (1,000.00 vs. 1.000,00)
- Currency symbol placement and formatting
- Pluralization rules (English has 2 forms; Arabic has 6)
- Text expansion (German text is often 30% longer than English)
Translation Workflow
We use a key-based translation system with JSON language files. Each supported language has its own file, and the platform loads the appropriate translations at runtime. New strings are automatically flagged for translation when added to the codebase.
RTL Challenges
Supporting RTL languages requires mirroring the entire layout. Navigation, forms, tables, and icons all need to flip. CSS logical properties (margin-inline-start instead of margin-left) make this manageable, but legacy CSS must be audited and updated.
User-Generated Content
Platform UI can be translated, but user-generated content exists in the language users write it in. Search, sorting, and display must handle mixed-language content gracefully, including proper Unicode collation.
Testing Across Languages
Automated screenshots in each supported language catch layout issues early. We use pseudo-localization (replacing characters with accented variants and adding padding) to test text expansion without waiting for real translations.