Tətbiq üçün lokallaşdırma strategiyası

1. Niyə məhz ChatGPT App üçün lokallaşdırmanı düşünməlisiniz

Əgər adi veb‑tətbiqlər hazırlamısınızsa, lokallaşdırma çox güman ki, klassik i18n ilə assosiasiya olunurdu: interfeys sətirləri, bir‑iki tarix və rəqəm formatı, lüğətlər — və siz hər şeyi səliqə ilə tərcümə edirsiniz. ChatGPT App daxilində isə daha maraqlıdır: burada üçüncü iştirakçı — LLM‑modelin özüdür. O, alətlərinizin təsvirlərini, promptları, nəticələri oxuyur, nəticə çıxarır və qərar verir.

Yəni dil təkcə “məti istifadəçiyə necə gözəl göstərmək” deyil, həm də “model alətinizin nə etdiyini, nə vaxt çağırılmalı olduğunu və ora hansı arqumentlərin qoyulacağını necə anlayacaq” deməkdir. “Al” düyməsini birtəhər də tərcümə etsəniz, istifadəçi başa düşəcək. Amma siz ödəniş edən tool‑u rus və ingilis qarışığında dumanlı təsvir etsəniz, model ya onu heç vaxt çağırmaya bilər, ya da gözlədiyinizdən tamam başqa cür çağırar.

Daha bir məqam: ChatGPT artıq sizin MCP‑serverinizə istifadəçinin lokali və lokasiyası barədə ipucları ötürür — _meta["openai/locale"] və _meta["openai/userLocation"]. Bu, alətlərə MCP sorğuları səviyyəsində edilir ki, siz mətni və məlumatları istifadəçinin dilinə və regionuna uyğunlaşdıra biləsiniz. Yəni platforma artıq sizə kontekst “verir”, inkişaf etdiricinin vəzifəsi isə ondan düşünülmüş şəkildə yararlanmaqdır.

Buna görə də bu modulda lokallaşdırmaya ChatGPT App‑in arxitektura aspekti kimi baxırıq, “UI‑ni tərcümə etdik və unutduq” kimi deyil.

2. Lokallaşdırılmalı laylar

Gəlin App‑i laylardan ibarət piroq kimi təsəvvür edək. Hər bir lay lokallaşdırıla bilər (və çox vaxt lokallaşdırılmalıdır). Dərhal dərinliyə qərq olmamaq üçün xəritədən başlayaq.

Laylara ümumi baxış

Əvvəlcə — ümumi cədvəl, sonra isə hissə‑hissə nəzərdən keçirək.

Bu, lokallaşdırma xəritəmizin ilk layıdır: sonra dərinlik (kosmetika/semantika), dillər və konkret elementlər əlavə edəcəyik.

İndi isə layları ardıcıllıqla nəzərdən keçirək.

Widget UI

Ən aşkar lay — widget interfeysi. GiftGenius‑da bunlar:

• blok başlıqları;
• sahə etiketləri (“Alıcı”, “Büdcə”, “Maraqlar”);
• düymələr (“Hədiyyə seç”, “Filtrləri sıfırla”);
• inputlarda ipucları (“məsələn, həmkar, ana…”);
• xəta və boş vəziyyət mesajları (“Hədiyyə tapılmadı”).

Adi React‑tətbiqində bunlar sözlüklərə çıxarmaq üçün ilk namizədlərdir. Burada da eyni şeydir, yalnız nəzərə almaq lazımdır ki, UI — bütün App deyil, onun simalarından yalnız biridir.

Bir az sonra modulda widget üçün normal i18n arxitekturası edəcəyik, amma artıq indi vacibdir ki, qeyd edək: JSX‑də birbaşa mətn sətirləri olmamalıdır. Hətta hələlik tək dili dəstəkləsəniz belə, UI mətnlərini dərhal strukturlaşdırmaq rahatdır.

GiftGenius üçün kiçik bir nümunə (hələ real i18n kitabxanası olmadan):

type Locale = "en" | "ru";

const uiText = {
  en: {
    title: "GiftGenius: find a perfect present",
    recipientLabel: "Recipient",
  },
  ru: {
    title: "GiftGenius: mükəmməl hədiyyə tapın",
    recipientLabel: "Alıcı",
  },
};

