When a menu, opening time or ordering action changes, the person responsible for that part of the business should approve the source change. A qualified reviewer for each affected language should then check the translation, and a website owner should verify the published page and its links. One person can hold more than one role, but each approval needs a named owner.
The goal is to keep every language aligned with what a guest can actually order or do. That takes a repeatable restaurant website translation review process, not just a good initial translation.
Assign a qualified reviewer for each language
Choose someone who can read both the source language and the target language comfortably, understands the restaurant's food and service terms, and can spot wording that sounds unnatural to the intended audience. A bilingual employee may be a good fit if they have time and relevant knowledge. An outside translator or editor may be better when the menu uses specialized terms or no employee can review confidently.
Speaking a language is useful, but it is not the only qualification. Ask a prospective reviewer to explain how they would handle a dish name, a preparation detail and an ordering instruction. They should be willing to ask what a term means rather than guess. For important changes, arrange a second check by someone who understands the operation, even if that person cannot judge every word in the target language.
Give reviewers the information they need before work starts:
- Menu lead: Supplies the current dish name, ingredients, preparation notes, options and price, and answers food-related questions.
- Manager: Confirms hours, service areas, exceptions and the effective date of a change.
- Ordering or website owner: Supplies the current page, destination links and details of what each button should do.
- Language reviewer: Checks meaning and natural wording, records questions and approves the final text for that language.
- Publisher: Applies the approved changes and checks the live result. This may be the website owner or another authorized person.
For each language, name a backup and decide how quickly a reviewer should respond to routine and urgent requests. If no qualified reviewer is available, do not quietly treat an unreviewed translation as approved. Decide who can temporarily remove or clearly flag the affected information while review is arranged. For an unexpected closure, prioritize correcting the operational information guests will see, then complete the language review as soon as possible.
Compare meaning, not just individual words
Start with one approved source version. Put it beside each translation, and review the complete guest task: finding a dish, understanding its options, seeing when service is available and taking the next action. A sentence can be grammatically sound but still give a different instruction.
Hypothetical example: A restaurant changes its dinner opening time from 5:00 p.m. to 5:30 p.m., adds a mushroom dish with an optional dairy topping, and changes a button from “View menu” to “Order online.” The manager confirms the new time and effective date. The menu lead explains which part of the dish contains dairy. The website owner identifies where the new button should lead.
The language reviewer checks that the translated hours show the new time, the dish description does not imply the dairy topping is required, and the button invites ordering rather than merely viewing a menu. If a translation has no concise equivalent for a dish name, retaining the name and adding a short explanation may be clearer than forcing a literal translation. The menu lead should resolve ingredient questions; the reviewer should not infer them from the old copy.
Give special attention to words that alter a guest's decision: optional, included, unavailable, pickup, delivery and reservation. Check whether a time applies to the dining room, pickup or delivery. If the restaurant uses regional terms, tell the reviewer which audience the page is intended to serve. Keep a short glossary of approved dish names and recurring action labels, but update it when the operation changes.
A useful acceptance rule is that the reviewer can explain the same guest action and conditions from both versions. If the wording remains ambiguous, return it for clarification before approval. A second reader can help catch ambiguity, but neither a translation nor a review replaces the restaurant's responsibility to keep its underlying menu and service details accurate.
Check prices, dates and actions on the page
Review the numbers and destinations separately from the prose. A translation can read well while displaying an old price, a past holiday schedule or a button that leads to the wrong place. Compare each published language with the approved source and check the full customer path on a phone as well as a larger screen.
In the hypothetical change above, the publisher can check that 5:30 p.m. appears in each affected language and that the ordering button opens the intended ordering page. The reviewer should also inspect any visible price and availability text associated with the new dish. If a page uses a date, confirm the day, month and year are understandable to the intended audience and match the approved schedule.
For a practice check, use a preview, test environment or another non-transactional route. Stop before any real payment, guest message or courier dispatch. Confirm the button destination and visible instructions without placing a real order. A simulated check can reveal a wrong link or confusing label; it cannot establish that every step of a live order will work.
If the restaurant later chooses a live service pilot, plan it separately with the relevant staff and system provider. Agree in advance which real actions, if any, are authorized and how they will be handled. Do not treat a preview check as a live-service result.
Also look beyond the main page. Hours may appear in a footer, ordering screen or reservation flow. Ask the website provider where those details are maintained and whether each language can be edited independently. The restaurant website builder comparison can help frame questions about editing and ownership; your review checklist should cover the actual pages and tools guests use.
Keep a translation review and version log
A version log connects a change to the people who approved it and the version guests should see. It can be a shared document or spreadsheet. Give every source change an identifier, record its effective date, and link or attach the exact text sent for translation. Do not rely on a message saying only “menu updated.”
The worksheet below continues the hypothetical example. It shows one way to record the source, review status and publication check. The names are roles rather than claims that a particular person performed the work.
| Change and source version | Source owner and effective date | Language review | Publication check |
|---|---|---|---|
| Hours: dinner begins at 5:30 p.m.; source H-02 | Manager; effective May 12 | Each affected language: reviewer and approval date recorded | Publisher checks page and footer against H-02 |
| Mushroom dish: dairy topping optional; source M-07 | Menu lead; effective May 12 | Each affected language: reviewer checks optional wording | Publisher checks description and approved price |
| Button: “Order online”; source A-03 | Website owner; effective May 12 | Each affected language: reviewer approves action label | Publisher checks destination without submitting an order |
In the working log, add the actual language, reviewer name, approval date, page location and publication date for each affected version. Record whether a change is awaiting translation, awaiting approval, published or withdrawn. Keep a link to the previous version and note who can restore it if a mistake appears. A correction should create a new entry rather than erase the earlier decision.
Not every edit needs the same review. A punctuation correction may only need a quick language check. A changed ingredient, price, service time or button destination needs the relevant operational owner and a review of every affected language. When the source changes after translation has started, mark the translation as needing another check against the new source version.
Set a regular time to reconcile the log with the live site, and assign someone to resolve overdue entries. If one language cannot be updated by the effective date, decide which affected content to remove or flag temporarily and record that decision. This is more useful than leaving an old translation in place and assuming a guest will find the newer source page.
Use this checklist on one recent menu or hours change. Then ask Fleksa about its restaurant website and online ordering setup, including how language edits are published and whether the relevant setup is available in the US.
Frequently asked questions
Can a bilingual employee approve every translation?
Yes, if the employee can review the relevant language and restaurant terminology and has time to do the work. The menu or operations owner should still confirm the underlying facts. Use an outside reviewer when the employee cannot confidently assess the text.
What should happen when hours change urgently?
The manager should confirm the new hours and effective time, and the publisher should correct the affected guest-facing information. Send each affected language for review promptly. If a translation cannot be checked in time, remove or clearly flag the affected information temporarily and record the decision.
Does every translated page need a separate log entry?
Each affected language and page location needs a traceable status, reviewer and publication check. You can group them under one change identifier, provided the log makes it clear which versions are approved, published or still waiting.
