Kas notiek, kad MI aģents internacionalizē reālu monorepozitoriju?

Tas izguva 28 lietotāja saskarnes teksta kandidātus, pārrakstīja 41 tulkojuma ierakstu vairākos failos, konfigurēja starpprogrammatūru un maršrutēšanu un izveidoja lokalizācijas failus 5 mērķa valodām. Iestatīšana, konvertēšana un tulkošana no sākuma līdz beigām aizņēma apmēram 90 minūtes. globalize.now ir MI darbināma lokalizācijas infrastruktūra, un mēs to izmēģinājām reālā produkcijas monorepozitorijā, lai redzētu, kas patiesībā notiktu. Bez sagatavotas demonstrācijas. Bez drošības tīkla. Vienkārši reāla koda bāze ar reālu sarežģītību.

Šī koda bāze piederēja lokalizācijas nozares veterānam, kurš vairāk nekā desmit gadus strādāja par arhitektu vienā no vadošajām tulkošanas pārvaldības platformām.

Kas atradās šajā monorepozitorijā?

Tas nebija mācību projekts. Monorepozitorijā bija ietverta Next.js tīmekļa lietotne, Android lietotne, MCP serveri un dokumentācija, ko atveido trešās puses pakalpojums. Izstrādātājs ikdienā izmanto Claude Code, veido produktus, izmantojot MI rīkus no sākuma līdz beigām, un bija izveidojis visu šo tehnoloģiju kopu trīs mēnešu laikā.

Mērķis bija Next.js priekšgals. Android lietotne, MCP serveri, dokumentācijas vietne, kas veidota ar Mintlify — nekas no tā nedrīkstēja tikt aiztikts. Jautājums bija, vai MI aģents spēs to noteikt pats, bez skaidras norādes.

Tas būtu iespējams. Aģents noskenēja visu repozitoriju un pievērsās Next.js lietotnei. Praksē manuāls tvēruma iestatījums nebija nepieciešams, tomēr izstrādātājs atzīmēja, ka viņam būtu patikusi iespēja norādīt „konvertēt tikai /apps/web“ – tā drošības sajūtai. Tas ir pamatots ieteikums un vērts pievienot. Tomēr tas nekavēja konvertāciju.

Kā darbojās konfigurācija?

Izstrādātājs izvēlējās vadītā režīma iestatīšanu, lai izprastu procesu. Konfigurācija ietvēra piecus lēmumus: pakotņu pārvaldnieku (NPM, lai gan pastāvēja arī vecāks PNPM lockfile), katalogu formātu (PO/GetText, ieteicams komentāru atbalsta dēļ), iestatīšanas režīmu (vadīts), pirmkoda valodu (angļu) un mērķa valodas (spāņu, itāļu, ungāru, čehu, slovāku).

Vērā ņemams novērojums: jautājums par kataloga formātu izraisīja svārstības pat kādam ar dziļu lokalizācijas pieredzi. Viņa reakcija bija tieša – viņš nedomāja, ka šai izvēlei ir tik lielā mērā jājautā lietotājam. Tas jāautomatizē.

Maršrutēšanas stratēģija balstīta uz ceļu (path-based). Domēnu maršrutēšana netika izmantota, jo izstrādātājam nebija papildu domēnu. Lietotne izmanto OAuth autentifikāciju, tāpēc pieteikšanās plūsmas ar nolūku palika angļu valodā. Aģents to apstrādāja korekti.

Ko konvertācijas solis faktiski dara?

Tā ir daļa, kas patiešām ir svarīga. Aģents identificēja 28 UI tekstu kandidātus visā Next.js lietotnē un apstrādāja 41 tulkošanas ierakstu. Tas pārorganizēja failus, atjaunināja starpprogrammatūru (middleware), pielāgoja komponentu importus un ģenerēja PO lokalizācijas failus visām 5 mērķa valodām.

