CodeGym /Cours /ChatGPT Apps /D’où obtenir la locale : openai/locale, _meta["opena...

D’où obtenir la locale : openai/locale, _meta["openai/userLocation"]

ChatGPT Apps
Niveau 9 , Leçon 1
Disponible

1. Pourquoi il est important d’utiliser la locale fournie par la plateforme plutôt que de la demander à l’utilisateur à chaque fois

Si l’on aborde la localisation « à l’ancienne », la logique est souvent : afficher une fenêtre modale « Choisissez une langue » et stocker le résultat dans localStorage. Dans les ChatGPT Apps, l’approche est différente : la plateforme est intelligente et fournit généreusement des signaux sur la langue et la région. Il faut apprendre à les utiliser sans importuner l’utilisateur avec des questions superflues.

ChatGPT ajoute à chaque requête vers votre App, dans le contexte :

  • la locale préférée de l’utilisateur (langue + région) — dans le champ openai/locale / _meta["openai/locale"] ;
  • la géolocalisation/la région de l’utilisateur — dans le champ _meta["openai/userLocation"].

Côté widget (front‑end), vous obtenez locale via window.openai ou un hook du SDK ; côté MCP/back‑end — via _meta dans la requête MCP.

Au final, un scénario normal ressemble à ceci : l’utilisateur écrit « Trouve un cadeau pour ma mère dans la limite de 50 € ». ChatGPT connaît déjà sa locale et son userLocation, la plateforme transmet ces signaux à votre App, et vous :

  • affichez l’UI dans une langue compréhensible,
  • chargez la bonne langue de catalogue,
  • mettez en forme les prix dans la devise et le format appropriés.

Sans dialogue séparé du type « Au fait, quelle est votre langue ? ».

2. Signal n° 1 : openai/locale — langue et région de l’utilisateur

De quoi s’agit‑il et à quoi cela ressemble

openai/locale est une chaîne au format BCP‑47, que vous avez sûrement déjà vu : "en", "en-US", "ru", "ru-RU", "uk-UA", etc.

Important : la plateforme

  • peut envoyer uniquement la langue ("en", "ru"),
  • peut envoyer la langue + la région ("en-US", "en-GB", "fr-CA").

BCP‑47 est un standard parfaitement pris en charge par l’API Intl dans le navigateur et par la plupart des bibliothèques i18n. Autrement dit, vous pouvez presque transmettre openai/locale tel quel à Intl.NumberFormat, au moteur de traduction et à vos tools.

Où la locale est disponible dans le widget

Dans l’UI personnalisée rendue à l’intérieur de ChatGPT, l’Apps SDK fournit un objet global window.openai, qui contient locale.

Typiquement, cela ressemble à ceci (TypeScript, Next.js 16, notre widget GiftGenius) :

// src/app/widgets/gift-widget.tsx
declare global {
  interface Window {
    openai?: { locale?: string };
  }
}

function getOpenAiLocale(): string {
  if (typeof window === "undefined") return "en";
  return window.openai?.locale || "en";
}

Dans une application réelle, il est plus simple d’écrire un hook qui fonctionne à la fois dans le bac à sable ChatGPT et dans Storybook :

// src/app/hooks/useOpenAiLocale.ts
import { useEffect, useState } from "react";

export function useOpenAiLocale(defaultLocale: string = "en") {
  const [locale, setLocale] = useState(defaultLocale);

  useEffect(() => {
    if (typeof window === "undefined") return;
    const next = window.openai?.locale || defaultLocale;
    setLocale(next);
  }, [defaultLocale]);

  return locale;
}

À présent, dans n’importe quel composant :

import { useOpenAiLocale } from "../hooks/useOpenAiLocale";

export function GiftHeader() {
  const locale = useOpenAiLocale();

  return (
    <h2>
      {/* plus tard, il y aura t('titles.gift_search') */}
      {locale.startsWith("ru") ? "Sélection de cadeaux" : "Gift search"}
    </h2>
  );
}

Dans le cours 4, nous externaliserons proprement toutes les chaînes dans des dictionnaires, mais dès maintenant nous relions l’UI au signal réel de la plateforme, et non à un navigator.language aléatoire. Ce hook est très spécialisé ; dans un vrai projet, il est pratique de le construire au‑dessus d’un mécanisme plus général d’accès aux globales de ChatGPT — nous y reviendrons plus loin.

Où la locale est disponible dans MCP/back‑end

Lorsque ChatGPT appelle un outil MCP, le SDK transmet _meta["openai/locale"] dans la requête JSON‑RPC. Sur un serveur TypeScript (notre MCP GiftGenius), c’est généralement disponible dans le deuxième argument du handler de l’outil.

Exemple :

// src/mcp/server.ts
import { McpServer } from "@openai/mcp-sdk";

const server = new McpServer();

server.registerTool(
  "suggest_gifts",
  {
    title: "Sélection de cadeaux",
    description: "Propose une liste de cadeaux selon les préférences",
    inputSchema: {
      type: "object",
      properties: {
        recipient: { type: "string" },
        budget: { type: "number" }
      },
      required: ["recipient", "budget"]
    }
  },
  async ({ input }, extra) => {
    const locale = extra?._meta?.["openai/locale"] || "en";
    // on peut ensuite charger le bon catalogue
    const gifts = await loadGiftCatalog(locale);
    // ...
    return {
      content: [
        {
          type: "text",
          text: `Found ${gifts.length} gifts for locale ${locale}`
        }
      ],
      structuredContent: { gifts }
    };
  }
);

Ainsi, locale traverse toute la pile : ChatGPT → Apps SDK → votre serveur MCP.

Insight

Chaque mcp‑tool sur le serveur possède un paramètre extra, où le serveur MCP place toutes les données qui n’entrent pas dans inputSchema. Voici un exemple d’un tel objet :

{
  sessionId: undefined,			// toujours undefined, utilisez `openai/subject` ci-dessous
  _meta: {
    'openai/userAgent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36',
    'openai/locale': 'en-US',		// locale de l’ordinateur de l’utilisateur, peut ne pas coïncider avec la langue du chat
    'openai/userLocation': {		// emplacement de l’utilisateur suffisamment précis
      city: 'London',
      region: 'London City',
      country: 'GB',
      timezone: 'Europe/London',
      latitude: '5.45466',
      longitude: '-0.52380'
    },
    timezone_offset_minutes: -240,	// décalage du fuseau horaire
    'openai/subject': 'v1/sEtRuS92UEOPNdwzEUZORfeOKf7XSk2KZoIUGfAsb68BzZ8h5FAOgrH'	// c’est le sessionId
  },
  authInfo: undefined,
  requestId: 1,
  requestInfo: {
    headers: {
      accept: 'application/json, text/event-stream',
      'accept-encoding': 'gzip, deflate, br, zstd',
      'access-control-allow-headers': '*',
      'access-control-allow-methods': 'GET,POST,PUT,DELETE,OPTIONS',
      'access-control-allow-origin': '*',
      'content-length': '542',
      'content-type': 'application/json',
      host: 'test.ngrok.app',					// domaine natif de l’application
      'mcp-protocol-version': '2025-11-25',	
      traceparent: '00-69399d3a000000004fb8cc13dc3a2203-8748a8698107eb34-00',
      tracestate: 'dd=s:-1;p:01514e334c1ccef5;t.dm:-3',
      'user-agent': 'openai-mcp/1.0.0',
      'x-datadog-parent-id': '6089244476286233754',
      'x-datadog-sampling-priority': '-1',
      'x-datadog-tags': '_dd.p.tid=69399c3a00000000,_dd.p.dm=-3',
      'x-datadog-trace-id': '5744565710382309891',
      'x-forwarded-for': '199.210.139.232',
      'x-forwarded-host': 'test.ngrok.app',
      'x-forwarded-port': '3001',
      'x-forwarded-proto': 'https'
    }
  },
}

Il est possible qu’une partie des en‑têtes ait été ajoutée par ngrok, mais il y a tout de même beaucoup d’informations intéressantes.

3. Signal n° 2 : _meta["openai/userLocation"] — géographie de l’utilisateur

Structure et signification

_meta["openai/userLocation"] est un objet contenant des informations géographiques : pays, région, ville, fuseau horaire et même coordonnées. Par exemple :

{
  "city": "London",
  "region": "England",
  "country": "GB",
  "timezone": "Europe/London",
  "latitude": 51.5074,
  "longitude": -0.1278
}

Les principaux champs réellement utiles dans GiftGenius :

  • country — code pays ISO à deux lettres, crucial pour l’assortiment et la devise ;
  • timezone — utile pour les formats de date/heure et les rappels.

Insight

Vérifié expérimentalement : la détermination de userLocation fonctionne très bien. Les données arrivent à chaque appel d’un MCP‑tool via le paramètre extra._meta["openai/userLocation"]. Vous pouvez vous y fier lors du développement de vos applications.

Comment utiliser userLocation dans les outils MCP

Sur le serveur MCP, userLocation vit dans _meta["openai/userLocation"] à côté de _meta["openai/locale"].

Étendons l’exemple de notre outil :

server.registerTool(
  "suggest_gifts",
  { /* schéma comme ci‑dessus */ },
  async ({ input }, extra) => {
    const meta = extra?._meta ?? {};
    const locale = (meta["openai/locale"] as string) || "en";
    const userLocation = meta["openai/userLocation"] as
      | { country?: string; city?: string }
      | undefined;

    const country = userLocation?.country || "US";

    const gifts = await loadGiftCatalog(locale, country);

    return {
      content: [
        {
          type: "text",
          text: `Found ${gifts.length} gifts for locale=${locale}, country=${country}`
        }
      ],
      structuredContent: { gifts }
    };
  }
);

La fonction loadGiftCatalog(locale, country) peut déjà :

  • choisir le bon fichier JSON : gift_catalog.en-US.json, gift_catalog.ru-RU.json ;
  • filtrer les produits qui ne peuvent pas être livrés dans ce pays,
  • choisir la devise de base.

Plus tard, dans les modules commerce, vous choisirez des règles fiscales basées sur country et mapperez vers les bons SKU, mais d’un point de vue architectural vous vous appuyez toujours sur le même signal — country.

Comment userLocation complète locale

Exemple classique :

locale = "en", userLocation.country = "DE".

La logique peut être la suivante :

  • UI et aides — en anglais (respecter la locale) ;
  • format et devise — euro, car l’utilisateur est physiquement en Allemagne ;
  • liste des cadeaux — uniquement ceux livrables en DE.

Dans GiftGenius, cela peut s’exprimer par une petite fonction utilitaire :

export function deriveCurrency(locale: string, country?: string): string {
  if (country === "DE") return "EUR";
  if (country === "JP") return "JPY";   
  if (locale === "zh_CN") return "CNY"; 
  return "USD";
}

Et s’utiliser côté back‑end / front‑end pour formater les prix :

const currency = deriveCurrency(locale, country);
const formatted = new Intl.NumberFormat(locale, {
  style: "currency",
  currency
}).format(price);

Côté back‑end, nous savons déjà utiliser locale et country pour choisir le catalogue et la devise. Ensuite, il est important de transmettre soigneusement les mêmes signaux à l’UI du widget pour que l’utilisateur voie les textes et les prix dans le format attendu.

4. Comment obtenir locale et userLocation dans le widget GiftGenius

Nous avons déjà vu comment locale et userLocation vivent côté MCP et influencent les catalogues et la devise. Voyons maintenant comment récupérer proprement locale dans le widget GiftGenius et l’utiliser directement dans l’UI React.

Important : dans le widget, nous avons un accès direct uniquement à locale (via window.openai et les hooks du SDK). userLocation vit dans _meta et s’utilise côté MCP/back‑end — nous l’avons déjà vu plus haut.

Dans l’Apps SDK, outre le window.openai « brut », il existe des utilitaires sous forme de hooks React. La documentation décrit des hooks comme useOpenAiGlobal("locale"), qui extraient les valeurs du contexte global de ChatGPT dans des composants React.

Modélisons nous‑mêmes un tel hook pour comprendre ce qui se passe sous le capot.

Hook de base useOpenAiGlobal

Nous avons précédemment écrit un useOpenAiLocale spécialisé. En pratique, il est plus confortable d’avoir un hook universel pour accéder aux globales de ChatGPT — sur sa base, on construit facilement useOpenAiLocale et d’autres enveloppes. Imaginons ce hook :

// src/app/hooks/useOpenAiGlobal.ts
import { useEffect, useState } from "react";

type OpenAiGlobals = {
  locale?: string;
  // on pourra ajouter plus tard theme, userAgent, etc.
};

export function useOpenAiGlobal<K extends keyof OpenAiGlobals>(
  key: K,
  fallback?: NonNullable<OpenAiGlobals[K]>
): NonNullable<OpenAiGlobals[K]> {
  const [value, setValue] = useState<NonNullable<OpenAiGlobals[K]>>(
    (fallback ?? "") as NonNullable<OpenAiGlobals[K]>
  );

  useEffect(() => {
    if (typeof window === "undefined") return;
    const globals = (window.openai || {}) as OpenAiGlobals;
    const next = globals[key] ?? fallback;
    if (next !== undefined) {
      setValue(next as NonNullable<OpenAiGlobals[K]>);
    }
  }, [key, fallback]);

  return value;
}

Désormais, useOpenAiGlobal("locale", "en") nous donne la valeur actuelle de locale avec la valeur par défaut "en".

Utilisation dans le widget GiftGenius

Écrivons un petit composant qui affiche un message d’accueil localisé et la locale actuelle pour le debug :

// src/app/widgets/GiftWelcome.tsx
"use client";

import React from "react";
import { useOpenAiGlobal } from "../hooks/useOpenAiGlobal";

export function GiftWelcome() {
  const locale = useOpenAiGlobal("locale", "en");

  const greeting =
    locale.startsWith("ru") || locale.startsWith("uk")
      ? "Bonjour ! Je vous aiderai à trouver un cadeau."
      : "Hi! I’ll help you find a great gift.";

  return (
    <div>
      <p>{greeting}</p>
      <small style={{ opacity: 0.6 }}>Debug locale: {locale}</small>
    </div>
  );
}

Pas encore de dictionnaires ni de bibliothèques i18n — cela viendra plus tard. Ce qui compte maintenant, c’est que nous savons déjà récupérer honnêtement la langue depuis ChatGPT, plutôt que de nous baser sur des suppositions.

5. Quand faut‑il demander explicitement la langue à l’utilisateur ?

Si openai/locale et userLocation sont si pratiques, peut‑on ne jamais demander à l’utilisateur la langue qu’il souhaite utiliser ? Malheureusement, parfois il le faut.

Quand les signaux ne suffisent pas

Quelques situations typiques :

  • Le compte ChatGPT est anglophone (locale = "en"), mais l’utilisateur écrit en russe. Le modèle répond en russe, mais votre UI est en anglais.
  • L’utilisateur est en Allemagne (userLocation.country = "DE"), locale = "en", et vous pouvez proposer une interface allemande et anglaise.
  • L’application est critique quant à la langue de communication : psychothérapie, conseils juridiques, apprentissage. Là, la précision de compréhension est plus importante que le confort d’un autodétect.

Dans ces cas, il est pertinent de poser une question courte et polie une seule fois au début du parcours, puis de mémoriser le choix.

Comment poser la question sur la langue sans être intrusif

Généralement, on formule la question de manière très simple et visuelle, par exemple :

  • « Dans quelle langue préférez‑vous : English ou Russian ? »
  • « Nous avons détecté votre langue comme English. Voulez‑vous en choisir une autre ? »

Dans un ChatGPT App, vous pouvez procéder de deux façons :

  • Via l’UI du widget : afficher un petit sélecteur de langue en haut.
  • Via un message de suivi (follow‑up) dans le chat au nom de l’App : envoyer un texte avec la question, puis traiter la réponse.

Code : choix simple de la langue dans GiftGenius

Créons un composant sélecteur qui :

  • prend la langue initiale à partir de locale,
  • permet à l’utilisateur de choisir ru ou en,
  • stocke le choix dans l’état du widget (pour l’instant dans l’état React).
// src/app/widgets/LanguageSwitcher.tsx
"use client";

import React, { useState, useEffect } from "react";
import { useOpenAiGlobal } from "../hooks/useOpenAiGlobal";

type SupportedLocale = "en" | "ru";

export function LanguageSwitcher(props: {
  onChange?: (locale: SupportedLocale) => void;
}) {
  const initialLocale = useOpenAiGlobal("locale", "en");
  const [locale, setLocale] = useState<SupportedLocale>("en");

  useEffect(() => {
    const normalized: SupportedLocale = initialLocale.startsWith("ru")
      ? "ru"
      : "en";
    setLocale(normalized);
    props.onChange?.(normalized);
  }, [initialLocale, props]);

  const handleChange = (next: SupportedLocale) => {
    setLocale(next);
    props.onChange?.(next);
  };

  return (
    <div style={{ marginBottom: 8 }}>
      <span style={{ marginRight: 8 }}>
        {locale === "ru" ? "Langue :" : "Language:"}
      </span>
      <button
        type="button"
        onClick={() => handleChange("en")}
        style={{ fontWeight: locale === "en" ? "bold" : "normal" }}
      >
        EN
      </button>
      <button
        type="button"
        onClick={() => handleChange("ru")}
        style={{ fontWeight: locale === "ru" ? "bold" : "normal", marginLeft: 4 }}
      >
        RU
      </button>
    </div>
  );
}

Et dans le widget principal GiftGenius, vous pouvez déjà choisir les textes/le dictionnaire selon selectedLocale, plutôt que selon les données « brutes » de ChatGPT.

Dans de futurs cours, vous remplacerez l’état local par un stockage plus robuste (par exemple, en transmettant la langue choisie à MCP / Gateway via _meta["openai/subject"]), mais le pattern restera le même.

6. Comment transmettre locale et userLocation au back‑end et les conserver

Les signaux de ChatGPT arrivent « par le haut », mais la vie ne s’arrête pas là. Il faut ensuite acheminer ces données vers vos outils et services, ne pas les perdre en route et éviter de forcer le modèle à deviner à nouveau la langue.

Champ locale explicite dans les arguments des tools

La méthode la plus fiable consiste à ajouter locale (et si nécessaire country) comme champs séparés dans l’inputSchema de l’outil. Ainsi, le modèle reçoit un signal explicite : « il faut remplir ce champ ».

server.registerTool(
  "suggest_gifts",
  {
    title: "Gift suggestions",
    description: "Suggest gifts based on recipient and budget",
    inputSchema: {
      type: "object",
      properties: {
        recipient: { type: "string" },
        budget: { type: "number" },
        locale: {
          type: "string",
          description: "Current user UI locale, BCP-47 (e.g. en-US, fr-FR)"
        },
        country: {
          type: "string",
          description: "ISO country code (e.g. US, DE)"
        }
      },
      required: ["recipient", "budget"]
    }
  },
  async ({ input }, extra) => {
    // Si le modèle n’a pas renseigné locale/country, secours depuis _meta :
    const meta = extra?._meta ?? {};
    const locale = input.locale || (meta["openai/locale"] as string) || "en";
    const country =
      input.country ||
      (meta["openai/userLocation"] as any)?.country ||
      "US";

    // ...
  }
);

Cela réduit la « magie » côté serveur : il voit clairement les arguments que le modèle compte utiliser.

Stocker la locale au niveau de la session / de l’utilisateur

Dans une architecture avec MCP Gateway (modules à venir), il est courant de stocker « l’état client » : locale, currency, préférences. Pour l’instant, retenez l’idée : on lit une fois les signaux de ChatGPT — puis on les utilise comme partie de l’état de session, plutôt que de les recalculer à chaque fois.

Un pseudo‑code indicatif :

// gateway.ts
const sessionState = new Map<string, { locale: string; country?: string }>();

function onMcpRequest(request: any) {
  const subject = request._meta?.["openai/subject"]; // identifiant utilisateur anonyme
  const locale = request._meta?.["openai/locale"] || "en";
  const country = request._meta?.["openai/userLocation"]?.country;

  if (subject) {
    sessionState.set(subject, { locale, country });
  }

  // ensuite, transmettre locale/country au serveur MCP concerné
}

Dans le cadre de ce cours, vous n’avez pas besoin d’implémenter Gateway, il suffit de comprendre que locale et userLocation sont des candidats naturels à cet « état de session ».

Insight

Données expérimentales : request._meta?.["openai/locale"] indique la locale actuellement configurée pour l’utilisateur. La langue d’échange peut être obtenue en paramètre de l’outil via inputSchema.

J’ai défini une locale EN sur mon ordinateur, tout en échangeant avec ChatGPT en allemand (DE). Résultat :

  • request._meta?.["openai/locale"] valait EN,
  • la locale reçue comme paramètre de l’outil via inputSchema était DE.

7. Locale vs détection automatique de la langue à partir du texte

Parfois, les développeurs sont tentés par l’idée : « Détectons simplement la langue d’après le texte de l’utilisateur, une LLM sait tout faire. » En pratique, c’est presque toujours pire que de s’appuyer sur openai/locale.

Les raisons sont très pragmatiques :

  • l’utilisateur peut écrire dans un mélange de langues ;
  • les distinctions fines (uk-UA vs ru-RU) se détectent mal sur un seul message ;
  • ChatGPT a déjà fait ce travail pour vous et a envoyé locale.

La détection automatique est utile comme solution de repli si openai/locale arrive sous une forme étrange ou est absent (aujourd’hui, c’est rare), mais ne bâtissez pas votre logique principale dessus. Règle simple :

  • regardez d’abord openai/locale comme « vérité » ;
  • tenez ensuite compte de userLocation (devise, assortiment) ;
  • et seulement dans les cas litigieux, vous pouvez examiner la langue du dernier message.

8. Différentes combinaisons de locale et userLocation : tableau de scénarios

Pour fixer les idées, voyons comment GiftGenius doit se comporter dans différents scénarios.

Scénario locale userLocation.country Langue de l’UI Devise Catalogue
1
en-US
US
EN
USD
Produits US
2
uk-UA
UA
UKR/RU
UAH
Produits UA
3
en
DE
EN
EUR
Produits DE
4
ru-RU
DE
RU
EUR
Produits DE
5
en
(pas de données) EN
USD
Global default

Ce point de vue vous sera utile plus tard quand nous parlerons de commerce, mais on voit déjà à quel point il est facile de changer le comportement en fournissant simplement différentes valeurs de locale et country.

9. Petit diagramme du flux des signaux de locale

Pour mettre les idées au clair, regardons un schéma simplifié :

flowchart TD
  U[L’utilisateur<br/>écrit un message] --> C[ChatGPT]
  C -->|détermine| L[openai/locale<br/>+ userLocation]
  L -->|transmet| W["Widget (Next.js)"]
  L -->|transmet via _meta| S[MCP Server]

  W -->|locale| UI[GiftGenius UI<br/>textes + format des nombres]
  S -->|locale + country| DATA[Catalogues, prix, filtres]

  style L fill:#e0f7ff,stroke:#00a
  style W fill:#f7fff0,stroke:#4b4
  style S fill:#fdf0ff,stroke:#b4

À noter : dans ce schéma, on ne voit nulle part une fenêtre modale « Choisissez une langue ». Elle n’est nécessaire qu’en couche supplémentaire, lorsque les signaux contredisent les attentes de l’utilisateur.

10. Pratique : quoi faire dès maintenant dans votre App

Pour que ce cours ne reste pas théorique, un court check‑list pratique pour GiftGenius :

  • Dans le widget : ajouter un hook useOpenAiGlobal("locale") ou équivalent et, au moins à un endroit, introduire une bifurcation RU/EN pour un texte.
  • Sur le serveur MCP : dans l’un des outils existants (suggest_gifts), récupérer _meta["openai/locale"] et _meta["openai/userLocation"], les journaliser et les utiliser pour choisir le catalogue.
  • Écrire une fonction simple deriveCurrency(locale, country) et l’utiliser quelque part pour le formatage des prix.

Inutile de construire immédiatement un moteur i18n complet et 15 langues — l’objectif est d’apprendre à utiliser honnêtement les signaux de la plateforme.

11. Erreurs courantes lors de l’utilisation de locale et userLocation

Erreur n° 1 : ignorer complètement openai/locale et ne se fier qu’à navigator.language.
C’est ce que font ceux qui sont habitués aux applications web classiques. Dans ChatGPT, l’utilisateur peut ne rien ouvrir dans un navigateur, et navigator.language de votre côté peut être la langue du serveur tunnel ou de Vercel, pas celle de l’utilisateur. Au final, l’UI est « mystérieusement » toujours en anglais, alors que ChatGPT vous envoie systématiquement ru-RU.

Erreur n° 2 : demander à chaque fois « dans quelle langue préférez‑vous travailler ? »
Si la première réplique de votre widget dans chaque chat est un sondage de langue, les utilisateurs ont l’impression d’être à l’aéroport, où on leur demande cinq fois de suite s’ils n’ont pas oublié leurs bagages. La plateforme connaît déjà la langue et la région — il suffit de respecter openai/locale et de ne poser la question qu’en cas de conflit manifeste (par exemple, demande en russe avec locale = "en").

Erreur n° 3 : stocker la langue choisie uniquement dans l’UI et ne pas la transmettre aux outils MCP.
Le widget peut être en russe tandis que le serveur continue de renvoyer un catalogue en anglais, faute d’être informé du changement de langue. Pensez toujours au chemin de bout en bout : si l’UI comporte un sélecteur, son résultat doit être transmis au back‑end — soit dans les arguments de l’outil, soit via la session Gateway.

Erreur n° 4 : essayer de « deviner » la langue uniquement à partir du texte des messages, en ignorant openai/locale.
La détection automatique peut bien fonctionner… tant que l’utilisateur écrit un anglais « pur ». Dès que des mélanges de langues ou des formulations proches apparaissent, le résultat devient instable. openai/locale est une estimation prête à l’emploi, suffisamment fiable, fournie par la plateforme. Il faut la considérer comme la source principale de vérité, la détection de texte n’étant qu’un signal complémentaire.

Erreur n° 5 : mêler logique métier et localisation avec des if (locale === 'ru') { ... } partout dans le code.
Dans ce cours, nous faisons encore un peu cela par simplicité, mais il est important de planifier dès le départ la séparation des chaînes, formats et catalogues de la logique métier. Sinon, dans quelques mois, vous aurez un code où chaque fonction commence par if (locale.startsWith("ru")), et ajouter une nouvelle langue deviendra pénible. Dans le cours 44, nous traiterons précisément ce problème, en gardant à l’esprit que nous avons déjà une source pour locale et savons l’utiliser.

Commentaires
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION