Kas ir ICU MessageFormat, un kāpēc to joprojām ir tik grūti tulkot?

ICU MessageFormat ir Unicode standarts, kas ļauj uzrakstīt vienu tulkojamu tekstu, kas pielāgojas skaitam, dzimtei un citiem mainīgajiem, un to joprojām ir grūti tulkot, jo šī sintakse tika izstrādāta kodam, nevis cilvēkiem, kas veic lokalizāciju. Šī specifikācija pastāv jau vairāk nekā desmit gadus, un tie, kas ar to saskaras visgrūtāk, ir netehniski tulkotāji, kuri raugās uz ligzdotām figūriekavām. globalize.now ir AI vadīta lokalizācijas infrastruktūra, kas darbojas vienu līmeni zemāk par šo problēmu": tā izgūst tekstus un ģenerē lokalizācijas failus, kuros atrodas šie ICU šabloni, un tad tos sinhronizē pēc katra Git push.

Kas ir ICU MessageFormat?

ICU MessageFormat ir sintakse, ar kuru izteikt ziņojumu, kura gala formulējums ir atkarīgs no izpildlaika datiem. Tā vietā, lai kodā salīmētu fragmentus kopā, jūs uzrakstāt vienu šablonu un ļaujat formatētājam katrai valodai izvēlēties pareizo zaru.

Visbiežāk sastopamais lietojums ir daudzskaitļa veidošana":

