Miten määritellä käännösintegraation laajuus olemassa olevaan yrityssovellukseen
Suunnitelkaa käännös yrityssovellukseenne. Määritelkää sisältö, kielet, tarkastus, tietosäännöt, virheiden käsittely ja hyväksymistestit ennen tarjouspyyntöä.
Aloittakaa yhdestä kokonaisesta tehtävästä, joka tiiminne tarvitsee tehdä toisella kielellä. Määritelkää sitten, miten käännös sopii tähän tehtävään. Näin ohjelmistotoimittaja saa selkeämmän pohjan arviolle kuin pelkästä pyynnöstä lisätä käännöspainike.
Laajuusmäärittelyn pitää kattaa teksti, ihmiset, data ja lopputulos. Sen pitää myös kertoa, mitä tapahtuu, kun käännös epäonnistuu. Käyttäkää alla olevia vaiheita laajuuden valmisteluun ennen kuin valitsette teknisen toteutustavan.
Valitkaa ensimmäiseen julkaisuun yksi työnkulku
Kirjatkaa, mistä lähdeteksti tulee ja minne hyväksytyn käännöksen on päädyttävä. Esimerkiksi asiakastuen työntekijän voi olla tarpeen lukea saapuva viesti ja laatia vastaus asiakkaan kielellä. Tämä on havainnollistava vaatimus, ei raportti Vavus-asennuksesta.
Listatkaa jokainen vaihe: viestin avaaminen, käännöksen pyytäminen, lähdetekstin lukeminen tuloksen rinnalla, vastauksen muokkaaminen ja sen hyväksyminen lähetettäväksi. Päättäkää, käynnistyykö käännös automaattisesti vai vasta, kun työntekijä valitsee sen.
Pitäkää ensimmäinen julkaisu pienenä. Yksi näkymä ja yksi selkeä liiketoimintatehtävä on helpompi testata kuin sovelluksen jokainen tekstikenttä.
Tunnistakaa sisältö ja kielitarpeet
Tehkää luettelo kentistä, jotka on käännettävä. Erotelkaa lyhyet nimikkeet, vapaa teksti, asiakirjat ja puhe. Ne voivat vaatia erilaista käsittelyä ja erilaisia testejä. Luetelkaa myös kentät, joiden on pysyttävä muuttumattomina, kuten tilausnumerot ja tuotekoodit.
Määritelkää lähde- ja kohdekielet, myös mahdolliset alueelliset kielimuodot. Kirjatkaa tekstin tyypillinen pituus ja arvioitu päivittäinen määrä. Kysykää, mitä kieliyhdistelmiä ja syöttömuotoja ehdotettu palvelu tukee.
Konteksti voi olla tärkeä lyhyissä teksteissä. Esimerkiksi DeepL:n teksti-API tukee context-parametria, joka voi vaikuttaa käännökseen ilman, että itse kontekstia käännetään. Sen dokumentaation mukaan saman pyynnön erilliset tekstikohdat eivät myöskään jaa kontekstia. [1] Laajuusmäärittelyssänne pitää kertoa, mistä hyödyllinen konteksti saadaan.
Määritelkää terminologia ja ihmisen tekemä tarkastus
Kootkaa termit, joita yrityksenne käyttää usein. Ottakaa mukaan suositellut käännökset, tuotenimet ja sanat, joiden pitää pysyä muuttumattomina. Nimetkää yksi henkilö ylläpitämään tätä luetteloa.
Jotkin käännöspalvelut tukevat sanastoja. Google Cloud Translation kuvaa sanastonsa mukautetuksi sanakirjaksi, jonka avulla alakohtainen terminologia pysyy johdonmukaisena. [2] Tarkistakaa ominaisuus juuri teidän kielipareillenne ja valitsemallenne palvelulle. Sanasto ei todista, että koko viesti on oikein.
Päättäkää, mitkä tulokset tarvitsevat pätevän kielentarkastajan. Antakaa tarkastajalle pääsy alkuperäiseen tekstiin. Asettakaa selkeä hyväksymisvaihe ennen kuin asiakkaille näkyvä teksti lähetetään tai julkaistaan.
Asettakaa säännöt datalle ja käyttöoikeuksille
Kuvatkaa, mitä tietoja työnkulku käsittelee. Käyttäkää varhaisissa testeissä keksittyjä esimerkkejä. Välttäkää todellisten asiakastietojen kopioimista kokeiluun pelkästään sen selvittämiseksi, toimiiko painike.
Kysykää, missä teksti käsitellään, mitä sovellus tallentaa, kuka voi lukea sen ja milloin se poistetaan. Ottakaa lokit ja varmuuskopiot mukaan tähän keskusteluun. Varmistakaa palveluntarjoajan voimassa olevat ehdot ja valitun paketin käytettävissä olevat hallintakeinot.
Räätälöity käyttöliittymä ei sellaisenaan tee ulkoisesta käännöspalvelusta yksityistä tai verkkoyhteydestä riippumatonta. Jos projektinne edellyttää paikallista käsittelyä, kertokaa vaatimus heti alussa ja testatkaa koko tietovirta sitä vasten.
Varautukaa viiveisiin ja virheisiin
Kirjatkaa odotettu vasteaika ja se, mitä henkilöstön pitää tehdä, jos palvelu ei ole käytettävissä. Sovelluksen pitää näyttää selkeä tila, kuten odottaa, valmis tarkastettavaksi tai epäonnistui. Säilyttäkää alkuperäinen teksti.
Pyytäkää kehittäjää erottamaan tilapäiset häiriöt virheistä, jotka vaativat muutosta. Esimerkiksi DeepL dokumentoi viivästetyt uudelleenyritykset pyyntörajan ylittymisestä johtuville virheille, kun taas loppuun käytetty kiintiö vaatii toisenlaisen toimenpiteen. [3] Toistuvat pyynnöt eivät saa luoda päällekkäisiä liiketoimintatoimenpiteitä, kuten saman vastauksen lähettämistä kahdesti.
Sopikaa käyttöhälytyksistä ja siitä, kuka vastaa tuesta. Ottakaa palvelumaksut, ylläpito ja tulevat muutokset mukaan, kun vertailette projektin kustannuksia.
Kirjoittakaa hyväksymistestit ennen kehitystä
Valitkaa edustavat esimerkit jokaiselle tarvittavalle kieliparille. Ottakaa mukaan pitkiä viestejä, epätavallisia merkkejä, puuttuvia kenttiä ja hyväksytyn luettelonne termejä. Testatkaa koko tehtävä lähdetietueesta tallennettuun tai lähetettyyn tulokseen.
Asettakaa hyväksymisehdot, jotka ihmiset voivat tarkistaa: tuotekoodit pysyvät muuttumattomina, hyväksymätöntä käännöstä ei voi lähettää, epäonnistunut pyyntö näkyy ja tarkastaja pääsee takaisin lähdetekstiin. Antakaa pätevän tarkastajan arvioida merkitys ja sävy. Kirjatkaa virheet ja toistakaa samat testit muutosten jälkeen.
Valmistelkaa selkeä tarjouspyyntö
Lähettäkää työnkulku, esimerkkikentät, kieliparit, arvioitu määrä, datasäännöt ja hyväksymistestit. Merkitkää jokainen kohta joko julkaisun kannalta välttämättömäksi tai myöhempään julkaisuun sopivaksi. Pyytäkää oletukset ja rajaukset kirjallisina.
Vavus tarjoaa kirjallisen laajuusmäärittelyn räätälöityihin projekteihin. [4] Kuvatkaa tarjoussivulla nykyinen sovelluksenne ja tehtävä, jota haluatte parantaa. Ehdotettu integraatio, käyttöönotto ja testaus pitää vahvistaa projektinne laajuusmäärittelyssä.