Tools və description-un lokallaşdırılması: GPT-yə təsir və davranışla bağlı eksperimentlər

1. Model alətlərinizi necə “görür”

Əvvəlcə bunu dəqiqləşdirək ki, model üçün tool — heç də “TypeScript-də sizin gözəl funksiyanız” deyil, üslub etibarilə belə bir struktur təsviridir:

• name: texniki ad, məsələn "search_gifts";
• description: bu alətin nə vaxt və nə üçün istifadə olunacağını izah edən insani dilə yazılmış mətn;
• inputSchema: sahələri olan JSON Schema; bu sahələrin hər birində də description, tip, məhdudiyyətlər ola bilər.

Çox sadə dillə desək, model təxminən belə edir (GPT-nin beynində psevdokod):

1. İstifadəçi sorğusunu oxumaq (istənilən dildə).
2. Tools siyahısını oxumaq: name + description + arqument təsvirləri.
3. Hər tool üçün tapşırığa uyğun olub-olmadığını qiymətləndirmək.
4. Tool lazımdırsa — sxemə uyğun arqumentlərlə JSON yaratmaq.
5. Əks halda — mətni cavab kimi qaytarmaq.

Buradan iki vacib nəticə çıxır.

Birincisi, alətin description sahəsi — bu, tərtibatçılar üçün şərh deyil, model ilə sizin backend-iniz arasında interfeysdir. Əgər alətin təsviri qeyri-müəyyəndirsə, natamamdırsa və ya istifadəçinin dili ilə üst-üstə düşməyən dildədirsə, model daha çox səhv edəcək: düzgün olmayan tool, yanlış arqumentlər, alətlər lazım olan yerdə alətsiz cavab və s.

İkincisi, JSON Schema-dakı sahələrin description hissəsi ən azı alətin təsviri qədər vacibdir. Model həqiqətən də hər xüsusiyyətin description-unu oxuyur və onun əsasında “yaşı” hansı sahəyə, “büdcəni” hansı sahəyə qoyacağını, habelə harada id olmalı olduğunu müəyyənləşdirir.

GiftGenius üçün mini‑nümunə

search_gifts alətimizi götürək. İlkin, “yalnız EN” versiyası təxminən belə görünə bilərdi:

// 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"],
  },
};

İstifadəçi belə yazırsa: “Anama hədiyyə lazımdır, onun 60 yaşı var, büdcə 3000 rubladək”, model aşağıdakıları etməlidir:

1. search_gifts — uyğun alət olduğunu anlamaq.
2. “60 yaş”ı recipient_age sahəsinə, “3000 rubl”u isə budget sahəsinə qoymağı başa düşmək.

Təsvirlər yalnız ingiliscə olanda belə, GPT yenə də öhdəsindən gəlir, amma bu, ondan əlavə “daxili tərcümə” tələb edir. Bir neçə dildə və zəif modellərdə bu, dəqiqliyə mənfi təsir edir.

2. Çoxdilli tətbiqdə “ingiliscə təsvirlər” problemi

9-cu moduldakı lokallaşdırma “xəritəsini” — UI vidceti, kataloqlar, xətalar, kommersiya mətnləri — yüngülcə yada salmışdıq. İndi diqqəti daraldıb baxaq: alətlərin təsvirləri yalnız ingiliscə yazılanda, istifadəçi isə, deyək ki, rusca və ya ispanca yazanda nə baş verir — elə burada kiçik bir xaos başlayır.

Tipik ssenari:

1. İstifadəçi: “IT sahəsində olan dostum üçün hədiyyə seç, büdcə 50 avroyadək”.
2. Model tools siyahısına baxır, təsvirlər yalnız EN dilindədir.
3. Əgər sorğu da EN-dirsə — hər şey qaydasındadır.
4. Əgər sorğu başqa dildədirsə, modelə bunları etmək lazım gəlir:
   • əvvəlcə sorğunu anlamaq,
   • daxildə onu ingiliscə təsvirlərlə tutuşdurmaq,
   • aləti seçmək,
   • sonra da JSON-da arqumentləri çıxarmaq.

Güclü modellərdə bu hələlik işləyir, amma:

