Lokalizacja narzędzi i opisów: wpływ na GPT oraz eksperymenty z zachowaniem

1. Jak model „widzi” twoje narzędzia

Zacznijmy od tego, że dla modelu tool — to wcale nie „twoja piękna funkcja w TypeScript”, lecz opis strukturalny w stylu:

• name: nazwa techniczna, na przykład "search_gifts";
• description: tekst w języku naturalnym, który wyjaśnia, kiedy i po co używać tego narzędzia;
• inputSchema: JSON Schema z polami, z których każde może mieć także description, typ, ograniczenia.

Bardzo uproszczając, model robi mniej więcej tak (pseudokod w „głowie” GPT):

1. Przeczytać zapytanie użytkownika (w dowolnym języku).
2. Przeczytać listę tools: name + description + opisy argumentów.
3. Dla każdego tool oszacować, czy pasuje do zadania.
4. Jeśli potrzebny jest tool — wygenerować JSON z argumentami zgodnie ze schematem.
5. W przeciwnym razie — odpowiedzieć tekstem.

Wynikają stąd dwa ważne wnioski.

Po pierwsze, pole description narzędzia to nie komentarz dla deweloperów, lecz interfejs między modelem a twoim backendem. Jeśli opis narzędzia jest mętny, niepełny albo w języku, który nie pokrywa się z językiem użytkownika, model częściej będzie się mylić: wybierze nie ten tool, wstawi nie te argumenty, albo odpowie tekstem tam, gdzie narzędzie było potrzebne.

Po drugie, description pól w JSON Schema jest tak samo ważne, jak opis samego narzędzia. Model naprawdę czyta description każdego właściwości i na tej podstawie decyduje, do którego pola trafi „wiek”, do którego „budżet”, a gdzie w ogóle powinien znaleźć się id.

Mini‑przykład dla GiftGenius

Weźmy nasze narzędzie search_gifts. W pierwotnej, „tylko EN” wersji mogło wyglądać tak:

// server/tools/searchGifts.ts
export const searchGiftsTool = {
  name: "search_gifts",
  description: "Search for gift ideas based on user preferences.",
  inputSchema: {
    type: "object",
    properties: {
      recipient_age: {
        type: "integer",
        description: "Age of the recipient in years.",
      },
      budget: {
        type: "number",
        description: "Maximum budget in user's currency.",
      },
    },
    required: ["budget"],
  },
};

Jeśli użytkownik pisze: „Potrzebny prezent dla mamy, ma 60 lat, budżet do 3000 rubli”, model powinna:

1. Zrozumieć, że search_gifts — to właściwe narzędzie.
2. Zrozumieć, że „60 lat” należy umieścić w recipient_age, a „3000 rubli” — w budget.

Dopóki opisy są tylko po angielsku, GPT i tak da radę, ale wymaga to od niej dodatkowego „wewnętrznego tłumaczenia”. Przy wielu językach i słabszych modelach obniża to dokładność.

2. Problem „angielskich opisów” w wielojęzycznym App

W module 9 wspominaliśmy już ogólną „mapę lokalizacji”: widżet UI, katalogi, błędy, treści commerce. Teraz zawęzimy fokus i zobaczymy, co się dzieje, gdy opisy narzędzi są tylko po angielsku, a użytkownik rozmawia np. po rosyjsku lub hiszpańsku — wtedy zaczyna się lekki chaos.

Typowy scenariusz:

1. Użytkownik: „Dobierz prezent dla znajomego‑informatyka, budżet do 50 euro”.
2. Model patrzy na listę tools, widzi opisy tylko po EN.
3. Jeśli zapytanie też po EN — wszystko gra.
4. Jeśli zapytanie w innym języku, musi:
   • najpierw zrozumieć zapytanie,
   • mentalnie zestawić je z angielskimi opisami,
   • wybrać narzędzie,
   • a potem jeszcze wyekstrahować argumenty do JSON‑a.

W mocnych modelach to jeszcze jakoś działa, ale:

• częściej rośnie odsetek odpowiedzi bez wywołania tools — model „myśli”, że poradzi sobie sam;
• wyższe ryzyko błędów w argumentach (zwłaszcza gdy ważna jest waluta, jednostki miary, ograniczenia regionalne);
• logika trasowania między kilkoma tools staje się mniej niezawodna (narzędzie „nie w sedno”).

