Kodėl lokalizacija kyla į ankstesnį kūrimo ciklo etapą?

Lokalizacija kyla į ankstesnį etapą, nes žlugo pagrindinė senojo proceso prielaida: kodas keičiasi pakankamai lėtai, kad būtų galima eksportuoti stabilų eilučių katalogą, išversti jį kitur ir importuoti rezultatus iki kito leidimo. DI kodavimo agentai šią prielaidą panaikino. globalize.now yra DI pagrįsta lokalizacijos infrastruktūra, sukurta naujai lokalizacijos vietai — ji veikia kūrimo ciklo viduje ir pateikiama kaip pull request. Šiame straipsnyje aiškinama, kodėl pasikeitė būtent vieta, o ne vertimo kokybė.

Ką reiškia perkelti lokalizaciją į ankstesnį kūrimo ciklo etapą?

Tai reiškia, kad lokalizacijos darbo vienetu tampa nebe eilučių katalogas, o commit. Sename modelyje lokalizacija prasideda užbaigus kodą. Naujajame modelyje ji vyksta ten, kur yra kodas, tuo metu, kai kodas keičiamas, o jos rezultatas taip pat yra kodas — lokalizuotas pull request, kurį galite palyginti, peržiūrėti ir sujungti.

Štai kaip atrodo abu procesai.

Traditional:   build → internationalize → export → translate → review → import → ship

Upstream:      code → push → localized PR → merge → ship

Pirmąjį procesą sudaro septyni etapai, o saugykla jame paliekama du kartus. Antrąjį sudaro penki etapai, ir nė vienas iš jų nepalieka saugyklos. Būtent šis struktūrinis skirtumas, o ne viena konkreti funkcija, yra pagrindinė šio straipsnio tema.

Kaip veikia tradicinis lokalizacijos procesas?

Jis veikia kaip ciklas, kuriame kiekviena rodyklė reiškia eilę. Sukuriate funkciją. Internacionalizuojate ją, ištraukdami eilutes į raktus, jei jūsų komanda arba DI agentas apskritai sugeneravo struktūruotą kodą. Eksportuojate katalogą į vertimų platformą. Vertėjai arba mašininio vertimo sistema jį apdoroja. Kažkas atlieka peržiūrą. Importuojate rezultatus, išsprendžiate konfliktus, susikaupusius katalogui esant išorėje, ir išleidžiate produktą.

Kiekvienas perdavimas reikalingas todėl, kad darbas vyksta kitoje vietoje, jį atlieka kiti žmonės ir pagal kitą grafiką. Tai buvo racionalus sprendimas, kai leidimai buvo kas ketvirtį, o eilutės keisdavosi paketais. Paslėpta proceso priklausomybė yra stabilumas: katalogas turi pakankamai ilgai nesikeisti, kad būtų galima užbaigti visą ciklą.

Dabar jis nebesustoja. DORA 2025 m. DI asistuojamo programinės įrangos kūrimo būklės ataskaitoje 90 % programinės įrangos specialistų nurodė darbe naudojantys DI įrankius, o DX 2025 m. ketvirtojo ketvirčio poveikio tyrime nustatyta, kad DI sugeneruotas kodas sudarė 22 % stebimos medianinės įmonės sujungto kodo. Kodas, kuris anksčiau keisdavosi kas savaitę, dabar pasikeičia tarp pietų ir kasdienio susitikimo.

Kaip atrodo lokalizacija kūrimo ciklo viduje?

Kaip bet kuris kitas automatizuotas patikrinimas, vykdomas po įkėlimo. Vieną kartą konvertuojate kodų bazę: ištraukiamos eilutės, sugeneruojami raktai, sukuriami lokalės failai ir prijungiama vykdymo infrastruktūra. Po to sinchronizavimas vyksta po kiekvieno įkėlimo. Kai commit įveda naujų eilučių, vertimai grįžta kaip pull request į jūsų šaką, jūsų saugykloje ir tokios struktūros, kokia naudojama likusioje programėlės dalyje.

Tai ne hipotetinis našumas. 2026 m. rugpjūtį atlikto bandymo demonstracinėje saugykloje metu įkeltas commit po 49 sekundžių grįžo kaip lokalizuotas pull request, apimantis 30 vertimo vienetų vokiečių, prancūzų ir ispanų kalbomis. Mažiau nei minutė nuo commit iki peržiūrai paruošto pull request, be žmogaus įsitraukimo iki peržiūros. Palyginkite tai su bet kuriuo procesu, kuriame yra žodis „eksportas“.

Kad būtų aišku, vienkartinė konversija nevyksta akimirksniu. Realioms programėlėms ji užtrunka apie 30 minučių, nes pertvarkomas kodas: ištraukiamos eilutės, generuojami raktai ir prijungiama vykdymo biblioteka. Tai yra durys. Produktas yra ciklas, vykstantis po kiekvieno vėlesnio įkėlimo.

