Kuidas määrata tõlke liidestamise ulatus olemasolevasse ärirakendusse
Planeerige tõlge oma ärirakenduses. Määrake enne hinnapakkumise küsimist sisu, keeled, ülevaatus, andmereeglid, tõrgete käsitlemine ja vastuvõtutestid.
Alustage ühest terviklikust ülesandest, mida Teie meeskond peab tegema teises keeles. Seejärel määrake, kuidas tõlge sellesse ülesandesse sobitub. Nii saab tarkvara tarnija hinnangu andmiseks selgema aluse kui palvest lisada tõlkenupp.
Töökirjeldus peaks hõlmama teksti, inimesi, andmeid ja tulemust. Samuti peaks see selgitama, mis juhtub, kui tõlkimine ebaõnnestub. Kasutage allolevaid samme, et see töökirjeldus enne tehnilise lähenemise valimist ette valmistada.
Valige esimese versiooni jaoks üks töövoog
Pange kirja, kust lähtetekst tuleb ja kuhu heakskiidetud tõlge peab jõudma. Näiteks võib klienditoe töötaja vajada sissetuleva sõnumi lugemist ja vastuse koostamist kliendi keeles. See on illustreeriv nõue, mitte kirjeldus mõnest Vavuse paigaldusest.
Loetlege kõik sammud: sõnumi avamine, tõlke küsimine, lähteteksti lugemine tulemuse kõrval, vastuse muutmine ja selle saatmiseks heakskiitmine. Otsustage, kas tõlkimine algab automaatselt või alles siis, kui töötaja selle valib.
Hoidke esimene versioon väike. Üht ekraani ja üht selget äriülesannet on lihtsam testida kui rakenduse kõiki tekstivälju.
Tehke kindlaks sisu ja keelte vajadused
Koostage loend väljadest, mis vajavad tõlkimist. Eristage lühikesed sildid, vabatekst, dokumendid ja kõne. Need võivad vajada erinevat töötlust ja erinevaid teste. Loetlege ka väljad, mis peavad jääma muutmata, näiteks tellimuste numbrid ja tootekoodid.
Määrake lähte- ja sihtkeeled, sealhulgas võimalikud piirkondlikud variandid. Pange kirja teksti tavapärane pikkus ja eeldatav päevane maht. Küsige, milliseid keelekombinatsioone ja sisendvorminguid pakutud teenus toetab.
Lühikese teksti puhul võib kontekst olla oluline. Näiteks DeepL-i teksti-API toetab parameetrit context, mis võib tõlget mõjutada ilma konteksti ennast tõlkimata. Selle dokumentatsioonis on ka öeldud, et ühe päringu eraldi tekstikirjed konteksti ei jaga. [1] Teie töökirjeldus peaks märkima, kust kasulik kontekst tuleb.
Määrake terminoloogia ja inimese tehtav ülevaatus
Koguge kokku terminid, mida Teie ettevõte sageli kasutab. Lisage eelistatud tõlked, tootenimed ja sõnad, mis peaksid jääma muutmata. Määrake selle loendi hoidmiseks üks vastutav inimene.
Mõned tõlketeenused toetavad sõnastikke. Google Cloud Translation kirjeldab oma sõnastikku kui kohandatud sõnaraamatut valdkonna terminoloogia järjepidevaks kasutamiseks. [2] Kontrollige seda funktsiooni oma täpsete keelepaaride ja valitud teenuse jaoks. Sõnastik ei tõenda, et kogu sõnum on õige.
Otsustage, millised väljundid vajavad pädeva keeletoimetaja ülevaatust. Andke toimetajale ligipääs algtekstile. Seadke enne klientidele mõeldud teksti saatmist või avaldamist selge heakskiitmise samm.
Kehtestage andmete ja ligipääsu reeglid
Kirjeldage, milliseid andmeid töövoog käsitleb. Kasutage varastes testides tehislikke näiteid. Ärge kopeerige katsesse päris kliendiandmeid lihtsalt selleks, et näha, kas nupp töötab.
Küsige, kus teksti töödeldakse, mida rakendus salvestab, kes saab seda lugeda ja millal see kustutatakse. Võtke sellesse arutellu ka logid ja varukoopiad. Kontrollige teenusepakkuja kehtivaid tingimusi ja valitud paketis saadaolevaid haldusvõimalusi.
Kohandatud kasutajaliides ei muuda välist tõlketeenust iseenesest privaatseks ega võrguühenduseta toimivaks. Kui Teie projekt nõuab kohalikku töötlust, märkige see nõue kohe alguses ja testige kogu andmevoogu selle vastu.
Arvestage viivituste ja vigadega
Pange kirja eeldatav vastamisaeg ja see, mida töötajad peavad tegema, kui teenus pole saadaval. Rakendus peaks näitama selget olekut, näiteks ootel, ülevaatuseks valmis või ebaõnnestunud. Säilitage algtekst.
Paluge arendajal eristada ajutisi tõrkeid vigadest, mis nõuavad muudatust. Näiteks DeepL kirjeldab päringumäära piirangu vigade korral viivitusega kordusi, samas kui ammendatud kvoot nõuab teistsugust reageerimist. [3] Korduvad päringud ei tohi tekitada topelt äritoiminguid, näiteks sama vastuse kahekordset saatmist.
Leppige kokku kasutusteavitustes ja selles, kes vastutab toe eest. Võtke projektikulude võrdlemisel arvesse teenustasud, hooldus ja tulevased muudatused.
Kirjutage vastuvõtutestid enne arendust
Valige iga vajaliku keelepaari jaoks esinduslikud näited. Lisage pikad sõnumid, ebatavalised märgid, puuduvad väljad ja terminid Teie heakskiidetud loendist. Testige kogu ülesannet alates lähtekirjest kuni salvestatud või saadetud tulemuseni.
Seadke läbimise kriteeriumid, mida inimesed saavad kontrollida: tootekoodid jäävad muutmata, heaks kiitmata tõlget ei saa saata, ebaõnnestunud päring on nähtav ja toimetaja saab lähteteksti juurde tagasi minna. Laske pädeval toimetajal hinnata tähendust ja tooni. Registreerige vead ja korrake pärast muudatusi samu teste.
Valmistage ette selge hinnapakkumise päring
Saatke töövoog, näidisväljad, keelepaarid, hinnanguline maht, andmereeglid ja vastuvõtutestid. Märkige iga punkti juures, kas see on käivitamiseks vajalik või sobib hilisemasse versiooni. Küsige eeldused ja välistused kirjalikult.
Vavus pakub eritellimusprojektidele kirjalikku töökirjelduse koostamist. [4] Kirjeldage hinnapakkumise lehel oma olemasolevat rakendust ja ülesannet, mida soovite parandada. Pakutud liidestus, juurutus ja testimine tuleks kinnitada Teie projekti töökirjelduses.
Küsige kirjalikku hinnapakkumist