Prosty przykład błędu: w polu budget oczekuje się „w walucie użytkownika”, a opis w ogóle o tym nie wspomina. Model zakłada USD domyślnie i wysyła do backendu 50 dolarów tam, gdzie użytkownik wyraźnie chciał 50 euro.

I tutaj wchodzi do gry lokalizacja opisów.

3. Podejścia do lokalizacji: osobne tools vs wielojęzyczne opisy

Istnieją dwa podstawowe podejścia architektoniczne i oba mają sens.

Osobne narzędzia dla każdego języka

W tym wariancie tworzysz kilka tools z różnymi nazwami, każdy ze „swoim” językiem opisów.

Dla GiftGenius może to wyglądać tak:

export const searchGiftsEn = {
  name: "search_gifts_en",
  description: "Search for gift ideas based on user preferences.",
  // ...
};

export const searchGiftsRu = {
  name: "search_gifts_ru",
  description: "Dobór prezentów na podstawie preferencji użytkownika.",
  // ...
};

Dla ChatGPT App ważne jest, aby lista dostępnych tools zależała od locale. Jeśli locale = "ru-RU", wówczas twój serwer MCP powinien zwrócić tylko search_gifts_ru. Jeśli locale = "en-US", — tylko search_gifts_en.

Plusy tego podejścia: opisy są maksymalnie „czyste” i jednojęzyczne. Możesz w ogóle myśleć o App jako o kilku jednojęzycznych wersjach, każda z własnymi promptami i opisami. Jest to wygodne, gdy języków jest mało, a rynki mocno się różnią.

Minusy — dublowanie logiki i trudności z analityką. W kodzie backendu najpewniej i tak będzie jeden i ten sam handler, natomiast na poziomie MCP/manifestów — już dwa różne narzędzia. Trzeba pamiętać o aktualizowaniu obu opisów przy każdej zmianie.

Insight (dane na 2025‑12‑01)

Eksperymentalnie nie stwierdzono zauważalnych przewag description w języku użytkownika/locale. Narzędzia były wybierane z praktycznie taką samą częstością, niezależnie od języka opisu. Gdy były 2 narzędzia o podobnych opisach (w różnych językach), myliło to ChatGPT.

Dodatkowo, twoja aplikacja będzie musiała przejść review przy rejestracji w Store. Dlatego polecam po prostu pisać wszystkie opisy tools i opisy argumentów po angielsku.

Jednak jeśli w przyszłości w ChatGPT będą tysiące aplikacji i konkurencja o „wybór narzędzia” wzrośnie, możliwe, że opisy w locale użytkownika będą zyskiwać przewagę. Czekamy na pojawienie się Tool Search Optimization.

Jedno narzędzie z wielojęzycznymi opisami

W drugim wariancie zostawiasz jedną name (np. search_gifts), ale jego description oraz opisy pól JSON Schema robisz wielojęzyczne.

Możliwe są różne style:

1. Krótka dwujęzyczna forma:

   description: "Search gifts for a recipient. / Wyszukiwanie prezentów na podstawie preferencji odbiorcy.",

2. Wydzielone bloki per język:

   description: "[EN] Search for gifts based on user preferences. [RU] Dobór prezentów na podstawie preferencji odbiorcy.",

3. Oddzielne pola sklejone w jeden string (mniej wygodne):

   description: `EN: ${enDescription} RU: ${ruDescription}`,

Plusy — jedno narzędzie, jedno źródło prawdy (single source of truth), łatwiej rozwinąć architekturę z MCP Gateway: zawsze eksponujesz ten sam interfejs dla ChatGPT, niezależnie od języka rozmowy użytkownika.

Minusy: opisy robią się dłuższe. Jeśli „mieszać” języki nieuważnie, model może się nieco gubić — zwłaszcza gdy angielski i lokalny tekst idą wymieszane bez wyraźnych oznaczeń [EN], [RU].

Dla projektu edukacyjnego pokroju GiftGenius rekomendujemy wariant hybrydowy: zostawić opisy głównie po angielsku, ale dodać zwięzłe objaśnienie w języku lokalnym, a całą właściwą „semantykę” (jaki język używać, jak zwracać się do użytkownika) przenosić przez argumenty (locale) i system‑prompt.

4. Lokalizacja JSON Schema: opisy pól

Schodzimy teraz głębiej: do samych argumentów narzędzia.

W JSON Schema dla każdego pola można (i warto) dodać description. Model czyta ten tekst, gdy generuje JSON do wywołania narzędzia.

Dla GiftGenius można to zrobić tak:

export const searchGiftsTool = {
  name: "search_gifts",
  description:
    "Search gifts based on user preferences (RU: dobór prezentów na podstawie preferencji odbiorcy).",
  inputSchema: {
    type: "object",
    properties: {
      recipient_age: {
        type: "integer",
        description:
          "Recipient age in years. RU: wiek odbiorcy (liczba całkowita).",
      },
      budget: {
        type: "number",
        description:
          "Maximum budget in user's currency. RU: maksymalny budżet w walucie użytkownika.",
      },
      locale: {
        type: "string",
        description:
          "User locale (e.g. 'en-US', 'ru-RU'). RU: język interfejsu i odpowiedzi.",
      },
    },
    required: ["budget", "locale"],
  },
};

Kilka praktycznych obserwacji.

Po pierwsze, nazwy pól (recipient_age, budget, locale) zwykle pozostają po angielsku. Tłumaczy się właśnie description. To ważne, aby format JSON nie zmieniał się między językami i by nie trzeba było utrzymywać dwóch różnych kontraktów.

Po drugie, w description warto jawnie podać walutę, jednostki i istotne ograniczenia. Zdecydowanie zmniejsza to liczbę „krzywych” argumentów.

Po trzecie, jeśli używasz już MCP Gateway, możecie uzgodnić, że automatycznie przekazuje on locale do argumentów narzędzia, dzięki czemu model nie musi wstawiać go samodzielnie. Nawet w takim przypadku pamiętanie o opisie locale jest pomocne: model i tak lepiej rozumie, czym jest ten parametr i po co.

5. Jak wybierać język opisów: strategie dla realnego App

Teraz najważniejsze pytanie praktyczne: który język uczynić podstawowym dla opisów i kiedy warto lokalizować je w całości?

Rekomendacje i realne doświadczenia pokazują, że modele GPT nadal najlepiej działają w kontekście angielskim, więc wielu deweloperów zostawia opisy tylko po EN. Ale dla wielojęzycznego App może to być rozwiązanie kompromisowe.

Przeanalizujmy kilka strategii.

Tylko opisy EN

Najprostszy wariant — wszystko po angielsku.

Plusy: jedna baza kodu, jeden język utrzymania, łatwiej pisać dobre, precyzyjne sformułowania. Model jest „szczęśliwy”, gdy wszystko wokół jest po angielsku.

Minusy: dla użytkowników piszących w innych językach jakość wyboru narzędzi i argumentów może być niższa. Zwłaszcza w „leniwszych” modelach lub przy złożonych narzędziach z wieloma parametrami.

EN + krótki lokalny dopisek

Podejście kompromisowe: główny opis po EN, a na końcu — krótki blok w języku lokalnym, który pomaga modelowi skojarzyć słowa użytkownika z argumentami.

Przykład:

description:
  "Search for gifts based on user preferences. RU: narzędzie dobiera prezenty na podstawie opisu odbiorcy, jego wieku i budżetu.",

Dla JSON Schema:

description:
  "Age of the recipient in years. RU: wiek odbiorcy (w latach).",

Plusy: model wciąż funkcjonuje w „angielskim” świecie, ale ma podpowiedź w języku użytkownika.

Minusy: opisy stają się dłuższe, ale zwykle nie jest to krytyczne.

Pełna lokalizacja opisów według locale

Najbardziej rozbudowane podejście: opisy narzędzi i pól zmieniają się w zależności od locale, które znasz z ChatGPT. Dla en-US zwracasz czysto angielskie opisy, dla ru-RU — czysto rosyjskie, a dla de-DE — niemieckie.

To już nie „jedno JSON Schema na zawsze”, tylko zestaw schematów, które MCP/Gateway wybiera w locie.

Na poziomie MCP wygląda to tak:

function getSearchGiftsToolDescription(locale: string) {
  if (locale.startsWith("ru")) {
    return {
      name: "search_gifts",
      description: "Dobór prezentów na podstawie preferencji odbiorcy.",
      // ru‑schema...
    };
  }
  return {
    name: "search_gifts",
    description: "Search for gifts based on user preferences.",
    // en‑schema...
  };
}

Plusy: model widzi interfejs w tym samym języku, w jakim pisze użytkownik. To maksymalna wygoda.

Minusy: rośnie złożoność utrzymania i testowania. Trzeba zbudować proces gwarantujący, że wszystkie zlokalizowane warianty opisów pozostają spójne znaczeniowo i że nie zapomnisz zaktualizować np. niemieckiego schematu po dodaniu nowego pola do angielskiego.

