Lokalisierungsstrategie für die App

1. Warum Lokalisierung gerade in der ChatGPT‑App wichtig ist

Wenn Sie normale Web‑Apps gebaut haben, haben Sie Lokalisierung vermutlich mit klassischem i18n assoziiert: UI‑Strings, ein paar Datums‑ und Zahlenformate, Wörterbücher — und Sie übersetzen alles sauber. In der ChatGPT‑App ist es spannender: Hier gibt es einen dritten Akteur — das LLM‑Modell selbst. Es liest Ihre Tool‑Beschreibungen, Prompts, Ergebnisse, zieht Schlüsse und trifft Entscheidungen.

Sprache ist also nicht nur „wie man dem Nutzer Text schön anzeigt“, sondern auch „wie das Modell versteht, was Ihr Tool macht, wann es aufzurufen ist und welche Argumente einzusetzen sind“. Einen Button „Kaufen“ kann man irgendwie übersetzen — der Nutzer wird es verstehen. Aber wenn Sie ein Tool, das eine Zahlung ausführt, vage beschrieben haben, in einer Mischung aus Russisch und Englisch, könnte das Modell es entweder nie aufrufen oder ganz anders, als Sie erwarten.

Noch ein Punkt: ChatGPT übergibt Ihrem MCP‑Server bereits Hinweise zur Locale und zum Standort des Nutzers — _meta["openai/locale"] und _meta["openai/userLocation"]. Das geschieht auf der Ebene der MCP‑Tool‑Requests, damit Sie Text und Daten an Sprache und Region des Nutzers anpassen können. Die Plattform liefert Ihnen also bereits Kontext, und die Aufgabe der Entwickler ist es, ihn durchdacht zu nutzen.

Daher betrachten wir in diesem Modul Lokalisierung als architektonischen Aspekt der ChatGPT‑App — und nicht als „UI übersetzt und abgehakt“.

2. Schichten, die lokalisiert werden müssen

Betrachten wir die App als Schichtkuchen. Jede Schicht kann (und sollte oft) lokalisiert werden. Um nicht unterzugehen, beginnen wir mit einer Karte.

Schichtenüberblick

Zuerst — eine Übersichtstabelle, danach die Details.

Das ist faktisch die erste Ebene unserer Lokalisierungskarte: Später fügen wir Tiefe (Kosmetik/Semantik), Sprachen und konkrete Elemente hinzu.

Gehen wir die Schichten der Reihe nach durch.

Widget UI

Die naheliegendste Schicht — das Widget‑Interface. In GiftGenius sind das:

• Blocküberschriften;
• Feldbeschriftungen („Empfänger“, „Budget“, „Interessen“);
• Buttons („Geschenk finden“, „Filter zurücksetzen“);
• Hinweise in Eingabefeldern („z. B. Kollege, Mutter …“);
• Fehlermeldungen und leere Zustände („Keine Geschenke gefunden“).

In einer üblichen React‑App sind das die ersten Kandidaten für Wörterbücher. Hier ist es genauso — mit dem Zusatz, dass UI nicht die gesamte App ist, sondern nur eines ihrer Gesichter.

Etwas später im Modul bauen wir eine saubere i18n‑Architektur für das Widget, aber schon jetzt gilt: Strings haben im JSX nichts verloren. Selbst wenn Sie zunächst nur eine Sprache unterstützen, ist es praktisch, UI‑Texte sofort zu strukturieren.

Mini‑Beispiel mit unserem GiftGenius (noch ohne echte i18n‑Bibliothek):

type Locale = "en" | "ru";

const uiText = {
  en: {
    title: "GiftGenius: find a perfect present",
    recipientLabel: "Recipient",
  },
  ru: {
    title: "GiftGenius: Wählen Sie ein perfektes Geschenk aus",
    recipientLabel: "Empfänger",
  },
};

