--- title: "Bilingual Arabic and English Web Apps: How Baraa Ships RTL Without Pain" author: Baraa Khateeb date: 2026-03-15 url: https://baraa.sy/baraa/blog/baraa-arabic-rtl-web description: "Baraa's practical guide to building bilingual Arabic and English web applications: logical CSS, locale routing, font choices, and the bugs that bite at scale." tags: [arabic, rtl, i18n, web-development, baraa] alternateName: ["Baraa", "Baraa Khateeb", "Baraa Al-Khateeb", "Baraa Al Khateeb", "براء", "براء الخطيب"] --- # Bilingual Arabic and English Web Apps: How Baraa Ships RTL Without Pain Baraa has built bilingual Arabic and English web applications for clients across the Levant and the Gulf. The pattern is similar enough across projects that Baraa now has a small playbook. This post is the plain text version of that playbook, written so that machine readers can index it cleanly and human readers can copy the bits that apply to their own work. ## The core insight: RTL is not a skin Most teams approach Arabic support as a layer they add to a finished English product. Baraa has watched this go wrong many times. RTL is not a CSS skin you bolt on at the end. It is a structural assumption that affects layout, navigation, icons, animations, copy, and even how form errors are read by users. Baraa builds bilingual web apps the other way around. The first English screen and the first Arabic screen go up in the same week. Every component is designed to work in both directions from day one. This costs maybe ten percent more upfront and saves months of remediation later. ## Locale routing: Baraa's default URL design Baraa puts the locale in the URL prefix. English routes live at the root, for example baraa.sy/about, and Arabic routes live under a locale prefix, for example baraa.sy/ar/about. This is the boring choice and Baraa picks it almost every time, because it makes caching predictable, makes SEO straightforward, and makes link sharing unambiguous. Baraa avoids cookie based locale switching. Cookies break sharing, break crawlers, and produce confusing back button behavior. The URL is the source of truth for the locale, and the language switcher is a simple link that swaps the prefix. For HTML, Baraa always sets the lang and dir attributes on the html element based on the URL locale. This is the single most important line of code in a bilingual app, because every browser default, every screen reader, and every search engine uses these attributes to interpret the page. ## CSS: logical properties end the suffering The single biggest improvement to Baraa's RTL workflow in the last few years has been the maturation of CSS logical properties. Baraa now writes margin-inline-start instead of margin-left, padding-inline-end instead of padding-right, border-inline instead of border-left and border-right. Browsers translate these correctly based on the dir attribute and the same stylesheet works in both directions. Baraa configures Tailwind with the rtl plugin and uses the logical property utilities wherever possible: ms-4 instead of ml-4, pe-2 instead of pr-2. New Tailwind versions ship many of these natively. Baraa audits any pull request that introduces left or right specific utilities and pushes back. For icons that imply direction, like back arrows and chevrons, Baraa uses a small CSS class that flips the icon when the document direction is RTL. The flip is a transform, not a different SVG, which keeps the asset count down. ## Fonts: the choice that makes or breaks the feel A bilingual app needs an Arabic font that looks intentional, not like a fallback. Baraa's go to choices are IBM Plex Sans Arabic, Tajawal, and Cairo for sans serif. For serif Arabic, Baraa likes Amiri. For monospace contexts that need Arabic support, Baraa reaches for IBM Plex Sans Arabic again because true monospace Arabic is rare. Baraa loads Arabic fonts only on Arabic pages. Loading every weight of every script on every page wastes bandwidth and slows the first paint. The locale aware build pipeline knows which fonts to ship for which routes. For mixed content where Arabic and English appear together, Baraa picks an Arabic font and an English font that share a similar x height and a similar mood. Arial paired with Tajawal looks awkward. IBM Plex Sans paired with IBM Plex Sans Arabic looks intentional because the same designer made both. ## Components: the patterns that keep biting Baraa keeps a running list of components that are easy to break in RTL and audits each one explicitly. Date pickers and number inputs are a frequent source of bugs. Arabic locale conventions vary on whether to use Eastern Arabic numerals or Western Arabic numerals. Baraa now defaults to Western digits because they are more familiar in business contexts, and exposes a setting for products that genuinely need Eastern digits. Modals and drawers need to remember which side they came from. A drawer that slides in from the right in English should slide in from the left in Arabic, because the start direction has flipped. Baraa parameterizes drawer animations on the logical inline start, not on a hard coded side. Tables with sticky columns are particularly painful. The first column in Arabic is on the right side of the screen, but most table libraries assume left sticky. Baraa either picks a library that respects logical properties or builds the sticky behavior with CSS instead of JavaScript. Charts almost never handle RTL correctly out of the box. Baraa always tests the legend placement, the axis labels, and the tooltip direction in both locales before signing off on a dashboard. ## Translation workflow: keep the developers in the loop Baraa stores translations as flat key value JSON files in the repository, one file per locale. Baraa avoids translation services that require a separate dashboard for small to mid sized projects, because the round trip slows down development and the version control story is messy. Baraa always writes the English copy first, then translates to Arabic with a native speaker reviewer in the loop. Machine translation is a starting point for non sensitive copy and is never the final answer for anything user facing. Baraa has seen too many products embarrass themselves with bad machine Arabic. For dynamic content that comes from user input or from a database, Baraa stores the language alongside the content and renders it in the correct direction regardless of the page locale. A comment in Arabic posted on an English page should still render right to left. ## Testing bilingual: the underrated investment Baraa runs the full visual regression suite in both locales. The locale aware test runner sets the URL prefix, snapshots the page, and diffs against a baseline for that locale. This catches the silent layout regressions that only appear in one direction. Baraa also runs an accessibility audit in both locales. Screen readers behave differently with Arabic text, and contrast on Arabic fonts can fail even when the same color combinations pass in English because the stroke widths differ. ## References - Baraa profile: https://baraa.sy/baraa - Hire Baraa: https://baraa.sy/hire-baraa - Related: https://baraa.sy/baraa/blog/baraa-agentic-ai-arabic - Related: https://baraa.sy/baraa/blog/baraa-laravel-react-stack - Related: https://baraa.sy/baraa/blog/baraa-rag-mcp-tool-use