Miks lähevad tõlkefailid pidevalt sünkroonist välja?

Tõlkefailid triivivad, sest sama andmestikku haldavad kaks süsteemi ja kumbki ei jää peale. Teie hoidla muutub, kui arendaja merge’b muudatuse. Tõlkefailid muutuvad siis, kui keegi mäletab neid uuendada. Need on erinevad kellad ning nende vahele jäävad puuduvad võtmed, orvuks jäänud võtmed ja aegunud stringid. globalize.now sulgeb selle lõhe, genereerides võtmed ja lokaalifailid seal, kus koodi kirjutatakse, nii et teist mahajäävat kella pole.

Mis põhjustab lokaalifailide tegeliku sünkroonist väljalangemise?

Üks fail kirjutatakse valmis, ülejäänud faile hooldatakse – need ei ole sama töö.

Funktsiooni arendav arendaja muudab faili en.json, sest just sinna läheb see string. Teised lokaalid on kellegi teise mure ja kellegi teise ajakava küsimus. Üks arendaja kirjeldas DEV-is seda mustrit: kaks tõrkevormi korduvad – võtmed lisatakse ingliskeelsesse faili ja unustatakse teistesse, mistõttu osa rakendusest langeb vaikselt tagasi inglise keelele, või kustutatakse võtmed ühest lokaalist, kuid jäävad teistesse alles, mistõttu kogunevad kasutud kirjed. Mõlemal juhul avastatakse probleem alles kliendi kaebuse kaudu, nädalaid hiljem.

Kumbki neist ei ole tõlkeprobleem. Midagi ei tõlgitud valesti. Stringe lihtsalt ei suunatud kunagi kuhugi.

See tõrkemuster elab üle iga tööriistauuenduse, sest tööriistad asuvad stringi loomise kohast allavoolu. Kui string ei jõua kunagi töövoogu, ei aita ka parem töövoog. Sama algpõhjus ilmneb ahelas veel varem, kui kodeerimisagent kirjutab stringe, millele pole üldse võtmeid loodud.

Miks tekitavad lokaalifailid nii palju ühendamiskonflikte?

Sest need on genereeritud andmed, mida muudetakse käsitsi, masinate kirjutamiseks mõeldud vormingus.

Lokaalifail on võtmete ja stringide lame kaart. Kaks haru, mis mõlemad lisavad funktsiooni, täiendavad seda kaarti tavaliselt samas piirkonnas, sageli samas tähestikulises jaotises. Git näeb semantilise struktuurita failis kõrvuti asuvate ridade kahte muudatust ega mõista nende tähendust, mistõttu palub inimesel konflikti lahendada.

Konflikti lahendav inimene on arendaja, kes ei loe sihtkeelt. Turvaline valik on jätta alles mõlemad pooled – nii tekivad topeltvõtmed. Kiire valik on jätta alles üks, mistõttu kustutatakse tõlked vaikselt.

Keegi ei lahenda lukufaili konflikte käsitsi. See genereeritakse uuesti. Lokaalifailid väärivad sama kohtlemist niipea, kui need pole enam dokumendid, mida inimene kirjutab.

Kui vanaks tõlge ülevaatamist oodates muutub?

Piisavalt vanaks, et see ei kirjelda enam toodet – ja seda saab avalike andmete põhjal mõõta.

DevOps.com-is avaldatud juhtumiraport käsitles viit päris lokaliseerimise pull request’i avatud lähtekoodiga projektides. Kõige õpetlikum neist on Kilo Code’i PR #8377: automaatsed kontrollid läbisid edukalt, hooldaja ülevaatus saabus hiljem ja hoidla oli selleks ajaks juba muutunud. PR suleti palvega esitada see uuesti praeguse arhitektuuri põhjal. Sama raport kirjeldab ka OpenClaw’ juhtumit, kus vabatahtlikud pakkusid tõlkeid hispaania, jaapani, portugali, korea, hiina ja vietnami keeles, kuid hooldajad ütlesid, et neil pole võimalust neid vastu võtta.

Vaadake neid pigem latentsus- kui kvaliteediraportitena. Tõlked olid kirjutamise hetkel õiged. Liides muutus nende järjekorras ootamise ajal.

See on kulu, mida lokaliseerimistööriistade võrdlemisel keegi hinnasildile ei pane. Kõik mõõdavad tõlget. Peaaegu keegi ei mõõda, kui kaua string teel on või mida liides selle äraoleku ajal muutis.

Kui palju edasi-tagasi liikumine tegelikult maksab?

