Så avgränsar du en översättningsintegration i en befintlig affärsapp
Planera översättning i din affärsapp. Definiera innehåll, språk, granskning, dataregler, felhantering och acceptanstester innan du begär en offert.
Börja med en hel uppgift som ditt team behöver utföra på ett annat språk. Definiera sedan hur översättningen passar in i den uppgiften. Det ger en programvaruleverantör ett tydligare underlag för en uppskattning än en begäran om att lägga till en översättningsknapp.
Avgränsningen bör omfatta texten, personerna, data och resultatet. Den bör också förklara vad som händer när översättningen misslyckas. Använd stegen nedan för att ta fram avgränsningen innan du väljer en teknisk lösning.
Välj ett arbetsflöde för den första versionen
Skriv ner var källtexten kommer ifrån och vart den godkända översättningen ska. En supportmedarbetare kan till exempel behöva läsa ett inkommande meddelande och förbereda ett svar på kundens språk. Det här är ett illustrativt krav, inte en beskrivning av en Vavus-installation.
Lista varje steg: öppna meddelandet, begär en översättning, läs källtexten bredvid resultatet, redigera svaret och godkänn det för att skickas. Bestäm om översättningen ska starta automatiskt eller först när en anställd väljer den.
Håll den första versionen liten. En skärm och en tydlig affärsuppgift är lättare att testa än varje textfält i en applikation.
Kartlägg behoven av innehåll och språk
Gör en lista över de fält som behöver översättas. Skilj mellan korta etiketter, fritext, dokument och tal. De kan kräva olika behandling och tester. Lista också fält som inte får ändras, till exempel ordernummer och produktkoder.
Ange käll- och målspråk, inklusive eventuella regionala varianter. Notera typisk textlängd och förväntad daglig volym. Fråga vilka språkkombinationer och indataformat den föreslagna tjänsten stöder.
Sammanhang kan spela roll för kort text. DeepL:s text-API stöder till exempel en kontextparameter som kan påverka översättningen utan att själva kontexten översätts. Dokumentationen anger också att separata textposter i samma begäran inte delar kontext. [1] Avgränsningen bör ange var användbar kontext kommer ifrån.
Definiera terminologi och mänsklig granskning
Samla de termer som ditt företag använder ofta. Ta med föredragna översättningar, produktnamn och ord som ska lämnas oförändrade. Utse en person som ansvarar för listan.
Vissa översättningstjänster stöder ordlistor. Google Cloud Translation beskriver sin ordlista som en anpassad ordbok för konsekvent fackterminologi. [2] Kontrollera funktionen för dina exakta språkpar och den tjänst du väljer. En ordlista bevisar inte att hela meddelandet är korrekt.
Bestäm vilka resultat som behöver granskas av en kvalificerad språkgranskare. Ge granskaren tillgång till originaltexten. Lägg in ett tydligt godkännandesteg innan text som riktar sig till kunder skickas eller publiceras.
Sätt regler för data och åtkomst
Beskriv vilken information arbetsflödet hanterar. Använd påhittade exempel i de tidiga testerna. Kopiera inte verkliga kundposter till ett test bara för att se om en knapp fungerar.
Fråga var texten kommer att behandlas, vad applikationen kommer att lagra, vem som kan läsa den och när den raderas. Ta med loggar och säkerhetskopior i diskussionen. Kontrollera leverantörens aktuella villkor och vilka kontroller som finns för den valda planen.
Ett anpassat gränssnitt gör inte i sig en extern översättningstjänst privat eller offline. Om projektet kräver lokal behandling ska du ange det kravet från början och testa hela dataflödet mot det.
Planera för fördröjningar och fel
Skriv ner förväntad svarstid och vad personalen ska göra om tjänsten inte är tillgänglig. Applikationen bör visa en tydlig status, till exempel väntar, klar för granskning eller misslyckades. Bevara originaltexten.
Be utvecklaren att skilja tillfälliga fel från fel som kräver en ändring. DeepL dokumenterar till exempel fördröjda nya försök vid fel på grund av hastighetsbegränsning, medan en förbrukad kvot kräver en annan åtgärd. [3] Upprepade förfrågningar bör inte skapa dubbla affärshändelser, till exempel att samma svar skickas två gånger.
Kom överens om aviseringar om användning och om vem som ansvarar för supporten. Räkna med serviceavgifter, underhåll och framtida ändringar när du jämför projektkostnader.
Skriv acceptanstester före utvecklingen
Välj representativa exempel för varje språkpar som krävs. Ta med långa meddelanden, ovanliga tecken, saknade fält och termer från den godkända listan. Testa hela uppgiften, från källposten till det sparade eller skickade resultatet.
Sätt godkännandekriterier som går att kontrollera: produktkoder förblir oförändrade, en ej godkänd översättning kan inte skickas, en misslyckad begäran syns och granskaren kan gå tillbaka till källtexten. Låt en kvalificerad granskare bedöma betydelse och ton. Dokumentera fel och kör samma tester igen efter ändringar.
Förbered en tydlig offertförfrågan
Skicka arbetsflödet, exempelfält, språkpar, uppskattad volym, dataregler och acceptanstester. Markera varje punkt som nödvändig vid lansering eller lämplig för en senare version. Be om antaganden och undantag skriftligt.
Vavus erbjuder skriftlig avgränsning av skräddarsydda projekt. [4] Beskriv din befintliga applikation och den uppgift du vill förbättra på offertsidan. Föreslagen integration, driftsättning och testning bör bekräftas i din projektbeskrivning.