function GiftForm({ locale }: { locale: Locale }) {
  const t = uiText[locale];

  return (
    <div>
      <h2>{t.title}</h2>
      <label>{t.recipientLabel}</label>
      {/* digər sahələr */}
    </div>
  );
}

Burada hələ “həqiqi” lokallaşdırma etmirik, amma artıq UI mətnləri qatını aydın şəkildə ayırırıq.

GPT mətnləri və promptlar

Növbəti lay — istifadəçiyə birbaşa görünməyən, lakin modelin davranışına güclü təsir edən sistem və köməkçi mətnlərdir:

• App‑inizin system‑promptu (“Sən — hədiyyə seçimi üzrə köməkçisən…”);
• modelə verdiyiniz izah şablonları (“Seçimin qısa xülasəsini hazırla”);
• model üçün əvvəlcədən hazırlanmış follow‑uplar və ipucları (“əgər …, istifadəçidən büdcəni dəqiqləşdirməsini istə” və s.).

Bu mətnlər də lokallaşdırıla bilər (və çox vaxt lokallaşdırılmalıdır). Sadə nümunə: istifadəçi Azərbaycan dilində yazırsa, amma system‑prompt tamamilə ingiliscədirsə, model, əlbəttə, öhdəsindən gələr, ancaq həmin dil üçün üsluba və ifadələrə dəqiq nəzarəti itirirsiniz.

Bir az sonra, promptların və təsvirlərin lokallaşdırılması üzrə alətlər haqqında dərslərdə (prompts/descriptions), çoxdilli system‑promptlarla necə dəqiq davranmağı görəcəyik. Burada bizim üçün vacib olan budur: promptlar — UI kimi lokallaşdırılan eyni qatdır.

Məlumat və kontent

Növbəti — məlumatlarınız. GiftGenius üçün bu, hədiyyə kataloqudur: adlar, təsvirlər, kateqoriyalar, bəzən hədiyyədən istifadə üçün ipucları. Kommersiya App‑lərində isə buna qiymətlər, valyutalar, ölçü vahidləri, tarix formatları və s. daxildir. ChatGPT üçün product feed (platforma üçün malları və xidmətləri təsvir etdiyiniz format) spesifikasiyalarında bu mətn sahələri (title, description) və qiymətlər açıq şəkildə ayrılıb ki, onları ChatGPT daxilində istifadəçilərə düzgün göstərmək mümkün olsun.

Qlobal App istəsəniz, hədiyyə kataloqunda ən azı belə suallar yaranır:

• adları/təsvirləri bir neçə dildə saxlayırıqmı;
• istifadəçiyə hansı dili verəcəyimizi necə seçirik;
• tərcümə hələ yoxdursa nə edirik (fallback);
• müxtəlif regionlar üçün valyutaları və tarix/qiymət formatlarını necə göstəririk.

Kataloq üçün kiçik tipləşdirilmiş nümunə:

type Locale = "en" | "ru";

interface LocalizedString {
  en: string;
  ru: string;
}

interface Gift {
  id: string;
  title: LocalizedString;
  description: LocalizedString;
  priceCents: number;
  currency: "USD" | "EUR" | "RUB";
}

function getLocalizedTitle(gift: Gift, locale: Locale) {
  return gift.title[locale] ?? gift.title.en;
}

Yəni lokallaşdırma təkcə frontend deyil, həm də bazadakı verilənlərin və MCP resurslarının strukturu deməkdir. Buna ChatGPT ilə sizin servisləriniz arasında şlüz olan Gateway və MCP‑serverdən danışarkən qayıdacağıq.

Tools və JSON Schema təsvirləri

Dördüncü lay — alətlərin və onların arqumentlərinin təsvirləri. Model məhz onlar vasitəsilə nə vaxt tool‑unuzu çağırmalı və ora hansı arqumentləri göndərməli olduğunu anlayır. MCP‑də bu, alətin title, description sahələri və JSON sxeminin sahələrindəki description‑dır.

Apps SDK sənədləri vurğulayır ki, model alətləri seçmək və arqumentlər qurmaq üçün adlardan, təsvirlərdən və parametrlərin sənədlərindən istifadə edir.

TypeScript MCP‑serverində GiftGenius alətinin şərti nümunəsi:

server.registerTool(
  "suggest_gifts",
  {
    title: "Suggest gifts",
    description: "Suggest 3–5 gift ideas based on recipient profile.",
    inputSchema: {
      type: "object",
      properties: {
        recipient: {
          type: "string",
          description: "Who is the gift for (e.g. mother, colleague)?",
        },
      },
      required: ["recipient"],
    },
  },
  async ({ input }) => { /* ... */ }
);

Hazırda hər şey ingiliscədir, model üçün tam aydındır. Bəs istifadəçi Azərbaycan dilində yazsa? O, yenə də “ana” sözünü recipient ilə əlaqələndirə bilər, amma mürəkkəb sahələr və domen terminləri olduqda səhv ehtimalı artır. Təsvirlərin lokallaşdırılması strategiyaları dərsində ayrıca müzakirə edəcəyik: təsvirlərin vahid ingiliscə saxlanılması ilə lokallaşdırılmış təsvirlər arasında seçim.

Bu mərhələdə lokallaşdırma xəritəsində sadəcə qeyd etmək vacibdir: tools və JSON Schema təsvirləri də lokallaşdırıla bilər və bu, modelin davranışına təsir edir.

Commerce və hüquqi hissə

Nəhayət, çox zaman ən sonda yada düşən lay — pulla və hüquqi mətnlərlə bağlı hər şey:

• SKU və abunə planlarının adları;
• commerce feedlərində title/description sahələri (mallar, xidmətlər, abunələr);
• Xidmət Şərtləri (Terms of Service), Məxfilik Siyasəti (Privacy Policy), Qaytarma Siyasəti (Refund Policy);
• məktublar və bildirişlər (email, push), əgər App ChatGPT‑dən kənara nəsə göndərirsə;
• ödənış statusları və göstərdiyiniz ödəniş xətaları (“Ödəniş rədd edildi”, “Regionunuzda mövcud deyil”).

Burada iki aspekt var: UX və qanun. İstifadəçi nəyə razılıq verdiyini və nəyə görə pul ödədiyini öz dilində başa düşməlidir. Eyni zamanda tərcümələr hüquqi baxımdan düzgün olmalıdır: bəzən hüquqşünaslar tələb edirlər ki, hüquqi qüvvəyə malik yalnız bir dildəki mətnlər (məsələn, ingilis dilində) sayılsın, digər tərcümələr isə “referens” xarakteri daşısın.

Lokallaşdırma xəritəmizdə commerce və hüquqi kontenti mütləq ayrıca lay kimi qeyd edirik, çünki çox vaxt bunun üçün başqa proses (hüquqşünaslar, compliance, mətnlərin marketinqlə razılaşdırılması) tələb olunur.

3. Lokallaşdırmanın dərinliyi: “kosmetika” və “semantika”

“App‑i lokallaşdırmaq” dedikdə, iki dərinlik səviyyəsini ayırmaq faydalıdır: kosmetik və semantik.

Kosmetik lokallaşdırma

Kosmetika — görünüşü və oxunaqlılığı dəyişən, amma sistemin davranışını demək olar ki, dəyişməyən hər şeydir. Nümunələr:

• tərcümə olunmuş başlıqlar və düymə etiketləri;
• inputlarda tərcümə olunmuş placeholderlər;
• UI‑də “insani” xəta mesajları;
• widgetdə lokallaşdırılmış marketinq banner mətni.

Klassik veb‑tətbiqlərdə adətən bununla dayanırlar. ChatGPT App‑də bu vacibdir, amma buzdağının yalnız üst hissəsidir.

Semantik lokallaşdırma

Semantika — modelin davranışını və App‑in məntiqini dəyişən şeylərdir. Burada dil təsir edir:

• modelin hansı aləti seçəcəyinə;
• alətin arqumentlərini necə dolduracağına;
• hansı məlumatları bu istifadəçi üçün “düzgün” sayacağına.

Semantik lokallaşdırma nümunələri:

• istifadəçi dilində system‑prompt (üslubu və qaydaları müəyyən edən);
• istifadəçinin danışdığı dildə tools və sahələrinin descriptions;
• mədəni kontekstdən asılı müxtəlif ipucları/təlimatlar mətni;
• parsinq və generasiyaya təsir edən tarix/valyuta formatları (31.12.2025 və ya 12/31/2025).