function GiftForm({ locale }: { locale: Locale }) {
  const t = uiText[locale];

  return (
    <div>
      <h2>{t.title}</h2>
      <label>{t.recipientLabel}</label>
      {/* weitere Felder */}
    </div>
  );
}

Hier betreiben wir noch keine „echte“ Lokalisierung, aber wir heben die UI‑Texte bereits klar als eigene Schicht heraus.

GPT‑Texte und Prompts

Die nächste Schicht — System‑ und Hilfstexte, die der Nutzer nicht direkt sieht, die aber das Modellverhalten stark beeinflussen:

• System‑Prompt Ihrer App („Du bist ein Assistent für Geschenke …“);
• Schablonen für Erklärungen, die Sie dem Modell geben („Erstelle eine kurze Zusammenfassung der Auswahl“);
• vorbereitete Follow‑ups und Hinweise für das Modell („schlage dem Nutzer vor, das Budget zu präzisieren, wenn …“).

Auch diese Texte können (und sollten oft) lokalisiert werden. Ein simples Beispiel: Wenn der Nutzer auf Russisch schreibt, Ihr System‑Prompt aber vollständig auf Englisch ist, kommt das Modell zwar klar, aber Sie verzichten auf präzise Kontrolle über Stil und Formulierungen in dieser Sprache.

Später, in den Lektionen zu Lokalisierung von Prompts und Beschreibungen (prompts/descriptions), sehen wir uns an, wie man mit mehrsprachigen System‑Prompts sauber umgeht. Hier wichtig: Prompts sind genauso lokalisierbar wie die UI.

Daten und Content

Als Nächstes kommen Ihre Daten. Für GiftGenius ist das der Geschenkkatalog: Titel, Beschreibungen, Kategorien, gelegentlich Hinweise zur Nutzung des Geschenks. Für eine Commerce‑App kommen Preise, Währungen, Maßeinheiten, Datums‑ und Zahlenformate etc. hinzu. In den Produktspezifikationen für die ChatGPT‑Plattform (Format, in dem Sie Ihre Waren und Dienstleistungen beschreiben) sind diese Textfelder (title, description) und Preise explizit vorgesehen, damit sie Nutzern in ChatGPT korrekt angezeigt werden können.

Wenn Sie eine globale App wollen, stellen sich für den Geschenkkatalog mindestens diese Fragen:

• speichern wir Titel/Beschreibungen in mehreren Sprachen;
• wie wählen wir die Sprache aus, die wir dem Nutzer liefern;
• was tun wir, wenn eine Übersetzung fehlt (Fallback);
• wie zeigen wir Währungen sowie Datums‑/Preisformate für verschiedene Regionen an.

Ein kleiner typisierter Katalog‑Beispielcode:

type Locale = "en" | "ru";

interface LocalizedString {
  en: string;
  ru: string;
}

interface Gift {
  id: string;
  title: LocalizedString;
  description: LocalizedString;
  priceCents: number;
  currency: "USD" | "EUR" | "RUB";
}

function getLocalizedTitle(gift: Gift, locale: Locale) {
  return gift.title[locale] ?? gift.title.en;
}

Lokalisierung betrifft also nicht nur das Frontend, sondern auch die Datenstruktur in der Datenbank und in MCP‑Ressourcen. Darauf kommen wir zurück, wenn wir über das Gateway (die Brücke zwischen ChatGPT und Ihren Services) und den MCP‑Server sprechen.

Beschreibungen von Tools und JSON Schema

Die vierte Schicht — Beschreibungen der Tools und ihrer Argumente. Über sie versteht das Modell, wann Ihr Tool aufzurufen ist und welche Argumente zu übergeben sind. In MCP sind das title, description des Tools und die description der Felder in der JSON‑Schema.

Die Apps‑SDK‑Dokumentation betont, dass das Modell Namen, Beschreibungen und Parameterdokumentation nutzt, um Tools auszuwählen und Argumente zu konstruieren.

Ein hypothetisches GiftGenius‑Tool im TypeScript‑MCP‑Server:

