Dove ottenere la locale: openai/locale, _meta["openai/userLocation"]

1. Perché è importante ottenere la locale dalla piattaforma e non chiederla ogni volta all’utente

Se affrontiamo la localizzazione “alla vecchia maniera”, la logica è di solito: mostrare una modale «Scegli la lingua» e salvare il risultato in localStorage. Nelle ChatGPT Apps l’approccio è diverso: abbiamo già una piattaforma intelligente che fornisce segnali su lingua e regione. Bisogna imparare a usarli e a non stressare l’utente con domande superflue.

ChatGPT in ogni richiesta alla vostra App aggiunge al contesto:

• la locale preferita dell’utente (lingua + regione) — nel campo openai/locale / _meta["openai/locale"];
• la geolocalizzazione/regione dell’utente — nel campo _meta["openai/userLocation"].

Dal lato del widget (frontend) ottenete locale tramite window.openai o un hook dell’SDK; dal lato MCP/backend — tramite _meta nella richiesta MCP.

Il flusso normale è quindi questo: l’utente scrive «Trova un regalo per la mamma entro 50 €». ChatGPT conosce già la sua locale e la sua userLocation, la piattaforma passa questi segnali alla vostra App e voi:

• mostrate la UI nella lingua giusta,
• caricate la lingua corretta del catalogo,
• formattate i prezzi nella valuta e nel formato appropriati.

Senza un dialogo separato del tipo «A proposito, qual è la tua lingua?».

2. Segnale n. 1: openai/locale — lingua e regione dell’utente

Che cos’è questo campo e com’è fatto

openai/locale è una stringa in formato BCP‑47, che probabilmente avete già visto: "en", "en-US", "ru", "ru-RU", "uk-UA" ecc.

È importante che la piattaforma:

• possa inviare solo la lingua ("en", "ru"),
• oppure lingua + regione ("en-US", "en-GB", "fr-CA").

BCP‑47 è uno standard con cui lavorano benissimo sia le API Intl del browser, sia la maggior parte delle librerie i18n. Quindi potete passare quasi direttamente openai/locale a Intl.NumberFormat, al motore di traduzione e dentro i vostri tool.

Dove è disponibile la locale nel widget

Nell’UI personalizzata renderizzata dentro ChatGPT, l’Apps SDK fornisce l’oggetto globale window.openai, in cui c’è locale.

Tipicamente appare così (TypeScript, Next.js 16, il nostro 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";
}

In un’app reale è più comodo creare un hook che funzioni sia nella sandbox di ChatGPT sia in 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;
}

Ora, in qualsiasi componente:

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

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

  return (
    <h2>
      {/* più tardi qui ci sarà t('titles.gift_search') */}
      {locale.startsWith("ru") ? "Selezione del regalo" : "Gift search"}
    </h2>
  );
}

Nella lezione 4 sposteremo con cura tutte le stringhe nei dizionari, ma già ora abbiamo agganciato la UI a un segnale reale proveniente dalla piattaforma, e non al casuale navigator.language. Questo hook è molto specifico; in un progetto reale conviene costruirlo sopra un meccanismo più generale di accesso ai globali di ChatGPT — ci torneremo in una sezione dedicata più sotto.

Dove è disponibile la locale in MCP/backend

Quando ChatGPT invoca uno strumento MCP, l’SDK passa _meta["openai/locale"] nella richiesta JSON‑RPC. Su un server TypeScript (il nostro MCP di GiftGenius) è di solito disponibile come secondo argomento dell’handler dello strumento.

Esempio:

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

const server = new McpServer();

server.registerTool(
  "suggest_gifts",
  {
    title: "Selezione dei regali",
    description: "Propone un elenco di regali in base alle preferenze",
    inputSchema: {
      type: "object",
      properties: {
        recipient: { type: "string" },
        budget: { type: "number" }
      },
      required: ["recipient", "budget"]
    }
  },
  async ({ input }, extra) => {
    const locale = extra?._meta?.["openai/locale"] || "en";
    // poi si può caricare il catalogo corretto
    const gifts = await loadGiftCatalog(locale);
    // ...
    return {
      content: [
        {
          type: "text",
          text: `Found ${gifts.length} gifts for locale ${locale}`
        }
      ],
      structuredContent: { gifts }
    };
  }
);

In questo modo locale vive lungo tutto lo stack: ChatGPT → Apps SDK → il vostro server MCP.

Insight

Ogni mcp-tool sul server ha un parametro extra, dove il server MCP inserisce tutti i dati che non sono finiti in inputSchema. Ecco un esempio di tale oggetto:

