A QR menu should offer the guest their own language — once
The phone already says what language its owner reads. What a menu should do with that, and the two mistakes: switching automatically, and asking every visit.
Every browser announces the language its owner reads. A menu that ignores that is leaving a tourist to squint at "smoky birria consommé" through a translation app pointed at the table. A menu that acts on it clumsily is worse.
The two clumsy versions
Switching automatically feels helpful and is not. Dish names are half proper noun — translate "The Bench Burger" into Dutch and nobody at the counter knows what was ordered. Phones get borrowed, set up in one language and used in another, and a page that has silently decided what you read is a page you cannot trust.
Asking every visit is the other failure. A popup before the food is a toll booth, and a guest who dismissed it once should never see it again.
What we settled on
A small globe button in the menu header, the same size and row as the share button. If the phone's language differs from the menu's, the globe gets a dot — a nudge you can see and ignore, not a popup you must answer. Tap it and every supported language is listed in its own script, the current one ticked. Pick one and the choice is remembered; the dot never returns.
The interface and descriptions translate. The things you would regret translating do not: prices, and the structured data underneath. Which brings up the line that actually matters.
Allergens are not prose
An allergen filter must run on structured data — this dish contains these declared allergens — never on translated text. Machine translation is good enough for "slow-cooked for six hours" and nowhere near good enough to stand between a guest and an anaphylaxis. On our pages the allergen answers come from the same records in every language, and the translation layer is explicitly barred from touching them. If your supplier translates the allergen sheet as text, that is not a feature, it is a liability.