i18n

Mehrsprachiges Restaurant-Menü — DE/FR/IT in der Schweiz richtig aufsetzen

Die Schweiz hat vier Landessprachen — dein Restaurant-Menü sollte mindestens drei davon abdecken. Wie du Übersetzungen, Allergene und Preise sauber pflegst, ohne dass es Chaos wird.

Adil Kaya·2. Mai 2026·9 min Lesezeit·

i18n menu tutorials

Die Schweiz hat vier Landessprachen — Deutsch (62 %), Französisch (23 %), Italienisch (8 %), Rätoromanisch (0.5 %) — plus einen relevanten englischsprachigen Tourismus-Anteil (12 % der Restaurant- Gäste in Städten). Wenn dein Restaurant-Menü nur auf Deutsch ist, schließt du strukturell einen Drittel deiner potenziellen Kunden aus.

Aber: Mehrsprachigkeit ist nicht nur „Google Translate drauflassen". Allergene müssen rechtlich korrekt benannt sein, Preise variieren nicht, kulturelle Erwartungen unterscheiden sich — und dein Backend muss das alles ohne Chaos verwalten. Diese Anleitung zeigt, wie es geht.

Die fünf Datenpunkte, die übersetzt werden müssen

Es ist nicht nur „der Pizza-Name". Eine sauber mehrsprachige Karte hat fünf Felder pro Gericht, die alle übersetzt werden müssen:

Produktname — „Margherita" bleibt, aber „Hausgemachte Tagliatelle" wird zu „Tagliatelle maison" / „Tagliatelle fatte in casa".
Beschreibung — die 1–2 Zeilen mit Zutaten und Zubereitung.
Allergene — rechtlich vorgeschrieben in der Sprache, in der der Kunde den Bon liest (LMIV / LIV).
Modifikatoren — „Extra Käse", „glutenfrei", „halbe-halbe".
Kategorie-Name — „Vorspeisen" → „Entrées" → „Antipasti".

Was NICHT übersetzt wird: Preise (gleich überall), Bestellungs-ID, MWSt.-Satz, Lieferzeiten. Diese sind sprach-neutral.

Backend-Schema: zwei Modelle

Es gibt im Wesentlichen zwei Wege, mehrsprachige Daten zu strukturieren:

Modell A: One Row Per Locale

Jedes Produkt hat ein Hauptobjekt mit id, und eine separate Tabelle product_translations mit Zeilen (product_id, locale, name, description, allergens). So macht es Forn, Lightspeed und gastronovi.

Pro: sauber relational, einfach Sprachen hinzufügen, einzelne Übersetzungen aktualisieren ohne andere zu touchieren. Contra: jede Abfrage braucht ein JOIN.

Modell B: JSON Column

Jedes Produkt hat eine Spalte translations als JSON: {"de": {...}, "fr": {...}, "it": {...}}. So macht es Wix und einige selbstgebaute Systeme.

Pro: ein Query, keine JOINs. Contra: schwierig zu validieren, Schema-Änderungen sind fehleranfällig.

Wir empfehlen Modell A für jedes ernsthafte System. Forn nutzt Modell A mit Supabase Postgres und einer Helper-Funktion get_product_with_locale(product_id, locale), die das richtige Übersetzungs-Set lädt.

Übersetzungs-Workflow: drei Optionen

Option 1: Manuelle Übersetzung von Hand

Du gibst die deutsche Karte einem freiberuflichen Übersetzer (CHF 40–80 / Stunde, ca. 8 Stunden für eine 80-Gerichte-Karte = CHF 320–640).

Pro: höchste Qualität, kulturell akkurat. Contra: teuer, dauert 1–2 Wochen, jedes neue Gericht muss neu beauftragt werden.

Option 2: DeepL / GPT-4 mit menschlicher Endkontrolle

Du nutzt DeepL Pro (~CHF 9 / Monat, unlimited) oder OpenAI GPT-4 (~CHF 0.05 pro Übersetzungs-Set) für die Roh- Übersetzung. Eine sprachkundige Person prüft und korrigiert in 30–60 Minuten.

