Rich text on todellinen käännöstyönkulun testi

Otsikko ja lyhyt kuvaus voivat saada lähes minkä tahansa käännöstyönkulun näyttämään pätevältä. Todellinen testi alkaa, kun lähdemerkintä sisältää sisäkkäisiä listoja, tekstinsisäisiä linkkejä, upotettuja merkintöjä ja merkitystä kantavaa muotoilua.

Siinä vaiheessa kääntäminen lakkaa olemasta tekstiongelma ja muuttuu sisältörakenneongelmaksi.

Rich text on dokumentti, ei merkkijono

Contentful rich text tallennetaan puuna. Kappaleet sisältävät tekstisolmuja. Listat sisältävät listakohteita. Linkit ja upotetut merkinnät viittaavat muuhun sisältöön. Merkinnät välittävät lihavoinnin, kursivoinnin, koodin ja muun muotoilun.

Jos tämä puu litistetään pelkäksi tekstiksi, sanat saattavat säilyä, mutta merkintä ei.

Luotettavan työnkulun on käännettävä kieli samalla kun se säilyttää dokumentin:

• otsikot pysyvät otsikkoina
• listakohteet säilyvät oikeassa järjestyksessä
• linkit säilyttävät kohteensa
• tekstinsisäiset merkinnät pysyvät siinä lauseessa, johon editorit ne sijoittivat
• upotetut lohkot säilyttävät suhteensa ympäröivään tekstiin

Käännösmallilta ei pitäisi koskaan pyytää sellaisen rakenteen uudelleenrakentamista, jonka työnkulku olisi voinut suojata nimenomaisesti.

Vaaralliset virheet näyttävät uskottavilta

Rich textin vauriot eivät aina ole ilmeisiä käännösarvioinnissa. Puuttuva upotus voi jättää jälkeensä kappaleen, joka kuulostaa edelleen luonnolliselta. Hajonnut lista voi näyttää useilta kelvollisilta kappaleilta. Tekstinsisäinen merkintä voi kadota niin, että lause sulkeutuu aukon ympärille.

Siksi rakenteelliset virheet ovat vaarallisempia kuin näkyvä poikkeus. Pyyntö voidaan merkitä onnistuneeksi, vaikka lokalisoitu merkintä ei enää vastaa lähdettä.

Hyvät arviointityökalut tekevät suojatun rakenteen näkyväksi. Editoreiden pitäisi voida nähdä, missä upotukset, linkit ja muotoilu sijaitsevat ilman raaka-JSONin lukemista tai luottamista siihen, että jokainen token säilyi.

Suojaa ensin, käännä vasta sitten

Vahva rich text -putki erottaa käännettävän sisällön rakenteellisesta sisällöstä.

Ennen kuin malli vastaanottaa dokumentin, työnkulku voi korvata suojatut solmut vakailla paikkamerkeillä. Malli kääntää ympäröivän kielen. Työnkulku palauttaa sitten alkuperäiset solmut ja varmistaa, että jokainen paikkamerkki palautui täsmälleen kerran.

Tämä luo selkeät vastuut:

• malli käsittelee kieltä
• sovellus käsittelee rakennetta
• validointi havaitsee puuttuvan tai monistetun suojatun sisällön

Tämä raja on paljon luotettavampi kuin koko CMS-dokumentin rakenteen säilyttämisen pyytäminen yhdeltä todennäköisyyspohjaiselta vastaukselta pelkän käytännön varassa.

Tarkista hierarkia, älä vain proosaa

Ihmisen tekemän arvioinnin pitäisi verrata muutakin kuin lauseita. Sen pitäisi myös vastata seuraaviin kysymyksiin:

1. Ovatko kaikki lähdeosiot mukana?
2. Säilyikö listojen sisäkkäisyys ehjänä?
3. Ovatko linkit ja upotetut merkinnät yhä kiinnittyneet oikeaan asiayhteyteen?
4. Jäivätkö tyhjät lähdelohkot pois käännetystä tuloksesta?
5. Vastaako renderöity esikatselu lähdesivun sisältöhierarkiaa?

Viimeinen kysymys on tärkeä, koska rakenteellisesti kelvollinen dokumentti voi silti tuottaa kömpelön sivun. Esikatselu paljastaa, kiertyykö käännetty otsikko huonosti, rikkooko CTA asettelun tai päätyykö upotus odottamattomaan visuaaliseen kohtaan.

Yhteenveto

Rich text on se kohta, jossa käännöstyönkulku ansaitsee luottamuksen. Sanojen säilyttäminen on vasta ensimmäinen vaatimus. Järjestelmän on myös säilytettävä dokumentti, jonka editorit rakensivat näiden sanojen ympärille.

Käsittele rakennetta suojattuna datana, validoi se ennen tallennusta ja tarkista tulos CMS-esikatselussa. Kun rich text selviää koko tästä polusta, yksinkertaisemmista kentistä tulee se helppo tapaus, joka niiden kuuluukin olla.