• çox vaxt tools çağırışı olmayan cavabların payı artır — model “düşünür” ki, özü öhdəsindən gələr;
• arqumentlərdə səhv ehtimalı yüksəlir (xüsusilə valyuta, ölçü vahidləri, regional məhdudiyyətlər vacib olanda);
• bir neçə tool arasında marşrutlaşdırma məntiqi daha az etibarlı olur (alət “güllədən yan keçir”).

Sadə bir səhv nümunəsi: budget sahəsində “istifadəçinin valyutası” gözlənilir, amma təsvir bunu ümumiyyətlə demir. Model bunun defolt olaraq USD olduğunu qərarlaşdırır və backend-ə istifadəçinin açıq-aydın 50 avro istədiyi yerdə 50 dollar göndərir.

Və burada təsvirlərin lokallaşdırılması işə düşür.

3. Lokallaşdırma yanaşmaları: ayrı tools vs çoxdilli təsvirlər

İki əsas arxitektura yanaşması var və hər ikisinin yaşamaq haqqı var.

Hər dil üçün ayrı alətlər

Bu variantda siz fərqli adlarla bir neçə tool hazırlayırsınız, hər biri “öz” dilində təsvirlərə sahib olur.

GiftGenius üçün bu, belə görünə bilər:

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

export const searchGiftsRu = {
  name: "search_gifts_ru",
  description: "İstifadəçinin üstünlüklərinə əsasən hədiyyələrin seçimi.",
  // ...
};

ChatGPT App üçün vacibdir ki, mövcud tools siyahısı locale-dən asılı olsun. Əgər locale = "ru-RU" dirsə, MCP-serveriniz yalnız search_gifts_ru qaytarmalıdır. Əgər locale = "en-US" dirsə — yalnız search_gifts_en.

Üstünlüklər: descriptions maksimal dərəcədə “təmiz” və təkdilli olur. Tətbiqi ümumiyyətlə bir neçə təkdilli versiya kimi düşünə bilərsiniz, hər birinin öz prompts və təsvirləri var. Dil sayı az olanda və bazarlar ciddi fərqlənəndə bu rahatdır.

Çatışmazlıqlar — məntiqin dublikatı və analitika çətinlikləri. Backend kodunda yəqin ki, yenə də eyni handler olacaq, amma MCP/manifest səviyyəsində artıq iki fərqli alət var. Hər dəyişiklikdə hər iki təsviri yeniləməyi unutmaq olmaz.

Insight (2025-12-01 tarixinə dair məlumat)

Eksperimental olaraq fərdi istifadəçi dili/locale ilə eyni dildə olan description-ların görünər üstünlüyü aşkarlanmayıb. Alətlər, təsvirlərin dilindən asılı olmayaraq, demək olar ki, eyni tezliklə seçilirdi. Oxşar təsvirləri olan (fərqli dillərdə) 2 alət olduqda, onlar ChatGPT-ni çaşdırırdı.

Bundan əlavə, tətbiqiniz Store-da qeydiyyatdan keçərkən review-dan keçməlidir. Ona görə də məsləhətim — bütün tool description və argument description mətnlərini ingiliscə yazmaqdır.

Lakin gələcəkdə ChatGPT-də minlərlə tətbiq olarsa və “alət seçimi” uğrunda rəqabət artsa, ola bilsin ki, istifadəçinin locale dilində olan description üstünlük qazansın. Tool Search Optimization-in yaranmasını gözləyirik.

Çoxdilli descriptions ilə tək alət

İkinci variantda siz bir name saxlayırsınız (məsələn, search_gifts), amma onun description-u və JSON Schema sahələrinin təsvirlərini çoxdilli edirsiniz.

Müxtəlif üslublar var:

1. Qısa ikidilli forma:

   description: "Search gifts for a recipient. / Alıcı üçün hədiyyə axtarışı.",

2. Dillərə görə işarələnmiş bloklar:

   description: "[EN] Search for gifts based on user preferences. [AZ] İstifadəçinin üstünlüklərinə əsasən hədiyyə seçimi.",

3. Ayrı sahələr, sətirdə birləşdirilmiş (daha az rahat):

   description: `EN: ${enDescription} AZ: ${azDescription}`,

