Kodėl vertimo failai nuolat išsiderina?

Vertimo failai išsiderina, nes tuos pačius duomenis valdo dvi sistemos ir nė viena iš jų nelaimi. Jūsų saugykla pasikeičia, kai kūrėjas sujungia pakeitimus. Vertimo failai pasikeičia, kai kas nors prisimena juos atnaujinti. Tai du skirtingi laikrodžiai, o tarp jų atsiradusiame tarpe gyvena trūkstami raktai, našlaičiais likę raktai ir pasenusios eilutės. globalize.now panaikina šį atotrūkį generuodama raktus ir lokalės failus ten, kur rašomas kodas, todėl nebelieka antro laikrodžio, kuris galėtų atsilikti.

Kas iš tikrųjų išderina lokalės failus?

Vienas failas kuriamas, o likę prižiūrimi — tai nėra tas pats darbas.

Kūrėjas, kuriantis funkciją, redaguoja en.json, nes būtent į šį failą bus įrašyta eilutė. Kitos lokalės — kažkieno kito problema, sprendžiama kažkieno kito tvarkaraščiu. Apie šį modelį DEV rašęs kūrėjas apibūdino dvi nesėkmių formas: raktai įtraukiami į anglų kalbos failą ir pamirštami kituose, todėl dalis programos tyliai grįžta prie anglų kalbos, o raktai ištrinami vienoje lokalėje, bet lieka kitoje, todėl kaupiasi nebegaliojantys įrašai. Abiem atvejais apie problemą sužinoma iš kliento skundo — po kelių savaičių.

Nė vienas iš šių atvejų nėra vertimo problema. Niekas nebuvo išversta neteisingai. Eilutės tiesiog niekur nebuvo nukreiptos.

Tai nesėkmės scenarijus, išliekantis po kiekvieno įrankių atnaujinimo, nes įrankiai veikia toliau grandinėje nei vieta, kurioje eilutė sukuriama. Jei eilutė niekada nepatenka į procesą, geresnis procesas nepadės. Ta pati pagrindinė priežastis pasirodo dar anksčiau, kai kodavimo agentas sukuria eilutes, kurioms apskritai nesuteikti raktai.

Kodėl dėl lokalių failų kyla tiek daug suliejimo konfliktų?

Nes tai yra sugeneruoti duomenys, redaguojami rankomis, nors formatas sukurtas mašininiam rašymui.

Lokalės failas yra plokščias raktų ir eilučių susiejimas. Dvi šakos, kuriose kuriama funkcija, abu papildo šį susiejimą — dažniausiai netoli tos pačios vietos, dažniausiai toje pačioje abėcėlinėje srityje. Git mato du gretimų eilučių pakeitimus faile, kurio semantinės struktūros jis nesupranta, todėl paprašo žmogaus išspręsti konfliktą.

Konfliktą sprendžia kūrėjas, kuris neskaito tiksline kalba. Saugus pasirinkimas — palikti abi puses, taip įvedant pasikartojančius raktus. Greitas pasirinkimas — palikti vieną, taip tyliai ištrinant vertimus.

Niekas rankomis nesprendžia lockfile konfliktų. Jis sugeneruojamas iš naujo. Lokalės failams turi būti taikomas toks pats principas, kai tik jie nustoja būti dokumentais, kuriuos rašo žmogus.

Kiek pasensta vertimas, kol laukia peržiūros?

Tiek, kad nebeapibūdina produkto — ir tai galima viešai išmatuoti.

DevOps.com paskelbtoje ataskaitoje iš praktikos išnagrinėti penki realūs lokalizavimo pull request'ai atvirojo kodo projektuose. Pamokantis pavyzdys — Kilo Code PR #8377: automatiniai patikrinimai buvo sėkmingi, prižiūrėtojo peržiūra įvyko vėliau, o tuo metu saugykla jau buvo pasikeitusi. PR buvo uždarytas, pasiūlius jį pateikti iš naujo pagal dabartinę architektūrą. Toje pačioje ataskaitoje aprašoma ir OpenClaw problema: savanoriai pasiūlė vertimus į ispanų, japonų, portugalų, korėjiečių, kinų ir vietnamiečių kalbas, tačiau prižiūrėtojai teigė neturintys būdo juos įtraukti.

Vertinkite tai kaip delsos, o ne kokybės ataskaitas. Parašyti vertimai buvo teisingi. Kol jie laukė eilėje, sąsaja pasikeitė.

Tai kaina, kurios niekas neįtraukia lygindamas lokalizavimo įrankius. Visi matuoja vertimą. Beveik niekas nematuoja, kiek laiko eilutė praleidžia kelyje arba kas nutinka sąsajai, kol jos nėra.

Kiek iš tikrųjų kainuoja visas ciklas?

Daugiau koordinavimo nei vertimo — todėl sąskaita niekada nepaaiškina, iš kur kyla skausmas.