Pro: schnell (Stunden statt Wochen), günstig. Contra: braucht zumindest eine sprachkundige Endprüfung, Allergene müssen manuell verifiziert werden.

Option 3: Hybrider Workflow im Backend

Bei Forn ist DeepL nativ eingebunden — du klickst „Auto- übersetzen" und die deutsche Beschreibung wird ins FR/IT/EN übersetzt, du siehst sie in einem Vergleichs-View und kannst pro Sprache 1-Klick-Edits machen. Sehr schneller Workflow für neue Produkte: 30 Sekunden statt 5 Minuten.

Forn-Admin mit Auto-Übersetzungs-Knopf — Im Forn-Produkt-Editor: links die deutsche Quelle, rechts die DeepL-Übersetzungen — ein Klick übernimmt sie alle, einzeln editierbar.

Allergene: rechtlich heikel

Die EU-Lebensmittel-Informations-Verordnung (LMIV) und in der Schweiz die LIV (Lebensmittel-Informations-Verordnung) schreiben vor, dass Allergene in der Sprache der Speisekarte stehen müssen. Wenn dein Online-Menü auf Französisch ist, müssen die Allergene auch auf Französisch sein — nicht auf Deutsch übersetzt im Footer.

Die 14 EU-Hauptallergene haben in jeder Sprache feste Bezeichnungen. Eine kleine Hilfstabelle:

| DE | FR | IT | EN | | --- | --- | --- | --- | | Glutenhaltige Getreide | Céréales contenant du gluten | Cereali contenenti glutine | Cereals with gluten | | Eier | Œufs | Uova | Eggs | | Milch | Lait | Latte | Milk | | Erdnüsse | Arachides | Arachidi | Peanuts | | Soja | Soja | Soia | Soy | | Schalenfrüchte | Fruits à coque | Frutta a guscio | Tree nuts |