Üstünlüklər — tək alət, yeganə həqiqət mənbəyi (single source of truth), MCP Gateway arxitekturasını yaymaq daha asandır: ChatGPT üçün həmişə eyni interfeysi göstərirsiniz, istifadəçi hansı dildə danışırsa-danışsın.

Çatışmazlıqlar: təsvirlər uzanır. Dilləri “qarışıq” şəkildə əlavə etsəniz, model bir qədər çaşa bilər — xüsusilə ingilis və lokal mətn açıq [EN], [AZ] işarələri olmadan iç‑içə gedəndə.

GiftGenius kimi tədris layihəsi üçün biz hibrid variant tövsiyə edirik: təsvirləri əsasən ingiliscə saxlayın, ancaq sonda lokal dildə qısa izah əlavə edin, dil seçimi və istifadəçi ilə müraciət qaydası kimi “semantikanı” isə arqumentlər (locale) və system‑prompt vasitəsilə ötürün.

4. JSON Schema lokallaşdırması: sahələrin təsviri

İndi daha dərinə — alətin arqumentlərinə keçək.

JSON Schema-da hər sahə üçün description göstərmək olar (və lazımdır). Model bu sətri alət çağırışı üçün JSON yaradan zaman oxuyur.

GiftGenius üçün bunu belə edə bilərsiniz:

export const searchGiftsTool = {
  name: "search_gifts",
  description:
    "Search gifts based on user preferences (AZ: alıcının üstünlüklərinə əsasən hədiyyə seçimi).",
  inputSchema: {
    type: "object",
    properties: {
      recipient_age: {
        type: "integer",
        description:
          "Recipient age in years. AZ: alıcının yaşı (tam ədəd, illərlə).",
      },
      budget: {
        type: "number",
        description:
          "Maximum budget in user's currency. AZ: istifadəçinin valyutasında maksimal büdcə.",
      },
      locale: {
        type: "string",
        description:
          "User locale (e.g. 'en-US', 'ru-RU'). AZ: interfeys və cavabların dili.",
      },
    },
    required: ["budget", "locale"],
  },
};

Bir neçə praktiki müşahidə.

Birincisi, sahələrin adları (recipient_age, budget, locale) adətən ingiliscə qalır. Tərcümə edilən məhz description-dur. Bu vacibdir ki, JSON format dilə görə dəyişməsin və siz iki fərqli müqaviləni dəstəkləməli olmayasınız.

İkincisi, description daxilində valyutanı, ölçü vahidlərini və vacib məhdudiyyətləri açıq şəkildə göstərmək faydalıdır. Bu, “əyrı” arqumentlərin sayını ciddi şəkildə azaldır.

Üçüncüsü, əgər artıq MCP Gateway istifadə edirsinizsə, onun locale-i alətin arqumentlərinə avtomatik ötürməsinə dair razılaşa bilərsiniz, beləliklə, model onu özü əlavə etməyə məcbur olmaz. Amma hətta bu halda da locale təsvirini saxlamaq faydalıdır: model yenə də bu parametrin nə olduğunu və nə üçün lazım olduğunu daha yaxşı anlayır.

5. Təsvirin dilini seçmək: real tətbiq üçün strategiyalar

Əsas praktiki sual: təsvirlər üçün əsas dili hansı etməli və onları nə vaxt tam lokallaşdırmaq lazımdır?

Tövsiyələr və real təcrübə göstərir ki, GPT modelləri hələ də ingilis kontekstində ən yaxşı işləyir və bir çox tərtibatçı təsvirləri yalnız EN saxlayır. Amma çoxdilli tətbiq üçün bu, kompromis qərar ola bilər.

Birkaç strategiyanı nəzərdən keçirək.

Yalnız EN təsvirlər

Ən sadə variant — hər şey ingiliscə.

Üstünlüklər: tək kod bazası, tək dil, dəqiq və yaxşı ifadələr yazmaq asandır. Model ətrafda hər şey ingiliscə olanda “xoşbəxtdir”.

Çatışmazlıqlar: başqa dillərdə yazan istifadəçilər üçün alət seçimi və arqumentlər keyfiyyəti aşağı ola bilər. Xüsusilə “tənbəl” modellərdə və parametrləri çox olan mürəkkəb alətlərdə.

