Skip to main content

Blog

Building Arabic and Urdu Support in Flutter: A Right-to-Left Checklist

Translating strings is the easy part. A practical checklist for right-to-left Flutter apps — directional layouts, icons that should and should not mirror, mixed-direction text, numbers, plurals, Urdu fonts and store listings.

By Muhammad Akash Hameed, Founder7 min read

Launching in Arabic or Urdu opens markets across the Gulf, the wider Middle East and South Asia. It is also where a lot of multilingual apps quietly break, because right-to-left support is not a translation task. The whole interface mirrors, and every place the code assumed “left” is now wrong.

Flutter handles more of this for you than most frameworks, which makes it easy to assume the job is done when it is about 70% done. Leklok ships in 15 locales, including Arabic and Urdu, so this is the checklist we work through rather than a theoretical one.

Start with the framework’s defaults

Add flutter_localizations, declare your supportedLocales, and register the localization delegates on your MaterialApp or CupertinoApp. Once a right-to-left locale is active, Flutter sets the text direction for the whole widget tree: rows lay out from the right, the back button moves to the right, drawers open from the other side, and sliders and progress bars run the other way.

Keep your strings in ARB files and generate the localization classes, rather than hand-rolling a map of strings. You will want ICU message syntax for plurals and placeholders before long.

Replace left and right with start and end

Everything that hard-codes a side ignores the text direction. The fix is mechanical but needs to be done everywhere:

Instead ofUse
EdgeInsets.only(left: 16)EdgeInsetsDirectional.only(start: 16)
Alignment.centerLeftAlignmentDirectional.centerStart
Positioned(left: 0)PositionedDirectional(start: 0)
BorderRadius.only(topLeft: …)BorderRadiusDirectional.only(topStart: …)
TextAlign.leftTextAlign.start

A search for left:, right:, Left and Right across the codebase finds most offenders. Adding a lint or a code-review rule for new code stops them coming back. Doing this from the first screen costs almost nothing; retrofitting it across an app with hundreds of screens is a project.

Decide which icons mirror

Icons that imply direction should flip: back and forward arrows, chevrons in list rows, “send” arrows, undo and redo, anything that points along the reading direction. Many Material icons, including the standard back arrow, already mirror automatically. Your own icons and images will not — use matchTextDirection: true on Image and icon widgets that should flip.

Icons that represent real-world objects should not flip: a clock still runs clockwise, a checkmark is still a checkmark, logos never mirror, and media playback controls such as play and fast-forward keep their usual direction because they describe the media’s timeline, not the layout. Mirroring everything is as wrong as mirroring nothing.

Handle mixed-direction text

Real content is rarely all one direction. An Arabic sentence containing an English brand name, a URL, a username, an email address or a phone number is bidirectional text, and without help the Unicode bidi algorithm will sometimes reorder punctuation and numbers in ways that look broken.

  • Inputs that are always left-to-right — phone numbers, email addresses, verification codes, URLs, card numbers — should set textDirection: TextDirection.ltr explicitly, regardless of the app’s locale.
  • User-generated text in a chat or feed should take its direction from its own content, not from the app’s locale. An English message in an Arabic interface should still read left-to-right.
  • Interpolated values inside translated strings, such as a username dropped into an Arabic sentence, can be wrapped in Unicode directional isolates so they do not drag the surrounding punctuation around.

Numbers, dates and plurals

Use intl for numbers, dates and currency, with the active locale, rather than formatting by hand. Then make a deliberate decision about digits: Arabic text may use Eastern Arabic numerals (٠١٢٣) or Western digits depending on the country and the context, and what intl produces depends on the exact locale you pass. Check the output with native speakers from your target market rather than assuming.

Plurals are a bigger trap than they look. English has two plural forms; Arabic has six — zero, one, two, few, many and other. Any string built as “count + noun + s” will be wrong. Use ICU plural syntax in your ARB files and give translators every form the language needs.

Fonts: Urdu needs room

Arabic usually renders well with the platform’s fonts or a font such as Noto Sans Arabic. Urdu is traditionally written in Nastaliq, a calligraphic style that slopes diagonally and has much taller ascenders and deeper descenders than Latin text. Readers notice when Urdu is shown in an Arabic Naskh style instead.

Nastaliq needs more line height than your Latin typography. Text inside fixed-height containers, buttons, chips and single-line fields gets clipped top and bottom. Bundle the font you intend to use, set per-locale line heights, and check every fixed-height component with real Urdu strings.

Translated strings also change length. Some Arabic strings are shorter than English, many Urdu ones are longer. Avoid layouts that only work at one text length.

Gestures and motion

Swipe directions should follow reading order: a carousel or onboarding flow should advance in the reading direction, and “swipe to go back” comes from the start edge. Slide-in animations defined with hard-coded positive or negative offsets will move the wrong way. Check every custom transition, not just the built-in ones.

Test in right-to-left all the time, not at the end

  • Keep an RTL locale in your daily development rotation so problems surface as they are written.
  • Add golden tests for key screens in both directions.
  • Test with real translated strings, not English text forced into RTL — length, script and line height all matter.
  • Have native speakers review the running app, not a spreadsheet of strings. Context changes translations.

Do not forget the store

Your store presence should speak the language too: localized app names where it makes sense, descriptions, keywords and screenshots showing the right-to-left interface. Translated store listings are part of how people find the app — an Arabic-speaking user searching in Arabic will not find an English-only listing. That is also where App Store Optimization work for these markets starts.

Build it in from the first screen

Right-to-left support costs very little when it is a habit from day one and a great deal when it is retrofitted. If you are planning to launch in the Gulf, the Middle East or South Asia, tell your team before the first screen is built. It is a standard part of how we approach mobile app development and UI/UX design — mirrored layouts and iconography, not just swapped strings.

Frequently asked questions

Does Flutter support right-to-left languages?
Yes. With flutter_localizations configured, Flutter sets the text direction from the active locale and mirrors built-in widgets automatically. You still need to use directional layout classes, decide which custom icons mirror, and handle mixed-direction text yourself.
Which icons should be mirrored in a right-to-left app?
Icons that point along the reading direction, such as back and forward arrows, chevrons and send buttons. Icons representing real-world objects, logos, checkmarks, clocks and media playback controls should not be mirrored.
Why does Urdu text get cut off in my app?
Urdu is usually set in Nastaliq, which has much taller ascenders and deeper descenders than Latin scripts. Fixed-height containers and default line heights clip it. Use a proper Nastaliq font, increase line height for the Urdu locale and avoid fixed text heights.
How many plural forms does Arabic have?
Six: zero, one, two, few, many and other. Use ICU plural syntax in your localization files so translators can supply each form, rather than building plurals by adding an “s”.

Ready to scope your MVP? Get in touch or explore our portfolio, or grab the free MVP scoping checklist.

Ready to build something remarkable?

Book a free 20-minute scoping call. We'll review your idea, share relevant case studies, and outline a realistic timeline.

Reply within 24 hours · No commitment required