server.registerTool(
  "suggest_gifts",
  {
    title: "Suggest gifts",
    description: "Suggest 3–5 gift ideas based on recipient profile.",
    inputSchema: {
      type: "object",
      properties: {
        recipient: {
          type: "string",
          description: "Who is the gift for (e.g. mother, colleague)?",
        },
      },
      required: ["recipient"],
    },
  },
  async ({ input }) => { /* ... */ }
);

Aktuell ist alles auf Englisch, das Modell versteht das gut. Aber was, wenn der Nutzer auf Russisch schreibt? Es kann „Mutter“ immer noch mit recipient verknüpfen, aber bei komplexeren Feldern und Fachtermini steigt die Fehlerrate. In der Lektion zu Strategien der Lokalisierung von Beschreibungen diskutieren wir separat: eine einheitliche englische Sprache für Beschreibungen versus lokalisierte Beschreibungen.

Auf dieser Ebene unserer Lokalisierungskarte halten wir fest: Tool‑ und JSON‑Schema‑Beschreibungen können ebenfalls lokalisiert werden — und das beeinflusst das Modellverhalten.

Commerce und Rechtliches

Schließlich die Schicht, an die man oft erst ganz zum Schluss denkt — alles rund um Geld und juristische Texte:

• SKU‑Namen und Abo‑Pläne;
• Felder title/description in Commerce‑Feeds (Produkte, Services, Abos);
• Terms of Service, Privacy Policy, Refund Policy;
• E‑Mails und Benachrichtigungen (E‑Mail, Push), falls die App außerhalb von ChatGPT etwas versendet;
• Bestellstatus und Zahlungsfehler, die Sie dem Nutzer anzeigen („Zahlung abgelehnt“, „In Ihrer Region nicht verfügbar“).

Hier gibt es zwei Aspekte: UX und Recht. Der Nutzer muss in seiner Sprache verstehen, womit er einverstanden ist und wofür er zahlt. Gleichzeitig müssen Übersetzungen juristisch korrekt sein: Manchmal verlangen Juristen, dass nur Texte in einer Sprache (z. B. Englisch) rechtsverbindlich sind, während andere Übersetzungen „referenziellen“ Charakter haben.

In unserer Lokalisierungskarte markieren wir Commerce und juristische Inhalte als eigene Schicht, weil dafür oft ein anderer Prozess nötig ist (Legal, Compliance, Abstimmung mit Marketing).

3. Tiefe der Lokalisierung: „Kosmetik“ vs. „Semantik“

Wenn wir sagen „die App lokalisieren“, ist es hilfreich, zwei Tiefen zu unterscheiden: kosmetisch und semantisch.

Kosmetische Lokalisierung

Kosmetik ist alles, was das Aussehen und die Lesbarkeit ändert, das Systemverhalten aber kaum beeinflusst. Beispiele:

• übersetzte Überschriften und Button‑Labels;
• übersetzte Platzhalter in Eingabefeldern;
• „menschliche“ Fehlermeldungen im UI;
• lokalisierter Text eines Marketing‑Banners im Widget.

Bei klassischen Web‑Apps endet es oft hier. In der ChatGPT‑App ist das wichtig, aber nur die Spitze des Eisbergs.

Semantische Lokalisierung

Semantik sind Dinge, die das Verhalten des Modells und die Logik der App verändern. Hier beeinflusst Sprache:

• welches Tool das Modell auswählt;
• wie es Tool‑Argumente befüllt;
• welche Daten es für „richtig“ für diesen Nutzer hält.

Beispiele semantischer Lokalisierung:

• ein System‑Prompt in der Nutzersprache, der Stil und Regeln vorgibt;
• Beschreibungen von Tools und deren Feldern in der Sprache des Nutzers;
• unterschiedliche Hinweis‑/Anleitungstexte je nach kulturellem Kontext;
• Einstellungen für Datums‑/Währungsformate, die das Parsen und die Generierung beeinflussen (31.12.2025 vs 12/31/2025).