6. Implementacja w naszej aplikacji GiftGenius

Przejdźmy do konkretów. Zrobimy w GiftGenius wariant hybrydowy: jedno narzędzie search_gifts, opisy głównie po EN, ale z rosyjskimi objaśnieniami, plus argument locale.

Załóżmy, że masz serwer MCP w TypeScript, który opisuje tools w stylu MCP SDK.

// mcp/tools/searchGifts.ts
import { z } from "zod";

export const searchGiftsInputSchema = z.object({
  recipient_age: z
    .number()
    .int()
    .describe(
      "Age of the recipient in years. RU: wiek odbiorcy (liczba całkowita)."
    ),
  budget: z
    .number()
    .describe(
      "Maximum budget in user's currency. RU: maksymalny budżet w walucie użytkownika."
    ),
  locale: z
    .string()
    .describe(
      "User locale (e.g. 'en-US', 'ru-RU'). RU: język interfejsu i odpowiedzi."
    ),
});

export const searchGiftsTool = {
  name: "search_gifts",
  description:
    "Search for gifts based on user preferences (RU: dobór prezentów na podstawie preferencji odbiorcy).",
  inputSchema: searchGiftsInputSchema,
  // execute(...) ...
};

Ważne, że:

• locale jest obowiązkowe. Jeśli widżet je zna (a znamy z _meta["openai/locale"]), to albo sam je wstawi do wywołania callTool, albo MCP Gateway zrobi to automatycznie po swojej stronie;
• opisy już zawierają rosyjskie słowa kluczowe „wiek”, „budżet”, „język interfejsu”, dzięki czemu modelowi łatwiej zrozumieć, co z zapytania użytkownika gdzie włożyć.

Po stronie Apps SDK możesz np. mieć funkcję, która woła ten tool bezpośrednio (jeśli włączono widgetAccessible), przekazując locale z widżetu.

// widget/hooks/useSearchGifts.ts
export async function searchGiftsFromWidget(params: {
  recipientAge: number;
  budget: number;
  locale: string;
}) {
  const openai = (window as any).openai;
  const result = await openai.callTool("search_gifts", {
    recipient_age: params.recipientAge,
    budget: params.budget,
    locale: params.locale,
  });
  return result;
}

To spięcie wzmacnia architekturę: locale przyszło z ChatGPT → trafi do tool → ten wybierze właściwy katalog i formaty cen, które następnie ładnie wyrenderujesz na froncie.

7. Eksperymenty z zachowaniem: jak mierzyć wpływ lokalizacji

Teraz najciekawsze: jak sprawdzić, że lokalizacja tools i opisów faktycznie poprawia zachowanie modelu, a nie na darmo poświęcasz czas na tłumaczenia?

Można zrobić mały „eksperyment naukowy” bezpośrednio w Dev Mode na GiftGenius.

Dwie wersje App: base vs localized

Przygotuj dwie konfiguracje swojej aplikacji:

• base — opisy narzędzi i JSON Schema tylko po EN;
• localized — opisy EN+RU (albo pełne wersje ru, jeśli jesteś gotów).

Resztę (katalogi, UI, prompty) zostaw taką samą, by nie mieszać efektów.

Dla prostoty możesz:

• w Dev Mode (a tym bardziej w Store) trzymać tylko wersję localized;
• a base uruchamiać lokalnie w osobnej gałęzi i porównywać wyniki na wcześniej przygotowanym zestawie zapytań.

Co mierzyć

Są trzy kluczowe metryki.

Pierwsza — częstość poprawnych wyborów narzędzi. Dla zestawu testowych zapytań po rosyjsku (i/lub innym języku) sprawdzasz, ile razy model:

• w ogóle zdecydował się wywołać narzędzie, gdy było to potrzebne;
• wybrał właśnie search_gifts, a nie inny tool.

Druga — poprawność argumentów. Sprawdzasz, jak często JSON wywołania odpowiada oczekiwaniom: pola nie są pomylone, budżet w odpowiedniej walucie, wiek to jawnie liczba całkowita, locale nie zginęło.

Trzecia — liczba dziwnych lub bezsensownych wywołań. Na przykład model wywołuje search_gifts dla pytania „która jest teraz godzina?” albo wstawia recipient_age: 3000 zamiast budżetu.

Testować można i ręcznie, i przez logi MCP/Agents — logi i tak przydadzą się w przyszłości, więc lepiej przyzwyczaić się do takiej analityki już teraz.