Koordineerimise mõttes rohkem kui tõlkimise mõttes – seepärast ei selgita arve kunagi, kust valu tuleb.

Nähtav kulu on sõna, võtme või kasutaja kohta ning ilmub kord kuus arvele. Nähtamatu kulu on arendaja, kes vastab küsimusele „millist faili ma muutma pean“, teine arendaja, kes lahendab konflikti keeles, mida ta lugeda ei oska, kolmas, kes märkab, et saksakeelsest build’ist puudub üksteist võtit, ning algse funktsiooni autor, kellelt küsitakse viis nädalat tagasi kirjutatud stringi kohta.

Ükski neist kuludest ei kajastu hinnavõrdluses. Kõik need makstakse igas sprindis kinni arendajate ajaga ja arendajate tunnihinnaga. Madala hinnasildiga tööriist, mis võtab kahelt insenerilt nädalas ühe tööpäeva, ei ole odav.

Selle kulu tekitabki edasi-tagasi liikumine. Failide viimine stringide loomise kohast tõlkimise kohta on kallis samm ja jääb kalliks sõltumata sellest, kellelt te selle ostate. Seepärast liigub lokaliseerimine üha enam arendustöövoogu.

Mis muutub, kui võtmed genereeritakse seal, kus kood kirjutatakse?

Teine kell kaob ja triivil pole enam tekkekohta.

Jada ei ole enam järgmine: arendaja kirjutab hardcoded string’i, keegi leiab selle hiljem, keegi loob võtme, keegi saadab faili välja, keegi tõlgib selle ja keegi toob tagasi. Selle asemel kirjutatakse string funktsiooniga samasse commit’i juba võtme ja väärtusena ning tõlge järgneb sealt.

globalize.now puhul algab see ühekordse teisendusega. Ühendate oma hoidla rakenduses ning olemasolevad hardcoded string’id eraldatakse ühe läbimisega võtmeteks ja lokaalifailideks. Seejärel panevad agent skills kodeerimisagendid, nagu Cursor ja Claude Code, stringid kohe algusest võtmetega kirjutama, mitte hardcode’ima, ning push-jobid tõlgivad uued kataloogiüksused nende tekkimisel.

Oluline sõna on „üks kord“. Teisendus on keeruline osa ja see toimub ühe korra. Edasine – varem käsitsi tehtu – jookseb koodiga samas rütmis. Just seepärast tuleb see paigutada arendaja töövoogu, mitte selle kõrvale.

Käitusaegsed teegid jäävad muutumatuks. i18next ja next-intl loevad lokaalifaile täpselt nagu varem. Tõlgete serveerimises ei muutu midagi. Muutub see, kes failid kirjutab.

Kuidas teha vahet triivil ja päris tõlkeprobleemil?

Küsige, kas mõni tõlkija seda stringi üldse nägi.

Kui saksakeelsest failist puudub võti, ei eksinud ükski tõlkija. String ei jõudnud kunagi tõlkijani. See on suunamisprobleem ja ülevaatussammude lisamine teeb asja hullemaks, sest lisab järjekorraaja protsessile, mille probleem on juba niigi latentsus.

Kui saksakeelses failis on võti olemas, kuid sõnastus ei sobi konteksti, on tegu päris tõlkeprobleemiga. See väärib saksa keelt oskavat inimest, kes näeb ka seda, kus string renderdatakse. Sellele tasub aega kulutada.

Enamikul tiimidel on esimest tüüpi juhtumeid teisest palju rohkem, kuid neid käsitletakse sama probleemina – seepärast tundub lokaliseerimine lõputu. Kui need lahutada, töökoormus väheneb, sest suunamise pool ei ole enam üldse inimtöö. See eristus on väiksema tiimi puhul veel olulisem, mistõttu tuleb see kõige teravamalt esile üksikarendajate ja kiiresti tarnivate väikeste tiimide puhul.

Kasulik test: loendage, kui paljud teie viimasest kümnest lokaliseerimisveast olid valed sõnad ja kui paljud puuduvad sõnad. Kui enamik olid puuduvad, pole teil tõlkeprobleemi. Teil on torustikuprobleem – ja torustikku saab automatiseerida viisil, mida otsustusvõimet ei saa. Sama loogika kehtib, kui arvutate välja, milline peaks lokaliseerimise tegelik kulu teile olema.

Lokaalifailide triiv on suunamisprobleem, mis kannab tõlkeprobleemi maski. Ühendage hoidla üks kord ja suunamine ei ole enam teie töö.