{count, plural,
  one {You have # message}
  other {You have # messages}
}

# tiek aizstāts ar skaitli, un zari one / other atbilst attiecīgās valodas daudzskaitļa kategorijām. Angļu valodā ir divas, poļu, krievu un arābu valodā — vairāk. ICU risina arī dzimti un citas izvēles ar select":

{gender, select,
  male {He liked your post}
  female {She liked your post}
  other {They liked your post}
}

Tieši tāpēc ICU kļuva par faktisko daudzskaitļa veidošanas standartu": tas gramatisko sarežģītību pārceļ datos, kas var atšķirties atkarībā no valodas, nevis sazarošanas loģikā, kas strādā tikai valodai, kurai tā uzrakstīta. Izpildlaika bibliotēkas, piemēram, FormatJS, i18next un next-intl, to visas atbalsta.

Kāpēc ICU MessageFormat ir tik grūti tulkot?

To ir grūti tulkot tāpēc, ka sintakse tika veidota izstrādātājiem, bet cilvēki, kas patiesībā tulko tekstus, parasti izstrādātāji nav.

Tulkotājs, atverot lokalizācijas failu, neredz „Jums ir 3 ziņojumi.” Viņš redz figūriekavas, atslēgvārdus plural un select, daudzskaitļa kategorijas, kuras viņš, iespējams, neatpazīst, un # vietturi, kas izskatās pēc drukas kļūdas. Viena izdzēsta iekava vai viena pārdēvēta kategorija, un teksts izpildlaikā izraisa kļūdu, nevis tiek attēlots. Struktūra, kas padara ICU spēcīgu izstrādātājiem, ir tā pati struktūra, kas padara to trauslu valodnieka rokās.

Šī ir plaisa, ar kuru lokalizācijas nozare klusībā dzīvo jau gadiem ilgi. Lielākā daļa rīku to risina, vienkārši parādot neapstrādāto šablonu un cerot, ka tulkotājs neaiztiks nepareizo rakstzīmi, vai arī paslēpjot daudzskaitļa formas atsevišķā redaktorā, kas tomēr joprojām prasa tulkotājam saprast daudzskaitļa kategorijas. Neviens pakalpojumu sniedzējs vēl nav pilnībā novērsis plaisu starp specifikācijas sarežģītību un netehniska tulkotāja domāšanas modeli.

Kas mainījās ar MessageFormat 2.0?

MessageFormat 2.0 ir sintakses pilnīgi jauns dizains, un 2025. gadā tas kļuva par stabilu standartu, nevis melnrakstu.

MF2 2025. gada martā sasniedza Final Candidate statusu un tagad ir stabila CLDR sastāvdaļa, publicēta kā daļa no Unicode LDML tehniskā standarta un pilnveidota LDML 47. un 48. izlaidumos. Atsauces implementācija atbilst specifikācijai, sākot ar LDML 48.2 versiju, kas izlaista 2026. gada sākumā. Jaunā sintakse nodala ievaddatus no atbilstības loģikas un atbalsta nosauktas formatēšanas funkcijas, kas padara sarežģītus ziņojumus vieglāk lasāmus":

.input {$count :number}
.match $count
one {{You have {$count} message}}
*   {{You have {$count} messages}}

Nolūks ir izveidot šablonu, kuru ir vieglāk paplašināt un kurš ir nedaudz mazāk pretīgs lasīšanai nekā oriģinālās ligzdotās figūriekavas.

Vai MessageFormat 2.0 atrisina tulkotāja problēmu?

Vēl nē, un tam ir divi iemesli.

Pirmkārt, MF2 uzlabo sintakses ergonomiku, taču tā joprojām paliek sintakse. Tulkotājs joprojām sastopas ar .match, daudzskaitļa atslēgām un figūriekavām. Kognitīvā slodze ir mazāka nekā MF1 gadījumā, taču tā nav pazudusi, un netehnisks tulkotājs joprojām var salauzt ziņojumu, rediģējot nepareizo elementu.

Otrkārt, gandrīz neviens to nelieto produkcijas vidē. Adopcija paliek ierobežota vēl labi tālu 2026. gadā": TC39 process JavaScript pusē vēlas redzēt aptuveni desmit organizācijas, kas izmanto MF2 produkcijā, pirms tas virzās tālāk, un šī robeža vēl nav sasniegta. Praksē lielākā daļa lietotņu, ko izlaižat šodien, joprojām darbojas ar oriģinālo ICU MessageFormat, izmantojot bibliotēkas, piemēram, FormatJS un i18next. Tātad ar tulkotāju saistītā problēma netiek atrisināta ar specifikāciju — to atrisina tas, kur sintakse tiek radīta un uzturēta.

Kur ICU MessageFormat salūst AI ģenerētās lietotnēs?

Tas salūst jau agri, jo AI kodēšanas rīki reti pirmajā mēģinājumā izveido pareizu ICU sintaksi.

Veidojot lietotni ar Cursor, Claude Code vai Lovable, ģenerētais kods mēdz apstrādāt skaitļus vienkāršotā veidā":

// What an AI coding tool often generates
const label = count + " " + (count === 1 ? "message" : "messages");

Šī loģika ir pareiza angļu valodai un nepareiza lielākajai daļai citu valodu, jo tā pieņem, ka pastāv tieši divas daudzskaitļa formas. Tā arī iecep teikumu tieši lietotnes kodā, tāpēc lokalizācijas failā vispār nav nekāda ICU šablona, ko tulkotājs varētu lokalizēt. Teksts lokalizācijas slānim ir neredzams, kamēr kāds nepamana salauztu gramatiku produkcijas vidē. AI rīki arī dublē atslēgas un izkaisa burtiskus tekstus pa komponentiem, tāpēc pat komandas, kas vēlas izmantot ICU, beigās iegūst tekstus, kas nekad nav nonākuši tulkojamā failā. globalize.now izstrādātāju pārskats ir veidots tieši tāpēc, lai atrastu šāda veida tekstus vēl pirms izlaišanas.

Kā izstrādātājiem 2026. gadā vajadzētu rīkoties ar ICU MessageFormat?

Uztveriet ICU kā ģenerētu infrastruktūru, nevis manuāli rakstītu saturu.

Praktiskais likums": izstrādātājiem un AI rīkiem nevajadzētu kodā rakstīt daudzskaitļa konkatenāciju, un tulkotājiem nevajadzētu manuāli rediģēt neapstrādātas ICU figūriekavas. ICU šablonam ir jāatrodas lokalizācijas failā, kas tiek radīts un automātiski uzturēts aktuāls, un pēc tam izpildlaikā attēlots ar bibliotēkas, piemēram, FormatJS, i18next vai next-intl, palīdzību. Tas nodrošina, ka sintakse ir pareiza jau tās izveides brīdī un konsekventa katrā valodā, mainoties lietotnei. Ja jūs izsverat, kā ICU iekļaujas jūsu izpildlaika slānī, globalize.now salīdzinājums ar i18next apraksta, kā infrastruktūra un izpildlaiks sadala šo darbu.

Šajā slānī darbojas globalize.now. Tas izgūst burtiskus tekstus no jūsu koda bāzes, ģenerē atslēgas un lokalizācijas failus, kuros atrodas ICU šabloni, un atkārtoti sinhronizē tos pēc katra Git push, lai struktūra paliktu pareiza bez manuālas eksportēšanas soļa. Tas necenšas kļūt par tulkotāja redaktoru vai aizstāt jūsu izpildlaika bibliotēku — tas nodrošina, ka ICU formas faili, no kuriem šie rīki ir atkarīgi, patiešām pastāv un ir sinhronizēti. Vibe-coderu ceļvedis apraksta to pašu iestatīšanu lietotnēm, kas veidotas ar Lovable, Bolt un Replit, un plašāka darbplūsma ir aprakstīta globalize.now sākumlapā.