Yalnız kosmetikanı lokallaşdırmısınızsa, amma semantikanı yox, App‑iniz lokallaşdırılmış görünə bilər, amma “pərdə arxasında” ingilisdilli kimi davrana bilər. Lokallaşdırma xəritəsində modelin davranışı üçün kritik olan elementləri birbaşa qeyd etmək faydalıdır.

Bizim GiftGenius üçün, məsələn:

• JSON Schema‑da budget sahəsinin təsviri (“Budget in the user’s currency”) — semantika;
• “Hədiyyə seç” düyməsinin etiketi — kosmetika (UX üçün vacibdir, amma model onu görmür).

Artıq kosmetika və semantikanı fərqləndirdiyimizə görə, məntiqli sual yaranır: ümumiyyətlə, App‑inizin neçə dildə işləməsini istəyirsiniz.

4. Təkdilli vs çoxdilli ChatGPT App

Xəritəni çəkməzdən əvvəl ambisiyanı anlamaq lazımdır: siz yalnız təkdilli App edirsiniz, yoxsa çoxdilli auditoriyaya yönəlirsiniz.

Təkdilli App

Təkdilli App — yalnız bir dili şüurlu şəkildə dəstəklədiyiniz variantdır. Məsələn, yalnız ingilis dili.

UI‑widget, promptlar, alət təsvirləri və məlumatlar — hamısı bir dildədir. Bu, işi xeyli asanlaşdırır:

• dillər üzrə şaxələnmə olmadan tək kod bazası;
• tək kataloq sxemi (title_en, title_ru və s. olmadan);
• daha sadə dəstək və test.

Amma aydındır ki, auditoriya məhduddur. ChatGPT App halında isə bu, belə deməkdir: istifadəçi başqa lokal ilə gəlsə belə, ChatGPT App‑inizi göstərə bilər, amma istifadəçinin dilini daima App‑in daxili dilinə “çevirəsi” olacaq. Bəzi nişlərdə bu uyğundur, amma kütləvi istehlak üçün hədiyyə servisi — çox güman ki, yox.

Çoxdilli App

Çoxdilli App — artıq arxitektura qərarıdır. Burada:

• UI və mətnlər istifadəçinin locale‑una əsasən düz göstərilir;
• məlumatlar (kataloqlar, məhsul təsvirləri) da dil/regiona bağlıdır;
• tools descriptions və system‑promptlar dilə görə fərqlənə bilər;
• commerce ssenariləri yerli valyutaları, vergiləri, məhdudiyyətləri nəzərə alır.

Bu halda kod boyunca bircə if (locale === "ru") şərti artıq açıq‑aşkar yetmir. Arxitektura lazımdır: sözlüklər, lokallaşdırılan resurslar, locale və userLocation saxlanılan/emal olunan vahid yer, widget ilə MCP‑server arasında razılaşmalar.

Apps SDK sənədləri açıq vurğulayır ki, ChatGPT alətlərinizi çağıranda sizə _meta daxilində locale və userLocation ötürür ki, server tərəfində düzgün dil və məlumat formatını seçə biləsiniz. Bu, çoxdilli App üçün “yanacaq”dır.

Kiçik müqayisə

Aydınlıq üçün — mini müqayisə:

Kurs səviyyəsində GiftGenius‑u çoxdilli (ən azı EN/RU) edəcəyik ki, “yetkin” sxemi göstərək. Amma bir çox fəndlər genişlənməyə hazır olmaq istəyən səliqəli təkdilli App üçün də faydalı olacaq.

5. Dilin modelə həqiqətən təsir etdiyi yerlər

İndi isə dilin ChatGPT davranışına birbaşa təsir etdiyi nöqtələri ayıraq.

İstifadəçi girişi dili vs tools descriptions dili

Təsəvvür edin:

• istifadəçi yazır: “Həmkar üçün 50 avroya hədiyyə seç”;
• sizin suggest_gifts tool‑unuz yalnız ingiliscə təsvir olunub;
• sxema sahələri: recipient, budget, currency, interests.

Model bunları etməlidir:

1. ümumiyyətlə suggest_gifts çağırmaq lazım olduğuna qərar vermək;
2. recipient = "colleague", budget = 50, currency = "EUR" çıxarmaq;
3. bunları düzgün şəkildə JSON arqumentlərinə seriyalaşdırmaq.

