<button>Submit order</button>

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

locales/
  en.json  fr.json  es.json

Tänapäevastel rakendustel on lokaliseerimisprobleem. Ja see ei ole tõlkimine.

Viimase kümne aasta jooksul on lokaliseerimistööstus keskendunud tõlketöövoogudele – tööriistadele, mis aitavad meeskondadel tõlkijaid hallata, stringe üle vaadata ja mitmekeelset sisu avaldada.

Phrase, Lokalise, Crowdin ja Transifex on tõlgete haldamisel suurepärased. Kuid kõik need eeldavad vaikselt üht kriitilist asja: teie rakendus on juba rahvusvahelistatud. Tegelikult ei ole enamik rakendusi seda. Ja AI-ga genereeritud koodi levikuga on see lõhe muutumas suureks probleemiks.

---

Mis on peidetud i18n-kiht, millest lokaliseerimistööriistad mööda vaatavad?

Lokaliseerimist ja rahvusvahelistamist aetakse sageli segamini. Need ei ole sama asi.

Lokaliseerimine (l10n) – rakenduse tõlkimine eri keeltesse.

Rahvusvahelistamine (i18n) – koodibaasi ettevalmistamine, et tõlkimine oleks üldse võimalik.

Rahvusvahelistamine hõlmab näiteks kasutajaliidese stringide eraldamist, tõlkevõtmete genereerimist, lokaalefailide loomist, mitmuse reeglite toetamist, arvude ja kuupäevade vormindamist, paremalt vasakule kirjutavate keelte toetamist ning hardcoded kasutajaliidese teksti vältimist. Enamik lokaliseerimistööriistu alustab alles pärast seda etappi. Kuid paljudes päris koodibaasides ei ole seda etappi kunagi tehtud.

---

Kuidas näeb korralikult rahvusvahelistatud kood välja?

Hästi struktureeritud rakenduses viidatakse kasutajaliidese tekstile tõlkevõtmete kaudu.

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

Tekst asub lokaalefailides:

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

Selline struktuur võimaldab tõlketööriistadel ja tõlkemootoritel usaldusväärselt töötada.

---

Kuidas enamik rakendusi tegelikult välja näeb?

Tegelikkuses näevad paljud rakendused välja sellised:

<button>Submit order</button>

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

Esmapilgul tundub see ohutu. Kuid korrutage see sadade komponentide ja tuhandete kasutajaliidese stringidega. Nüüd eeldab kogu koodibaas ainult ingliskeelset kasutajaliidest. Niipea kui proovite toetada mõnda muud keelt, hakkavad probleemid ilmnema kõikjal.

• Saksakeelne tekst on umbes 30% pikem. Nupud jooksevad üle.
• Araabia keel nõuab paremalt vasakule paigutust. Terved kasutajaliidesed lähevad katki.
• Mitmuse reeglid erinevad keeliti. Sõnumid muutuvad grammatiliselt vigaseks.

Ilma rahvusvahelistamise arhitektuurita muutub lokaliseerimine kiiresti suureks refaktoreerimisprojektiks.

---

Kuidas muutis AI-ga koodi genereerimine lokaliseerimise keerulisemaks?

Tänapäevane arendus toetub üha enam AI-kodeerimistööriistadele: Cursor, GitHub Copilot, ChatGPT, Replit, Lovable ja Bolt. Need tööriistad optimeerivad kiiruse ja töötava kasutajaliidese, mitte arhitektuuri jaoks.

Tüüpiline genereeritud kood näeb välja selline:

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

Tüüpilisest AI-ga genereeritud projektist võib leida sadu või tuhandeid hardcoded kasutajaliidese stringe, dubleeritud kasutajaliidese teksti, tõlkevõtmete puudumise, lokaalefailide puudumise ja mitmuse toe puudumise. Teisisõnu: suurepärased demod, kohutav lokaliseerimisarhitektuur.

Muster on etteaimatav. Meeskonnad ehitavad kiiresti, avaldavad toote, koguvad hoogu – ja saavad siis aru: „Kogu meie kasutajaliides on hardcoded inglise keeles.” Selleks hetkeks nõuab lokaliseerimise lisamine suure osa kasutajaliidese koodibaasi muutmist.

---

Üks korduv muster, mida näeme