EN + qısa lokal izah

Kompromis yanaşma: əsas təsvir EN, sonda isə modelə istifadəçinin sözlərini arqumentlərlə tutuşdurmağa kömək edən lokal dildə qısa blok.

Nümunə:

description:
  "Search for gifts based on user preferences. AZ: alət alıcının təsvirinə, yaşına və büdcəsinə əsasən hədiyyələr seçir.",

JSON Schema üçün:

description:
  "Age of the recipient in years. AZ: alıcının yaşı (illərlə).",

Üstünlüklər: model hələ də “ingilis” dünyasındadır, amma istifadəçi dilində bir bələdçi var.

Çatışmazlıqlar: təsvirlər bir qədər uzanır, adətən kritik deyil.

Locale görə təsvirlərin tam lokallaşdırılması

Ən ciddi yanaşma: alətlərin və sahələrin təsvirləri ChatGPT-dən bildiyiniz locale-dən asılı olaraq dəyişir. en-US üçün təmiz ingiliscə, ru-RU üçün təmiz rusca, de-DE üçün almanca təsvirlər verirsiniz.

Bu artıq “bir JSON Schema həmişəlik” deyil, MCP/Gateway-in yerində seçdiyi sxemlər toplusudur.

MCP səviyyəsində bu, belə görünür:

function getSearchGiftsToolDescription(locale: string) {
  if (locale.startsWith("ru")) {
    return {
      name: "search_gifts",
      description: "İstifadəçinin üstünlüklərinə əsasən hədiyyə seçimi.",
      // ru‑schema...
    };
  }
  return {
    name: "search_gifts",
    description: "Search for gifts based on user preferences.",
    // en‑schema...
  };
}

Üstünlüklər: model interfeysi istifadəçi hansı dildə yazırsa, həmin dildə görür. Maksimum rahatlıq.

Çatışmazlıqlar: dəstək və test mürəkkəbləşir. Elə proses qurulmalıdır ki, bütün lokallaşdırılmış təsvir variantları məna baxımından sinxron qalsın və məsələn, ingilis sxeminə yeni sahə əlavə ediləndə almanca sxemi yeniləməyi unutmayasınız.

6. GiftGenius tətbiqimizdə reallaşdırma

Konkretliyə keçək. GiftGenius-də hibrid variant edək: bir alət search_gifts, təsvirlər əsasən EN, amma azərbaycanca izahlar, üstəlik locale arqumenti.

Təsəvvür edin ki, tools-u MCP SDK üslubunda təsvir edən TypeScript MCP-serveriniz var.

// 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. AZ: alıcının yaşı (tam ədəd)."
    ),
  budget: z
    .number()
    .describe(
      "Maximum budget in user's currency. AZ: istifadəçinin valyutasında maksimal büdcə."
    ),
  locale: z
    .string()
    .describe(
      "User locale (e.g. 'en-US', 'ru-RU'). AZ: interfeys və cavabların dili."
    ),
});

export const searchGiftsTool = {
  name: "search_gifts",
  description:
    "Search for gifts based on user preferences (AZ: alıcının üstünlüklərinə əsasən hədiyyə seçimi).",
  inputSchema: searchGiftsInputSchema,
  // execute(...) ...
};

Vacib məqamlar:

• locale məcburidir. Vidcet onu bilirsə (biz isə _meta["openai/locale"]-dan bilirik), ya özü callTool çağırışına əlavə edəcək, ya da MCP Gateway bunu öz tərəfində avtomatik edəcək;
• təsvirlərdə artıq “yaş”, “büdcə”, “interfeys dili” kimi azərbaycanca açar sözlər var, buna görə modelə istifadəçi sorğusundan nəyi hara qoymaq daha asan olur.

Apps SDK tərəfində məsələn, bu aləti birbaşa çağıran (əgər widgetAccessible açıqdırsa) və vidcetdən gələn locale-i ora ötürən funksiya saxlaya bilərsiniz.

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

Bu zəncir arxitekturanı möhkəmləndirir: locale ChatGPT-dən gəldi → tool-a düşəcək → o, düzgün kataloqları və qiymət formatlarını seçəcək, siz də onları front-end-də gözəl göstərəcəksiniz.