Əgər descriptions qısa və başqa dildədirsə, model bunun öhdəsindən gəlir, amma sahələri səhv doldurma ehtimalı daha yüksəkdir. Məsələn, budget ilə price_limit‑i qarışdıra və ya interests sahəsinə mətn verə bilər, çünki sahənin təsvirində “Any extra info about the gift” kimi dumanlı bir şey yazılıb.

İstifadəçi mətni Azərbaycan dilində, descriptions isə ingiliscə olanda model dillər arasında daima “atlayır”.

Lokallaşdırılmış sxem variantı:

const locale = _meta?.["openai/locale"] ?? "en"; // ChatGPT-dən gəlir 
const isRu = locale.startsWith("ru");

server.registerTool(
  "suggest_gifts",
  {
    title: isRu ? "Hədiyyə seçimi" : "Suggest gifts",
    description: isRu
      ? "Alıcı profilinə əsaslanaraq 3–5 hədiyyə ideyası seç."
      : "Suggest 3–5 gift ideas based on recipient profile.",
    inputSchema: { /* ... */ },
  },
  async ({ input }) => { /* ... */ }
);

Burada sadələşdirilib: əslində descriptions server işə düşəndə bir dəfə generasiya etmək daha yaxşıdır, hər çağırışda yox, amma fikir aydındır. Biz ChatGPT‑yə locale‑dan asılı olaraq müxtəlif descriptions verə bilərik ki, modelə istifadəçini anlamaq asan olsun.

Məlumatın dili vs sorğunun dili

Əgər hədiyyə kataloqunuz yalnız ingiliscədirsə, istifadəçi isə Azərbaycan dilində ünsiyyət qurursa, model ingilisdilli adlar və təsvirlər seçəcək. Bəzən bu uyğundur, bəzən — yox. Amma daha vacibi çıxışı necə format etdiyinizdir:

• istifadəçiyə serverdən gələn orijinal title/description‑ları göstərirsiniz;
• yoxsa model onları öz mətnində istifadəçi dilində nağıl edir;
• yaxud tool‑unuz locale‑a əsasən artıq lokallaşdırılmış mətni qaytarır.

Apps SDK‑da structured content (alətlərdən qaytardığınız strukturlu məlumatlar) və mətn cavabı ayrı yaşaya bilər. Siz strukturlu məlumatları (məsələn, məhsul sahələri olan JSON) və ayrıca istifadəçi üçün mətni qaytara bilərsiniz, sonra model bunu necə render etmək və ya nəql etmək barədə qərar verəcək.

Lokallaşdırma server səviyyəsində (məlumatlar) və ya model səviyyəsində (lazım olan dildə yenidən ifadə etmək) baş verə bilər. Xəritə tərtib edərkən “son instansiya”nı harada saxlamaq istədiyinizə qərar vermək faydalıdır.

System‑prompt və follow‑uplar

Əgər system‑prompt yalnız ingiliscədirsə, istifadəçi isə azərbaycandilli, model daim iki dil arasında balans saxlayacaq. Bu, normal ola bilər, amma bəzən üslubu sərt şəkildə təyin etmək istəyirsiniz: məsələn, azərbaycandilli versiyada daha qeyri‑rəsmi, ingiliscə versiyada isə rəsmi üslub.

Beləliklə, lokallaşdırma xəritəsində qeyd olunmalıdır:

• system‑prompt EN;
• system‑prompt RU;
• follow‑up şablonları (EN/RU);
• alətlər üçün hər hansı “sərt” ipucları.

6. GiftGenius üçün lokallaşdırma xəritəsi

İndi laylar, dərinlik və dillər barədə danışdıqlarımızı GiftGenius üçün açıq lokallaşdırma xəritəsində toplayaq. Gəlin elə onu edək ki, sonra siz də öz App‑iniz üçün edəcəksiniz: lokallaşdırma xəritəsi tərtib edək. Fikir sadədir: cədvəl, sütunlarda — lay və obyekt tipi, sətirlərdə — konkret elementlər.

Xəritə nümunəsi

Budur GiftGenius üçün sadələşdirilmiş xəritə (EN/RU):

suggest_gifts.description

budget.description