Pati konvertācijas darbība aizņēma apmēram 30 minūtes. Pieskaitot iestatīšanu un konfigurāciju pirms tās, kā arī izstrādātāja veiktos pēdējos soļus, lai patstāvīgi pabeigtu tulkošanas savienojumu, kopējais process no sākuma līdz beigām aizņēma tuvāk 90 minūtēm. Tas nav acumirklīgi. Salīdzinājumam – vienkāršai lietotnei ar dažām lapām visa plūsma noris zem 15 minūtēm. Sarežģītai lietotnei ar desmitiem tulkojamu virsmu tas ilgst ilgāk. Laiks palielinās atbilstoši tekstu skaitam, ne repozitorija izmēram.

Izstrādātājs, novērojot konvertācijas soli, sacīja tā: teksta izgūšana un koda pārrakstīšana ir tā smagā, ikdienas darba daļa. Tas ir darbs, no kura izstrādātāji baidās. Viņa iepriekšējā uzņēmumā, kas bija vadošs TMS pakalpojums, tulkojumu faili repozitorijā bija tikai ledus kalna redzamā daļa – patiesās sāpes bija sagatavošanas un internacionalizācijas darbs. Un AI aģents tieši šo daļu paveica.

Tas sakrīt ar to, ko dzirdam no ikviena izstrādātāja, kurš i18n process ir izgājis manuāli. Neviens nesūdzas par tulkojumiem. Sūdzas par to, ka jāaiztiek 40 faili, lai ietvertu tekstus t() izsaukumos, ģenerētu saprātīgas atslēgas, pārstrukturētu importus un konfigurētu starpprogrammatūru. Tieši šo darbu globalize.now automatizē.

Vai tas faktiski nostrādāja no sākuma līdz beigām?

Jā. Pēc tiešraides sesijas beigām izstrādātājs patstāvīgi pabeidza atlikušos soļus. Viņš publicēja globalize.now Git zaru, savienoja lietotni ar tīmekļa platformu, iestatīja uzraudzību globalize.now zaram un pārbaudīja, ka faili tika augšupielādēti un tulkoti korekti.

Viņa vērtējums par čehu valodas tulkojuma kvalitāti: gandrīz perfekts. Šis vērtējums pieder cilvēkam, kurš savu karjeru pavadījis, profesionāli izvērtējot lokalizācijas rezultātus. Tas nav vispārīgs pozitīvs atsauksmes žests – tas ir jomas eksperta apstiprinājums, ka kvalitāte ir gatava produkcijai valodu pārī, kas nav triviāls.

Pēc patstāvīgas plūsmas pabeigšanas viņš norādīja uz divām problēmām tīmekļa lietotnē. Pirmkārt, atkārtota repozitorija pārbaude parādīja ziņu „i18n faili nav atrasti“, lai gan tulkošanas darbs faktiski darbojās fonā – maldinošs saskarnes stāvoklis, ne reāla kļūme. Otrkārt, tulkošanas darbs sākās bez skaidras piekrišanas – jebkurai darbībai, kas patērē kredītus, vajadzētu prasīt apstiprinājumu. Abas ir pamatotas lietotāja pieredzes problēmas, kuras tiek risinātas.

Kas nogāja greizi?

Kaut kas salūza. Šis bija reāls tests, tāpēc būsim par to atklāti.

Instalēšanas komanda (npx skills add globalize-now/globalize-skills) neizdevās Windows PowerShell vidē. Tas bija pirmais reizes, kad rīks tika testēts Windows sistēmā. Prasmju (skills) faili bija jāsūta kā ZIP arhīvs, izmantojot Swiss Transfer, jo Google bloķēja e-pasta pielikumu. Kopējā iestatīšanas berzē: apmēram 15 minūtes pirms faktiskās plūsmas sākuma.

Konvertācijas laikā radās konflikts starp ES modules un CommonJS. Projekts izmanto CommonJS, savukārt aģenta rezultāts vienā vietā pieņēma ES modules formātu. Tas nebija kavēklis, tomēr šāda situācija būtu jāatpazīst iestatīšanas laikā un jārisina proaktīvi.

Sesijas beigās, savienojot GitHub repozitoriju globalize.now tīmekļa lietotnē, tika parādīta tukša lapa. Izstrādātājs izmantoja Opera pārlūkprogrammu. Nebija pieteikšanās ekrāna, kļūdas ziņojuma vai saturas. Sesija noslēdzās, pirms problēma tika atrisināta.

