Multilingual Next.js: RTL, French & Spanish Done Right
We shipped multilingual Next.js sites in Arabic RTL, Spanish, and French. Arabic RTL is a frontend constraint you commit to on day one—not a CSS flag. Here's what we learned from real builds at Altamar Charters, Chatberry, and Taqaddum.
multilingual next.js website development isn't just about swapping strings. If you're building for the MENA region or European markets, you'll face three distinct beasts: Arabic RTL, French, and Spanish. At Techpotions, we've shipped all three in real projects—Altamar Charters (Spanish/English), Chatberry (Arabic-first RTL), Parcoursup Zen (French), and Taqaddum (Arabic/English assessments). Here's what got tested and what actually works, straight from the trenches.
The Arabic RTL Trap: Why dir="rtl" Is Only 10% of the Work
Arabic RTL is the one that bites. Setting a dir="rtl" attribute on the <html> tag won't cut it. The layout must be mirrored: navigation order reverses, icons flip, padding and margin trade sides, and every component orientation inverts. Without this, your Arabic site looks broken to native readers.
Mixed Arabic/English content—like product names or technical terms—introduces bidirectional (bidi) chaos. A string like "أهلاً World" can render out of order unless you wrap it in <bdi> tags or use CSS unicode-bidi: isolate. Font choice is equally critical; a Latin-first typeface will butcher Arabic script. We've learned to lock in a robust Arabic font (like Noto Naskh Arabic or Cairo) from day one. If you treat RTL as an afterthought, the refactor will cost you component-level rewrites across your entire UI.
French and Spanish: Content Discipline Over Layout Chaos
Contrary to Arabic RTL, French and Spanish are content problems, not layout ones. The CSS grid doesn't need to flip—but you do need rigorous translation workflows and locale-aware SEO. For Spanish, for instance, we built Altamar Charters Spanish-first, with English available via a language switcher. That meant structuring next-intl messages for every user-facing string and ensuring hreflang tags matched both language and region.
French sites like Parcoursup Zen follow the same discipline. The key is declaring lang="fr" on the <html> element and letting Next.js' internationalized routing handle the rest. You trade layout panic for content management: translation drift between languages can break user trust if you are not updating all locale files in sync.
How Altamar Charters Tripled Bookings with a Bilingual Next.js Build
The proof is in the fleet. Altamar Charters, a luxury yacht operator in Cancún, needed a Spanish-first marketing site that converted international guests. Their old site read like a tour operator, prices varied between WhatsApp agents, and international visitors bounced before requesting a quote.
We built a bilingual (ES/EN) Next.js site with:
- Calendar-aware availability and instant-quote pricing
- Stripe-backed deposit collection
- WhatsApp booking integration, cutting agent triage
- i18n routing via
next-intl, with Spanish as the default locale
Real outcomes:
- 3× direct bookings within 60 days
- −35% WhatsApp triage volume
- 0 ad spend in the first two months
- 98 mobile Lighthouse score
No fluff. The brand stayed restrained; the fleet did the selling. This is what multilingual next.js website development looks like when the locale matches business intent.
The Real Multilingual Next.js Stack We Use
Across our projects, we default to next-intl for translation management and Next.js built-in i18n routing for locale detection. For RTL layouts, we avoid hardcoded left/right values entirely. Instead, we use CSS logical properties (margin-inline-start, padding-inline-end) and Tailwind's ltr: / rtl: variants to keep layouts coherent in both directions.
Language | Key challenges | Tooling sweet spot |
|---|---|---|
Arabic RTL | Mirror layout, bidi text, font stack | |
Spanish | Regional translations, locale SEO | |
French | Language attribute, content sync | |
For bilingual Arabic/English platforms like Taqaddum, we dealt with assessment reports that mixed both scripts in the same paragraph—bidi isolation became non-negotiable. Every user-facing string was wrapped and tested.
Don't Retrofit RTL—Commit on Day One
We've seen teams bolt RTL onto an LTR-first app and suffer. Buttons misalign, carousels scroll backward, modals appear off-screen. Arabic RTL is a design constraint, not a feature flag. If your layout isn't conceived as a mirrored system from the first wireframe, retrofitting it will inflate scope and introduce regression bugs across every component.
French and Spanish forgive this more: you can layer translations onto an existing LTR UI without gutting the structure. But even there, a late-stage locale switch forces a full content audit. Start with next-intl configured and your translation files ready before you write the first component.
Build Your Multilingual Next.js Site Right
Whether you're targeting Cancún tourists, Arabic-speaking WhatsApp users, or French students, the principle stands: the locale is part of the architecture, not a skin. Explore our web services to see how we approach i18n-first builds, or start a project if you need a site that works in real-world scripts—not just demo locales.
FAQ
Is Next.js good for multilingual websites?
Yes, Next.js integrates i18n routing and dynamic localization out of the box, and with libraries like next-intl it handles both static and server-rendered multilingual content cleanly.
How do you handle Arabic RTL in Next.js?
Arabic RTL goes beyond a dir attribute—it requires mirrored layouts, bidirectional text handling for mixed Arabic/English strings, and careful font selection; we treat it as a design constraint from day one.
Can I add multiple languages to an existing Next.js site later?
You can, but retrofitting RTL into an LTR-first layout is costly. For Spanish or French, content-only i18n is manageable, but RTL demands refactoring component structure and styles, so starting early saves pain.