Jak zorganizować ręczny zestaw testowy

Możesz przygotować niewielki „golden prompt set” dla lokalizacji:

1. "Potrzebuję niedrogiego prezentu do 30 euro dla dziewczynki 10 lat, lubi rysować."
2. "Dobierz prezent dla kolegi‑programisty, 35 lat, budżet 100 $."
3. "Potrzebny prezent dla babci na jubileusz, 70 lat, budżet do 5000 rubli."

I przepuścić je przez obie wersje App (base i localized), obserwując:

• jakie tools wybiera model;
• jakie argumenty podstawia;
• jak zmienia się tekst odpowiedzi, jeśli narzędzie nie zostało wywołane.

Półprofesjonalny trik: można zrobić prostą obudowę skryptową, która będzie puszczać te zapytania przez ChatGPT API, ale w ramach kursu wystarczy tryb ręczny w Dev Mode. Osobna kategoria zapytań, którą szczególnie warto włączyć do takiego zestawu, to wiadomości mieszane językowo i dziwne kombinacje locale. Poświęcimy im oddzielny blok.

Jeśli rozwijasz poważną aplikację komercyjną i mówimy o milionach dolarów, to koniecznie przetestuj te kwestie konkretnie dla swojej aplikacji. Moduł 20 poświęcony jest profesjonalnej pracy z „golden prompt set” — koniecznie zgłęb ten temat.

8. Mieszane języki i dziwne kombinacje locale

Nic tak nie bawi dewelopera LLM, jak użytkownik piszący jednocześnie w dwóch językach. Na przykład:

"Potrzebny prezent for my friend, on lubi Star Wars, budget 100 €"

Wiemy już, że model jest wielojęzyczny i najczęściej sobie poradzi. Ale przy mieszaniu języków oraz „angielskich” opisach rośnie prawdopodobieństwo błędu.

Jest kilka typowych sytuacji.

Pierwsza — użytkownik pisze po RU, a opisy narzędzi są po EN. Model może zrozumieć, ale czasem się myli, zwłaszcza przy specyficznej terminologii (nazwy kategorii, rzadkie etykiety pól).

Druga — locale = "ru-RU", ale użytkownik z jakiegoś powodu pisze po angielsku. ChatGPT przysłał ci sygnały, że interfejs lepiej budować po rosyjsku, ale faktyczny język tekstu to EN. Można:

• wciąż zwracać rosyjskie opisy, uznając locale za prawdę nadrzędną;
• albo zaimplementować wykrywanie języka wiadomości jako sygnał dodatkowy i dostosowywać opisy do faktycznego języka.

Trzecia — locale = "en", a użytkownik czasem wtrąca rosyjskie słowa. W takim przypadku, co do zasady, anglojęzyczne opisy czują się świetnie.

W praktyce wystarczy wybrać jedną, jasną politykę. Na przykład:

• jeśli locale zaczyna się od "ru" — dodajesz rosyjskie fragmenty do opisów;
• jeśli nie — opisy są czysto angielskie.

Jasna reguła jest o tyle użyteczna, że możesz celowo testować każdą gałąź, zamiast zgadywać, czemu dziś opisy okazały się w takim czy innym języku.

9. Dokumentacja, proces i „kanoniczny” język

Lokalizacja opisów to nie jednorazowy akt, lecz proces. Użytkownicy lubią, gdy pojawiają się funkcje, a wy — gdy nic starego się nie psuje. Dlatego warto z góry ustalić:

• który język uznać za „kanoniczny”, względem którego tworzyć wszystkie tłumaczenia;
• gdzie przechowywać zlokalizowane opisy;
• jak sprawdzać spójność.

Zazwyczaj rolę języka kanonicznego pełni angielski. Wszystkie nowe narzędzia i pola najpierw opisuje się po EN, przechodzą review, a dopiero potem są lokalizowane na pozostałe języki. W bazie kodu można to wyrazić tak:

• plik tools.en.json z pełnym opisem name/description/pól;
• pliki tools.ru.json, tools.de.json jako „derywaty” dla konkretnych języków;
• niewielki generator, który składa finalne JSON Schema dla MCP na bazie tych słowników.

W prostym wariancie można na razie obyć się stringami w kodzie, ale strukturyzować je tak, żeby potem łatwo wynieść do osobnych słowników.