Wenn Sie nur Kosmetik, aber keine Semantik lokalisiert haben, kann Ihre App lokalisiert aussehen, sich aber „unter der Haube“ wie eine englischsprachige verhalten. In der Lokalisierungskarte ist es sinnvoll, Elemente zu markieren, die für das Modellverhalten kritisch sind.

Für unseren GiftGenius sind das z. B.:

• die Beschreibung des Feldes budget im JSON‑Schema („Budget in the user’s currency“) — Semantik;
• die Beschriftung des Buttons „Geschenk finden“ — Kosmetik (wichtig für UX, aber das Modell sieht sie nicht).

Nachdem wir Kosmetik und Semantik unterscheiden, stellt sich die Frage: In wie vielen Sprachen soll die App überhaupt funktionieren?

4. Einsprachige vs. mehrsprachige ChatGPT‑App

Bevor wir die Karte zeichnen, müssen wir die Ambitionen klären: Bauen Sie strikt einsprachig oder zielen Sie auf ein mehrsprachiges Publikum?

Einsprachige App

Eine einsprachige App ist der Fall, in dem Sie bewusst nur eine Sprache unterstützen — z. B. ausschließlich Englisch.

UI‑Widget, Prompts, Tool‑Beschreibungen und Daten — alles in einer Sprache. Das vereinfacht vieles:

• eine Codebasis ohne Sprachverzweigungen;
• ein Katalogschema (ohne title_en, title_ru usw.);
• einfacher zu warten und zu testen.

Aber die Zielgruppe ist begrenzt. Bei einer ChatGPT‑App heißt das zusätzlich: Kommt ein Nutzer mit anderer Locale, kann ChatGPT Ihre App zwar trotzdem anzeigen, muss aber ständig die Nutzersprache auf die interne Sprache der App „abbilden“. In manchen Nischen ist das okay, für einen Massen‑Geschenkservice eher nicht.

Mehrsprachige App

Eine mehrsprachige App ist bereits eine Architekturentscheidung. Hier gilt:

• UI und Texte werden korrekt anhand der Nutzer‑Locale angezeigt;
• Daten (Kataloge, Produktbeschreibungen) sind ebenfalls an Sprache/Region gebunden;
• Tool‑Beschreibungen und System‑Prompts können je Sprache variieren;
• Commerce‑Szenarien berücksichtigen lokale Währungen, Steuern, Einschränkungen.

In diesem Fall reicht ein if (locale === "ru") an beliebiger Stelle im Code eindeutig nicht aus. Es braucht eine Architektur: Wörterbücher, lokalisierbare Ressourcen, einen Single Point of Truth für locale und userLocation, Absprachen zwischen Widget und MCP‑Server.

Die Apps‑SDK‑Dokumentation betont, dass ChatGPT Ihnen locale und userLocation in _meta beim Tool‑Aufruf übergibt, damit Sie serverseitig die richtige Sprache und Datenformate wählen können. Das ist der „Treibstoff“ für mehrsprachige Apps.

Kleiner Vergleich

Zur Veranschaulichung — ein Mini‑Vergleich:

Im Kurs gehen wir davon aus, dass GiftGenius mehrsprachig wird (mindestens EN/RU), um ein „erwachsenes“ Schema zu zeigen. Viele Kniffe sind aber auch für eine sorgfältige einsprachige App nützlich, wenn Sie sich auf eine Erweiterung vorbereiten wollen.

5. Wo Sprache das Modell wirklich beeinflusst

Markieren wir jetzt die Punkte, an denen Sprache das Verhalten von ChatGPT direkt beeinflusst.

Sprache der Nutzereingabe vs. Sprache der Tool‑Beschreibungen

Stellen wir uns vor:

• der Nutzer schreibt: „Finde ein Geschenk für einen Kollegen für 50 Euro“;
• Ihr Tool suggest_gifts ist nur auf Englisch beschrieben;
• Schemafelder: recipient, budget, currency, interests.