{
  sessionId: undefined,			// sempre undefined, usare `openai/subject` sotto
  _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 del computer dell'utente, può non coincidere con la lingua in chat
    'openai/userLocation': {		// posizione utente sufficientemente precisa
      city: 'London',
      region: 'London City',
      country: 'GB',
      timezone: 'Europe/London',
      latitude: '5.45466',
      longitude: '-0.52380'
    },
    timezone_offset_minutes: -240,	// offset del fuso orario
    'openai/subject': 'v1/sEtRuS92UEOPNdwzEUZORfeOKf7XSk2KZoIUGfAsb68BzZ8h5FAOgrH'	// questo è il 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',					// dominio nativo dell'applicazione
      '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'
    }
  },
}

Probabilmente alcune intestazioni sono state aggiunte da ngrok, ma ci sono comunque molti dati interessanti.

3. Segnale n. 2: _meta["openai/userLocation"] — geografia dell’utente

Struttura e significato

_meta["openai/userLocation"] è un oggetto con informazioni geografiche: paese, regione, città, fuso orario e persino coordinate. Più o meno così:

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

I campi principali che userete realmente in GiftGenius:

• country — codice paese ISO a due lettere, critico per assortimento e valuta;
• timezone — utile per formati di data/ora e promemoria.

Insight

Verificato sperimentalmente — la determinazione di userLocation funziona molto bene. I dati arrivano a ogni chiamata dell’MCP‑tool tramite il parametro extra._meta["openai/userLocation"]. Potete farci affidamento nello sviluppo delle vostre applicazioni.

Come usare userLocation negli strumenti MCP

Sul server MCP, userLocation si trova in _meta["openai/userLocation"] accanto a _meta["openai/locale"].

Estendiamo l’esempio del nostro strumento:

server.registerTool(
  "suggest_gifts",
  { /* schema come sopra */ },
  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 funzione loadGiftCatalog(locale, country) può già:

• selezionare il JSON corretto: gift_catalog.en-US.json, gift_catalog.ru-RU.json,
• filtrare i prodotti che non si possono spedire in quel paese,
• scegliere la valuta base.

Più avanti, nei moduli commerce, in base a country sceglierete le regole fiscali e mapperete gli SKU corretti, ma dal punto di vista architetturale vi appoggiate comunque allo stesso segnale — country.

Come userLocation completa la locale

Esempio classico:

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

La logica può essere questa:

• UI e suggerimenti — in inglese (rispettiamo la locale);
• formato della valuta e prezzi — euro, perché l’utente si trova fisicamente in Germania;
• lista dei regali — solo quelli consegnabili in DE.

In GiftGenius lo si può esprimere con una piccola funzione helper:

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";
}

E usarla su backend/frontend per formattare i prezzi:

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

Sul backend abbiamo già imparato a usare locale e country per scegliere catalogo e valuta. È poi importante far arrivare con cura gli stessi segnali alla UI nel widget, così che l’utente veda testi e prezzi nel formato atteso.

4. Come ottenere locale e userLocation nel widget GiftGenius

Abbiamo già visto come locale e userLocation vivono sul lato MCP e influenzano cataloghi e valuta. Ora vediamo come recuperare ordinatamente locale nel widget GiftGenius e usarlo direttamente nella UI React.

Importante: nel widget abbiamo accesso diretto solo a locale (tramite window.openai e gli hook dell’SDK). userLocation vive in _meta ed è usato sul lato MCP/backend — lo abbiamo già visto sopra.

Nell’Apps SDK, oltre a window.openai “grezzo”, ci sono utilità sotto forma di hook React. La documentazione descrive hook come useOpenAiGlobal("locale"), che portano i valori del contesto globale di ChatGPT nei componenti React.

Replichiamo da soli un hook così, per capire cosa succede sotto il cofano.

Hook di base useOpenAiGlobal

Prima abbiamo creato lo specifico useOpenAiLocale. Nella pratica è più comodo avere un unico hook universale per accedere ai globali di ChatGPT — su di esso è facile costruire sia useOpenAiLocale sia altri wrapper. Immaginiamo un hook del genere:

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

type OpenAiGlobals = {
  locale?: string;
  // in seguito si possono aggiungere theme, userAgent ecc.
};

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;
}

Ora useOpenAiGlobal("locale", "en") ci restituisce il valore corrente di locale con valore di default "en".

Uso nel widget GiftGenius

Creiamo un piccolo componente che mostra un saluto localizzato e la locale corrente per il 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")
      ? "Ciao! Ti aiuterò a trovare un bel regalo."
      : "Hi! I’ll help you find a great gift.";

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

Per ora niente dizionari o librerie i18n — arriveranno più avanti. È importante che già sappiamo prendere in modo affidabile la lingua da ChatGPT, e non da ipotesi casuali.