7. Davranış üzrə eksperimentlər: lokallaşdırmanın təsirini necə ölçmək

İndi ən maraqlısı: tools və təsvirlərin lokallaşdırılmasının model davranışını həqiqətən yaxşılaşdırdığını necə anlamaq olar — yəni tərcümələrə sərf olunan vaxta dəyibmi?

Kiçik bir “elmi eksperiment”i birbaşa GiftGenius-un Dev Mode‑unda edə bilərsiniz.

App-ın iki variantı: base vs localized

Tətbiqinizin iki konfiqurasiyasını hazırlayın:

• base — alətlərin və JSON Schema-nın təsvirləri yalnız EN;
• localized — təsvirlər EN+AZ (və ya tam azərbaycan dilində versiyalar, hazırsınızsa).

Qalan hər şeyi (kataloqlar, UI, promptlar) eyni saxlayın ki, effekti qarışdırmayasınız.

Sadəlik üçün belə edə bilərsiniz:

• Dev Mode-da (və Store-da bir o qədər də) yalnız localized versiyanı saxlayın;
• base-i isə lokalda ayrıca budaqda işə salın və əvvəlcədən hazırlanmış sorğu dəsti ilə nəticələri müqayisə edin.

Nələri ölçmək lazımdır

Üç əsas metrika var.

Birincisi — alətlərin düzgün seçilmə tezliyi. Azərbaycan (və/və ya başqa dildə) test sorğuları dəsti üçün baxırsınız, model nə qədər halda:

• lazım olanda ümumiyyətlə aləti çağırmağa qərar verir;
• məhz search_gifts-i seçir, başqa aləti yox.

İkincisi — arqumentlərin düzgünlüyü. Alət çağırışının JSON-u gözləntilərə nə qədər uyğundur: sahələr qarışmayıb, büdcə düzgün valyutadadır, yaş açıq şəkildə tam ədəddir, locale itirilməyib.

Üçüncüsü — qəribə və ya məntiqsiz çağırışların sayı. Məsələn, model “indi saat neçəsidir?” sualı üçün search_gifts-i çağırır və ya recipient_age yerinə 3000 qoyur.

Testləri həm əl ilə, həm də MCP/Agents logları vasitəsilə apara bilərsiniz — loglar sizə gələcəkdə də lazım olacaq, ona görə belə analitikaya indidən öyrəşmək daha yaxşıdır.

Əl ilə “golden prompt set” necə təşkil olunmalı

Lokallaşdırma üçün kiçik bir “golden prompt set” yarada bilərsiniz:

1. "10 yaşlı qız üçün 30 avroyadək ucuz hədiyyə lazımdır, o, rəsm çəkməyi sevir."
2. "35 yaşlı əməkdaş–proqramçı üçün hədiyyə seç, büdcə 100$."
3. "Nənəmə yubileyə hədiyyə lazımdır, 70 yaşı var, büdcə 5000 rubladək."

Və onları App-ın hər iki versiyasından (base və localized) keçirin, müşahidə edərək:

• model hansı alətləri seçir;
• hansı arqumentləri qoyur;
• alət çağırılmadıqda mətn cavabı necə dəyişir.

Yarım‑peşəkar lifehack: bu sorğuları ChatGPT API-dən döndərən sadə skript də yaza bilərsiniz, amma kurs çərçivəsində Dev Mode-da əl rejimi kifayətdir. Belə dəstə daxil etmək üçün xüsusilə faydalı olan ayrıca kateqoriya — qarışıq dillərdə mesajlar və qeyri-adi locale kombinasyonlarıdır. Onlara ayrıca blok həsr edəcəyik.

Əgər ciddi kommersiya tətbiqi hazırlayırsınız və söhbət milyonlarla dollardan gedirsə, bu məqamları mütləq məhz sizin tətbiqiniz üçün test edin. 20-ci modul “golden prompt set” ilə peşəkar işləməyə həsr olunub — mütləq bu mövzunu mənimsəyin.

8. Qarışıq dillər və qəribə locale kombinasyonları

