·Adiamo Studio
When a restaurant website needs a second language
Decide if a second language will earn bookings, what to translate first, and how to keep hours, prices, and the Reserve button identical so visitors are not guessing.
Answer first
Add a second language when a real group of guests — visitors, hotel referrals, a second local language — would book if they could read the page. Translate the first screen, the menu highlights, the hours, and the Reserve button first. Keep dish prices, hours, address, and the booking channel identical in both languages. A language switch on the page is enough for the guest in front of you; separate URLs matter later, if you want search to offer each language on its own.
A restaurant site in one language is the right default. Translating it badly is worse than not translating it: a visitor who cannot trust the hours will not book, and a machine-translated menu that invents dishes is a service problem, not a marketing win.
This guide is the decision, then the order of work. Who the second language is for, what to translate before the story, what must stay identical, and how a small site should handle the switch without pretending to be a multi-country brand. A live French-and-English page is the Le Velvet case study.
How a second language differs from a translated brochure
A brochure translation rewrites the whole story and hopes someone reads it. A booking page translation makes the decision possible: where you are, when you are open, what you serve, how to reserve. Google’s guidance on managing multi-regional and multilingual sites is written for sites with real alternate versions, not for a paragraph of English under a French hero. Match the effort to the audience you actually have.
| One language | Second language on the same site | Separate regional sites | |
|---|---|---|---|
| Who it is for | Guests who read the local language | Visitors and referrals who do not | Venues that truly operate in several countries |
| What changes | Nothing | Sentences, button labels, short dish glosses | Offers, legal text, sometimes the menu itself |
| What stays identical | Everything | Prices, hours, address, booking channel | Only the brand, if even that |
| How the guest switches | No switch | A visible control on the page | A different domain or path |
| What search needs | Ordinary local pages | Separate URLs if you want each language offered in results | hreflang between real alternates |
| Maintenance | One carte to update | The same facts, checked in both languages | A process per market |
Local language
Default for the room and the neighbourhood
Second language
The one visitors already use to book
Facts
Copied, not rewritten
When a second language is worth it
Add it
- A visible share of covers comes from visitors, hotels, or cruise and event traffic.
- The front desk already answers in that language.
- Your Maps listing and reviews include that language often enough that guests expect it.
- You can name one person who will check the translation when the menu changes.
Wait
- Almost every guest lives nearby and reads the local language.
- You would be translating into a language nobody on the floor speaks.
- The menu changes weekly and you cannot update both versions.
- You want a third and a fourth language before the second one is correct.
Tourist cities are the usual case, not the only one. A restaurant in a bilingual city may need both local languages even with no tourists. The test is the same: will someone fail to book because they cannot read the hours or the Reserve button?
How to add the second language without breaking the booking
Audience
One language guests already book in
Switch
Visible on the first screen
Facts
Hours, prices, address unchanged
Menu
Names kept, short gloss added
Reserve
Same channel, translated label
- 1
Name the audience in one sentence
“English for hotel guests in Nantes” is a brief. “International diners worldwide” is not. Write the sentence down. If you cannot, you do not have a second language yet — you have a wish.
- 2
Translate the booking path before the story
First screen: name, neighbourhood, hours, one Reserve button. Then menu highlights and how to get there. The essay about the chef can wait. The restaurant website checklist is the order of those blocks; do not invert it just because you are translating.
- 3
Keep dish names, and gloss them
“Boudin noir” stays “boudin noir” if that is what the kitchen sends. Add a short line in the second language. Renaming plates so they sound familiar creates a different menu from the one on the pass. How the page menu should be structured is in how to put your menu on your restaurant website.
- 4
Copy facts; do not rephrase them
Hours, prices, address, phone, and the reservation channel are pasted, not rewritten. A translator who “smooths” Tuesday’s closing into “some weekdays” has created a false listing. The same rule as why your Google Maps listing is not enough: the site and the listing must match, in every language you publish.
- 5
Put the switch where the first screen is
A guest who cannot find the language control will not hunt in the footer. Label it with the language name in that language (“English”, “Français”), not with a flag that means three countries. The Reserve button label is translated; the destination is the same WhatsApp thread, the same inbox, the same phone.
- 6
Do not auto-redirect, and do not ship raw machine text
Sending every visitor to a language based on their browser hides the version you meant them to compare, and Google notes that a crawler may not see versions that depend on browser settings. A machine draft is a start. A person who knows the room reads it before it is public, at least for the booking path and the menu.
What to translate, and what to leave
| Piece | Translate | Leave identical |
|---|---|---|
| Restaurant name | No | The name on the door and on Maps |
| Neighbourhood and address | The words around it, if any | The address itself |
| Hours | The words “closed”, “kitchen” | The times and the days |
| Dish names | A one-line gloss | The name on the pass |
| Prices | The currency word if you must | The number |
| Reserve button | The label | The channel it opens |
| Reviews you quote | Only if you also show the original | Do not invent a smoother quote |
| Allergen words | Yes — into clear words | The substance. Do not drop one |
If you later give each language its own URL, tell Google they are alternates. The doc is localized versions of your pages: each version should point at the others, URLs should be complete, and a switch based only on cookies is a weak way to do it. A single page with a visible language control is still the right first step for one restaurant. You can split URLs when search language actually matters, not before the copy is correct. The inLanguage property is how structured data names the language of a page; it does not translate anything.
When a second language fails
- The switch is there and the facts differ. English says you are open Monday; the local language says you are closed. Guests believe neither.
- Only the hero is translated. The menu, the hours, and the button are still in the other language, which is where the booking happens.
- Machine text shipped untouched. Dish descriptions name ingredients you do not use. That is a floor problem.
- Flags instead of language names. A flag is a country. Your guest may read English and not be from the country on the flag.
- Three languages, none maintained. Two correct languages beat four stale ones.
- The reservation channel changes by language. English opens email, the local language opens WhatsApp, and nobody owns both during service.
What a second language does not do
It does not bring tourists who were not going to look for you. It does not replace a floor that can greet a guest in that language, or a Maps listing still written only in the local language. It does not require a second website, a second domain, or a translator on retainer before the first version is useful. And it is not an SEO project: the point is that a visitor can book without guessing. Search can be told about separate URLs later, once those URLs exist and agree with each other.
Frequently asked questions
Do I need a second language if I am not in a tourist city?
Only if a real group of guests reads another language — a bilingual city, hotel contracts, a large expat neighbourhood. If your covers are local and the floor works in one language, stay with one and spend the effort on hours and the menu.
Should the whole site be translated?
Start with the first screen, hours, menu highlights, address, and the Reserve button. Translate the longer story when those are correct in both languages. A fully translated page with wrong hours is worse than a short correct one.
Can I use automatic translation?
As a draft, yes. Publish it only after someone who knows the menu reads the booking path and the dish lines. Automatic text invents ingredients and softens hours. That is not a shortcut you can leave in place.
Do I need a separate page URL per language?
Not to help the guest at the table. A clear switch on the page is enough for a single restaurant. Separate URLs, each pointing at the other, are what Google recommends when you want search to offer the right language. Do that when the copy is stable, not instead of writing it.
Should I translate guest reviews?
Show the original. A translation next to it is fine if it is honest and marked as a translation. Do not rewrite a review into smoother praise. The original is the proof.
How does Adiamo handle this?
A generated site can ship with the local language and a second one on the same page, the way Le Velvet publishes French and English. You still edit both so prices, hours, and the reservation channel match.