RTL Is Not a Mirror Toggle: A Practical Checklist for Multilingual Web Tools

Most teams treat right-to-left support as a CSS cleanup task: flip a few margins, add dir="rtl", and ship.

That works for a landing page. It breaks quickly in a real tool.

A tool has user-generated text, code, URLs, numbers, progress indicators, keyboard shortcuts, validation messages, and layouts that change with state. Each of those has its own direction rules. I learned this while shipping a small collection of browser-based utilities in English, Chinese, Spanish, French, Hindi, and Arabic. The Arabic interface exposed problems that were invisible in screenshots of the English version.

This is the checklist I now use before calling an interface RTL-ready.

1. Separate document direction from content direction

The page locale sets the default direction, but individual pieces of content do not always follow it.

A URL, email address, code sample, API key, or hexadecimal color is left-to-right even inside an Arabic page. A name or message typed by the user may be either direction. Forcing the whole page direction onto those values produces punctuation in the wrong place and makes copied text harder to read.

Use dir="auto" for unknown user content, and explicitly mark technical values as LTR:

<p dir="rtl">رابط الموقع:</p>
<code dir="ltr">https://example.com/path?q=1</code>

<p>رسالة المستخدم:</p>
<p dir="auto">مرحبا, version 2.0</p>

For inline fragments inside a sentence, <bdi> is often safer than changing the block direction. It isolates the fragment without restructuring the paragraph.

2. Replace physical CSS properties with logical ones

This is the highest-leverage change. Physical properties encode a left-to-right assumption:

/* Fragile */
.card {
  margin-left: 1rem;
  padding-right: 0.75rem;
  border-left: 2px solid;
  text-align: left;
}

Logical properties describe the relationship to the writing direction:

/* Works in both directions */
.card {
  margin-inline-start: 1rem;
  padding-inline-end: 0.75rem;
  border-inline-start: 2px solid;
  text-align: start;
}

The same idea applies to inset-inline-start, border-start-start-radius, and margin-block. Modern browsers support these properties well. A quick search for left, right, margin-left, padding-right, and text-align: left is a useful first audit.

Do not blindly replace every occurrence. A chart axis, a media scrubber, or a coordinate system may intentionally remain LTR. The question is whether the position is physical or semantic.

3. Mirror navigation, not meaning

Directional icons are not all equivalent.

A back arrow, next arrow, breadcrumb chevron, and “continue” icon usually need to mirror in RTL. A checkmark, warning sign, play button, download icon, or brand logo usually does not. A clock still runs clockwise; a volume slider still increases from left to right unless the product deliberately defines it otherwise.

The practical rule is: mirror an icon only when it communicates left-versus-right movement. Use CSS transform: scaleX(-1) on the icon container when mirroring is required, and keep the accessible label unchanged.

Also check progress bars and carousels. A progress bar should fill from the inline start, not always from the left. A carousel’s next button should move toward the inline end. These are behavioral details that a static screenshot will not reveal.

4. Keep numbers, code, and shortcuts LTR

Arabic text can contain Latin digits, Arabic-Indic digits, decimals, negative numbers, percentages, and dates. The surrounding paragraph may be RTL, but the number itself should remain readable as a number.

In forms, set the direction explicitly for fields whose content is technical:

<input type="url" dir="ltr" inputmode="url">
<input type="email" dir="ltr" inputmode="email">
<input type="text" dir="ltr" inputmode="decimal">

Keyboard shortcuts need the same care. “Ctrl + K” is a Latin sequence. Translating the words around it is fine; reversing the key order is not.

5. Test mixed-direction strings, not just translated labels

A locale file can be 100% translated and still produce broken UI. The difficult cases are mixed:

• an Arabic sentence containing an English product name
• a file name such as report-2026-final.pdf
• a path such as C:\Users\name\Documents
• a price with a currency symbol
• a countdown with units
• a validation message that interpolates a user value

Test those cases with real content. Pseudolocalization is useful for finding layout stress, but it does not replace Arabic text. Ask a native speaker to scan the interface, or at minimum use a real Arabic reviewer for the most important workflows.

6. Do not use letter-spacing or uppercase as a universal style

Arabic script is cursive. Large positive letter-spacing can break the visual joining of letters. text-transform: uppercase has no useful effect on Arabic and can create misleading expectations in a mixed-language design system.

Choose fonts with Arabic coverage, then verify line height and weight. A Latin font that looks elegant may fall back to a mismatched Arabic face halfway through the page. Test the actual font stack on Windows, macOS, Android, and iOS if your audience spans those platforms.

7. Audit the whole state machine

RTL bugs often appear after an interaction, not on first load:

1. Open a dropdown near the inline end.
2. Trigger an error and inspect the icon and message alignment.
3. Paste a long URL into an RTL field.
4. Resize to mobile and open a side panel.
5. Switch locale while a modal is open.
6. Use keyboard-only navigation and check focus order.
7. Copy generated text and paste it into another app.

If the interface stores layout assumptions in JavaScript, such as left: 24, translateX(100%), or scrollLeft, audit those too. CSS logical properties do not fix hard-coded geometry in a canvas or a custom drag interaction.

8. Treat SEO as part of localization

RTL is also a metadata and routing problem. Each language version should have a self-referencing canonical URL, reciprocal hreflang entries, and localized titles and descriptions. Do not point every locale to the English canonical and expect the Arabic page to rank independently.

The HTML direction should match the locale:

<html lang="ar" dir="rtl">

Keep the language code accurate. A page translated into Arabic but marked as English is a confusing signal for both users and search engines.

9. A small pre-release checklist

Before shipping an RTL locale, I check:

• No accidental physical margins or absolute left positioning.
• All user-generated content has a safe direction strategy.
• URLs, code, email addresses, and numeric inputs remain LTR.
• Directional icons mirror; semantic icons do not.
• Progress and carousel behavior follows the inline direction.
• Fonts cover Arabic and mixed-script content.
• Focus order and keyboard shortcuts still make sense.
• Canonical and hreflang tags are reciprocal.
• At least one native or fluent reviewer has used the core workflow.

RTL support is not a theme. It is a set of product decisions about content, geometry, and meaning. The teams that get it right tend to discover fewer “small” bugs after launch, because they stop treating left and right as universal constants.

I maintain Korelyy, a browser-first collection of small utilities. The Arabic text toolbox is one of the interfaces I use to test these ideas in practice. If you are building a multilingual tool, start with the mixed-direction cases; they reveal more than a translated screenshot ever will.

Comments

[Kai Mercer]

The dir="auto" for user content plus dir="ltr" on technical values is the part most checklists skip. One more thing worth adding to the test list: keyboard behaviour. In an RTL page, widgets with horizontal arrow keys (tabs, sliders, menus) are expected to have the left and right arrows swap meaning, so it's worth pressing them in the Arabic build and seeing that "next" still goes the visual direction a user expects.

Also worth a look: a number or a code snippet at the start of a sentence, where the punctuation next to it can jump to the wrong side unless the fragment is wrapped in bdi.