Wichtig: Auto-Übersetzung („DeepL hat das gemacht") ist rechtlich riskant, wenn ein allergischer Kunde reagiert. Lass Allergene immer von Hand verifizieren oder nutze ein System, das die 14 LMIV-Allergene fest in allen Sprachen hinterlegt hat (Forn, Lightspeed). Vermeide „freie Text-Felder" für Allergene.

Frontend: wie der Kunde die Sprache wählt

Drei Patterns, die wir in Schweizer Restaurants sehen:

Pattern A: Sprache aus Browser-Sprache erkennen

Beim ersten Besuch liest dein Frontend den Accept-Language-Header und zeigt die passende Sprache. Funktioniert für die Mehrheit der Besucher, aber Touristen mit deutschen Browsern in der Welschschweiz bekommen DE statt FR — irreführend.

Pattern B: Sprach-Selector im Header

Klassische Lösung: ein Sprach-Dropdown oben rechts mit DE/FR/IT/EN. Der Kunde wählt einmal, du speicherst in einem Cookie. Das ist unser Standard bei Forn.

Pattern C: URL-Routing

/de/menu, /fr/menu, /it/menu. Gut für SEO (jede Sprache hat eigene URLs, hreflang-Tags), aber URL-Struktur wird länger und Bookmarks sind sprachgebunden.

Wir empfehlen Pattern B + URL-Routing kombiniert. Der Kunde wählt im Header, das setzt den Cookie UND leitet auf die richtige URL um. Bots (Google) sehen klare Sprach-URLs, Menschen sehen einen einfachen Switcher.

SEO-Implikationen

Die größte SEO-Frage bei mehrsprachigen Sites: wie sage ich Google, welche Version für welchen Markt ist?

Antwort: hreflang-Tags im <head>. Beispiel für ein Produkt:

<link rel="alternate" hreflang="de-CH" href="https://pizzeria.ch/de/menu/margherita" />
<link rel="alternate" hreflang="fr-CH" href="https://pizzeria.ch/fr/menu/margherita" />
<link rel="alternate" hreflang="it-CH" href="https://pizzeria.ch/it/menu/margherita" />
<link rel="alternate" hreflang="en" href="https://pizzeria.ch/en/menu/margherita" />
<link rel="alternate" hreflang="x-default" href="https://pizzeria.ch/de/menu/margherita" />

Forn macht das automatisch für jede Tenant-Seite (Produkt, Menü, Reservation). Bei selbstgebauten Sites musst du das manuell pflegen — wir sehen sehr oft, dass das fehlt und Google deshalb falsche Sprach-Versionen in den Suchergebnissen zeigt.

Konkrete Kostenkalkulation

Was kostet eine vollständige mehrsprachige Karte für eine 80-Gerichte-Pizzeria realistisch?

| Posten | Manuell | DeepL+Review | Forn Auto | | --- | --- | --- | --- | | Initial-Übersetzung 3 Sprachen | CHF 1'500 | CHF 200 | CHF 0 (im Plan) | | Pro neues Gericht | CHF 30 | CHF 5 | CHF 0 | | Allergene-Pflege | inkl. | extra (~10 Min) | inkl. (LMIV-Liste fix) | | Erstes Jahr (20 neue Gerichte) | CHF 2'100 | CHF 300 | CHF 0 zusätzlich |

Anmerkung: Forn berechnet keine Extra-Gebühr für Auto-Übersetzung, aber im Pro-Tarif (CHF 149 / Monat) — fairer Vergleich ist also nicht 0, sondern „im Plan enthalten".

Empfehlung nach Restaurant-Profil

Italienisches Restaurant in Zürich

DE + EN reichen. IT optional (10 % deiner Gäste, kulturell aber gerne gesehen). FR weglassen, außer du bist nah an einer Sprachgrenze.

Bäckerei mit Café in Lausanne

FR + EN als Haupt-Sprachen. DE klein als drittes Optionen-Set für Geschäftsreisende. IT nicht nötig.

Pizzeria in Lugano

IT als Haupt-Sprache. DE als zweites (Touristen aus der Deutschschweiz). EN drittes. FR nicht nötig.

Restaurant in Zermatt / Interlaken

4 Sprachen + idealerweise eine fünfte (z. B. JP oder KR), je nach dominanter Touristengruppe. EN als „Default für alle anderen".

Migration von einer einsprachigen zu einer mehrsprachigen Karte

Wenn du heute nur Deutsch hast und auf 3 Sprachen umstellen willst, ist das ein 5-Schritte-Plan:

Inventur: liste alle Produkte mit Beschreibungen und Allergenen in einem CSV.
Auto-Übersetzung: DeepL Pro für FR + IT + EN, ~30 Min für 80 Gerichte.
Manuelles Review: ein Muttersprachler liest in 1–2 Stunden alles durch.
Allergen-Verifizierung: separat von der Übersetzung, mit LMIV-Standard-Begriffen.
Frontend-Switch: Sprach-Selector aktivieren, hreflang-Tags ergänzen.

Bei Forn-Onboarding ist das Schritt 2–5 in 1 Tag erledigt — wir nehmen den CSV aus deiner alten Karte, importieren ihn, machen Auto-Übersetzung, und du klickst durch die Vorschläge. Bei gastronovi und Lightspeed dauert es typisch 3–5 Tage.

Was wir intern bei Forn machen

Forn ist multi-locale by default: jedes Tenant-Restaurant kann sechs Sprachen aktivieren (DE, FR, IT, EN, TR, SQ). Im Admin gibt es einen Toggle pro Sprache; sobald aktiv, hat jedes Produkt-Edit-Formular sechs Tabs. Auto-Übersetzung via DeepL ist ein Knopf pro Produkt oder „alle übersetzen" für die ganze Karte.

Die LMIV-Allergene sind in allen 6 Sprachen fest hinterlegt — du wählst sie aus einer Liste, sie sind nicht frei editierbar (genau das ist die rechtliche Absicherung).

Wenn du wissen willst, wie sich das für dein Restaurant ausgestaltet — schau dir unsere Demo an oder lies, wie wir die ePOS-Bon-Integration und TWINT-Setup in jede Sprache automatisch synchronisiert haben.