Väikeste AI-ga genereeritud SaaS-projektide skannimisel ilmneb muster kiiresti. Ühes analüüsitud Reacti prototüüpprojektis oli 312 failis 1 284 kasutajaliidese stringi ja rahvusvahelistamise struktuur puudus täielikult. Näited hõlmasid:

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

Lokaliseerimise lisamiseks pidi meeskond eraldama kasutajaliidese stringid sadadest komponentidest, kasutusele võtma tõlkevõtmed, looma lokaalefailid ja kasutajaliidese loogika ümber kirjutama – enne kui tõlkimine üldse alata sai. Näeme seda mustrit AI-ga genereeritud projektides korduvalt.

---

Miks ei saa traditsioonilised lokaliseerimistööriistad AI-ga genereeritud koodiga hakkama?

Enamik lokaliseerimistööriistu loodi tõlkemeeskondadele, mitte arendajatele. Nende töövood eeldavad, et arendusmeeskond on juba juurutanud i18n-raamistiku, tõlkevõtmed, lokaalfailide struktuurid ja stringide eraldamise töövood. Kuid tänapäevastel koodibaasidel – eriti AI-ga genereeritutel – puudub see alus sageli täielikult. Seetõttu seisavad meeskonnad silmitsi ootamatu tegelikkusega: enne kui nad saavad midagi tõlkida, peavad nad esmalt kogu kasutajaliidese kihi ümber refaktoreerima.

---

Lokaliseerimisvirna puuduv kiht

Tänapäevane lokaliseerimisvirn näeb tavaliselt välja selline:

Kuid üks kriitiline osa on puudu. Tegelikult peab toimuma järgmine:

See puuduv kiht peab skannima koodibaasi, eraldama kasutajaliidese stringid, genereerima tõlkevõtmed, looma lokaalefailid, tuvastama duplikaatstringid ja koostama terminoloogiasõnastikud. Alles seejärel saavad tõlketöövood alata.

---

Miks see probleem on plahvatuslikult kasvamas

Kolm suurt trendi põrkuvad.

1. AI-keskne arendus. Üha rohkem rakendusi ehitatakse AI-toega kodeerimise abil. Mõne idufirma koodibaas on nüüd suuresti AI-ga genereeritud. Arhitektuur jääb sageli kiirele tarnimisele alla.
2. Indie-häkkerite plahvatuslik kasv. Igal nädalal käivitatakse tuhandeid uusi SaaS-tooteid. Enamik neist alustab inglise keelega.
3. Üleilmsed kasutajad esimesest päevast. Isegi väikesed tooted tõmbavad kiiresti kasutajaid Saksamaalt, Brasiiliast, Indiast ja Jaapanist. Niipea kui rahvusvahelised kasutajad saabuvad, muutub lokaliseerimine kiireloomuliseks. Kuid arhitektuur ei ole tavaliselt valmis.

---

Teistsugune lähenemine

Mis siis, kui rahvusvahelistamist saaks automatiseerida? Just seda teeb hoidla ühendamine globalize.now-ga. Esimene teisendus käivitatakse rakenduses ühe korra ja see annab teada, mida leiti:

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

Done in 2.7s

Tööriist skanniks koodibaasi, eraldaks kasutajale nähtavad stringid, genereeriks struktureeritud tõlkevõtmed, looks lokaalefailid ja kirjutaks kasutajaliidese koodi automaatselt ümber. Muutes selle:

<button>Submit order</button>

selliseks:

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

Järsku on kogu koodibaas tõlkevalmis.

---

Uus kategooria: AI-valmis lokaliseerimine

Lokaliseerimistööriistade järgmine põlvkond ei alusta tõlkijatest. See alustab koodi teisendamisest. Töövoog näeb pigem välja selline:

Lokaliseerimisökosüsteemi suurim puudujääk on praegu selle esimese sammu automatiseerimine: koodibaasi ettevalmistamine üleilmsete kasutajate jaoks.

Vaadake, kuidas globalize.now seda arendajameeskondade jaoks automaatselt teeb.

CAT-tööriistadest AI-põhiste töövoogudeni kulgeva ajaloolise arengu kohta lugege lokaliseerimise kolmest etapist AI-ajastul.

---

Lokaliseerimise tulevik

Lokaliseerimine oli varem tõlkeprobleem. AI-arenduse ajastul muutub see koodiarhitektuuri probleemiks. Meeskonnad, kes selle kihi lahendavad, määravad, kuidas üleilmset tarkvara järgmisel kümnendil ehitatakse.