5. Quando è necessario chiedere esplicitamente la lingua all’utente

Se openai/locale e userLocation sono così potenti, possiamo non chiedere mai all’utente in che lingua vuole lavorare? Purtroppo, a volte serve comunque.

Quando i segnali non bastano

Ci sono alcune situazioni tipiche:

• L’account ChatGPT è in inglese (locale = "en"), ma l’utente scrive in russo. Il modello risponde in russo, ma la UI che fornite è in inglese.
• L’utente è in Germania (userLocation.country = "DE"), locale = "en", e voi siete pronti a fornire sia interfaccia tedesca sia inglese.
• L’app è critica per la lingua di comunicazione: psicoterapia, consulenze legali, formazione. In questi casi la precisione di comprensione è più importante del comfort dell’autodetect.

In tali casi è opportuno porre una domanda breve e cortese una sola volta all’inizio dello scenario, e poi ricordare la scelta.

Come chiedere la lingua senza essere invadenti

Di solito la formulazione è il più possibile semplice e visuale, ad esempio:

• «In quale lingua preferisci: English o Russo?»
• «Abbiamo determinato la tua lingua come English. Vuoi passare a un’altra?»

Nella ChatGPT App si può fare in due modi:

• Tramite la UI del widget: disegnare un piccolo selettore di lingua in alto.
• Tramite un messaggio di follow‑up in chat a nome dell’App: inviare un follow‑up testuale con la domanda e poi gestire la risposta.

Codice: scelta semplice della lingua in GiftGenius

Creiamo un componente‑selettore che:

• prende la lingua iniziale da locale,
• permette all’utente di scegliere tra ru ed en,
• memorizza la scelta nello stato del widget (per ora solo nello state di 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" ? "Lingua:" : "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>
  );
}

Nel widget principale di GiftGenius potrete quindi scegliere testi/dizionario in base a selectedLocale, e non ai dati “grezzi” provenienti da ChatGPT.

Nelle lezioni future sostituirete lo state locale con un archivio più robusto (per esempio propagherete la lingua scelta a MCP / Gateway tramite _meta["openai/subject"]), ma il pattern rimarrà lo stesso.

6. Come trasmettere locale e userLocation al backend e conservarli

I segnali arrivano da ChatGPT “dall’alto”, ma la storia non finisce qui. Bisogna poi portarli fino ai vostri strumenti e servizi, senza perderli per strada e senza costringere il modello a indovinare di nuovo la lingua.

Campo locale esplicito negli argomenti dei tool

La soluzione più affidabile è aggiungere locale (e, se volete, country) come campi separati in inputSchema dello strumento. Così il modello riceve un segnale esplicito: «bisogna compilare questo campo».

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) => {
    // Se il modello non ha compilato locale/country, facciamo fallback da _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";

    // ...
  }
);

Questo riduce la “magia” all’interno del server: vede chiaramente gli argomenti che il modello intende usare.

Memorizzazione della locale a livello di sessione/utente

Nell’architettura con MCP Gateway (moduli futuri) è prassi memorizzare lo “stato del client”: locale, currency, preferenze. Per ora è importante solo cogliere l’idea: si leggono una volta i segnali da ChatGPT — poi li si usa come parte dello stato di sessione, invece di ricalcolarli ogni volta.

Pseudo‑codice indicativo:

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

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

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

  // poi trasmettiamo locale/country al server MCP specifico
}

Nel contesto di questa lezione non serve implementare un Gateway; basta capire che locale e userLocation sono candidati naturali a far parte di questo “stato di sessione”.

Insight

Dati sperimentali: request._meta?.["openai/locale"] mostra la locale attualmente impostata dall’utente. La lingua di interazione si può ottenere come parametro del tool tramite inputSchema.

Ho impostato sul mio computer una locale EN, ma ho conversato con ChatGPT in tedesco (DE). Di conseguenza:

• request._meta?.["openai/locale"] era EN
• locale ottenuta come parametro del tool tramite inputSchema era DE

7. Locale vs rilevamento automatico della lingua dal testo

Talvolta agli sviluppatori viene l’idea: «Rileviamo semplicemente la lingua dal testo dell’utente, tanto l’LLM sa fare tutto». In pratica è quasi sempre peggio che affidarsi a openai/locale.

Le ragioni sono piuttosto concrete:

• l’utente può scrivere in una mescolanza di lingue;
• differenze sottili (uk-UA vs ru-RU) si rilevano male da un singolo messaggio;
• ChatGPT ha già fatto questo lavoro per voi e ha inviato locale.

L’autodetect è utile come fallback, se openai/locale arriva in una forma strana o è assente (cosa oggi rara), ma non conviene basarci la logica principale. Regola spiccia:

