React RTL Arabic: Build Bilingual Apps for UAE Markets

Practical guide to implementing Arabic/English RTL support in React. Component-level control, CSS strategies, performance tips for UAE startups.

sohail
By Sohail Ahmad
Posted
0

Building a React application for the UAE or broader MENA region means supporting Arabic and English, often in the same interface. But RTL (right-to-left) support is not just about flipping the layout. It requires thoughtful architecture at the component level, strategic CSS choices, and awareness of performance trade-offs when switching languages dynamically.

Adding RTL to an existing React app requires addressing directional properties throughout your codebase. The better approach is to treat RTL and LTR as first-class citizens in your component library from the start.

Why Component-Level RTL Control Matters

Many teams start by setting a global dir attribute on the HTML element and letting CSS handle the rest. Global dir attributes work for simple layouts. Complex applications benefit from component-level control because they often have:

  • Mixed language content (an English quote inside an Arabic paragraph)
  • Embedded third-party widgets that don’t respect the global direction
  • Design systems where some components need explicit directional control regardless of the page direction
  • Real-time language switching without full page reloads

Component-level control means each component knows its own direction and applies the right styles independently. This gives you predictability and avoids surprises when you nest components or change languages on the fly.

Setting Up a Direction Context

Start with a React context to manage and provide the current text direction throughout your app:

import React, { createContext, useContext, useState, useEffect } from 'react';

type Direction = 'ltr' | 'rtl';

interface DirectionContextType {
  direction: Direction;
  setDirection: (dir: Direction) => void;
  isRTL: boolean;
}

const DirectionContext = createContext<DirectionContextType | undefined>(undefined);

export const DirectionProvider: React.FC<{ children: React.ReactNode }> = ({ children }) => {
  const [direction, setDirection] = useState<Direction>('ltr');

  useEffect(() => {
    document.documentElement.dir = direction;
    document.documentElement.lang = direction === 'rtl' ? 'ar' : 'en';
  }, [direction]);

  return (
    <DirectionContext.Provider value={{ direction, setDirection, isRTL: direction === 'rtl' }}>
      {children}
    </DirectionContext.Provider>
  );
};

export const useDirection = () => {
  const context = useContext(DirectionContext);
  if (!context) {
    throw new Error('useDirection must be used within DirectionProvider');
  }
  return context;
};

This context keeps direction in sync with the DOM and provides a hook any component can use. When you change direction, the HTML element’s dir attribute updates, which cascades to child elements automatically.

Building Direction-Aware Components with Styled-Components

Styled-components makes it straightforward to apply directional styles at the component level. Create a helper function that generates directional CSS properties:

import styled from 'styled-components';
import { useDirection } from './DirectionContext';

const dirValue = (ltrValue: string, rtlValue: string, isRTL: boolean) =>
  isRTL ? rtlValue : ltrValue;

const Card = styled.div<{ isRTL: boolean }>`
  padding: 16px;
  border-radius: 8px;
  margin-${props => (props.isRTL ? 'right' : 'left')}: 16px;
  text-align: ${props => (props.isRTL ? 'right' : 'left')};
  background: #f5f5f5;
`;

export const DirectionalCard: React.FC<{ children: React.ReactNode }> = ({ children }) => {
  const { isRTL } = useDirection();
  return <Card isRTL={isRTL}>{children}</Card>;
};

By passing the direction as a prop to styled components, each component instance respects the current direction. This approach works well alongside CSS logical properties, which modern browsers support natively.

CSS Logical Properties: The Modern Approach

CSS logical properties like margin-inline-start and margin-inline-end automatically flip based on the element’s direction. According to better-i18n.com, this is the single biggest improvement you can make for RTL support:

/* Instead of this: */
.sidebar {
  margin-left: 16px;
  padding-right: 1.5rem;
  border-left: 2px solid var(--accent);
  text-align: left;
}

/* Use this: */
.sidebar {
  margin-inline-start: 16px;
  padding-inline-end: 1.5rem;
  border-inline-start: 2px solid var(--accent);
  text-align: start;
}

In LTR, inline-start maps to left. In RTL, it maps to right. The same component works in both directions without duplication. All modern browsers support logical properties, and they’re the recommended approach for new projects.

Tailwind CSS with Logical Property Utilities

If you’re using Tailwind CSS, use the built-in logical property utilities instead of directional variants. According to DEV Community, Tailwind 3 exposes logical properties as ms-*, me-*, ps-*, pe-*, border-s, and border-e:

<div className="ms-4 ps-2 border-s-2 text-start">
  Responsive to direction
</div>

These utilities handle 90% of layout flipping automatically when dir changes. Reserve rtl: and ltr: variants only for things logical properties can’t handle, like icon transforms or animation origins.

Language Switching and Performance

Dynamic language switching is common in UAE apps. Users expect to toggle between Arabic and English without reloading the page. However, this has performance implications:

  • Changing direction re-renders all components that consume the direction context
  • CSS-in-JS libraries may need to regenerate styles if they’re direction-dependent
  • Font loading might differ between Arabic and English (Arabic fonts are often heavier)

