Kāpēc tulkošanas faili pastāvīgi izkrīt no sinhronizācijas?

Tulkošanas faili izkrīt no sinhronizācijas, jo divas sistēmas pārvalda tos pašus datus, un neviena no tām nav galvenā. Jūsu repozitorijs mainās, kad izstrādātājs veic apvienošanu (merge). Jūsu tulkošanas faili mainās, kad kāds atceras tos atjaunināt. Tie ir divi dažādi pulksteņi, un starpība starp tiem ir vieta, kur mīt pazudušas atslēgas, atraitas atslēgas un novecojuši teksti. globalize.now ir AI darbināta lokalizācijas infrastruktūra, kas novērš šo plaisu, ģenerējot atslēgas un lokalizācijas failus tur, kur tiek rakstīts kods, tāpēc otra pulksteņa, kuram atpalikt, vienkārši nav.

Kas tieši izraisa lokalizācijas failu nesinhronizāciju?

Viens fails tiek autora rakstīts, bet pārējie tikai uzturēti, un tie nav vienādi darbi.

Izstrādātājs, kas veido funkciju, rediģē en.json, jo tieši šajā failā šis teksts nonāk. Pārējās valodas ir kāda cita problēma, kāda cita grafikā. Izstrādātājs, kurš par šo modeli rakstīja DEV platformā, aprakstīja divas kļūmju formas: atslēgas tiek pievienotas angļu failam un aizmirstas citos, tāpēc daļa lietotnes klusi atgriežas pie angļu valodas, un atslēgas tiek dzēstas vienā valodā, bet saglabājas citā, tāpēc uzkrājas nedzīvi ieraksti. Atklāšanas mehānisms abos gadījumos ir klienta sūdzība, kas pienāk pēc nedēļām.

Neviens no šiem gadījumiem nav tulkošanas problēma. Nekas nebija nepareizi iztulkots. Teksti vienkārši nekad netika novirzīti nekur.

Šī ir kļūme, kas pārdzīvo katru rīku uzlabojumu, jo rīki atrodas lejasplūsmā no vietas, kur teksts tika izveidots. Ja teksts nekad neieiet cauruļvadā, labāks cauruļvads nepalīdz. Tas pats pamatcēlonis parādās agrāk ķēdē, kad kodēšanas aģents raksta tekstus, kas nekad netika sasaistīti ar atslēgām.

Kāpēc lokalizācijas faili rada tik daudz apvienošanas konfliktu?

Tāpēc, ka tie ir ģenerēti dati, kas tiek manuāli rediģēti formātā, kas paredzēts, lai to rakstītu mašīnas.

Lokalizācijas fails ir plakana karte no atslēgām uz tekstiem. Divi zari, kas abi pievieno funkciju, abi pievieno ierakstus šai kartei, parasti līdzīgā vietā, parasti tajā pašā alfabētiskajā apkaimē. Git redz divus labojumus blakus esošās rindās failā bez semantiskas struktūras, ko tas saprastu, un lūdz cilvēkam to atrisināt.

Cilvēks, kas to atrisina, ir izstrādātājs, kurš neprot lasīt mērķa valodu. Drošais gājiens ir paturēt abas puses, un tā rodas dublētas atslēgas. Ātrais gājiens ir paturēt vienu, un tā tulkojumi tiek klusi izdzēsti.

Neviens manuāli neatrisina konfliktus lockfile failā. Tie tiek pārģenerēti. Lokalizācijas faili pelna to pašu attieksmi brīdī, kad tie pārstāj būt dokumenti, ko raksta cilvēks.

Cik ļoti tulkojums noveco, gaidot pārskatīšanā?

Pietiekami, lai vairs nepārstāvētu produktu, un tas ir izmērāms publiski.

Lauka pārskats, publicēts DevOps.com izpētīja piecus reālus lokalizācijas pull request atklātā koda projektos. Pamācošākais ir Kilo Code PR Nr. 8377: automātiskās pārbaudes noritēja veiksmīgi, uzturētāja pārskats pienāca vēlāk, un repozitorijs tā laikā jau bija attīstījies tālāk. PR tika slēgts ar aicinājumu iesniegt to no jauna atbilstoši pašreizējai arhitektūrai. Tas pats pārskats fiksē OpenClaw problēmu, kurā brīvprātīgie piedāvāja tulkojumus spāņu, japāņu, portugāļu, korejiešu, ķīniešu un vjetnamiešu valodā, bet uzturētāji atbildēja, ka viņiem nav veida, kā tos iestrādāt.

Lasiet tos kā aizkaves ziņojumus, nevis kvalitātes ziņojumus. Tulkojumi bija pareizi to tapšanas brīdī. Interfeiss mainījās, kamēr tie gaidīja rindā.

Tā ir izmaksa, ko neviens neaprēķina, salīdzinot lokalizācijas rīkus. Visi mēra tulkojumu. Gandrīz neviens nemēra, cik ilgi teksts pavada ceļā, vai ko interfeiss dara tā prombūtnes laikā.

Cik faktiski maksā šis turp-atpakaļ cikls?

Vairāk koordinācijā nekā tulkošanā, tāpēc rēķins nekad neatspoguļo šīs sāpes.