Solda laylar üzrə qruplaşdırırıq, sonra — konkret elementlər. Son sütun GPT ilə razılaşdırmadan toxunmaq olmaz olanları anlamağa kömək edir: semantika kimi işarələnən hər şey modelin davranışına təsir edir.

Kiçik kod eskizi

Xəritəni kodla əlaqələndirmək üçün lokallaşdırılan obyektlər üçün sadə bir tip yarada bilərsiniz:

type LocalizedTextKey =
  | "ui.title"
  | "ui.recipient_label"
  | "error.no_gifts"
  | "prompt.summary_intro";

type Locale = "en" | "ru";

type Messages = Record<Locale, Record<LocalizedTextKey, string>>;

const messages: Messages = {
  en: {
    "ui.title": "GiftGenius: find a perfect present",
    "ui.recipient_label": "Recipient",
    "error.no_gifts": "No gifts found",
    "prompt.summary_intro": "Here’s why these gifts fit:",
  },
  ru: {
    "ui.title": "GiftGenius: ideal hədiyyə tapın",
    "ui.recipient_label": "Alıcı",
    "error.no_gifts": "Hədiyyə tapılmadı",
    "prompt.summary_intro": "Bu hədiyyələrin niyə uyğun olduğunu izah edirəm:",
  },
};

Sonra bu eyni açarlardan həm widgetdə, həm də serverdə promptları formalaşdırarkən istifadə edə bilərsiniz (locale‑u stack boyunca ötürdüyünüz halda — bu, növbəti dərsin mövzusudur). Beləliklə, “lokallaşdırma xəritəniz” tədricən tipikləşdirilmiş sözlüyə çevrilir, ayrı‑ayrı sətirlər yığınına yox.

7. Təcrübə: öz App‑iniz üçün lokallaşdırma xəritəsi hazırlayın

Konkret i18n texnikalarına və Gateway/MCP arxitekturasına dərinə getməzdən əvvəl, bir darıxdırıcı, amma çox faydalı məşqi etmək vacibdir: nəyi lokallaşdıracağınızı dürüst şəkildə təsvir etmək.

Yaxşı yanaşma — istənilən redaktoru açın (Google Sheets, Notion və s.) və bu sütunlarla cədvəl yaradın:

• kateqoriya/lay (UI, promptlar, məlumatlar, tools, commerce və hüquqi hissə, xətalar);
• element (konkret düymə, konkret sahə təsviri, mətn olan konkret endpoint);
• EN dəyər nümunəsi;
• ikinci dildə dəyər nümunəsi (əgər artıq varsa, heç olmasa qaralama);
• “kosmetika/semantika/hüquqi əhəmiyyətli” qeyd;
• məsul şəxs (kim düzəlişlərə cavabdehdir: frontend, MCP‑server, product, hüquqşünas).

Sonra App‑iniz üzrə keçib, mətin olan və ya dilin məlumat formatına təsir etdiyi hər şeyi dürüst şəkildə yazırsınız.

GiftGenius üçün bu, yuxarıdakı cədvəlin təxminən genişləndirilmiş versiyası kimi alınardı. Yolda demək olar ki, mütləq bir neçə “gizli” yer tapacaqsınız:

• MCP‑serverlərin kodunda mətn konstantları (məsələn, xəta mesajları);
• structuredContent‑də defolt dəyərlər (məsələn, UI‑də göstərmədiyiniz kateqoriyalar);
• tools üçün köhnə etiketlər, artıq faktiki davranışlarına uyğun gəlmir.

Bu məşqi commerce və hüquqi biznes prosesləri ilə lokallaşdırmanı birləşdirməzdən əvvəl etmək xüsusilə faydalıdır (ödənişlər, abunə aktivləşdirmələri, hüquqi sənədlər). charge_user alətini ACP və hüquqi mətnlərlə çoxdilli sistemdə sonradan yenidən adlandırmaq xeyli daha ağrılıdır.

Ümumilikdə, əgər əvvəlcədən lokallaşdırma xəritəsini çəkir və nələri, hansı dillərdə dəstəkləyəcəyinizi dürüst şəkildə qeyd edirsinizsə, növbəti modullarda — MCP, Gateway, commerce və Store işə qarışanda — əsəblərinizi xeyli qorumuş olursunuz.

