Building a Multi-Language Site with next-intl: My Setup After 3 Projects

Last week, I was reviewing Tawasul Limo's analytics—a luxury car service platform I built for Abu Dhabi clients—and noticed 43% of their bookings come through the Arabic interface. That number would’ve been a pipe dream without proper localization. Three years ago, my first attempt at multi-language React sites felt like wrestling a snake in the dark. Today, next-intl is my go-to solution for English/Arabic projects, and here’s why.

Setting Up next-intl: The Boring Necessary Stuff

I start every project by running npm install next-intl. Version 3.6.0 introduced server-side translation loading, which saved me hours of debugging hydration mismatches—a godsend for clients who want to update translations without redeploying.

The core of my setup lives in /public/locales. I structure folders by locale (en, ar) with flat JSON files per page to avoid nested chaos. Example for the home page:

•public/locales/en/index.json
•public/locales/ar/index.json

In next.config.js, I explicitly set supported locales and default locale:

javascript

// next.config.js
module.exports = {
  i18n: {
    locales: ['en', 'ar'],
    defaultLocale: 'en',
  },
}

I skip Next.js’s built-in routing prefix (/ar/about) in favor of subdomains (ar.example.com) for Arabic SEO. This setup requires DNS configuration but aligns with how Gulf-based users expect language switching. More details in my Arabic SEO post.

Dealing With Dynamic Routes and ISR

Static site generation bites when translating dynamic routes. Last year, I spent two nights figuring out why my Reach Home Properties listings kept 404ing in Arabic. Turns out, next-intl’s useTranslations doesn’t work during ISR unless you preload messages. Final fix:

typescript

// pages/[slug].tsx
export async function getStaticProps({ locale, params }) {
  const messages = await loadTranslations(locale, 'details');
  return {
    props: { messages, slug: params.slug },
    revalidate: 60,
  };
}

Preloading translations for each locale on dynamic pages isn’t optional. If you miss it, ISR builds will render blank pages in production—ask me how I know.

Right-to-Left (RTL) Headaches and Fixes

Arabic text alignment broke my first component in the Greeny Corner plant app. Text was stuck in left-aligned purgatory despite correct HTML attributes. The culprit? Material-UI’s default styles overriding dir="rtl".

Two fixes worked:

Separate CSS classes for Arabic using [dir='rtl'] selectors
Server-side attribute injection

I bundle RTL styles in /styles/ar.scss and load them conditionally. No CSS-in-JS library handles this cleanly out of the box, so plain old Sass wins for RTL control.

Why Not Use Next.js App Router's i18n Options?

It's 2026 and the App Router's i18n middleware still has issues with Arabic numerals and date formatting. In Tawasul Limo's dashboard, booking dates in Hijri calendar format caused confusion until I manually adjusted localization options:

javascript

useTranslations('common', { locale: 'ar-EG' });

For GCC clients, sticking with next-intl's granular control beats fighting React Server Components' hydration issues. My opinion might change in Q3 when Next 15 drops—but not today.

A Real Annoying Gotcha: Arabic Numerals

A client in Dubai asked why their pricing looked wonky. The numbers 50, 100, 200 appeared as "٥٠, ١٠٠, ٢٠٠" in Arabic. Arabic script uses different numeral characters—something I completely forgot about.

Fixed it by adding formatNumber helpers across price components:

import { useTranslations } from 'next-intl';

export default function Price({ value }) {
  const t = useTranslations();
  return <span>{t(`formats.amount`, { value })}</span>;
}

With corresponding translation files:

json

// ar/index.json
{
  "formats": {
    "amount": "{value, number} AED"
  }
}

This forces Arabic locales to use standard 50/100/200 numerals while keeping other text right-to-left.

Frequently Asked Questions

Can I use next-intl with Laravel APIs for bilingual websites?

Absolutely. When building Tawasul Limo, I made Laravel return language-specific content fields (title_en, title_ar) then passed them to loadTranslations. Just make sure database columns store UTF-8 properly—check your Laravel Arabic text config.

How do search engines treat next-intl multisite?

Googlebot respects hreflang tags, which I manually add to for each locale. For Arabic pages:

html

<link rel="alternate" hreflang="ar" href="https://ar.example.com/">

This setup is why UAE real estate clients rank equally in both languages—check my Arabic SEO guide for full details.

Is next-intl slower than alternatives like linguijs?

Not in my load time tests. Both add ~30–60ms per page depending on translation file size. Use code splitting and preload critical page translations to keep speeds tight.

How to handle RTL CSS without duplicating stylesheets?

I use RTL CSS with PostCSS. It auto-generates RTL versions from your default LTR styles. No more editing two files—just write one set and let the plugin handle mirror direction.

If you're building a bilingual English-Arabic site for UAE/GCC clients and need battle-tested next-intl implementation, we should chat. I've navigated the pitfalls from RTL styling to dynamic pricing localization—book a free 30-minute consultation, or get in touch if your deadline yesterday.

METADATA:{"excerpt":"Learn how a UAE full-stack dev handles multi-language Arabic/English sites with next-intl after 3 production deployments.","tags":["next-intl","i18n","Arabic-English websites","Next.js localization","multilingual SEO"]}"