LLM tərtibatçısını heç nə, iki dildə eyni anda yazan istifadəçi qədər “sevindirmir”. Məsələn:

"Hədiyyə lazımdır for my friend, o Star Wars-u sevir, budget 100€"

Artıq bilirik ki, model çoxdillidir və çox vaxt öhdəsindən gəlir. Amma qarışıq dillər və “ingiliscə” təsvirlər olduqda səhv ehtimalı artır.

Birkaç tipik situasiya var.

Birinci — istifadəçi AZ yazır, alətlərin təsvirləri isə EN-dir. Model başa düşə bilər, amma bəzən qarışır, xüsusən spesifik terminologiyada (kateqoriya adları, nadir sahə etiketləri).

İkinci — locale = "ru-RU", amma istifadəçi nədənsə ingiliscə yazır. ChatGPT sizə siqnal verir ki, interfeysi rus dilində qurmaq daha yaxşıdır, amma real mətn dili — EN. Mümkündür:

• yenə də rusca təsvirlər vermək və locale-ni ilkin həqiqət hesab etmək;
• və ya mesaj dilini aşkar etməyi əlavə siqnal kimi tətbiq edib təsvirləri faktiki dilə uyğunlaşdırmaq.

Üçüncü — locale = "en", amma istifadəçi bəzən azərbaycanca sözlər əlavə edir. Bu halda, qayda olaraq, ingiliscə təsvirlər özünü əla hiss edir.

Praktikada bir aydın siyasət seçmək kifayətdir. Məsələn:

• locale "ru" ilə başlayırsa — təsvirlərə rusca hissələr əlavə edirsiniz;
• əks halda — təsvirlər tam ingiliscədir.

Aydın qaydanın faydası odur ki, hər budağı xüsusi test edə biləcəksiniz və bu gün təsvirlərin niyə belə və ya elə dildə göründüyünü təxmin etməyəcəksiniz.

9. Sənədləşmə, proses və “kanonik” dil

Təsvirlərin lokallaşdırılması bir dəfəlik akt deyil, prosesdir. İstifadəçilər yeni fəsilələrə sevinir, siz isə köhnənin sındırılmamasına. Ona görə öncədən özünüzlə razılaşın:

• hansı dili “kanonik” hesab edirsiniz və bütün tərcümələri onun əsasında edirsiniz;
• lokallaşdırılmış təsvirləri harada saxlayırsınız;
• konsistentliyi necə yoxlayırsınız.

Adətən kanonik dil ingilis olur. Bütün yeni alətlər və sahələr əvvəlcə EN-də təsvir edilir, review-dan keçir və yalnız sonra digər dillərə lokallaşdırılır. Kod bazasında bunu belə ifadə etmək olar:

• tools.en.json — name/description/sahələrin tam təsviri olan fayl;
• tools.ru.json, tools.de.json — konkret dillər üçün “törəmələr”;
• bu lüğətlər əsasında MCP üçün final JSON Schema yaradan kiçik generator.

Sadə variantda hələlik sətirlərlə kifayətlənmək olar, amma onları sonra ayrıca lüğətlərə çıxarmağı asanlaşdıracaq şəkildə strukturlaşdırın.

Unutmayın ki, təsvirlər də məhsul mətnidir. Onları UI mətnləri kimi ciddi review etmək lazımdır: anlaşıqlı, birmənalı və “su”dan uzaq olub-olmadığını yoxlayın. Xüsusilə çoxdilli variantda biz istəmirik ki, azərbaycanca izah ingilis hissəsi ilə ziddiyyət təşkil etsin.

10. Vizual sxem: dil stək boyunca necə keçir

Hamısını yadda toplamaq üçün, alət lokallaşdırmasını nəzərə alaraq sorğu axınının sadələşdirilmiş sxeminə baxaq.

flowchart TD
    U[İstifadəçi RU dilində yazır] --> C[ChatGPT UI]
    C -->|"_meta.openai/locale = 'ru-RU'"| W[GiftGenius vidceti]
    W -->|"locale = 'ru-RU'"| T["Tool descriptions (EN+AZ)"]
    T --> M[GPT modeli]
    M -->|callTool search_gifts| MCP[MCP / Gateway]
    MCP -->|"locale = 'ru-RU'"| B[Backend / RU kataloqları]
    B --> MCP --> M2["GPT modeli (cavab)"]
    M2 --> C2[ChatGPT UI + RU vidcet]