8. Lokallaşdırma planlaşdırmasında tipik səhvlər

Səhv №1: lokallaşdırmanı “düymələri tərcümə etməklə” eyniləşdirmək.
Çox yayılmış ssenari: komanda UI sətirlərini səliqəli şəkildə sözlüklərə çıxarır, tərcümə edir və sevinir. Bu zaman system‑prompt yalnız ingiliscə qalır, tools descriptions da eləcə, kataloq isə yalnız ingilisdilli adlardan ibarətdir. Nəticədə App lokallaşdırılmış görünür, amma model içəridə öz dünyasında yaşayır və davranış ingilisdilli olaraq qalır. Praktikada bu, qəribə tövsiyələr və tools arqumentlərində səhvlərlə üzə çıxır.

Səhv №2: kosmetika ilə semantikanı ayırmamaq.
Bəzən product “formulyovkanı bir az düzəltməyi” xahiş edir — alət təsvirində və ya system‑promptda — və proqramçı mətni sanki sadə UI etiketi kimi dəyişir. Amma JSON Schema sahəsinin description‑u və ya system‑promptdakı bir ifadə model ilə kontraktın bir hissəsidir. Belə dəyişikliklər GPT‑nin alətinizi necə çağırdığını radikal şəkildə dəyişə bilər. Əgər lokallaşdırma xəritəsində semantik elementləri əvvəlcədən işarələməsəniz, App‑in davranışını təsadüfən sındırmaq asandır.

Səhv №3: arxitektura olmadan çoxdilli xaosa başlamaq.
Başlanğıcda kod boyunca sadəcə if (locale === "ru") yayıb lazım olan yerdə Azərbaycan dilində sətirlər qoymaq çox cazibədardır. Nəticədə bir neçə həftə sonra tətbiq “lokallaşdırma cəhənnəminə” çevrilir: bir komponentdə sətirlər sözlükdən, digərində JSX‑ə yapışdırılıb, serverdə isə açarların adlandırılması sxemi üçüncü cürdür. Sonradan normal i18n sistemini qoşmaq və hər şeyi vahid formaya salmaq xeyli çətinləşir.

Səhv №4: məlumatları və pulu yaddan çıxarmaq.
Hətta təcrübəli komandalar tez‑tez UI və promptların tərcüməsi ilə başlayır, amma mallar kataloqları, qiymətlər, valyutalar və hüquqi mətnlərin də locale və userLocation nəzərə alınmalıdırını gözdən qaçırırlar. ChatGPT üçün product feed spesifikasiyalarında məhz istifadəçi üçün düzgün görüntülənməsi üçün hansı mətn sahələrinin və qiymətlərin lazım olduğu sərt şəkildə verilib. Əgər məlumat səviyyəsində çoxdilliliyi əvvəlcədən nəzərdə tutmasanız, sonra ya feed‑i dublikatlaşdırmalı, ya da ağrılı miqrasiyalar etməli olacaqsınız.

Səhv №5: platformanın lokal və lokasiya siqnallarını görməzdən gəlmək.
ChatGPT artıq MCP çağırışlarında _meta["openai/locale"] və _meta["openai/userLocation"] ötürür ki, sizinlə hansı dildə və hansı regiondan ünsiyyət qurulduğunu anlayasınız. Bəzi inkişaf etdiricilər isə hələ də ilk işə salmada istifadəçidən “İnterfeys dilini seçin” soruşur və bu siqnallardan resurslar və qiymətləri seçmək üçün istifadə etmirlər. Nəticədə UX zədələnir, arxitektura isə lazım olduğundan daha mürəkkəb olur.

Səhv №6: lokallaşdırılan elementlərin “sahiblərini” təyin etməmək.
Hər şey dövriyyəyə girəndə aydın olur ki, tərcümələr müxtəlif insanlara yayılıb: frontenderlər UI mətnlərini düzəldir, backendçilər — tools descriptions, ML‑mütəxəssis — system‑prompt, hüquqşünaslar isə redaktə olunmuş Terms göndərirlər. Əgər lokallaşdırma xəritəsində hansı laydan kim məsuldur göstərilməsə, dəyişikliklər toqquşmağa başlayır, bəzən isə mətnlər bir yerdə yenilənir, başqasında yox.