Redzamā izmaksa ir par vārdu, par atslēgu vai par lietotāja vietu, un tā parādās rēķinā reizi mēnesī. Neredzamā izmaksa ir izstrādātājs, kas jautā „kuru failu man rediģēt”, otrs izstrādātājs, kas atrisina konfliktu valodā, kuru nesaprot, trešais, kas pamana, ka vācu versijai trūkst vienpadsmit atslēgu, un sākotnējais funkcijas autors, kuram jautā par tekstu, ko viņš uzrakstīja pirms piecām nedēļām.

Nekas no tā neparādās cenu salīdzinājumā. Tas viss tiek apmaksāts izstrādātāju laikā, pēc izstrādātāju likmēm, katrā sprintā. Rīks ar zemu uzlīmes cenu, kas maksā divus inženierus dienu nedēļā, nav lēts.

Šis turp-atpakaļ cikls ir tas, kas rada šo izmaksu. Failu pārvietošana starp vietu, kur teksti tiek izveidoti, un vietu, kur tie tiek tulkoti, ir dārgais posms, un tas paliek dārgs neatkarīgi no tā, no kā to iegādājaties. Tāpēc arī lokalizācija arvien vairāk pārceļas augšupplūsmā izstrādes ciklā.

Kas mainās, kad atslēgas tiek ģenerētas tur, kur tiek rakstīts kods?

Otrais pulkstenis pazūd, un novirzei vienkārši nav no kurienes rasties.

Secība vairs neizskatās šādi: izstrādātājs uzraksta burtisku tekstu, kāds to vēlāk atrod, kāds tam pievieno atslēgu, kāds nosūta failu ārā, kāds to iztulko, kāds to atved atpakaļ. Tā izskatās šādi: teksts uzreiz tiek rakstīts kā atslēga ar vērtību, tajā pašā commit kā funkcija, un tulkojums no tā seko automātiski.

Ar globalize.now tas sākas ar vienreizēju konversiju. Jūs savienojat savu repozitoriju lietotnē, un esošie burtiskie teksti tiek izgūti atslēgās un lokalizācijas failos vienā piegājienā. Pēc tam aģenta prasmes liek kodēšanas aģentiem, piemēram, Cursor un Claude Code, uzreiz rakstīt tekstus ar atslēgām, nevis tos iekodēt burtiski, un push uzdevumi iztulko jaunās kataloga vienības, tiklīdz tās parādās.

Svarīgais vārds ir vienreiz. Konversija ir grūtākā daļa, un tā notiek vienu reizi. Tas, kas seko, ir daļa, kas agrāk bija manuāla, tagad darbojas tajā pašā tempā, kādā tiek rakstīts kods — tieši tas ir jēga to ievietot izstrādes darbplūsmā, nevis blakus tai.

Izpildlaika bibliotēkas tas neietekmē. i18next un next-intl joprojām lasa lokalizācijas failus tieši tāpat kā iepriekš. Nekas nemainās tajā, kā tulkojumi tiek pasniegti. Mainās tas, kas raksta failus.

Kā atšķirt novirzi no īstas tulkošanas problēmas?

Jautājiet, vai tulkotājs vispār kādreiz redzēja šo tekstu.

Ja vācu failā trūkst atslēgas, neviens tulkotājs nekļūdījās. Teksts vienkārši nekad nesasniedza nevienu. Tā ir maršrutēšanas kļūme, un pārskatīšanas soļu pievienošana to tikai pasliktina, jo pievieno gaidīšanas laiku procesam, kura problēma jau tā ir aizkave.

Ja vācu failā atslēga ir, bet formulējums neatbilst kontekstam, tā ir īsta tulkošanas problēma, un tā ir pelnījusi cilvēku, kurš prot vāciski un var redzēt, kur teksts tiek attēlots. Tas ir laika vērts.

Lielākajai daļai komandu pirmā veida gadījumu ir daudz vairāk nekā otrā, un tās tiek uzskatītas par vienu un to pašu problēmu, tāpēc lokalizācija šķiet bezgalīga. Ja tās nodala, darba apjoms samazinās, jo maršrutēšanas puse vairs vispār nav cilvēka darbs. Šī atšķirība ir jo svarīgāka, jo mazāka komanda, tāpēc tā visasāk izpaužas neatkarīgiem izstrādātājiem un mazām komandām, kas strādā ātri.

Noderīgs tests: saskaitiet, cik no jūsu pēdējām desmit lokalizācijas kļūdām bija nepareizi vārdi un cik — trūkstoši vārdi. Ja lielākā daļa bija trūkstoši, jums nav tulkošanas problēmas. Jums ir cauruļvadu problēma, un cauruļvadus var automatizēt tā, kā to nevar izdarīt ar vērtējumu. Tā pati loģika attiecas arī tad, kad domājat, cik lokalizācijai patiesībā vajadzētu jums maksāt.

Lokalizācijas failu novirze ir maršrutēšanas problēma, kas tērpusies tulkošanas problēmas drēbēs. Pievienojiet repozitoriju vienu reizi, un maršrutēšana vairs nebūs jūsu darbs.