• prima guardiamo a openai/locale come “verità”;
• poi consideriamo userLocation (valuta, assortimento);
• solo in casi davvero controversi si può dare un’occhiata alla lingua dell’ultimo messaggio.

8. Diverse combinazioni di locale e userLocation: tabella degli scenari

Per fissare le idee, vediamo come dovrebbe comportarsi GiftGenius in vari scenari.

en-US

US

USD

uk-UA

UA

UAH

en

DE

EUR

ru-RU

DE

EUR

en

USD

Questa prospettiva tornerà utile più avanti, quando parleremo di commerce, ma è già evidente quanto sia facile cambiare il comportamento semplicemente fornendo locale e country diversi.

9. Piccolo diagramma del flusso dei segnali di locale

Per fare ordine, guardiamo uno schema semplificato:

flowchart TD
  U[Utente<br/>scrive un messaggio] --> C[ChatGPT]
  C -->|determina| L[openai/locale<br/>+ userLocation]
  L -->|trasmette| W["Widget (Next.js)"]
  L -->|trasmette via _meta| S[MCP Server]

  W -->|locale| UI[GiftGenius UI<br/>testi + formattazione dei numeri]
  S -->|locale + country| DATA[Cataloghi, prezzi, filtri]

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

È importante notare: in questo schema non compare da nessuna parte una modale «Scegli la lingua». Serve solo come livello aggiuntivo quando i segnali sono in conflitto con le aspettative dell’utente.

10. Pratica: cosa potete fare subito nella vostra App

Per non lasciare la lezione solo in teoria, un breve check‑list pratico per GiftGenius:

• Nel widget: aggiungere l’hook useOpenAiGlobal("locale") o analogo e, almeno in un punto, introdurre una biforcazione RU/EN per il testo.
• Nel server MCP: in uno degli strumenti esistenti (suggest_gifts) leggere _meta["openai/locale"] e _meta["openai/userLocation"], loggarli e usarli per scegliere il catalogo.
• Scrivere una semplice funzione deriveCurrency(locale, country) e usarla in un punto per formattare il prezzo.

Non serve costruire subito un motore i18n completo con 15 lingue — l’obiettivo ora è imparare a usare in modo corretto i segnali della piattaforma.

11. Errori tipici nella gestione di locale e userLocation

Errore n. 1: ignorare del tutto openai/locale e basarsi solo su navigator.language.
Lo fanno quelli abituati alle web app tradizionali. In ChatGPT l’utente potrebbe non aprire nulla nel browser e navigator.language dalla vostra parte è la lingua del server di tunneling o di Vercel, non quella dell’utente. Il risultato è che la UI è sempre “misteriosamente” in inglese, mentre ChatGPT vi invia stabilmente ru-RU.

Errore n. 2: chiedere ogni volta all’utente «in che lingua preferisci?»
Se in ogni chat la prima battuta del widget è un sondaggio sulla lingua, gli utenti iniziano a sentirsi in aeroporto, dove vengono chiesti cinque volte di fila se hanno dimenticato il bagaglio. La piattaforma conosce già lingua e regione — basta rispettare openai/locale e fare domande solo in caso di conflitto evidente (ad esempio richiesta in russo con locale = "en").

Errore n. 3: conservare la lingua scelta solo nella UI e non passarla agli strumenti MCP.
Il widget può essere in russo, ma il server continua a servire il catalogo in inglese perché non sa del cambio lingua. Pensate sempre al percorso end‑to‑end: se nella UI c’è un selettore, il suo risultato va portato al backend — o come argomento dello strumento, o tramite la sessione del Gateway.

Errore n. 4: “indovinare” la lingua solo dal testo dei messaggi ignorando openai/locale.
L’autodetect dal testo può funzionare bene… finché l’utente scrive un inglese pulito. Non appena ci sono lingue miste o frasi simili, il risultato inizia a oscillare. openai/locale è una valutazione già pronta e sufficientemente affidabile, fornita dalla piattaforma. Va considerata la fonte principale di verità, mentre il rilevamento dal testo solo un segnale aggiuntivo.

Errore n. 5: mescolare logica di business e localizzazione con if (locale === 'ru') { ... } sparsi ovunque.
In questa lezione lo facciamo ancora un po’ per semplicità, ma è importante pianificare fin da subito che stringhe, formati e cataloghi siano separati dalla logica di business. Altrimenti tra un paio di mesi vi ritroverete con codice in cui ogni funzione inizia con if (locale.startsWith("ru")), e aggiungere un’altra lingua sarà doloroso. Nella lezione 44 affronteremo proprio questo problema, ricordando che la fonte di locale l’abbiamo già e sappiamo usarla.