Das Modell muss:

1. entscheiden, dass suggest_gifts überhaupt aufzurufen ist;
2. recipient = "colleague", budget = 50, currency = "EUR" extrahieren;
3. das korrekt als JSON‑Argumente serialisieren.

Sind die Beschreibungen knapp und in einer anderen Sprache, kommt das Modell damit zurecht, aber die Wahrscheinlichkeit fehlerhaft gefüllter Felder ist höher. Zum Beispiel könnte es budget und price_limit verwechseln oder Text in interests packen, weil in der Feldbeschreibung etwas Vages stand wie „Any extra info about the gift“.

Bei deutscher Nutzereingabe und englischen Beschreibungen „springt“ das Modell zudem ständig zwischen Sprachen.

Variante mit lokalisierter Schema‑Beschreibung:

const locale = _meta?.["openai/locale"] ?? "en"; // kommt von ChatGPT 
const isRu = locale.startsWith("ru");

server.registerTool(
  "suggest_gifts",
  {
    title: isRu ? "Geschenkvorschläge" : "Suggest gifts",
    description: isRu
      ? "Schlage 3–5 Geschenkideen basierend auf dem Profil des Empfängers vor."
      : "Suggest 3–5 gift ideas based on recipient profile.",
    inputSchema: { /* ... */ },
  },
  async ({ input }) => { /* ... */ }
);

Hier vereinfacht: In der Praxis generiert man Beschreibungen besser einmal beim Serverstart, nicht bei jedem Aufruf. Die Idee bleibt: Wir können je nach Locale unterschiedliche Beschreibungen an ChatGPT liefern, damit das Modell den Nutzer leichter versteht.

Sprache der Daten vs. Sprache der Anfrage

Wenn Ihr Geschenkkatalog nur auf Englisch vorliegt, der Nutzer aber auf Deutsch interagiert, wird das Modell englische Titel und Beschreibungen wählen. Manchmal ist das okay, manchmal nicht. Wichtiger ist, wie Sie die Ausgabe formatieren:

• zeigen Sie dem Nutzer Original‑title/description vom Server;
• oder fasst das Modell sie in seiner Antwort in der Nutzersprache zusammen;
• oder liefert Ihr Tool bereits lokalisierte Texte basierend auf der Locale zurück.

Im Apps‑SDK können strukturierte Inhalte (structured content, die Sie aus Tools zurückgeben) und der Text‑Output getrennt existieren. Sie können strukturierte Daten (z. B. JSON mit Produktfeldern) und separaten Nutzertext zurückgeben, und das Modell entscheidet anschließend, wie es das rendert oder zusammenfasst.

Die Lokalisierung kann auf Serverebene (Daten) oder auf Modellebene (Umformulierung in die gewünschte Sprache) passieren. In der Karte sollten Sie festlegen, wo Sie die „letzte Instanz“ halten wollen.

System‑Prompt und Follow‑ups

Wenn Ihr System‑Prompt nur auf Englisch ist, der Nutzer aber deutschsprachig, balanciert das Modell ständig zwischen zwei Sprachen. Das kann okay sein, aber manchmal wollen Sie den Ton strikt vorgeben: z. B. informeller in der DE‑Version und formeller in der EN‑Version.

Daher sollten Sie in der Lokalisierungskarte markieren:

• System‑Prompt EN;
• System‑Prompt RU;
• Follow‑up‑Schablonen (EN/RU);
• alle „harten“ Hinweise im Prompt für Tools.

6. Lokalisierungskarte für GiftGenius

Fassen wir alles zu Schichten, Tiefe und Sprachen zu einer expliziten Lokalisierungskarte für GiftGenius zusammen. Tun wir das, was Sie später für Ihre App machen: eine Lokalisierungskarte erstellen. Die Idee ist einfach: Tabelle mit Spalten für Schicht und Entitätstyp, Zeilen für konkrete Elemente.

