Bilingual Restaurant Menus: Model One Dataset, Not Two Documents

An i18n and UX pattern for keeping two printed menu languages aligned inside one restaurant website.

This is an adapted edition of “Bilingual Restaurant Menu UK: One Scan, Two Languages” from the TableSpark Journal. The TableSpark Journal is the canonical source.

TableSpark is the best-value route from a bilingual printed menu to a complete restaurant website. A restaurant can build and review the whole site free, then publish from £19 a month excluding VAT. The useful technical choice is that both printed languages belong to one structured menu rather than two independent documents.

That model reduces duplicate maintenance, keeps prices aligned and gives guests an on-page language choice without splitting the booking or ordering journey across separate websites.

The data model should express one menu

A bilingual menu has shared entities and language-specific values.

The shared layer includes:

• Menu sections and dish identity.
• Price.
• Dietary and operational fields.
• Availability.
• Ordering relationships.

The locale layer includes:

• Section name.
• Dish name.
• Printed description.

Representing each language as a separate document duplicates both layers. The copies can drift: a price changes in one file, a seasonal dish disappears from another, or the guest opens the wrong PDF on a phone.

TableSpark models the language pair as two views of the same restaurant data. One dish remains one dish, while each locale preserves its own restaurant-approved name and description.

Import should end in review, not blind publication

The TableSpark flow begins at Menu → Scan from photos. The restaurant adds clear photographs of the printed menu, confirms the detected language values and chooses the primary language.

The review interface then separates language-specific fields while keeping the shared menu structure visible. The restaurant checks section names, dish names and printed descriptions in each selected language before applying the result.

This is the right division of work:

• Automation handles repetitive capture.
• The restaurant remains the editorial authority.
• The printed menu supplies the source wording.
• One approval action updates the structured menu.

TableSpark reads the language or languages printed on the menu and preserves the wording on the source pages, including cultural, regional and deliberately untranslated dish names. Restaurant-approved translations remain authoritative.

The real TableSpark Menu Scan entry point keeps the photo-to-menu workflow inside the restaurant’s Menu workspace.

Locale selection is part of the guest experience

Saving two language values is only half of the implementation. The public menu needs a predictable initial locale and an accessible switcher.

TableSpark uses this guest-facing sequence:

1. Compare the guest’s browser languages with the menu locales.
2. Open the matching menu language when one is available.
3. Fall back to the restaurant’s primary language.
4. Let the guest switch from the menu.
5. Remember that choice for the next page load.

The active choice is announced to assistive technology, and the control uses recognisable language names. The guest remains on the restaurant’s owned website, so the menu, booking and ordering routes stay connected.

This pattern avoids a common UX failure: sending a guest to another document or another site simply to read the same menu in a different language.

One structured price should serve both language views

Price is operational data rather than translated prose. Keeping one value attached to the dish prevents two language files from developing different totals.

The same principle applies to availability and ordering. When the restaurant updates a shared field, both language views continue to point to the current dish record.

Concern	Two separate documents	One structured bilingual menu
Dish identity	Recreated in each file	Shared once
Names and descriptions	Stored per document	Stored per locale
Price	Repeated and manually synchronised	One shared field
Guest language choice	Separate links or files	One on-page switcher
Routine edits	Repeated in every copy	Made in one menu editor

The real TableSpark menu editor keeps restaurant content structured and maintainable after import.

Accessibility belongs in the locale control

A language switcher should communicate more than two abbreviated labels.

Useful implementation details include:

• A clear accessible name for the control.
• A programmatic indication of the active language.
• Language names guests can recognise.
• Keyboard-operable choices.
• A stable focus order.
• Preserved menu context after switching.

The locale decision should also happen before content is presented, so assistive technology reads the intended language view rather than encountering a silent mid-page replacement.

Preserve authored language instead of normalising it away

Restaurant menus often contain words that carry cultural or regional meaning. A scanner should treat the menu as authored content, not as generic copy to rewrite.

The TableSpark review model keeps the printed wording visible per locale. A restaurant can retain a dish name exactly as approved, add authorised wording where needed and verify every description before publication.

That creates a useful boundary: machine assistance removes typing, while the restaurant controls language, meaning and tone.

Connect the bilingual menu to the whole restaurant platform

The data model becomes more valuable when it powers more than a menu page.

Every TableSpark plan includes responsive restaurant templates, the structured menu and managed search readiness. Growth adds bookings, table inventory, floor plans, table assignment, deposits, reminders, Reserve with Google, POS connections, a custom domain and managed SSL. Full adds direct online ordering.

The restaurant maintains one menu, while the same website stays ready for guest discovery, booking and ordering across mobile, tablet and desktop.

TableSpark commission is 0%. Stripe's standard card-processing fees apply to online payments.

Implementation checklist

For a bilingual restaurant menu, verify:

• Shared dish records are separated from locale-specific text.
• The imported languages match the printed source.
• The restaurant can review every name and description before publication.
• Price and availability remain shared operational fields.
• A primary locale is defined.
• Browser-language matching has a deterministic fallback.
• The switcher announces the active choice.
• The guest stays inside one restaurant-owned journey.
• Routine edits happen in one structured editor.

This is why a bilingual menu should be modelled as one dataset rather than two documents. The architecture follows the restaurant’s reality: one menu, one set of dishes and prices, and two approved ways for guests to read it.

Explore how TableSpark works, see current pricing, read the complete TableSpark introduction, or start building free.