Trīs kļūdas. Visas reālas. Visas ir novērstas vai tiek risinātas.

Kāpēc tekstu izgūšana ir īstais kaklarozis?

Vairums i18n satura pievēršas tulkojumu kvalitātei, ietvaru konfigurācijai vai TMS funkciju salīdzinājumiem. Tas paliek garām tur, kur izstrādātāji patiesībā zaudē laiku.

Internacionalizācijas pievienošana esošai kodubāzei nozīmē skenēt katru komponentu, meklējot burtiskus tekstus, izlemt, kuri teksti ir tulkojami, ģenerēt saprātīgas tulkošanas atslēgas, ietvert katru tekstu atbilstošā t() vai <Trans> izsaukumā, atjaunināt importus visā failu struktūrā, izveidot sākotnējos lokalizācijas failus un konfigurēt maršrutēšanas starpprogrammatūru. Monorepozitorija gadījumā pievienojas arī sarežģītība noteikt, kurām kodubāzes daļām i18n vispār ir nepieciešams.

Šis darbs ir garlaicīgs, kļūdām pakļauts un tieši tas veids, kurā AI aģenti izceļas. Izstrādātājs, kurš to novēroja, izteicās skaidri: no izstrādātāja skatpunkta tā ir tā smagā darba daļa. Tas ir liels atvieglojums. Vibe kodētāji, kas veido produktus ar AI rīkiem, tagad var pilnībā izvairīties no vissliktākās starptautiskās izplatīšanas daļas.

Ko mēs iemācījāmies par monorepozitorija tvērumu?

Aģents ar monorepozitorija tvērumu tika galā netieši. Tas pievērsās Next.js tīmekļa lietotnei un ignorēja Android kodu, MCP serverus un Mintlify dokumentāciju, pat nesaņemot tiešu norādi. Vairumā gadījumu tā ir korekta rīcība.

Tomēr netiešais tvērums nav tas pats, kas skaidri noteikts tvērums. Izstrādātājs gribēja iespēju konfigurācijas solī norādīt „konvertēt tikai manu Next.js lietotni“. Monorepozitorijā ar vairākiem tīmekļa saskarnēm – teiksim, klientiem paredzētu lietotni un administratoru paneli – gribētos precīzu kontroli, kura saskarne tiek internacionalizēta vispirms.

Šī ir produkta nepilnība, ko mēs novēršam. Pašlaik aģents praksē to izpilda korekti. Skaidram tvēruma iestatīšanas solim vajadzētu būt konfigurācijas daļai, jo īpaši, ja konvertācija ietekmē desmitus failu.

Kā šis process salīdzinās ar manuālu i18n iestatīšanu?

Manuāla i18n iestatīšana šāda sarežģītības līmeņa kodubāzē prasa vairākas dienas. Ne tāpēc, ka kāds konkrēts solis būtu sarežģīts, bet tāpēc, ka soļu ir desmitiem un katram nepieciešama uzmanība. Palaid garām kādu tekstu, un tu izlaidīsi lapu ar daļēju tulkojumu. Kļūdies atslēgas nosaukumā, un radīsies dublēti ieraksti, kas atgriezīsies pie tevis pēc mēnešiem. Aizmirsti atjaunināt starpprogrammatūru, un lokalizācijas maršrutēšana klusi sabruks.

AI aģents paveica ekvivalentu darbu apmēram 90 minūtēs, no sākuma līdz beigām. Izstrādātājs, kurš profesionāli redzējis tūkstošiem i18n implementāciju, nosauca to par elegantu.

Izstrādātājiem, kas veido produktus ar AI rīkiem, tas maina apsvērumus par to, kad pievienot valodas. Ja i18n iestatīšana prasa nedēļu, tu to atlieksi, līdz esi pierādījis produkta un tirgus saderību. Ja tā prasa 90 minūtes, tu vari izlaist daudzvalodu versiju uzreiz no pirmās dienas.

globalize.now to atrisina. Savieno savu repozitoriju, un konvertācija tiek izpildīta vienreiz, lietotnē; npx skills add globalize-now/globalize-skills prasmes sedz visu turpmāko darbu tavā redaktorā. Aplūko, kā tas darbojas, globalize.now.