Lähdemuutosten tunnistaminen pitää käännösarvioinnit rehellisinä

Käännös voi olla oikein ja silti vanhentunut.

Näin tapahtuu, kun toimittaja muuttaa lähdemerkintää sen jälkeen, kun kääntäminen on alkanut. Lokalisoitu luonnos heijastaa edelleen alkuperäistä tilannekuvaa, mutta arviointinäkymä saattaa näyttää uusimman lähteen. Ellei työnkulku merkitse eroa, arvioija voi hyväksyä kaksi sisältökappaletta, joita ei todellisuudessa koskaan verrattu toisiinsa.

Lähdemuutosten tunnistaminen estää tätä hiljaista ristiriitaa päätymästä julkaisuun.

Kääntäminen alkaa tilannekuvasta

Jokaisella käännöspyynnöllä on lähderajaus: joukko kenttiä, arvoja ja rich-text-rakenteita tietyllä hetkellä.

Tämä tilannekuva tulisi tallentaa pyynnön yhteyteen. Se selittää, mitä malli vastaanotti, mitä arvioija arvioi ja miksi kohdeluonnos sanoo sen, mitä se sanoo.

Lähteen hakeminen uudelleen näyttämistä varten on hyödyllistä, mutta se ei saa korvata historiallista tilannekuvaa. Työnkulku tarvitsee molemmat:

• lähteen, jota käytettiin luonnoksen tuottamiseen
• nykyisen lähteen CMS:ssä

Ilman ensimmäistä luonnoksella ei ole luotettavaa alkuperää. Ilman toista tiimi ei näe, että sivu on jo muuttunut.

Kaikki muutokset eivät mitätöi kaikkea

Pelkkä aikaleima voi kertoa, että merkintä muuttui, mutta ei sitä, onko käännös vanhentunut.

Toimittaja voi päivittää sisäisen huomautuksen, lisätä aineiston lokalisoimattomaan kenttään tai korjata kentän, jota ei sisällytetty pyyntöön. Näiden muutosten ei pitäisi välttämättä estää lokalisoitua luonnosta.

Vertaa sen sijaan käännetyn kentän tasolla. Jos lähdeotsikko muuttui, merkitse otsikkoluonnos vanhentuneeksi. Jos vain leipäteksti muuttui, pidä arvioitu otsikko ennallaan ja palauta leipäteksti käsiteltäväksi.

Rajattu mitätöinti säilyttää valmiin työn ja tekee samalla jäljellä olevan riskin näkyväksi.

Näytä arvioijille todellinen ero

"Lähde muuttui" on varoitus, ei päätös.

Arvioijien on nähtävä, mikä muuttui alkuperäisen tilannekuvan ja nykyisen arvon välillä. Tavallisessa tekstissä sanatasoinen diff voi riittää. Rich text -sisällössä vertailun tulisi tuoda esiin myös rakenteelliset muutokset, kuten poistetun linkin, uuden luettelokohdan tai erilaisen upotetun merkinnän.

Hyödyllinen kysymys ei ole vain se, eroavatko merkkijonot toisistaan. Se on, edustaako hyväksytty kohdeteksti edelleen nykyistä lähdettä tarkasti.

Anna tiimille harkittuja valintoja

Kun käännetty lähdekenttä muuttuu, työnkulku voi tarjota pienen joukon selkeitä polkuja:

1. pidä nykyinen käännös, kun muutos ei vaikuta merkitykseen
2. muokkaa lokalisoitua luonnosta käsin
3. generoi vain muuttunut kenttä uudelleen
4. palauta pyyntö käännettäväksi, kun muutos on laaja

Valinta ja arvioija tulisi kirjata. Vanhentumisvaroitus, joka voidaan ohittaa ilman audit trailia, on helppo sivuuttaa julkaisupaineen alla.

Tarkista uudelleen ennen siirtoa

Arviointi voi alkaa vastaavalla lähdesisällöllä ja päättyä sen jälkeen, kun uusi muokkaus tulee voimaan.

Suorita lähdevertailu uudelleen juuri ennen CMS:ään siirtämistä. Tämä viimeinen tarkistus sulkee hyväksynnän ja toimituksen välisen aukon. Sen tulisi käyttää samoja kenttäkohtaisia sääntöjä kuin arviointinäkymän ja pysäyttää vain ne kirjoitukset, joihin muutos vaikuttaa.

Automaattisessa julkaisemisessa tarkistus on vielä tärkeämpi. Automaatio poistaa ihmisen pitämän tauon, joten järjestelmän on oltava täsmällinen sen suhteen, minkä hyväksytyn tilannekuvan se on valmis julkaisemaan.

Yhteenveto

Käännösarviointi on luotettavaa vain silloin, kun arvioitava lähde on sama lähde, joka tuotti luonnoksen.

Tallenna alkuperäinen tilannekuva, vertaa sitä nykyisiin CMS-arvoihin, tunnista muutokset kentittäin ja anna arvioijien ratkaista merkitykselliset erot harkitusti. Lähdemuutosten tunnistaminen ei hidasta lokalisointia. Se estää tiimejä julkaisemasta itsevarmasti eilisen vastausta tämän päivän sisältöön.