Sådan afgrænser du en oversættelsesintegration i en eksisterende forretningsapp
Planlæg oversættelse i din forretningsapp. Fastlæg indhold, sprog, gennemgang, dataregler, fejlhåndtering og accepttest, før du beder om et tilbud.
Start med én komplet opgave, som dit team skal kunne udføre på et andet sprog. Fastlæg derefter, hvordan oversættelse passer ind i den opgave. Det giver en softwareleverandør et klarere grundlag for et estimat end en anmodning om at tilføje en oversæt-knap.
Afgrænsningen skal dække teksten, personerne, dataene og resultatet. Den skal også forklare, hvad der sker, når oversættelsen mislykkes. Brug trinene nedenfor til at forberede afgrænsningen, før du vælger en teknisk løsning.
Vælg én arbejdsgang til den første version
Skriv ned, hvor kildeteksten kommer fra, og hvor den godkendte oversættelse skal hen. En supportmedarbejder kan for eksempel have brug for at læse en indgående besked og forberede et svar på kundens sprog. Det er et illustrativt krav, ikke en beskrivelse af en Vavus-installation.
Angiv hvert trin: åbn beskeden, bed om en oversættelse, læs kildeteksten ved siden af resultatet, rediger svaret, og godkend det til afsendelse. Beslut, om oversættelsen starter automatisk eller først, når en medarbejder vælger den.
Hold den første version lille. Én skærm og én klar forretningsopgave er lettere at teste end alle tekstfelter i et program.
Fastlæg behovene for indhold og sprog
Lav en liste over de felter, der skal oversættes. Skeln mellem korte etiketter, fritekst, dokumenter og tale. De kan kræve forskellig behandling og forskellige test. Angiv også felter, der skal forblive uændrede, som ordrenumre og produktkoder.
Angiv kilde- og målsprogene, herunder eventuelle regionale varianter. Notér den typiske tekstlængde og den forventede daglige mængde. Spørg, hvilke sprogkombinationer og inputformater den foreslåede tjeneste understøtter.
Kontekst kan have betydning for kort tekst. DeepL's tekst-API understøtter for eksempel en context-parameter, der kan påvirke oversættelsen, uden at selve konteksten bliver oversat. Dokumentationen siger også, at separate tekstposter i samme anmodning ikke deler kontekst. [1] Din afgrænsning skal angive, hvor nyttig kontekst kommer fra.
Fastlæg terminologi og menneskelig gennemgang
Saml de termer, som din virksomhed ofte bruger. Medtag foretrukne oversættelser, produktnavne og ord, der skal forblive uændrede. Udpeg én person til at vedligeholde listen.
Nogle oversættelsestjenester understøtter ordlister. Google Cloud Translation beskriver sin ordliste som en tilpasset ordbog til ensartet fagterminologi. [2] Tjek funktionen for dine præcise sprogpar og den valgte tjeneste. En ordliste beviser ikke, at hele beskeden er korrekt.
Beslut, hvilke output der skal gennemgås af en kvalificeret sproglig korrekturlæser. Giv korrekturlæseren adgang til den oprindelige tekst. Indfør et klart godkendelsestrin, før tekst til kunder sendes eller offentliggøres.
Fastlæg regler for data og adgang
Beskriv, hvilke oplysninger arbejdsgangen håndterer. Brug kunstige eksempler i de tidlige test. Undgå at kopiere rigtige kundedata ind i en test bare for at se, om en knap virker.
Spørg, hvor teksten skal behandles, hvad programmet gemmer, hvem der kan læse den, og hvornår den bliver slettet. Medtag logfiler og sikkerhedskopier i drøftelsen. Bekræft udbyderens aktuelle vilkår og de kontrolmuligheder, der findes i den valgte plan.
En skræddersyet brugerflade gør ikke i sig selv en ekstern oversættelsestjeneste privat eller offline. Hvis dit projekt kræver lokal behandling, skal du angive kravet fra starten og teste hele dataflowet op imod det.
Planlæg for forsinkelser og fejl
Skriv den forventede svartid ned, og hvad medarbejderne skal gøre, hvis tjenesten ikke er tilgængelig. Programmet skal vise en tydelig status, for eksempel venter, klar til gennemgang eller mislykket. Bevar den oprindelige tekst.
Bed udvikleren om at skelne mellem midlertidige fejl og fejl, der kræver en ændring. DeepL dokumenterer for eksempel forsinkede genforsøg ved fejl på grund af hastighedsbegrænsning, mens en opbrugt kvote kræver en anden reaktion. [3] Gentagne anmodninger må ikke skabe dobbelte forretningshandlinger, som at det samme svar bliver sendt to gange.
Aftal advarsler om forbrug, og hvem der har ansvaret for support. Medtag gebyrer for tjenesten, vedligeholdelse og fremtidige ændringer, når du sammenligner projektomkostninger.
Skriv accepttest før udviklingen
Vælg repræsentative eksempler for hvert nødvendigt sprogpar. Medtag lange beskeder, usædvanlige tegn, manglende felter og termer fra din godkendte liste. Test hele opgaven, fra kildeposten til det gemte eller sendte resultat.
Fastlæg kriterier for godkendelse, som folk kan kontrollere: Produktkoder forbliver uændrede, en ikke-godkendt oversættelse kan ikke sendes, en mislykket anmodning er synlig, og korrekturlæseren kan vende tilbage til kilden. Lad en kvalificeret korrekturlæser vurdere betydning og tone. Registrér fejl, og gentag de samme test efter ændringer.
Forbered en klar anmodning om tilbud
Send arbejdsgangen, eksempelfelter, sprogpar, den anslåede mængde, dataregler og accepttest. Markér hvert punkt som nødvendigt ved lanceringen eller egnet til en senere version. Bed om at få forudsætninger og undtagelser på skrift.
Vavus tilbyder skriftlig afgrænsning af skræddersyede projekter. [4] Brug tilbudssiden til at beskrive dit eksisterende program og den opgave, du vil forbedre. Den foreslåede integration, udrulning og test skal bekræftes i din projektbeskrivelse.