Lectures

In this material, we treat localizing a ChatGPT App as an architectural task: which layers need translation (UI, prompts, data, descriptions of tools/ JSON Schema, commerce/legal), where localization is just “cosmetics,” and where it affects the model’s behavior (“semantics”), and how to use platform signals _meta [ "openai/locale" ] and _meta [ "openai/userLocation" ] in MCP calls to choose the right language, data formats, and user‑facing copy.

We’ll break down how ChatGPT Apps obtain the “true” user locale and region from platform signals: openai/locale for language/region (BCP‑47) and _meta [ "openai/userLocation" ] for geography. In practice we’ll connect window . openai in a widget (React/Next.js) via a hook, show how to read locale on an MCP server via extra._meta, learn to render prices with Intl.NumberFormat, and discuss when it still makes sense to explicitly ask the user about their language.

We break down a practical i18n architecture for ChatGPT widgets on Next.js + React: why the language arrives as state from the Apps SDK (for example, openai/locale and the hook useOpenAiGlobal), why JSX shouldn’t contain hardcoded strings, how to organize dictionaries ( ru/ en) and build a lightweight localization layer via I18nProvider and the useT hook. Plus—formatting numbers/dates/currencies via Intl, reacting to locale changes, placeholders, and common mistakes.

We break down how GPT “reads” tools through the name, description fields and argument descriptions in JSON Schema, why the language of descriptions may (or may not) influence tool selection, and which architectural localization options are available (from separate tools for each language to a single tool with multilingual descriptions). In the end — a diagram of the locale flow throughout the stack and a list of common mistakes with testing recommendations.

We will cover how to design localization in MCP applications without a “Christmas tree” of if statements: where to make decisions about locale and region, how to use _meta metadata (including "openai/locale", "openai/userLocation", and "openai/subject"), how a “polyglot monolith” (one MCP) differs from a MCP Gateway + monolingual backend servers, and how to store client state so you don’t have to manually pass parameters in every tool call.