Burada istifadəçi dili və locale müəyyən edir:

• UI-ın hansı dildə göstəriləcəyini;
• modelin hansı alət və sahə təsvirlərini görəcəyini;
• backend-in hansı kataloqları və valyutaları seçəcəyini;
• cavabların necə formatlanacağını (hem model, həm də vidcet tərəfindən).

11. Tools və təsvirlərin lokallaşdırılmasında tipik səhvlər

Səhv №1: description sahəsini “texniki” saymaq və ümumiyyətlə lokallaşdırmamaq.
Bu yanaşma yalnız ingilisdilli istifadəçiləriniz olanda işləyir. Başqa dillər peyda olan kimi, model daha çox alətsiz cavab verir və ya sxemlər üzrə əyri arqumentlər göndərir. Sanki UI-ı tərcümə etmisiniz, amma tətbiq “ingiliscə” davranır.

Səhv №2: JSON-da sahə adlarını dilə görə dəyişmək.
Bəzən age → vozrast, budjet və s. etmək istəyi yaranır. Bu isə backend tərəfində kabusa çevrilir: fərqli sxemlər, fərqli formatlar, mürəkkəb log analitikası. name sahələrini sabit saxlayın, yalnız təsvirləri lokallaşdırın.

Səhv №3: təsvirlərdə dilləri xaotik qarışdırmaq.
“İstifadəçi preferences-ə görə gifts axtarışı” tipli ifadələr nə modelə, nə də insana kömək edir. Çoxdilli təsvirlər edirsinizsə, blokları açıq şəkildə ayırın: [EN] ... [AZ] .... Beləliklə model struktur görür, qarışıq yox.

Səhv №4: locale-i alətlərə ötürməmək.
Hətta təsvirləri lokallaşdırmısınızsa belə, locale-i tool-a ötürmürsünüzsə (və ya MCP Gateway onu ötürmürsə), backend hansı kataloqları və formatları istifadə edəcəyini bilmir. Nəticədə model “çoxdilli” olmağa çalışır, server isə yalnız bir bazar üçün məlumat qaytarır.

Səhv №5: təsvirləri review olmadan maşın tərcüməsinə vermək.
Elə bilirsiniz ki, avtomatik tərcümədən keçirmək olar və həyat gözəldir. Praktikada belə tərcümələr çox vaxt qeyri-dəqiq olur, xüsusən terminlər və arqumentlər hissəsində. Nəticədə model alətin və ya sahənin mənasını səhv başa düşə bilər. Bir yaxşı düşünülmüş EN variantı və diqqətlə lokallaşdırılmış versiyalar, iyirmi “avtomatik” dildən daha yaxşıdır.

Səhv №6: müxtəlif localelar üçün testlərin/eksperimentlərin olmaması.
Ən azı hər locale üçün bazal sorğu dəsti ilə tətbiqin davranışını yoxlamırsınızsa, hər şey aylarla “sınıq” qala bilər — ta ki, həmin dilli ilk real istifadəçi gələnə qədər. Kiçik golden dəsti və Dev Mode-da əl testləri bu riski xeyli azaldır.

Səhv №7: kanonik və lokallaşdırılmış təsvirlər arasında assimetriya.
İngilis sxeminə occasion (hədiyyənin “səbəbi”) adlı yeni sahə əlavə etmisiniz, amma rus versiyasını yeniləməmisiniz. Nəticədə RU locale-də model bu sahədən ümumiyyətlə xəbərsiz olur və onu doldurmur, halbuki backend artıq gözləyir. Məsələn, server hədiyyələri səbəbə görə filtr etmək istəyir, null alır və həddən artıq ümumi siyahı göstərir — EN-də hər şey işləyir, RU-da davranış isə hiss olunmadan “sınır”. Ona görə alət təsvirlərində istənilən dəyişiklik sadə, amma müntəzəm prosesdən keçməlidir: EN-i yenilə → localeları yenilə → qısa testlərdən keçir.