To minimize re-renders, split your context into separate providers for direction and language content:

interface DirectionContextType {
  direction: Direction;
  setDirection: (dir: Direction) => void;
}

interface LanguageContextType {
  language: 'ar' | 'en';
  setLanguage: (lang: 'ar' | 'en') => void;
  t: (key: string) => string;
}

// Two separate providers
export const DirectionProvider = ({ children }) => { /* ... */ };
export const LanguageProvider = ({ children }) => { /* ... */ };

Components that only need translated text don’t re-render when the direction changes, and vice versa. Wrap your app with both providers at the root level.

For font optimization, preload Arabic fonts separately and use font-display: swap to avoid invisible text while fonts load:

@font-face {
  font-family: 'Arabic Font';
  src: url('/fonts/arabic-font.woff2') format('woff2');
  font-display: swap;
  unicode-range: U+0600-U+06FF;
}

Form Inputs and Text Alignment

A common RTL bug is hardcoded text alignment on form inputs. BahrTech recommends using text-align: start instead of text-align: left. This ensures the cursor begins at the leading edge for both languages:

input {
  text-align: start;
}

/* Exception: numeric inputs should keep text-align: end */
input[type="number"] {
  text-align: end;
}

The exception is numeric inputs (price, quantity, year), which should use text-align: end so the trailing digit aligns with the field’s edge.

Testing RTL and LTR Paths

Always test both directions in your component library. A simple way to do this is to render your component twice in a test or storybook:

import { render } from '@testing-library/react';
import { DirectionProvider } from './DirectionContext';

const renderWithDirection = (component: React.ReactNode, direction: 'ltr' | 'rtl') => {
  return render(
    <DirectionProvider initialDirection={direction}>
      {component}
    </DirectionProvider>
  );
};

test('Button renders correctly in LTR and RTL', () => {
  const { container: ltrContainer } = renderWithDirection(<Button>Click me</Button>, 'ltr');
  const { container: rtlContainer } = renderWithDirection(<Button>Click me</Button>, 'rtl');

  expect(ltrContainer.querySelector('button')).toHaveStyle('text-align: start');
  expect(rtlContainer.querySelector('button')).toHaveStyle('text-align: start');
});

This ensures your components adapt correctly regardless of the active direction.

Real-World Patterns from UAE Tech Teams

Teams building bilingual apps in the UAE typically combine these approaches:

  • A direction context at the app root that syncs to document.documentElement.dir
  • CSS logical properties as the default, with styled-components or Tailwind utilities for component-level overrides
  • Separate language and direction providers to avoid unnecessary re-renders
  • A shared component library that handles RTL internally, so product teams build features without thinking about direction
  • Preloaded Arabic fonts with font-display: swap to prevent layout shifts
  • Both LTR and RTL test coverage in CI/CD pipelines

The key insight is that RTL support is not a feature you add at the end. It’s an architectural decision that shapes how you build components from day one. Teams that design for bilingual RTL from the start move faster and avoid technical debt.

Conclusion

Building bilingual React applications for UAE markets requires more than translating text. Component-level RTL control, strategic use of CSS logical properties, and careful performance optimization ensure that your app feels native to both Arabic and English speakers. Start with a direction context, build components that are direction-aware by default, and test both paths consistently. Your users will notice the difference, and your codebase will be easier to maintain.

Should I use CSS logical properties or directional variants?

CSS logical properties are the modern standard and work in all current browsers. Use margin-inline-start, padding-inline-end, text-align: start, and similar properties as your default. Reserve rtl: and ltr: variants only for edge cases like icon transforms or animation origins that logical properties can’t handle.

Can I switch languages without reloading the page?

Yes. Use separate context providers for direction and language content. This minimizes re-renders and lets users toggle between Arabic and English smoothly. Preload fonts for both languages to avoid layout shifts during the switch.

What’s the performance impact of dynamic language switching?

The main cost is re-rendering components that depend on the direction context. Splitting your contexts and memoizing components that don’t need direction changes can mitigate this. Font loading differences between Arabic and English may also affect perceived performance; use font-display: swap and preload critical fonts.

How do I handle mixed-language content in a single paragraph?

Use the HTML dir attribute on inline elements or spans to override the parent direction. For example, an English phrase in an Arabic sentence can be wrapped in a span with dir=”ltr”. This signals to the browser how to render the text bidirectionally.

Do I need a separate component library for RTL?

No. Build your primary component library to be direction-aware from the start using context and logical CSS properties. This single library works correctly for both LTR and RTL without duplication.

What’s the most common RTL bug?

Hardcoded directional utilities like padding-left, margin-right, or text-align: left. These don’t flip in RTL mode. Replace them with logical properties: padding-inline-start, margin-inline-end, text-align: start.

sohail

Sohail Ahmad

Leave a Reply

Your email address will not be published. Required fields are marked *