<button>Submit order</button>

<button>{t("checkout.submit_order")}</button>

locales/
  en.json  fr.json  es.json

Šiuolaikinės programos susiduria su lokalizavimo problema. Ir tai ne vertimas.

Pastarąjį dešimtmetį lokalizavimo pramonė daugiausia dėmesio skyrė vertimo procesams — įrankiams, padedantiems komandoms valdyti vertėjus, peržiūrėti eilutes ir išleisti daugiakalbį turinį.

Tokie įrankiai kaip „Phrase“, „Lokalise“, „Crowdin“ ir „Transifex“ puikiai valdo vertimus. Tačiau visi jie tyliai daro vieną kritinę prielaidą: jūsų programa jau yra internacionalizuota. Realybėje dauguma programų tokios nėra. O plintant AI sugeneruotam kodui, ši spraga netrukus taps milžiniška problema.

---

Koks yra paslėptas i18n sluoksnis, kurio lokalizavimo įrankiai nepastebi?

Lokalizavimas ir internacionalizavimas dažnai painiojami. Tai nėra tas pats.

Lokalizavimas (l10n) — programos vertimas į skirtingas kalbas.

Internacionalizavimas (i18n) — kodų bazės parengimas taip, kad vertimas apskritai būtų įmanomas.

Internacionalizavimas apima tokius veiksmus kaip vartotojo sąsajos eilučių išskyrimas, vertimo raktų generavimas, lokalės failų kūrimas, daugiskaitos taisyklių palaikymas, skaičių ir datų formatavimas, rašymo iš dešinės į kairę kalbų palaikymas ir įrašyto vartotojo sąsajos teksto vengimas. Dauguma lokalizavimo įrankių pradeda veikti tik po šio etapo. Tačiau daugelyje realių kodų bazių šis etapas taip ir nebuvo atliktas.

---

Kaip atrodo tinkamai internacionalizuotas kodas

Gerai struktūrizuotoje programoje vartotojo sąsajos tekstas nurodomas naudojant vertimo raktus.

<button>{t("checkout.submit_order")}</button>

Tekstas saugomas lokalės failuose:

/locales/en.json
{
  "checkout.submit_order": "Submit order"
}

Tokia struktūra leidžia vertimo įrankiams ir vertimo varikliams veikti patikimai.

---

Kaip iš tikrųjų atrodo dauguma programų

Realybėje daugelis programų atrodo taip:

<button>Submit order</button>

<h1>Welcome back</h1>
<p>Your payment was successful</p>

Iš pirmo žvilgsnio tai atrodo nekenksminga. Tačiau įsivaizduokite, kad taip yra šimtuose komponentų ir tūkstančiuose vartotojo sąsajos eilučių. Dabar visa kodų bazė remiasi tik anglų kalba veikiančia vartotojo sąsaja. Vos pabandžius palaikyti kitą kalbą, problemos ima rastis visur.

• Vokiškas tekstas pailgėja maždaug 30 %. Mygtukų turinys nebetelpa.
• Arabų kalbai reikia iš dešinės į kairę išdėstomų sąsajų. Sugriūva ištisos sąsajos.
• Skirtingose kalbose taikomos skirtingos daugiskaitos taisyklės. Pranešimai tampa gramatiškai netaisyklingi.

Be internacionalizavimo architektūros lokalizavimas greitai virsta dideliu refaktoringo projektu.

---

Kaip AI kodo generavimas apsunkino lokalizavimą?

Šiuolaikinis kūrimas vis labiau remiasi AI kodavimo įrankiais: Cursor, GitHub Copilot, ChatGPT, Replit, Lovable, Bolt. Šie įrankiai optimizuoti greičiui ir veikiančiai vartotojo sąsajai, o ne architektūrai.

Tipinis sugeneruotas kodas atrodo taip:

<button>Submit</button>
<h2>Welcome back</h2>
<p>Your order has been confirmed</p>

Tipiniame AI sugeneruotame projekte galite rasti šimtus ar tūkstančius įrašytų vartotojo sąsajos eilučių, pasikartojantį sąsajos tekstą, jokių vertimo raktų, jokių lokalės failų ir jokio daugiskaitos palaikymo. Kitaip tariant: puikios demonstracinės versijos, siaubinga lokalizavimo architektūra.

Šis scenarijus nuspėjamas. Komandos greitai kuria, išleidžia produktą, sulaukia susidomėjimo — ir tada supranta: „Visa mūsų vartotojo sąsaja yra įrašyta anglų kalba.“ Tuo metu, norint pridėti lokalizavimą, reikia keisti didelę vartotojo sąsajos kodų bazės dalį.

---

Tikras pavyzdys, kurį matome

