Build RTL Interfaces Without Patching the Design Later

RTL starts with the page structure

Set the language and writing direction at the document level instead of trying to reproduce RTL behavior with CSS alone. But an RTL page does not mean every piece of content inside it should also be RTL. Code, terminal commands, file paths, email addresses, URLs, and other technical content often need to remain left-to-right. Direction should follow the content, not simply the page around it.

<html lang="ar" dir="rtl">
  <body>
    ...
  </body>
</html>

<html lang="en" dir="ltr">
  <body>
    ...
  </body>
</html>

<pre dir="ltr">npm run dev</pre>

<span dir="ltr">
  src/components/Navbar.tsx
</span>

Use CSS that works in both directions

Avoid building reusable components around assumptions such as left and right when what you really mean is the beginning or end of an element. CSS Logical Properties make this much easier. The same component can then adapt naturally to Arabic and English instead of maintaining separate layout rules for every locale.

• margin-inline-start
• margin-inline-end
• padding-inline-start
• border-inline-end
• inset-inline-start

.card {
  padding-inline: 1.5rem;
}

.icon {
  margin-inline-end: 0.5rem;
}

Design for Arabic and English appearing together

Real Arabic products rarely contain Arabic alone. Interfaces constantly mix scripts and directions. For example: تم تحديث الملف src/app/page.tsx بنجاح. Or: Run npm run build and try again. Or: تم إرسال الرسالة إلى ahmed@example.com. These combinations expose direction problems much faster than testing with clean paragraphs of Arabic text. URLs, email addresses, code, commands, filenames, and file paths may need their own LTR direction inside an RTL interface. The goal is not to force everything into RTL. The goal is to let every type of content appear in the direction that makes it readable.

<code dir="ltr">src/app/page.tsx</code>

<code dir="ltr">npm run build</code>

<a href="mailto:ahmed@example.com" dir="ltr">ahmed@example.com</a>

Do not mirror every component

RTL does not mean flipping the entire interface horizontally. Some elements communicate movement or navigation. A back arrow, previous button, or directional chevron may need to change direction. Other elements should normally remain unchanged. A logo does not become mirrored because the language changed. Neither does a search icon, GitHub logo, play button, or many types of charts. For each component, ask: Is direction part of what this element means? If it is not, there may be no reason to mirror it.

• navigation
• breadcrumbs
• forms
• tables
• dropdowns
• modals
• sidebars
• icons

Form direction should follow the data

An Arabic form can contain several different types of content at the same time. A person's name may be Arabic. Their email is likely LTR. A phone number, password, OTP code, or URL may need different behavior again. Do not give every field the same direction simply because the overall form is RTL. Check the position of icons, placeholders, validation messages, select controls, checkboxes, password toggles, and OTP inputs. Forms are also one of the places where weak RTL support becomes especially obvious on mobile.

<input type="email" dir="ltr" />

Arabic typography changes the layout

Arabic typography is not just an aesthetic choice. Font metrics affect line height, heading length, button height, spacing, and how much content fits inside a component. A layout that looks balanced with short English labels may become cramped once the real Arabic text is inserted. Test long headings, small labels, error messages, buttons, navigation items, and English technical terms inside Arabic sentences. Do not leave Arabic typography testing until the end of development.

Mobile is part of RTL testing

A desktop layout can hide many direction problems. Narrow screens reveal them quickly. Check navigation menus, sidebars, dialogs, dropdowns, tables, forms, long filenames, URLs, and code blocks on mobile. Fixed-width technical content should be able to scroll when needed. Test both RTL and LTR versions at narrow widths instead of assuming a responsive English component will automatically behave correctly in Arabic.

pre {
  overflow-x: auto;
}

How Nuwat fits into RTL development

RTL requirements are often easier to describe naturally than to turn into a carefully engineered English prompt. Nuwat is designed to interpret this kind of mixed Arabic and technical language and add relevant Arabic web and RTL context before the coding agent starts making changes in the project. You describe what the interface should do. Nuwat prepares the context. The coding model works on the implementation.

• خل الـ dashboard RTL، وخلي الـ sidebar على اليمين، بس خلي chart والكود والـ email ظاهرين LTR.
• راجع صفحة التسجيل بالعربي وتأكد إن الـ form والـ validation messages شغالة صح على الموبايل.
• سو navbar يشتغل بالعربي والإنجليزي واستخدم logical properties بدل left وright.

Want the deeper technical guide?

This page covers the main principles behind building RTL interfaces. For a deeper technical walkthrough covering logical CSS properties, mixed-direction text, forms, navigation, sidebars, breadcrumbs, testing, accessibility, and SEO:

Does RTL mean mirroring everything?

No. Arabic text and layout generally follow RTL direction, while code, URLs, email addresses, file paths, and some other content should remain LTR. Icons should only be mirrored when their direction contributes to their meaning.

When should I use CSS Logical Properties?

Use logical properties when you mean the start or end of an element rather than a fixed physical side. They make it easier for the same component to support both RTL and LTR layouts.

Can Nuwat work on an existing RTL project?

Yes. You can ask Nuwat to review an existing page or component, convert a layout to RTL, fix direction problems, or inspect related components without rebuilding the project from scratch.

Good RTL should not look mirrored

A well-designed RTL interface should not feel like an English website that was flipped at the end. Direction, mixed content, typography, components, and mobile behavior should feel like they were considered from the beginning. RTL is not a final patch. It is part of the product architecture.