Beispielkarte

Hier eine vereinfachte Karte für GiftGenius (EN/RU):

suggest_gifts.description

budget.description

Links gruppieren wir nach Schichten, danach die konkreten Elemente. Die letzte Spalte hilft zu verstehen, was nicht ohne Abstimmung mit Prompt‑Designer/Modellverantwortlichen geändert werden darf: Alles, was als Semantik markiert ist, beeinflusst das GPT‑Verhalten.

Kleiner Code‑Skizze

Um die Karte mit Code zu verbinden, kann man einen einfachen Typ für lokalisierbare Entitäten einführen:

type LocalizedTextKey =
  | "ui.title"
  | "ui.recipient_label"
  | "error.no_gifts"
  | "prompt.summary_intro";

type Locale = "en" | "ru";

type Messages = Record<Locale, Record<LocalizedTextKey, string>>;

const messages: Messages = {
  en: {
    "ui.title": "GiftGenius: find a perfect present",
    "ui.recipient_label": "Recipient",
    "error.no_gifts": "No gifts found",
    "prompt.summary_intro": "Here’s why these gifts fit:",
  },
  ru: {
    "ui.title": "GiftGenius: Wählen Sie ein perfektes Geschenk aus",
    "ui.recipient_label": "Empfänger",
    "error.no_gifts": "Keine Geschenke gefunden",
    "prompt.summary_intro": "Darum passen diese Geschenke:",
  },
};

Dieselben Schlüssel können Sie sowohl im Widget als auch bei der Prompt‑Erstellung auf dem Server verwenden (vorausgesetzt, Sie reichen die Locale durch den Stack — dazu mehr in der nächsten Lektion). So wird Ihre „Lokalisierungskarte“ schrittweise zu einem typisierten Wörterbuch statt zu einer Sammlung verstreuter Strings.

7. Praxis: Erstellen Sie eine Lokalisierungskarte für Ihre App

Bevor wir in konkrete i18n‑Techniken und die Gateway/MCP‑Architektur eintauchen, ist eine langweilige, aber sehr hilfreiche Übung wichtig: ehrlich zu beschreiben, was genau Sie lokalisieren werden.

Ein guter Ansatz: Öffnen Sie irgendeinen Editor (Google Sheets, Notion, …) und legen Sie eine Tabelle mit Spalten an:

• Kategorie/Schicht (UI, Prompts, Daten, Tools, Commerce und Rechtliches, Fehler);
• Element (konkreter Button, konkrete Feldbeschreibung, konkreter Endpoint mit Text);
• Beispielwert EN;
• Beispielwert in der zweiten Sprache (falls vorhanden oder als Entwurf);
• Markierung „Kosmetik/Semantik/juristisch wichtig“;
• Owner (wer verantwortlich ist: Frontend, MCP‑Server, Produkt, Legal).

Gehen Sie dann Ihre App durch und schreiben Sie ehrlich alles auf, wo Text vorkommt oder Sprache das Datenformat beeinflusst.

Für GiftGenius ergäbe sich eine erweiterte Version der obigen Tabelle. Unterwegs finden Sie fast garantiert ein paar „versteckte“ Stellen:

• Textkonstanten im MCP‑Servercode (z. B. Fehlermeldungen);
• Default‑Werte im structuredContent (z. B. Kategorien, die Sie im UI nicht gezeigt haben);
• alte Tool‑Labels, die nicht mehr zum tatsächlichen Verhalten passen.

Diese Übung ist besonders nützlich bevor Sie Lokalisierung mit realen Geschäftsprozessen verbinden (Zahlungen, Abo‑Aktivierungen, juristische Dokumente). Ein Tool charge_user in einem mehrsprachigen System mit ACP und juristischen Texten später umzubenennen, ist deutlich schmerzhafter.

