Slik definerer du omfanget av oversettelsesintegrasjon i en eksisterende forretningsapp
Planlegg oversettelse i forretningsappen din. Definer innhold, språk, gjennomgang, dataregler, feilhåndtering og akseptansetester før du ber om et tilbud.
Start med én hel oppgave som teamet ditt må utføre på et annet språk. Definer deretter hvordan oversettelse passer inn i den oppgaven. Det gir en programvareleverandør et tydeligere grunnlag for et estimat enn en forespørsel om å legge til en oversettelsesknapp.
Omfanget bør dekke teksten, personene, dataene og resultatet. Det bør også forklare hva som skjer når oversettelsen mislykkes. Bruk trinnene nedenfor til å forberede omfanget før du velger en teknisk tilnærming.
Velg én arbeidsflyt for den første versjonen
Skriv ned hvor kildeteksten kommer fra og hvor den godkjente oversettelsen skal. En kundestøttemedarbeider kan for eksempel trenge å lese en innkommende melding og forberede et svar på kundens språk. Dette er et illustrerende krav, ikke en rapport om en Vavus-installasjon.
List opp hvert trinn: åpne meldingen, be om en oversettelse, lese kilden ved siden av resultatet, redigere svaret og godkjenne det for sending. Bestem om oversettelsen starter automatisk eller først når en ansatt velger det.
Hold den første versjonen liten. Én skjerm og én tydelig forretningsoppgave er enklere å teste enn hvert eneste tekstfelt i en applikasjon.
Kartlegg behovene for innhold og språk
Lag en liste over feltene som må oversettes. Skill mellom korte etiketter, fritekst, dokumenter og tale. De kan kreve ulik behandling og ulike tester. List også opp felt som ikke skal endres, for eksempel ordrenumre og produktkoder.
Angi kilde- og målspråk, inkludert eventuelle regionale varianter. Noter typisk tekstlengde og forventet daglig volum. Spør hvilke språkkombinasjoner og inndataformater den foreslåtte tjenesten støtter.
Kontekst kan ha betydning for korte tekster. DeepLs tekst-API støtter for eksempel en context-parameter som kan påvirke oversettelsen uten at selve konteksten oversettes. Dokumentasjonen sier også at separate tekstoppføringer i samme forespørsel ikke deler kontekst. [1] Omfanget ditt bør si hvor nyttig kontekst skal komme fra.
Definer terminologi og menneskelig gjennomgang
Samle begrepene virksomheten din bruker ofte. Ta med foretrukne oversettelser, produktnavn og ord som ikke skal endres. Gi én person ansvaret for å vedlikeholde listen.
Noen oversettelsestjenester støtter ordlister. Google Cloud Translation beskriver ordlisten sin som en egendefinert ordbok for konsekvent fagterminologi. [2] Sjekk funksjonen for de nøyaktige språkparene dine og den valgte tjenesten. En ordliste beviser ikke at hele meldingen er riktig.
Bestem hvilke resultater som trenger en kvalifisert språkkontrollør. Gi kontrolløren tilgang til originalteksten. Sett et tydelig godkjenningstrinn før tekst som kundene skal se, sendes eller publiseres.
Fastsett regler for data og tilgang
Beskriv hvilken informasjon arbeidsflyten håndterer. Bruk kunstige eksempler i de tidlige testene. Unngå å kopiere ekte kundeposter inn i en test bare for å se om en knapp virker.
Spør hvor teksten skal behandles, hva applikasjonen skal lagre, hvem som kan lese den og når den skal slettes. Ta med logger og sikkerhetskopier i denne diskusjonen. Bekreft leverandørens gjeldende vilkår og kontrollene som er tilgjengelige i den valgte planen.
Et skreddersydd grensesnitt gjør ikke i seg selv en ekstern oversettelsestjeneste privat eller frakoblet. Hvis prosjektet ditt krever lokal behandling, må du si det fra starten og teste hele dataflyten mot det kravet.
Planlegg for forsinkelser og feil
Skriv ned forventet svartid og hva de ansatte skal gjøre hvis tjenesten ikke er tilgjengelig. Applikasjonen bør vise en tydelig status, for eksempel venter, klar til gjennomgang eller mislyktes. Ta vare på originalteksten.
Be utvikleren skille midlertidige feil fra feil som krever en endring. DeepL dokumenterer for eksempel forsinkede nye forsøk ved feil som skyldes hastighetsbegrensning, mens en oppbrukt kvote krever en annen håndtering. [3] Gjentatte forespørsler skal ikke føre til doble forretningshandlinger, for eksempel at det samme svaret sendes to ganger.
Bli enige om varsler om forbruk og hvem som har ansvaret for brukerstøtte. Ta med tjenesteavgifter, vedlikehold og fremtidige endringer når du sammenligner prosjektkostnader.
Skriv akseptansetester før utviklingen
Velg representative eksempler for hvert språkpar som trengs. Ta med lange meldinger, uvanlige tegn, manglende felt og begreper fra den godkjente listen. Test hele oppgaven, fra kildeposten til det lagrede eller sendte resultatet.
Sett kriterier for bestått test som folk kan kontrollere: Produktkoder forblir uendret, en oversettelse som ikke er godkjent, kan ikke sendes, en mislykket forespørsel er synlig, og kontrolløren kan gå tilbake til kilden. La en kvalifisert kontrollør vurdere mening og tone. Registrer feil og gjenta de samme testene etter endringer.
Forbered en tydelig forespørsel om tilbud
Send arbeidsflyten, eksempelfelt, språkpar, anslått volum, dataregler og akseptansetester. Merk hvert punkt som påkrevd ved lansering eller egnet for en senere versjon. Be om å få forutsetninger og unntak skriftlig.
Vavus tilbyr skriftlig avklaring av omfang for skreddersydde prosjekter. [4] Bruk tilbudssiden til å beskrive den eksisterende applikasjonen og oppgaven du vil forbedre. Den foreslåtte integrasjonen, utrullingen og testingen bør bekreftes i prosjektomfanget ditt.