A London-based agency builds a beautiful website for a Dubai client.

Clean grid. Perfect spacing. Typography lockup that took weeks to refine. Animations timed to millisecond precision.

Then they add Arabic.

Everything breaks.

The navigation stacks wrong. The hero image is on the wrong side. Text overflows containers. Animations run in reverse but feel off. The grid that looked pristine in English looks chaotic in Arabic.

They patch it. Override here, exception there, hide this, reposition that. It works. Barely.

But it doesn't feel right. The vibe that made the English version special is gone in Arabic.

This happens to 90% of bilingual websites. And it's a technical and creative failure that reveals how little most designers understand about true bilingual design.

The Fundamental Problem: Two Reading Directions, One Design System

Let's start with the core challenge.

English (and most Latin scripts): Left-to-Right (LTR)

• Read from left to right

• Navigate from left to right

• Visual hierarchy flows left to right

• Animations progress left to right

• Time flows left to right (past on left, future on right)

Arabic (and Hebrew, Urdu, Farsi): Right-to-Left (RTL)

• Read from right to left

• Navigate from right to left

• Visual hierarchy flows right to left

• Animations should progress right to left

• Time flows right to left (past on right, future on left)

The mistake most designers make: Treating RTL as a technical switch, not a design paradigm.

They flip the layout horizontally and call it done. But that's not designing for RTL. That's mirroring LTR. And users can tell.