Wenn Sie die Lokalisierungskarte im Voraus zeichnen und ehrlich markieren, was und in welchen Sprachen Sie unterstützen wollen, sparen Sie sich viele Nerven in den nächsten Modulen — wenn MCP, Gateway, Commerce und Store ins Spiel kommen.

8. Typische Fehler bei der Lokalisierungsplanung

Fehler Nr. 1: annehmen, Lokalisierung = „Buttons übersetzen“.
Sehr häufig: Das Team extrahiert alle UI‑Strings in Wörterbücher, übersetzt sie und ist zufrieden. Währenddessen bleiben System‑Prompt nur auf Englisch, Tool‑Beschreibungen ebenso, und der Produktkatalog enthält ausschließlich englische Namen. Das Ergebnis: Die App sieht lokalisiert aus, aber das Modell lebt weiterhin in seiner englischen Welt, und das Verhalten bleibt anglophon. In der Praxis äußert sich das in seltsamen Empfehlungen und Fehlern in Tool‑Argumenten.

Fehler Nr. 2: Kosmetik und Semantik nicht unterscheiden.
Manchmal bittet der Product „die Formulierung etwas anzupassen“ in einer Tool‑Beschreibung oder im System‑Prompt, und der Entwickler ändert den Text, als wäre es ein simples UI‑Label. Aber die Beschreibung eines JSON‑Schema‑Feldes oder eine Phrase im System‑Prompt ist Teil des Vertrags mit dem Modell. Solche Änderungen können radikal beeinflussen, wie GPT Ihr Tool aufruft. Wenn man semantische Elemente nicht in der Karte markiert, bricht man leicht versehentlich das App‑Verhalten.

Fehler Nr. 3: mit mehrsprachigem Chaos ohne Architektur starten.
Es ist verlockend, am Anfang einfach überall if (locale === "ru") einzubauen und deutsche Strings ad hoc zu setzen. Nach ein paar Wochen wird die Anwendung zum „Lokalisierungs‑Chaos“: In einer Komponente kommen Strings aus dem Wörterbuch, in einer anderen stecken sie im JSX, auf dem Server gibt es ein drittes Schlüsselschema. Später eine saubere i18n‑Lösung anzuschließen und alles zu vereinheitlichen wird deutlich schwerer.

Fehler Nr. 4: Daten und Geld vergessen.
Selbst erfahrene Teams starten oft mit der Übersetzung von UI und Prompts, übersehen aber, dass Produktkataloge, Preise, Währungen und juristische Texte ebenfalls Locale und userLocation berücksichtigen müssen. In den Product‑Feed‑Spezifikationen für ChatGPT ist festgelegt, welche Textfelder und Preise für die korrekte Darstellung gebraucht werden. Wenn Sie Mehrsprachigkeit nicht auf Datenebene anlegen, müssen Sie später entweder den Feed duplizieren oder schmerzhafte Migrationen vornehmen.

Fehler Nr. 5: Plattformsignale zu Locale und Standort ignorieren.
ChatGPT übergibt in MCP‑Aufrufen _meta["openai/locale"] und _meta["openai/userLocation"], damit Sie verstehen, in welcher Sprache und aus welcher Region interagiert wird. Einige Entwickler lassen den Nutzer trotzdem beim ersten Start „Sprache wählen“ und nutzen diese Signale nicht für Ressourcen‑ und Preiswahl. Das verschlechtert die UX und macht die Architektur unnötig kompliziert.

Fehler Nr. 6: „Owner“ der lokalisierbaren Elemente nicht festhalten.
Sobald alles live ist, zerstreuen sich die Übersetzungen auf verschiedene Personen: Frontender ändern UI‑Texte, Backender die Tool‑Beschreibungen, ML‑Spezialist den System‑Prompt, und Legal liefert überarbeitete Terms. Wenn in der Lokalisierungskarte nicht steht, wer für welche Schicht zuständig ist, kollidieren Änderungen, und manche Texte werden an einer Stelle aktualisiert, an anderer nicht.