Matoma kaina skaičiuojama už žodį, raktą arba naudotoją ir kartą per mėnesį pasirodo sąskaitoje. Nematoma kaina — kūrėjas, klausiantis „kurį failą redaguoti?“, antras kūrėjas, sprendžiantis konfliktą kalba, kurios nemoka perskaityti, trečias pastebintis, kad vokiškame build'e trūksta vienuolikos raktų, ir pradinės funkcijos autorius, kurio po penkių savaičių klausiama apie jo parašytą eilutę.

Nė vienas iš šių dalykų nepatenka į kainų palyginimą. Už viską mokama kūrėjų laiku, pagal kūrėjų įkainius, kiekvieno sprinto metu. Įrankis, kurio kaina etiketėje maža, bet kuris dviem inžinieriams kainuoja po dieną per savaitę, nėra pigus.

Būtent visas ciklas sukuria šias išlaidas. Failų perkėlimas iš vietos, kurioje sukuriamos eilutės, į vietą, kurioje jos verčiamos, yra brangiausias etapas — ir jis išlieka brangus, nesvarbu, iš ko perkate paslaugą. Todėl lokalizavimas vis labiau keliamas į kūrimo procesą.

Kas pasikeičia, kai raktai generuojami ten, kur rašomas kodas?

Antrasis laikrodis išnyksta, o nukrypimui nebelieka iš kur atsirasti.

Procesas nebeatrodo taip: kūrėjas parašo į kodą įterptą eilutę, kažkas vėliau ją randa, kažkas suteikia jai raktą, kažkas išsiunčia failą, kažkas ją išverčia, o kažkas parsiunčia atgal. Dabar eilutė parašoma kaip raktas su reikšme tame pačiame commit'e kaip ir funkcija, o vertimas atliekamas toliau.

Su globalize.now viskas prasideda nuo vienkartinės konversijos. Prijungiate savo saugyklą programoje, o esamos į kodą įterptos eilutės vienu veiksmu ištraukiamos į raktus ir lokalių failus. Vėliau agentų įgūdžiai leidžia tokiems kodavimo agentams kaip Cursor ir Claude Code nuo pat pradžių rašyti eilutes su raktais, o push užduotys verčia naujus katalogo vienetus, kai tik jie atsiranda.

Svarbiausias žodis — vieną kartą. Konversija yra sudėtingiausia dalis, ir ji atliekama vieną kartą. Toliau vyksta tai, kas anksčiau buvo daroma rankomis, tuo pačiu tempu kaip ir kodas — būtent todėl tai perkeliama į kūrėjo darbo eigą, o ne paliekama šalia jos.

Vykdymo bibliotekos nesikeičia. i18next ir next-intl toliau skaito lokalių failus lygiai kaip anksčiau. Nieko nesikeičia ir tai, kaip pateikiami vertimai. Keičiasi tik tai, kas rašo failus.

Kaip atskirti nukrypimą nuo tikros vertimo problemos?

Paklauskite, ar vertėjas apskritai matė eilutę.

Jei vokiškame faile trūksta rakto, vertėjas nesuklydo. Eilutė jo nepasiekė. Tai maršrutizavimo problema, o papildomi peržiūros etapai ją tik pablogina, nes į procesą, kurio problema jau ir taip yra delsa, įtraukia dar daugiau laukimo.

Jei vokiškame faile raktas yra, bet formuluotė netinka kontekstui, tai tikra vertimo problema. Jai reikia žmogaus, mokančio vokiečių kalbą ir matančio, kur eilutė atvaizduojama. Tokiam darbui verta skirti laiko.

Dauguma komandų turi gerokai daugiau pirmojo tipo problemų nei antrojo, tačiau laiko jas ta pačia problema — todėl lokalizavimas atrodo nesibaigiantis. Atskirkite jas, ir darbo sumažės, nes maršrutizavimo dalis apskritai nustos būti žmogaus darbas. Šis skirtumas dar svarbesnis mažesnėms komandoms, todėl ryškiausiai jis matomas vieniems kūrėjams ir mažoms, greitai leidžiančioms komandoms.

Naudingas testas: suskaičiuokite, kiek iš dešimties paskutinių lokalizavimo klaidų buvo neteisingi žodžiai, o kiek — trūkstami. Jei dauguma buvo trūkstami, neturite vertimo problemos. Turite infrastruktūros problemą, o infrastruktūrą galima automatizuoti taip, kaip neįmanoma automatizuoti sprendimo priėmimo. Ta pati logika taikoma aiškinantis, kiek iš tikrųjų turėtų kainuoti lokalizavimas.

Lokalės failų nukrypimas yra maršrutizavimo problema, apsimetanti vertimo problema. Prijunkite saugyklą vieną kartą, ir maršrutizavimas nebebus jūsų darbas.