Svarbiausia šio ciklo savybė nėra greitis. Svarbu tai, kad niekas nepaliko saugyklos. Išorinėje platformoje nėra katalogo, kuris pamažu nutolsta nuo pagrindinės šakos. Anksčiau paskelbtas monorepo bandymas parodė vienkartinės konversijos mastą, o ciklas užtikrina, kad rezultatas išliktų ir vėliau. Sujungti arba uždaryti — tie patys du veiksmai, kurie taikomi bet kuriam kitam pakeitimui. Jei jau dirbate tokiu būdu, kūrėjams skirtoje dokumentacijoje rasite sąrankos instrukcijas.

Kodėl DI kodavimo agentai verčia keisti šį procesą?

Nes jie perkėlė kliūtį. Anksčiau lokalizaciją ribojo vertimo pajėgumai — kaip greitai tiekėjas ar variklis galėjo apdoroti tinkamai struktūruotą katalogą. Agentai šią ribą gerokai viršija ir sukūrė naują kliūtį prieš ją. Dabar trūkstamas išteklius yra architektūrinė tvarka po generavimo: išlaikyti nuoseklius raktus, pilnus lokalės failus ir nepažeistą struktūrą, kai agentas kasdien papildo kodų bazę naudotojo sąsaja.

Agentas, paprašytas sukurti atsiskaitymo puslapį, sugeneruoja veikiantį atsiskaitymo puslapį, kurio eilutės kietai įrašytos JSX kode. Apie šio reiškinio anatomiją rašėme straipsnyje DI kodas sugadino lokalizaciją: viename analizuotame React projekte buvo 1 284 naudotojo sąsajos eilutės 312 failų, tačiau nebuvo jokios i18n struktūros. Katalogo, kurį tradicinis procesas nori eksportuoti, toje kodų bazėje apskritai nėra. Rytoj kodų bazė vėl atrodys kitaip, nes agentas ir toliau leidžia pakeitimus.

Vėlesnis procesas su tokia realybe nuolat atsilieka. Kad ir ką jis eksportavo, importo metu tai jau pasenę. Vienintelė vieta, iš kurios lokalizacija gali suspėti paskui sugeneruotą kodą, yra pats jį generuojantis ciklas — nesvarbu, ar kodas gaunamas iš Cursor, Claude Code ar Lovable.

Argi DI vertimas nėra tas pats?

Ne, ir būtent čia rinkos diskusija nukrypsta. Lokalise save pristato kaip DI lokalizacijos platformą, o Phrase siūlo Language AI mastelio mašininiam vertimui. Abi yra realios galimybės. Abi pagreitina vieną senojo proceso rodyklę — vertimo etapą. Katalogas vis tiek eksportuojamas, vis tiek laikomas išorinėje platformoje ir vis tiek grįžta per importą.

Greitesnė rodyklė septynių etapų cikle yra optimizacija. Ciklo pašalinimas yra kitas produktas. Tai ir yra tikrasis sluoksnių skirtumas: platformos, sukurtos vertėjų darbo eigoms, priklauso valdymo sluoksniui, o globalize.now yra žemiau esančiame infrastruktūros sluoksnyje — jis generuoja raktus ir lokalės failus tiesiai iš kodo, saugykloje. „DI pagrįsta“ apibūdina abu sprendimus, bet neatskiria nė vieno. Skirtumą lemia vieta.

Kas vis dar priklauso vėlesniam proceso etapui?

Didelės rizikos tekstams reikia žmogaus sprendimo. Teisiniai tekstai, reglamentuojami teiginiai, prekės ženklo balsas rinkoje, kuri jums ypač svarbi — tokiems dalykams reikia profesionalaus vertėjo ir papildomos peržiūros. Komandos, kurioms to reikia, ir toliau rinksis įrankius, sukurtus pagal vertėjų darbo eigą. Lokalizavimas ankstesniame etape tam netrukdo: lokalizuotas PR yra peržiūrimas paviršius, o prieš suliejimą žmogus gali jį įvertinti pagal bet kokį standartą.

Baigiasi era, kai kiekviena komanda turėjo diegti vertėjų darbo eigos platformą vien tam, kad galėtų išleisti antrąją kalbą. Vienas kūrėjas, naudodamas DI sukurtam produktui, neturi vertėjų, kuriuos reikėtų valdyti. Jis turi commitus. Įrankiai turi prisitaikyti prie jo darbo būdo.

Ciklas ir yra produktas

Jei jūsų kodas išleidžiamas per pull request’us, taip turėtų būti išleidžiami ir vertimai. globalize.now vieną kartą konvertuoja kodų bazę, o tada lokalizuoja ją po kiekvieno push’o — pateikus PR, jį suliejus ir išleidus.