A multilingual QR menu works when guests can find their language, understand what they are ordering, and see the same essential information as everyone else. Test those outcomes before choosing a system. A long list of supported languages is less useful if guests cannot switch languages easily or a translated modifier changes the meaning of an order.
Start with the languages your guests actually use and one approved source menu. Then check selection, translation, prices, and updates on real phones. Have a fluent reviewer check each language, and give staff a fallback for questions the menu cannot answer. The worksheet below turns those checks into a buying decision.
Choose languages and a source of truth
Ask front-of-house staff which languages guests request when ordering, and look for patterns across shifts. A lunch crowd may have different needs from a weekend dinner crowd. Avoid assuming that every guest speaks the language associated with their phone settings or where they live.
Choose a manageable starting list. One carefully reviewed additional language can serve guests better than several incomplete translations. Ask prospective vendors whether each chosen language can cover the full guest journey: category names, dish descriptions, modifiers, warnings, prices, and any ordering or payment instructions. A translated menu may not mean every screen outside the menu is translated too.
Next, designate one approved source menu. It should include more than dish names: record descriptions, ingredient and allergen information, modifier rules, prices, availability, and the date of the latest approval. Decide who can change it and where staff should look when two versions disagree.
For example, a kitchen may call a sauce “house dressing,” while the printed menu uses “sesame dressing.” Before translating, the owner needs the kitchen to confirm what is actually served. A fluent translator cannot correct an inaccurate source description without that information.
Ask how translations are entered and maintained. Can the restaurant edit each language directly? Can it see when the source text has changed but a translation has not? If those controls are not available, decide whether a separate change log and manual review are practical for your menu's rate of change.
Test automatic selection and the manual switch
Automatic selection can offer a useful starting point, but it should not be the only route to the right language. Ask what the system uses to choose a language, such as a browser or device setting, and whether the guest can override that choice. A traveler using a borrowed phone may prefer a different language from the one the device suggests.
Find the language control from the first menu screen. Check whether its label or icon is understandable before a guest knows the current language. A selector hidden inside a long settings menu may technically support switching while still leaving guests dependent on staff.
Use a few phones and browsers that represent your guests' devices. Set one browser to a language the restaurant offers and another to a language it does not. Scan the same code, note the starting language, and switch manually. Then move between categories and reopen an item. Does the chosen language remain in place, or does the guest need to select it again?
If ordering is part of the purchase, check what happens when a guest switches languages after choosing a modifier. The important question is whether the same selection remains clear and correct, not simply whether the screen changes language. Also check whether staff receive an order they can understand without relying on the guest's screen language.
Run these checks in a demonstration or test environment. A simulation should not create a real payment, guest message, or courier dispatch. A live service pilot is different: use it only after staff understand the workflow and you have agreed with the vendor how real orders and payments will be handled.
A menu-only QR code, an ordering system, and a pay-at-table flow are different purchases. The guide to placing QR ordering in table service can help you decide which parts of the service you want guests to handle.
Use a language decision worksheet
The following example is hypothetical. It assumes a restaurant wants English and Spanish, uses English as its approved source, and requires guests to be able to switch languages visibly. A fluent Spanish reviewer and a kitchen lead review a sample menu. The restaurant has not yet decided whether to enable ordering or payment.
| Check | Acceptance rule | Illustrative result | Decision |
|---|---|---|---|
| Language choice | Spanish is easy to select from the first menu screen | Selector is visible; Spanish stays selected while browsing | Pass for menu browsing |
| Dish and allergen text | Reviewer and kitchen lead agree that meanings match the source | One sauce description omits sesame | Hold Spanish publication until corrected and rechecked |
| Modifiers and prices | Options, requirements, and displayed prices match the approved menu | One required choice appears optional in Spanish | Correct the wording and repeat the check |
| Updates | A source change prompts review of the affected translation | Staff can edit both texts but must track the review manually | Accept only if an owner maintains the change log |
The result is not a rejection of the entire system. Under these assumptions, the language control passes the browsing check, but the Spanish menu should not go live until the two content problems are fixed and reviewed. The manual update process is acceptable only if someone owns it. If no one can maintain that log, the restaurant should seek a different workflow or reduce the number of languages it publishes.
Use your own acceptance rules in the same way. Include every language you plan to launch and repeat checks after a vendor changes the setup. Record the device, browser, menu version, reviewer, and outcome so a later correction can be checked against the same conditions.
Check meaning, modifiers, and prices in every language
Do not judge a translation by whether it sounds natural at a glance. A fluent reviewer should compare it with the approved source, while a kitchen lead confirms the food details. The two reviews answer different questions: one checks meaning in the guest's language; the other checks whether the source reflects what the kitchen prepares.
Pay particular attention to ingredients and allergen information. Check that a translated description does not omit an ingredient, turn “contains” into “may contain,” or imply that a dish is suitable for a guest when staff have not confirmed it. Give guests a clear way to ask staff about an allergy or ingredient question. If a reviewer finds an ambiguity, hold that text until the kitchen and reviewer agree on a correction.
Modifiers need the same care. Review required choices, optional additions, preparation instructions, and quantity limits. A guest should be able to tell whether a sauce is included, whether choosing a side is required, and whether an extra costs more. If an option is unavailable in one language, ask whether it is hidden, marked unavailable, or still selectable.
Check prices against the approved menu in each language, including additions and substitutions. Make sure the guest can tell which price belongs to the base dish and which belongs to an extra. If the system supports ordering, walk through the displayed total in the test environment and compare it with the selected items. Do not confuse a displayed menu price with a payment-processing fee charged to the restaurant.
Use difficult examples, not just the first few popular dishes. Include a dish with a long description, an item with several modifiers, an unavailable item, and a name that should remain untranslated. Ask whether the vendor supports a translation preview before publication and how the restaurant can correct a mistake quickly.
Assign owners and rehearse updates
A good launch review can become outdated after the first menu change. Assign a menu owner to approve source text, a kitchen contact to confirm food details, and a fluent reviewer for each additional language. One person may hold more than one role, but each responsibility needs a named owner and a backup.
Set a simple publishing rule: when an approved source item changes, identify every translation affected by that change before publishing it in those languages. A price change, ingredient swap, new modifier, and removal of an item all deserve attention. Ask the vendor whether an update can be staged and previewed, and whether older translations can remain unpublished while review is pending.
Rehearse with a simulated change, such as replacing one sauce description. Update the source in a test environment, have the reviewer inspect the translated version, and confirm that staff can tell which version is approved. The simulation must not trigger a real payment, guest message, or courier dispatch. If staging is unavailable, agree on a safe review and publishing procedure with the vendor before making a live change.
Keep a short change log: item, change, affected languages, reviewer, approval date, and publication status. If an error reaches guests, staff should know who can correct it and what to say while the correction is underway. Keep an accessible non-phone option, such as a current printed menu or staff assistance, and make sure it follows the same approved menu information.
Before signing, compare written quotes for the workflow you actually need. Ask which fixed subscription or setup charges, variable processing charges, and exception costs such as translation revisions or additional support are included. A quoted processing fee alone is not the all-in operating cost. Also ask what happens if you later add a language or change providers.
Fleksa's QR ordering lets guests scan, order, and pay at the table in a browser without downloading an app. Ask to see the language workflow you need rather than assuming every control is available. There is no Fleksa commission on table QR orders; processing and applicable tax still apply. See Fleksa's plans for pricing, checked November 2026, and request a current quote for your setup.
Next step: Bring your approved source menu, target languages, and worksheet to a Fleksa demonstration. Ask to walk through language selection, a modifier change, and a translated update, then compare the answers with your acceptance rules.
Frequently asked questions
Is automatic language detection enough for a QR menu?
No. It can provide a starting language, but guests also need an obvious way to choose another one. Test both the initial selection and whether the choice remains in place while browsing.
Who should approve a translated restaurant menu?
A fluent reviewer should check meaning against the approved source, and a kitchen contact should confirm ingredients, preparation details, and modifier rules. Assign an owner to coordinate corrections and publication.
Can a QR menu support multiple languages without taking orders?
Yes. A QR menu can display information without handling ordering or payment. Check language coverage separately for any ordering, payment, or staff-handoff screens you also plan to use.