Warto pamiętać, że opisy to także tekst produktu. Należy je reviewować tak samo rygorystycznie jak teksty w UI: sprawdzać zrozumiałość, brak dwuznaczności i zbędnej „wody”. Zwłaszcza w wariancie wielojęzycznym nie chcemy, by rosyjski dopisek przeczył angielskiej części opisów.

10. Schemat wizualny: jak język przechodzi przez stack

Aby wszystko poukładać w głowie, spójrzmy na uproszczony schemat przepływu zapytania z uwzględnieniem lokalizacji tools.

flowchart TD
    U[Użytkownik pisze po RU] --> C[ChatGPT UI]
    C -->|"_meta.openai/locale = 'ru-RU'"| W[Widżet GiftGenius]
    W -->|"locale = 'ru-RU'"| T["Opisy narzędzi (EN+RU)"]
    T --> M[Model GPT]
    M -->|callTool search_gifts| MCP[MCP / Gateway]
    MCP -->|"locale = 'ru-RU'"| B[Backend / katalogi RU]
    B --> MCP --> M2["Model GPT (odpowiedź)"]
    M2 --> C2[ChatGPT UI + widżet RU]

Tutaj język użytkownika i locale determinują:

• w jakim języku widżet pokazuje UI;
• jakie opisy narzędzi i pól widzi model;
• jakie katalogi i waluty wybiera backend;
• jak formatowane są odpowiedzi (przez model i widżet).

11. Typowe błędy przy lokalizacji tools i opisów

Błąd №1: uznać pole description za „techniczne” i w ogóle go nie lokalizować.
Takie podejście działa, dopóki masz tylko użytkowników anglojęzycznych. Gdy pojawiają się inne języki, model częściej odpowiada bez tools lub przekazuje krzywe argumenty według schematów. Niby przetłumaczyłeś UI, a App zachowuje się „po angielsku”.

Błąd №2: zmieniać nazwy pól w JSON zależnie od języka.
Czasem kusi, by zrobić age → vozrast, budjet itd. To prowadzi do koszmaru po stronie backendu: różne schematy, różne formaty, trudna analiza logów. Lepiej zostawić name pól stabilne i lokalizować tylko opisy.

Błąd №3: chaotycznie mieszać języki w opisach.
Frazy w stylu „Wyszukiwanie gifts według preferencji usera” nie pomagają ani modelowi, ani człowiekowi. Jeśli robisz opisy wielojęzyczne, rozdzielaj bloki wyraźnie: [EN] ... [RU] .... Wtedy model widzi strukturę, a nie „papkę”.

Błąd №4: nie przekazywać locale do narzędzi.
Nawet jeśli zlokalizowałeś opisy, ale nie przekazujesz locale do tool (lub MCP Gateway go nie podaje), backend nie wie, jakie katalogi i formaty zastosować. W efekcie model stara się być „wielojęzyczny”, a serwer zwraca dane tylko dla jednego rynku.

Błąd №5: automatyczne tłumaczenie opisów bez review.
Wydaje się, że można przepuścić opisy przez automatyczny translator i cieszyć się życiem. W praktyce takie tłumaczenia bywają nieprecyzyjne, zwłaszcza w zakresie terminów i argumentów. W rezultacie model może błędnie interpretować sens narzędzia lub pola. Lepiej mieć jeden dobrze przemyślany wariant EN i starannie zlokalizowane wersje niż dwadzieścia „automatycznych” języków.

Błąd №6: brak testów/eksperymentów dla różnych locali.
Jeśli nie sprawdzasz zachowania App choćby na podstawowym zestawie zapytań dla każdej locali, wszystko może „psuć się” miesiącami, aż do przyjścia pierwszego realnego użytkownika z danym językiem. Niewielki golden‑zestaw zapytań i ręczne testy w Dev Mode znacząco zmniejszają to ryzyko.

Błąd №7: rozjazd między kanonicznymi i zlokalizowanymi opisami.
Dodałeś nowe pole occasion („okazja” prezentu) do angielskiego schematu, ale zapomniałeś zaktualizować rosyjski. W efekcie w RU‑locale model w ogóle nie wie o tym polu i nie wypełnia go, choć backend już go oczekuje. Na przykład serwer próbuje filtrować prezenty po okazji, dostaje null i pokazuje zbyt ogólną listę — po EN wszystko działa, a po RU zachowanie „po cichu” się psuje. Dlatego wszelkie zmiany opisów narzędzi powinny przechodzić przez prosty, lecz regularny proces: zaktualizować EN → zaktualizować locale → krótko puścić testy.