An Arabic travel booking website is not a translation

An agency in Jeddah turns the Arabic toggle on, looks at its homepage, and decides the job is done. Two weeks later a customer forwards a fare link to her sister on WhatsApp and it arrives as a wall of percent signs. Someone else calls because the total appeared on what she considered the wrong side of the price. A third books Riyadh–Dubai for the wrong day, because the date picker started its week on Monday. None of those is a translation bug. An Arabic travel booking website is a layout, a number system and a URL scheme before it is a set of strings — and the strings get done first, because the strings are the part you can see in a screenshot.

Here is what actually changes, roughly in the order agencies hit it.

RTL is a layout decision, not a text direction

Setting dir="rtl" mirrors the page. Navigation moves right, the filter rail moves left, paragraphs align right. That part is close to free. The expensive part is everything that must not mirror.

Flight times do not mirror: 07:45 is 07:45. An itinerary strip that reads DXB to CAI still has to read as a route in that order inside a right-to-left paragraph, because the departure airport is the departure airport whichever way the sentence runs. Airline codes, PNRs and e-ticket numbers are Latin strings dropped into Arabic sentences, and if they are not isolated the browser's bidirectional algorithm reorders the punctuation around them — a record locator followed by a full stop can render with the stop at the wrong end, which looks to a customer like a typo in their booking reference. Your logo does not mirror. A play triangle does not mirror. A back arrow does.

Then the things nobody lists until a customer mentions one: the order of the currency symbol and its number, the progress stepper across the booking funnel, the seat map, the direction a carousel advances, which side of a results row the airline logo sits on, and which edge a wide fare table scrolls from. Every one of those is a decision. None of them is a flag you set.

Numerals, dates, and the calendar your customer is actually holding

Arabic is written with two sets of digits that are both in ordinary use, and travel is full of digits: fares, times, durations, baggage allowances, card fields, OTP codes. Which set your market reads is a question to answer once, with your own customers, and then apply without exception. The visible failure is not picking the less common one. It is mixing them — a price in one set and a departure time in the other on the same results card — which reads as a half-finished site.

Dates carry more assumptions than digits do. A week that starts on Monday is wrong for a customer whose week starts on Sunday, and a calendar that begins on the wrong day causes exactly one kind of mistake: a booking one column out. A customer planning Umrah is working from a Hijri month, not a Gregorian one, and showing the Hijri date beside the Gregorian on the date picker and the itinerary costs you nothing and saves a phone call. Showing it everywhere, on a Frankfurt business trip, is noise.

What an Arabic travel booking website has to get right

The gap between a translated site and a localised one is surface by surface, not global. This is the list worth arguing with your developer about:

The name row is the one that costs real money, and it is the row most often wrong. A traveller types their name in Arabic because the form invited them to, the ticket is issued against that string, and it does not match the passport the airline checks. Everything downstream — the reissue, the argument, the refund — lands on you and not on the carrier.

The typeface row is cheaper than it looks. On this platform the theme, including fonts, colours and logo, is swappable from the admin panel without a redeploy, so trying a different Arabic face against your own fare table is an afternoon rather than a release. The currency row is its own subject; we went through it in multi-currency pricing and where the margin leaks.

Slugs, and what survives a WhatsApp paste

An Arabic slug renders beautifully in the address bar and is made of the words people actually type into a search box. Copied into a plain-text field it percent-encodes and inflates several times over, and what your customer forwards looks like machine output. A Latin transliteration pastes cleanly and is unreadable to everybody — it matches nothing an Arabic reader searches for and nothing an English reader does either.

Split the decision by what the URL is for. A content page lives or dies on search, so give it the native-script slug; the encoded form only appears when somebody copies it, and the page it lands on is correct either way. A booking deep link — a search result, a held fare, a quote to a sub-agent — is never going to be pretty, because it is carrying dates and passenger counts in the query string anyway. Give that one a short link and let it stay short.

The rule underneath both: one canonical URL per page per language. Publishing the same article at an Arabic slug and a transliterated one splits whatever that page earns between two addresses and leaves you maintaining both.

hreflang, or your Arabic page competes with your English one

Two language versions of one page are not two pages. If a crawler cannot tell that, the most common outcome is not a penalty — it is that one version is chosen and the other is treated as a near-duplicate and quietly dropped.

Four things keep them apart. Each language needs its own URL, which rules out one address with a JavaScript toggle. Every version lists every language including itself, because a set that does not point back at itself is discarded whole. Each page's canonical points at itself, not at the English original — Arabic pages canonicalised to English is the single fastest way to have no Arabic pages indexed at all. And x-default goes to whatever you want a reader with no match to land on.

Resist splitting into ar-AE and ar-SA unless those pages genuinely differ — different currency, different phone number, different inventory. Two regional variants of identical copy is two pages competing for the same query with your own name on both.

What it costs you when this is wrong

The abandonment does not happen on the homepage. It happens at passenger details, which is the most expensive place in the funnel to lose somebody: they have already searched, chosen, seen the price and agreed to it, and you have already paid for the search that got them there.

The rest of the cost is quieter. Every confused caller is a staff minute you went online to save. Every name mismatch is a reissue and a customer who blames you rather than the airline. And an Arabic page that never gets indexed is an article you paid to write that nobody can find — the only category of failure that produces no complaints at all, which is why it can run for a year.

Where to start

If Arabic is your second market, the work is a retrofit and the table above is your punch list. If it is your first, the order inverts: choose the digit set and the Arabic face before the colour scheme, build the passenger form against a real passport, and treat English as the translation.

Either way the cheapest test is a real storefront in front of one real customer. The wizard at create a travel website provisions a branded site on a platform subdomain from the form itself and does not ask for a card; the storefront ships in 40 languages, Arabic, Farsi, Hebrew and Urdu among them, with your own domain attachable later. If you are still deciding whether to build the engine yourself, that argument is laid out here — but do it in Arabic before you decide, because the RTL work is the part in-house estimates leave out.