Is Arabic support just a translation layer?
Most indoor mapping platforms treat Arabic as a language pack: swap the strings, flip the layout, ship it. That holds up in a screenshot and falls apart the moment someone actually uses the map, because right to left changes more than which side the text starts on. It changes typography, how search has to match what people type, and how a page has to be built in the first place. Below is what that took to get right, mistake by mistake, on the way to shipping it.
What changes beyond the direction of the text
Type set correctly for English is not automatically correct for Arabic at the same size. Three corrections apply by direction rather than by component, so a page inherits them rather than every template having to remember:
- Tracking goes back to zero
- Latin display type is set with tight negative tracking. Arabic is a connected script, so the same negative tracking pulls letterforms into each other and degrades the joins.
- More space between lines
- Arabic ascenders and descenders reach further than Latin ones. Headings and body copy both open up their line height so nothing clips or crowds.
- A small size increase
- Arabic reads optically smaller than Latin at the same pixel size. A few percent is enough to match without disturbing the layout.
Why a mirrored layout is not enough
Flipping a layout for right to left mostly works for free, provided every rule is written as a logical direction, start and end, rather than a physical one, left and right. The trap is anything that was written as a physical direction without anyone noticing, because it renders correctly in English and silently breaks in Arabic.
A gradient is the clearest example. A rule that runs a colour from left to right does exactly that regardless of which way the page reads, so on a right to left page it starts at the wrong end. The fix is not automatic. It has to be written as an explicit right to left counterpart, checked page by page, because nothing warns you when one is missing.
Search has to work the way people actually type
Arabic has several accepted ways to write the same sound, and people use them interchangeably: the letter alef alone carries at least four common forms depending on the word. A search box that expects one exact spelling will fail on a query that is not misspelled, just written the way that particular person writes it. Getting this right means normalising those variants before matching, not asking the visitor to spell more carefully.
Arabic also inflects at both ends of a word, so a request and its answer can share no literal characters even though they mean the same thing. Matching on the exact word alone misses results that are sitting right there in the content. A light stemming pass, applied the same way to the query and to the content, closes that gap without needing an exact grammatical match.
None of that helps if the content behind it was only ever entered in one language. A category label typed once in English and never given an Arabic equivalent will not match an Arabic search no matter how good the normalising is. That is a content workflow, not a rendering one, so the map editor treats localising point-of-interest categories as its own step rather than a field a translator fills in after the fact.
Smaller breaks that are easy to miss
None of these fail loudly. Each one only shows up when a page is actually read in Arabic rather than glanced at:
- Heading anchors that go nowhere
- A Latin heading slugs into a readable anchor. An Arabic heading reduces to nothing under the same rule, so every anchor on a translated article needs its own fallback rather than an empty id.
- A font downloaded for four characters
- The language toggle shows the Arabic word for "Arabic" on English pages, which is the right call for anyone scanning for it. It also means an English page can end up downloading an Arabic font subset for those four characters alone, unless the fallback is deliberate.
- A button that fits in one language and wraps in the other
- Arabic strings commonly run longer than their English equivalent. A button sized for "Book a demo" can wrap to two lines the moment the same control is translated, at exactly the width a phone screen uses.
Why this matters more than it looks
Arabic first is not a checkbox on a feature list. It is route instructions that read right to left, search that matches how people actually spell a place, and labels that stay legible on a map viewed at an angle rather than only face on. Vendors built and supported from outside the region tend to treat this as a localisation ticket handled after launch. Getting each of the details above right is what separates a map that was designed for Arabic from one that had Arabic added to it afterwards, and a visitor notices the difference even if they could not name it.
See how this plays out for a specific market in indoor wayfinding in Saudi Arabia or indoor wayfinding in the UAE. Comparing vendors more broadly, read how to choose indoor wayfinding software, or start with indoor wayfinding explained.