Three languages on a hotel menu without three menus: one catalog, several views

A guest arriving from another country opens the hotel restaurant menu and finds a translation done years ago, listing a dish that no longer exists and missing one the kitchen just added. The guest who speaks the local language gets the updated menu. Both menus came from the same restaurant, but they tell a different story, and the difference is not cultural: it is that someone translated a document once and the real catalog kept changing without them.

The problem is not translating, it is staying in sync

Translating a menu once is fairly easy. The problem shows up six months later, when the chef changes two dishes, raises a price and adds a vegetarian option, and the local-language menu updates the same day while the English menu stays exactly as it was when it was first translated. Nobody decided to leave it outdated on purpose: nobody simply has the job of keeping three documents in sync every time one of them changes.

This gets worse in a hotel because the menu does not live in one place. It is on the restaurant table, on the room service menu, at the pool bar and sometimes printed in the room. If every language version had to be replicated at every revenue center, the number of documents that need to stay current multiplies fast, and nobody keeps up with all of them consistently.

One catalog, several translations of the same data

The right way to solve language is not to have three menus, but to have a catalog where every dish has a name and a description in each language the hotel serves, with a single price, a single availability status and a single recipe behind it. The guest picks the screen language and sees the matching translation; the kitchen, the price and the inventory do not change at all because they are the same regardless of which language is shown.

This means that when the chef runs out of a dish, it disappears from the menu in all three languages at the same time, because availability lives in the catalog, not in each translation. And when a price goes up, it goes up in all three languages at the same time for the same reason. The translation is a layer displayed on top of the real data, never an independent copy of that data.

Which fields need translation and which do not

• Dish name: translated, and in some cases the original name is also kept in parentheses when it is a dish with a regional identity.
• Description: translated in full, without trimming details that explain ingredients a foreign guest would not recognize on sight.
• Allergens and warnings: translated with the same priority as the name, because a translation mistake here has health consequences.
• Price, availability and category: not translated, they are the same data in any language.

What happens on the kitchen ticket when there are three languages

This is where many hotels trip without noticing. If the guest orders in English and the order reaches the kitchen in English, a cook who does not speak the language loses valuable seconds mentally translating every ticket, and during a busy shift those seconds pile up into assembly mistakes or longer delivery times.

The fix is that language is a presentation layer for the guest and for the server taking the order, but the ticket that reaches the kitchen is always printed in the kitchen’s working language, usually the hotel’s local language, no matter which language the guest ordered in. The dish is the same catalog object either way; the only thing that changes is which language it is presented in to each person based on their role.

The case of allergens, where there is no room for error

A translated dish name can be a bit off without anything serious happening. A translated allergen warning does not have that margin: a guest allergic to a nut who reads a mistranslated warning, or who cannot find it because it only existed on the local-language menu, faces a real risk, not a minor inconvenience.

That is why allergen warnings should be treated as a mandatory catalog field, with a translation checked by someone who truly speaks the language, not machine-translated and published without review. It is one of the few parts of the menu worth spending extra time on in every language the hotel offers.

How many languages to offer and how to decide

Not every hotel needs the same languages. The decision should come from who actually stays there, not from a generic list of popular languages. A beach hotel with guests mostly from international corporate agreements, as described on the corporate traveler page (Corporate traveler), may need English and Portuguese before a third language almost none of its guests use.

1. Check the country of origin of guests over the last few months, not a general assumption about the area.
2. Rank languages from highest to lowest guest volume that speaks them.
3. Start with the top two languages by volume before trying to cover a third or fourth.
4. Review this every season, because where guests come from shifts between high and low season.

An illustrative example with numbers

The figures below are invented to show the calculation. Imagine a hotel restaurant with 60 dishes in the catalog. Translating each dish, with its name, description and allergen warning, takes an average of 6 minutes per language when done carefully by someone who speaks it well.

1. Initial translation into a second language: 60 dishes times 6 minutes is 360 minutes, that is 6 hours of work, once.
2. If the catalog had to live in three separate menus by revenue center, restaurant, room service and pool bar, that same translation would have to be copied and kept up in all three places.
3. With a single catalog, those 6 hours are done once and serve all three revenue centers at the same time.
4. When the chef changes 5 dishes in a month, translating those 5 takes 30 minutes, and it shows up immediately at all three revenue centers without repeating the work three times.
5. If there were three independent menus instead, those same 5 changes would take 30 minutes times three, 90 minutes, with a higher chance one of the three is left outdated.

The gap between 30 minutes and 90 minutes every time the menu changes does not look large in one month, but it adds up over a year and, more importantly, it keeps a guest from ever seeing an outdated menu in the language nobody got around to updating.

Common mistakes when offering several languages

• Translating the menu once when the restaurant opens and never touching it again as the menu changes.
• Using an unreviewed automatic translation on allergen warnings.
• Keeping three independent documents instead of one catalog with several views.
• Printing the kitchen ticket in the guest’s language instead of the kitchen’s working language.
• Offering five languages when actual guest volume only justifies two, and ending up maintaining all five poorly.
• Not checking price and availability in every language after a change, assuming that if it updated in one it updated everywhere.

What to do this week

1. Compare the menu in every language your restaurant offers and note which dishes, prices or warnings no longer match between versions.
2. Check the country of origin of your guests over the last three months and confirm the languages you offer are the ones you actually need.
3. Check which language the kitchen ticket prints or shows in and fix it if it depends on the guest’s language instead of the kitchen’s working language.
4. Have someone fluent in each language review the allergen warnings specifically, not just the dish names.
5. Check whether your menu lives in a single catalog or in separate documents by revenue center and by language.
6. If they are separate documents, calculate how long the last menu change took, multiplied by those documents.

Inn Restaurant keeps every catalog dish with its translations, showing the guest their own language while the kitchen ticket always goes out in the hotel’s working language, without duplicating menus per revenue center. If you want to see what your menu would look like in several languages without tripling the work, book a 15-minute demo (contact).