What Actually Needs to Flip (and What Doesn't)

Here's where it gets complex. Not everything mirrors.

Elements That MUST Flip

✓ Text direction (obviously)
✓ Reading order (right to left)
✓ Navigation placement (menu goes right instead of left)
✓ Directional icons (arrows, chevrons reverse)
✓ Form field order (labels on right, inputs on left)
✓ Timeline direction (newest on right, oldest on left)
✓ Carousel/slider progression (swipe left to advance, not right)
✓ Animation directionality (slide-ins come from right, not left)

Elements That MUST NOT Flip

✗ Logo orientation (stays the same unless it contains directional elements)
✗ Product images (a shoe pointing left doesn't point right in Arabic)
✗ People in photos (they don't face the opposite direction in different languages)
✗ Graphs and charts (data visualisation conventions are typically universal)
✗ Video player controls (play buttons don't mirror)
✗ Clocks and circular progress indicators (clockwise is universal)

Elements Where It's Ambiguous (Designer's Judgement Required)

⚠ Grid asymmetry (if your layout is intentionally weighted left, do you weight it right in Arabic?)
⚠ Diagonal lines and shapes (do angles flip?)
⚠ Shadows and depth (does light source change direction?)
⚠ Gestural interactions (swipe patterns)

Getting these decisions wrong destroys the design integrity. Getting them right requires understanding cultural context, not just technical specs.

The Technical Implementation (Three Approaches)

Let's talk about how this is actually built.

Approach 1: CSS Logical Properties (The Modern Way)

How it works: Instead of specifying left and right positions, developers use "start" and "end" properties. Instead of setting margin on the left side, they set margin on the "inline-start" side, which automatically becomes right in RTL and left in LTR.

Advantages:

• Clean code that works in both directions automatically

• Automatic flipping when RTL is activated

• Future-proof as browsers improve support

Disadvantages:

• Requires thinking in logical properties from the start

• Older browser support is limited (but improving)

• Doesn't solve everything (images, animations, etc. still need manual handling)

Approach 2: Duplicate Stylesheets with RTL Overrides

How it works: Write your main stylesheet assuming LTR, then create a separate RTL stylesheet that overrides specific properties for right-to-left layouts.

Advantages:

• Compatible with older browsers

• Explicit control over every RTL change

• Easy to debug (you can see exactly what's different)

Disadvantages:

• Maintenance nightmare (every change needs to be reflected in two files)

• Code bloat and larger file sizes

• Easy to miss things when updating

Approach 3: Script-Based Flipping

How it works: Detect the language being used, add an RTL marker to the page, and handle specific element positioning through automated scripts.

Advantages:

• Maximum control for complex interactions

• Can handle animations and dynamic content

• Good for elements that don't flip cleanly with styling alone

Disadvantages:

• Performance overhead from running scripts

• Flash of unstyled content if scripts load slowly

• Harder to maintain and debug

Best practice: Hybrid approach. Use logical properties as foundation, RTL overrides for exceptions, scripts only for complex interactions that can't be handled with styling alone.

The Typography Challenge: Arabic ≠ Latin

Here's where most designs fail hardest.

The Latin Font Problem

You pick a beautiful sans-serif for your English site. Clean. Modern. Perfect spacing.

Then you need Arabic. So you pick an Arabic font that "looks similar."

Problem: Arabic script has fundamentally different characteristics than Latin.

What makes Arabic typography different:

1. Vertical proportions
Arabic letters have more vertical variation. Ascenders go higher, descenders go lower. Your line-height that worked for English creates cramped, illegible Arabic.

2. Connecting letterforms
Most Arabic letters connect horizontally. This creates continuous flow that Latin doesn't have. Your letter-spacing settings don't translate.

3. Diacritical marks
Arabic has dots and marks above and below baseline. Your text containers sized for English clip these essential marks.

4. Weight distribution
Arabic letterforms have different stroke weight patterns. A "regular" weight in Latin doesn't map to "regular" in Arabic visually.

5. No uppercase
Arabic doesn't have capital letters. Your design that relies on uppercase headings and lowercase body text doesn't work.

The Solution: Design with Both Typographies Simultaneously

Don't design in English then add Arabic. Design in both at the same time.

Practical workflow:

1. Choose typefaces together
Pick Latin and Arabic fonts that share design DNA, not just aesthetic similarity.

Examples of well-paired typefaces:

• Proxima Nova with GE SS (both geometric sans-serifs with similar proportions)

• Freight Text with Boutros (both have calligraphic influences)

• Custom pairing: Commission custom Arabic to match your Latin font exactly

2. Test layouts in both languages from the start
Every mockup should show English and Arabic versions. Not just text swapped, fully designed in both directions.

3. Establish typographic scale for both
Your heading hierarchy needs to work in both scripts. Arabic might need different size ratios because of different vertical proportions.

4. Design containers that flex
Arabic text often runs 20-30% longer than equivalent English. Your fixed-width containers will overflow.

The Animation Direction Problem

Animations are where the "vibe" lives. And they're where RTL implementations most commonly fail.

Why Direction Matters for Motion

Cultural reading:

• In LTR cultures, progress moves left to right (think progress bars, timelines)

• In RTL cultures, progress moves right to left

• If your animations contradict reading direction, they feel wrong

Spatial metaphors:

• "Next" in English implies rightward movement

• "Next" in Arabic implies leftward movement

• Your carousel that advances right on click feels backwards in Arabic

How to Handle Directional Animations

Approach 1: Mirror all directional motion

When the page is in RTL mode, all sliding, swiping, and directional animations need to move in the opposite direction. Elements that slide in from the left in English should slide in from the right in Arabic. Progress indicators that move left-to-right should move right-to-left.

Approach 2: Use non-directional animations

Fade, scale, rotate. These work regardless of language direction and avoid the problem entirely.

When you can't avoid directionality (carousels, slides), make sure it mirrors properly.

Approach 3: Culturally appropriate motion design

Some animation patterns are culturally specific. Sliding drawers, expanding menus, page transitions.

Research how these patterns work in Arabic interfaces and design accordingly, don't just mechanically mirror.

The Grid System: Symmetric vs. Asymmetric Layouts

Here's a design choice that reveals philosophical approach.

Symmetric Grids (Easy Mode)

What it is: Centered layouts, balanced columns, no directional weighting.

Why it works for RTL: Mirrors perfectly. Looks identical in both directions.

Example: Most e-commerce sites use symmetric grids for this reason.

Limitation: Can feel generic. Lacks the dynamic tension that asymmetric layouts create.

Asymmetric Grids (Hard Mode, Better Results)

What it is: Intentionally weighted layouts. Content heavier on one side. Directional flow.

Why it's challenging for RTL: The weight needs to flip, but not just mechanically. The designer needs to ensure the Arabic version has the same intentionality as the English.

Example: Editorial sites, portfolio sites, brand homepages that prioritise vibe over symmetry.

The skill: Making both versions feel deliberately designed, not like one is the "real" version and one is mirrored.

Real Example: How This Works (or Doesn't)

Let's walk through a common design pattern and how it translates.

The Hero Section

English version (LTR):

• Image occupies left 60% of screen

• Text content on right 40%

• Headline aligned to the left

• Body copy aligned to the left

• Call-to-action button aligned left

• Visual weight: Heavy left, light right

Bad Arabic implementation:

• Text content on left 40%

• Image on right 60%

• Headline aligned to the right

• Body copy aligned to the right

• Call-to-action button aligned right

• Visual weight: Heavy right, light left

Why this is bad: It's mechanically flipped, but the image-text relationship feels inverted, not mirrored. The image was composed for left-side placement (subject looking right, lighting from left). Now it's on the right but still composed for left placement.

Better Arabic implementation:

• Image on right 60%, recomposed or flipped if it contains directional elements

• Text content on left 40%

• Headline aligned to the right

• Body copy aligned to the right, but with adjusted line length for readability

• Call-to-action button aligned right with adjusted padding and spacing

• Visual weight: Intentionally balanced for RTL reading direction

Why this is better: Every element is reconsidered for RTL, not just repositioned.

The Tools That Actually Help

Building true RTL support requires the right tooling.

Design Tools

Figma:

• Supports RTL text natively

• Allows mirroring of entire frames

• Can set up RTL variants of components in design system

Limitation: Animations and interactions don't flip automatically in prototypes.

Adobe XD:

• Basic RTL text support

• Manual mirroring required for layouts

Limitation: Weaker RTL typography support than Figma.

Development Frameworks

Tailwind CSS:

• Has RTL modifier classes built in

• Makes logical properties easier to implement

• Allows developers to specify different styles for RTL contexts

Chakra UI:

• Built-in RTL support out of the box

• Components flip automatically when RTL is enabled

• Well-documented RTL patterns

Material-UI:

• RTL theme provider included

• Comprehensive RTL documentation

• Large community with RTL experience

Testing Tools

BrowserStack: Test actual RTL rendering across different browsers and devices
Polypane: Side-by-side LTR/RTL view during development for real-time comparison
Manual testing: Essential. Automated tests don't catch UX and cultural issues.

The Quality Checklist: What True Bilingual Design Requires

Here's what separates good bilingual design from bad.

Visual Quality

✓ Both languages use appropriate, well-chosen typography
✓ Line lengths are readable in both directions
✓ Images are composed or selected appropriately for each direction
✓ Spacing and rhythm feel intentional in both versions
✓ Neither version looks like an afterthought

Technical Quality

✓ No text overflow or clipping in either language
✓ No broken layouts in either direction
✓ Animations work correctly in both directions
✓ Icons flip appropriately (directional icons mirror, others don't)
✓ Forms work intuitively in both directions

Cultural Quality

✓ Reading patterns respected (F-pattern in LTR, reversed F in RTL)
✓ Visual hierarchy matches reading direction
✓ No cultural assumptions embedded in one direction only
✓ Both versions feel designed for that audience, not translated to them

If you can't check all of these, your bilingual design isn't done.

Why Most Agencies Fail at This

Let's be honest about why bilingual design is usually done poorly.

Reason 1: English-First Development Culture

Most agencies design and build in English, then bolt on other languages as an afterthought. By the time Arabic is added, the entire system is optimised for LTR.

Fixing it properly would mean rebuilding. So they patch instead.

Reason 2: Lack of Native Language Expertise

Designers who don't read Arabic can't evaluate whether the Arabic version feels right. They can see if it's technically functional, but not if it's culturally appropriate or aesthetically refined.

They're designing blind for 50% of the users.

Reason 3: Budget Constraints

True bilingual design takes roughly 40-60% more time than single-language design. Not double, but substantially more.

Most clients don't budget for this. So agencies cut corners.

Reason 4: Testing Gaps

English-speaking QA teams test the English version thoroughly. The Arabic version gets cursory checks for broken layouts, but nuanced UX issues go unnoticed.

Native Arabic speakers find problems on day one that the agency never caught.

The Cost of Getting It Wrong

What happens when bilingual design fails?

User Experience Degradation

Arabic-speaking users get a worse experience. They're treated as second-class users, even if the brand doesn't intend this.

They notice. And they leave.

Brand Perception Damage

When the Arabic version looks cheap or broken, users assume:

• The brand doesn't care about Arabic speakers

• The brand is Western-centric and not truly for them

• The brand cut corners on quality

This destroys trust in markets where Arabic is primary.

Competitive Disadvantage

Brands that do bilingual design well differentiate themselves. When your site works beautifully in both directions and competitors' sites break in Arabic, you win those customers.

Regulatory and Accessibility Issues

In some Gulf markets, proper Arabic support is becoming a regulatory requirement. Getting it wrong isn't just bad UX, it's potential legal liability.

The DARB Standard

We don't build websites in one direction and flip them.

We design bilingual systems from the start.

Our process:

Week 1: Typographic foundation

• Select and test Latin and Arabic typeface pairings

• Establish scale and spacing rules for both scripts

• Design lockups and text treatments that work in both directions

Week 2: Layout exploration

• Design key pages in English and Arabic simultaneously, not sequentially

• Test grid systems in both directions

• Identify elements that need special treatment when flipped

Week 3: Component building

• Build all UI components to work bidirectionally from the start

• Test animations in both directions during development

• Ensure interactive elements feel natural in both LTR and RTL

Week 4: Integration and testing

• Implement language switching mechanism

• Test across devices and browsers in both directions

• Have native Arabic speakers review for UX and cultural issues

Result: Websites that feel equally crafted in both languages, not like one is the original and one is the translation.

Building a bilingual website that actually works in both directions? Let's design a system that respects both languages equally. Get in touch with DARB.