Multilingual

Last updated: 2026-08-20

Software answering in many languages is standard equipment by now.

The part that actually counts in daily work is rarely mentioned: what does your front desk do with a conversation it cannot read?

Two languages at once

A guest writes in Italian. Your receptionist speaks German.

Both get what they need. The guest gets their answer in Italian, because anything else would be rude. Your team sees the same conversation in German, because anything else would be useless.

That applies not only to received messages but to the draft that has not been sent yet. A waiting AI reply can be read in German before anybody approves it.

That sounds like a detail and it is the decisive one. Approving a reply you cannot read is not review, it is a click. And it is the one place in the whole system where something goes out in your property's name.

The reading copy stays strictly separate from the sendable text: what goes out is always the version in the guest's language. The translation exists to be read, not to be sent.

The cases too, not just the messages

A ticket comes from what a guest wrote, so it is in the guest's language. A German team receiving a German notification email with an English subject inside it is nobody's idea of help.

So the case is translated once, when it is created, and stored that way. The original text is preserved, so the audit trail still shows what the guest actually wrote.

System-generated cases, with no model on the path at all, come from a fixed catalogue rather than a translation. That is both the cheaper and the more reliable answer, and it is why you do not end up with some of your tickets in German and others in English.

Why a line in the prompt is not enough

This is the most technically honest section on this page.

A guest started in English, switched to German for three messages, and switched back. The reply came in German. Language detection had been right, and the instruction to answer in English was the last line in front of the model. It read that line and wrote German anyway, because three German messages before it weigh more than one sentence in brackets.

A language directive is a request. Five different phrasings failed to fix it, and one that worked six times out of six in testing came back in production.

So today the language is checked after the answer rather than only instructed before it. If it is wrong, the model is asked again before the guest sees anything.

On the email path, where a reply would go out automatically with nobody in the loop, the stricter rule applies: a reply in the wrong language is not sent at all, it is put in front of a person to approve. In chat that would be wrong, because the guest would then be waiting on nobody. Two paths, two answers, the same rule behind them.

The automatic mail too

Booking confirmations, payment requests, reminders.

Those emails used to follow a setting where a missing value silently meant English. Two German properties had exactly that missing value, and a German guest who had booked in German received an English confirmation, with an English legal footer under a booking in Germany.

That is fixed, and it is written here because it is the kind of fault nobody notices until a guest complains.

Limits

It is a translation, not a second edition. The reading copy for your team is machine-generated. It is good enough to decide whether a reply may go out, and it is not the legally binding version of anything.

The original always wins. What the guest wrote is stored as they wrote it. No translation replaces it, not in the audit trail and not in a subject access request under Article 15 GDPR.

The sendable text stays in the guest's language. There is deliberately no way to accidentally send the German reading copy to an Italian guest.

Your knowledge base does not translate itself. What you record as house rules can be written in one language, and the answer drawn from it is produced in the guest's. For wording that matters, it is still better to record it yourself.

The difference

A vendor's language list tells you how many languages their model handles. That list is roughly the same everywhere, because the models are roughly the same everywhere.

What differs is what happens on the evening an Italian complaint arrives and the colleague on the desk speaks no Italian. Whether she can read the conversation. Whether she can see what is about to go out in her name. Whether the ticket makes sense to housekeeping the next morning.

That is not a question about the model. It is a question of whether anybody thought about it.