Multilingual Booking Engine
The booking engine is the last screen between a guest and a direct reservation — and the one most likely to be in the wrong language. Here is how language and currency should work, and where hotels get it wrong.
Why the Booking Engine Is the Page That Must Be Translated
Hotels translate their marketing pages and leave the booking engine in English. That is backwards. A guest browsing your rooms in a second language is doing something low-stakes; a guest entering card details, reading a cancellation policy and confirming a non-refundable rate is not. The booking flow is where uncertainty kills the conversion, and uncertainty is exactly what a foreign language creates.
The OTAs understood this early and it is a real part of why they convert so well. A guest arriving on Booking.com sees their own language and, usually, their own currency, on every screen through to confirmation. If your direct site drops them into English at the payment step, you have handed the booking back to the channel charging you commission.
Where Language Actually Has to Reach
- The room and rate names, not just the page furniture. "Deluxe Double — Non-refundable" is the part the guest is deciding on.
- The cancellation and prepayment policy. This is the highest-anxiety text on the page and the one most often left untranslated.
- Date formats and number formats. 09/12 means two different dates depending on where the guest is from, and getting it wrong on a booking is expensive.
- Plural rules. "1 night" versus "2 nights" is trivial in English and genuinely complex in Russian, Arabic and Lithuanian, where a naive implementation produces text that reads as broken.
- The confirmation screen and email. A guest who cannot read their own confirmation contacts the hotel, which costs you the staff time the automation was meant to save.
How Language Should Be Detected
In a defined order, with the guest always able to override.
- An explicit link parameter first. A hotel linking from a Spanish-language page of its own site should be able to pass the language directly, so the guest never sees a wrong-language flash.
- A cookie set by the hotel’s own website next, so a guest who already chose a language on your site keeps it when the booking engine loads.
- The returning visitor’s stored preference after that, so a repeat guest gets what they picked last time.
- The browser’s own language preference as the general fallback. This is right far more often than IP-based guessing, which mistakes travellers for locals constantly.
- English as the final fallback, and a visible language switcher regardless — detection is a convenience, never a cage.
A note on IP-based detection: it is the approach that feels cleverest and performs worst. A German guest booking from a Bangkok hotel lobby is not a Thai speaker, and a guest on a VPN is nobody at all. Browser language is a statement of preference; an IP address is a guess about location.
Display Currency Is Not Charge Currency
The distinction that prevents most currency complaints.
A guest wants to see prices in a currency they can judge. The hotel needs to be paid in its own. These are two different things and conflating them causes real problems — a guest who believes they were charged in their own currency, then sees a different figure on their statement, raises a dispute.
The safe pattern is to let the guest switch the display currency for comparison, while the booking is always charged in the hotel’s currency, clearly stated at the payment step. The converted figure is an indication; the charge is the truth. Say so on the page rather than leaving the guest to discover it.
This also avoids the trap of holding rates in multiple currencies, which quietly creates a pricing-consistency problem the moment exchange rates move. One charge currency, many display currencies, one source of truth for the rate.
The 15 Languages Frontdesko Supports
The set covers the global web majors plus the home languages of the markets our properties actually sell into: English, Spanish, Chinese, Hindi, Arabic, Portuguese, French, Russian, German, Japanese, Indonesian, Italian, Thai, Lithuanian and Filipino.
Lithuanian and Filipino are there for a specific reason worth explaining: they were the founding pair, added because real properties needed them, not because a market-size spreadsheet suggested them. That is generally the right way to choose — a language your actual guests read beats a language with a large speaker count you never sell to.
Translations are loaded only when a guest needs them, so adding languages does not slow the booking page down for anyone. Plural rules follow each language’s own grammar rather than English’s two-form assumption, which is what keeps night counts and guest counts reading naturally in Russian, Arabic and Lithuanian.
The booking engine is free forever with the Frontdesko PMS, including every language and the display-currency switcher, with no commission on direct bookings.
Frequently Asked Questions
Why does a hotel booking engine need multiple languages?
Because the booking flow is where a guest commits money, and uncertainty at that moment is what loses the booking. Guests will browse rooms in a second language but hesitate at a cancellation policy or a non-refundable rate they cannot read precisely. OTAs present the whole flow in the guest’s language, so a direct site that switches to English at payment hands the booking back to the commission channel.
How should a booking engine detect a guest’s language?
In order: an explicit link parameter, then a cookie set by the hotel’s own website, then the returning visitor’s stored preference, then the browser’s language setting, with English as the final fallback. A visible switcher should always be available. Avoid IP-based detection — a German guest booking from a Bangkok lobby is not a Thai speaker.
What is the difference between display currency and charge currency?
Display currency is what the guest sees so they can judge the price; charge currency is what the card is actually billed in, which stays the hotel’s own. Keeping them separate avoids disputes from guests who believed they were charged in their currency, and avoids the pricing-consistency problem that comes from holding rates in several currencies as exchange rates move.
Which languages does the Frontdesko booking engine support?
Fifteen: English, Spanish, Chinese, Hindi, Arabic, Portuguese, French, Russian, German, Japanese, Indonesian, Italian, Thai, Lithuanian and Filipino. The set combines the global web majors with the home languages of the markets our properties sell into. All are included free with the PMS.
Does adding languages slow down the booking page?
Not if translations are loaded on demand rather than bundled together. Each language is fetched only when a guest actually needs it, so a guest booking in English never downloads the Japanese or Arabic text. A booking engine that ships every language to every visitor will feel slow, which costs more conversions than the translations gain.
Why do plural rules matter in a booking engine?
Because English has only two forms — one night, two nights — and many languages do not. Russian, Arabic and Lithuanian have several plural forms selected by the number itself, so an implementation assuming English grammar produces text that reads as visibly broken at exactly the moment a guest is deciding whether to trust the page with a card number.
Let Guests Book in Their Own Language
Fifteen languages, guest-selectable display currencies and a charge currency that stays yours — in a direct booking engine that is free forever and takes no commission.
Related Guides
Winning the direct booking
Hotel Booking Engine
The commission-free direct booking widget for your own website.
Learn More →Increase Direct Bookings
The levers that shift share to your own site without a price war.
Learn More →Direct Booking vs OTA Costs
What each OTA reservation really costs once commission is counted.
Learn More →