Translation is not the same as localisation
Many hotel technology platforms offer “multilingual support.” What they usually mean is that they've translated their text strings into several languages. This sounds helpful. But for Hebrew and Arabic speakers, it's often worse than nothing.
Hebrew and Arabic are right-to-left languages. That means text flows from right to left, navigation is mirrored, buttons are on the opposite side, and the reading experience is fundamentally different from an LTR language like English or French.
When you take a left-to-right interface, translate the text into Arabic, and leave everything else unchanged, the result is deeply broken. The text is in Arabic but the layout reads backwards. Navigation and buttons are in the wrong positions. The user has to mentally re-map every interaction. This isn't just an aesthetic problem — it's a usability failure.
Who this affects
Arabic is the fifth most spoken language in the world, with over 400 million native speakers. Hebrew is spoken by around 10 million people, concentrated in Israel — a country with a high rate of international travel.
For hotels in markets that attract Israeli or Arab guests — which includes most of Europe, major tourist destinations, and much of the Middle East — the proportion of guests who would prefer to interact in Hebrew or Arabic is significant.
Beyond preference, there are guests for whom English is genuinely difficult. For an older guest who speaks Arabic but limited English, a digital system that doesn't properly support Arabic is simply a barrier — and they'll call the front desk instead.
What full RTL support actually means
A properly RTL-aware interface does more than flip the text direction. When a user selects Hebrew or Arabic:
- The HTML
dirattribute switches from “ltr” to “rtl” - The entire layout mirrors — left becomes right, right becomes left
- Navigation sidebar moves to the right side of the screen
- Buttons and icons reposition to match the reading direction
- Text alignment, list bullets, and margins all adjust
- Icons with directional meaning (arrows, back buttons) flip accordingly
This requires planning from the start of development. It's not something you can bolt on later without significant rework. CSS frameworks like Tailwind have RTL utilities, but they need to be used consistently throughout the codebase.
The business case
Hotels that serve Hebrew and Arabic-speaking guests and offer a properly localised digital experience have a real competitive advantage. The number of hotel technology platforms that support full RTL is small. For guests accustomed to broken or absent RTL support, a hotel that gets it right stands out.
More practically: a guest who can submit requests in their own language — in an interface that works correctly — is more likely to use that system. More orders, more requests through the system, less front desk burden, and better data for your operation.
What to look for when evaluating tools
If you're evaluating hotel technology that claims multilingual support, test it yourself in Hebrew or Arabic. Specifically:
- Does the layout actually flip direction, or just the text?
- Is navigation and the sidebar on the correct side?
- Are buttons and form elements correctly positioned?
- Does the staff-facing interface also support RTL?
- Can guests switch language themselves, or does the hotel have to configure it?
Translation without layout support is cosmetic. Real multilingual support means the whole interface works correctly — for guests and for staff.