Nuskaitant nedidelius AI sugeneruotus SaaS projektus, tam tikras scenarijus greitai išryškėja. Viename mūsų analizuotame „React“ prototipe buvo 1 284 vartotojo sąsajos eilutės 312 failų, tačiau nebuvo jokios internacionalizavimo struktūros. Pavyzdžiai:

<h1>Welcome back</h1>
<button>Start free trial</button>
<p>Your payment failed</p>

Norėdama pridėti lokalizavimą, komanda turėjo išskirti vartotojo sąsajos eilutes iš šimtų komponentų, įdiegti vertimo raktus, sukurti lokalės failus ir perrašyti vartotojo sąsajos logiką — tik tada apskritai galėjo prasidėti vertimas. Šį scenarijų AI sugeneruotuose projektuose matome nuolat.

---

Kodėl tradiciniai lokalizavimo įrankiai negali tvarkyti AI sugeneruoto kodo?

Dauguma lokalizavimo įrankių buvo sukurti vertimo komandoms, o ne kūrėjams. Jų procesai daro prielaidą, kad kūrimo komanda jau įdiegė i18n karkasą, vertimo raktus, lokalės failų struktūras ir eilučių išskyrimo procesus. Tačiau šiuolaikinėse kodų bazėse, ypač AI sugeneruotose, šio pagrindo dažnai apskritai nėra. Todėl komandos susiduria su netikėta realybe: prieš versdamos bet ką, jos pirmiausia turi refaktorizuoti visą vartotojo sąsajos sluoksnį.

---

Trūkstamas lokalizavimo steko sluoksnis

Šiandieninis lokalizavimo stekas paprastai atrodo taip:

Tačiau trūksta vieno kritinio elemento. Iš tikrųjų reikia atlikti štai ką:

Šis trūkstamas sluoksnis turi nuskaityti kodų bazę, išskirti vartotojo sąsajos eilutes, sugeneruoti vertimo raktus, sukurti lokalės failus, aptikti pasikartojančias eilutes ir sukurti terminologijos žodynus. Tik tada gali prasidėti vertimo procesai.

---

Kodėl ši problema netrukus taps milžiniška

Susiduria trys pagrindinės tendencijos.

1. Kūrimas pirmiausia pasitelkiant AI. Vis daugiau programų kuriama naudojant AI padedamą kodavimą. Kai kurių startuolių kodų bazės dabar daugiausia sugeneruotos AI. Architektūra dažnai tampa antraeile, palyginti su greitu išleidimu.
2. Nepriklausomų kūrėjų bumas. Kiekvieną savaitę išleidžiama tūkstančiai naujų SaaS produktų. Dauguma jų pradedami nuo anglų kalbos.
3. Pasauliniai vartotojai nuo pirmos dienos. Net maži produktai greitai pritraukia vartotojų iš Vokietijos, Brazilijos, Indijos ir Japonijos. Vos atsiradus tarptautiniams vartotojams, lokalizavimas tampa skubus. Tačiau architektūra paprastai tam neparengta.

---

Kitoks požiūris

O kas, jei internacionalizavimą būtų galima automatizuoti? Būtent tai suteikia saugyklos prijungimas prie globalize.now. Pirmasis konvertavimas programoje atliekamas vieną kartą ir pateikia ataskaitą apie tai, ką rado:

✔ Found 128 UI strings
✔ Generated 92 translation keys
✔ Created /locales/en.json
✔ Updated 41 files

Done in 2.7s

Įrankis nuskaitytų kodų bazę, išskirtų vartotojams matomas eilutes, sugeneruotų struktūrizuotus vertimo raktus, sukurtų lokalės failus ir automatiškai perrašytų vartotojo sąsajos kodą. Iš šio:

<button>Submit order</button>

Į šį:

<button>{t("checkout.submit_order")}</button>

Staiga visa kodų bazė tampa parengta vertimui.

---

Nauja kategorija: AI parengtas lokalizavimas

Naujos kartos lokalizavimo įrankiai nepradės nuo vertėjų. Jie pradės nuo kodo transformavimo. Procesas atrodys maždaug taip:

Didžiausia šiandienos lokalizavimo ekosistemos spraga — pirmojo etapo automatizavimas: kodų bazės parengimas pasauliniams vartotojams.

Sužinokite, kaip globalize.now tai automatiškai atlieka kūrėjų komandoms.

Jei norite sužinoti istorinę kelionę nuo CAT įrankių iki AI pritaikytų procesų, skaitykite apie tris lokalizavimo etapus AI eroje.

---

Lokalizavimo ateitis

Anksčiau lokalizavimas buvo vertimo problema. AI kūrimo eroje jis tampa kodo architektūros problema. Komandos, išspręsiančios šį sluoksnį, nulems, kaip per ateinantį dešimtmetį bus kuriama pasaulinė programinė įranga.