Cum definiți integrarea traducerii într-o aplicație de afaceri existentă
Planificați traducerea în aplicația dumneavoastră de afaceri. Definiți conținutul, limbile, revizuirea, regulile pentru date, gestionarea erorilor și testele de acceptare înainte de a cere o ofertă.
Porniți de la o sarcină completă pe care echipa dumneavoastră trebuie să o realizeze într-o altă limbă. Apoi stabiliți cum se încadrează traducerea în acea sarcină. Astfel, un furnizor de software are o bază mai clară pentru o estimare decât o simplă cerere de a adăuga un buton de traducere.
Specificația ar trebui să acopere textul, oamenii, datele și rezultatul. Ar trebui să explice și ce se întâmplă când traducerea eșuează. Folosiți pașii de mai jos pentru a pregăti această specificație înainte de a alege o abordare tehnică.
Alegeți un singur flux de lucru pentru prima versiune
Notați de unde provine textul sursă și unde trebuie să ajungă traducerea aprobată. De exemplu, un angajat de la suport poate avea nevoie să citească un mesaj primit și să pregătească un răspuns în limba clientului. Aceasta este o cerință ilustrativă, nu relatarea unei instalări Vavus.
Enumerați fiecare pas: deschiderea mesajului, solicitarea traducerii, citirea textului sursă alături de rezultat, editarea răspunsului și aprobarea lui pentru trimitere. Decideți dacă traducerea pornește automat sau doar după ce un angajat o solicită.
Păstrați prima versiune mică. Un singur ecran și o singură sarcină de business clară se testează mai ușor decât toate câmpurile de text dintr-o aplicație.
Identificați conținutul și limbile necesare
Faceți o listă cu câmpurile care trebuie traduse. Separați etichetele scurte, textul liber, documentele și vorbirea. Acestea pot necesita procesări și teste diferite. Enumerați și câmpurile care trebuie să rămână neschimbate, cum ar fi numerele de comandă și codurile de produs.
Specificați limbile sursă și țintă, inclusiv eventualele variante regionale. Notați lungimea obișnuită a textelor și volumul zilnic estimat. Întrebați ce combinații de limbi și ce formate de intrare acceptă serviciul propus.
Contextul poate conta în cazul textelor scurte. API-ul de text DeepL, de exemplu, acceptă un parametru de context care poate influența traducerea fără ca acel context să fie tradus. Documentația sa precizează și că intrările de text separate din aceeași solicitare nu au context comun. [1] Specificația dumneavoastră ar trebui să arate de unde provine contextul util.
Definiți terminologia și revizuirea umană
Adunați termenii pe care afacerea dumneavoastră îi folosește des. Includeți traducerile preferate, denumirile de produse și cuvintele care trebuie să rămână neschimbate. Desemnați o persoană care să actualizeze această listă.
Unele servicii de traducere acceptă glosare. Google Cloud Translation își descrie glosarul ca pe un dicționar personalizat pentru o terminologie de specialitate consecventă. [2] Verificați funcția pentru perechile exacte de limbi și pentru serviciul ales. Un glosar nu dovedește că întregul mesaj este corect.
Decideți ce rezultate trebuie verificate de un revizor lingvistic calificat. Oferiți-i revizorului acces la textul original. Stabiliți un pas clar de aprobare înainte ca textele destinate clienților să fie trimise sau publicate.
Stabiliți reguli pentru date și acces
Descrieți ce informații gestionează fluxul de lucru. Folosiți exemple artificiale în testele inițiale. Evitați să copiați înregistrări reale ale clienților într-o probă doar pentru a vedea dacă un buton funcționează.
Întrebați unde va fi procesat textul, ce va stoca aplicația, cine îl poate citi și când va fi șters. Includeți în discuție jurnalele și copiile de rezervă. Confirmați condițiile actuale ale furnizorului și controalele disponibile pentru planul ales.
O interfață personalizată nu face, prin ea însăși, un serviciu extern de traducere privat sau offline. Dacă proiectul dumneavoastră necesită procesare locală, menționați această cerință de la început și testați întregul flux de date în raport cu ea.
Planificați pentru întârzieri și erori
Notați timpul de răspuns așteptat și ce trebuie să facă personalul dacă serviciul nu este disponibil. Aplicația ar trebui să afișeze o stare clară, cum ar fi „în așteptare”, „gata de revizuire” sau „eșuat”. Păstrați textul original.
Cereți dezvoltatorului să facă diferența între erorile temporare și cele care necesită o modificare. DeepL, de exemplu, documentează reîncercări amânate pentru erorile de depășire a limitei de solicitări, în timp ce o cotă epuizată necesită o altă reacție. [3] Solicitările repetate nu ar trebui să creeze acțiuni de business duplicate, cum ar fi trimiterea aceluiași răspuns de două ori.
Stabiliți alertele de utilizare și cine răspunde de suport. Includeți costurile serviciului, întreținerea și modificările viitoare atunci când comparați costurile proiectului.
Scrieți testele de acceptare înainte de dezvoltare
Alegeți exemple reprezentative pentru fiecare pereche de limbi necesară. Includeți mesaje lungi, caractere neobișnuite, câmpuri lipsă și termeni din lista aprobată. Testați întreaga sarcină, de la înregistrarea sursă până la rezultatul salvat sau trimis.
Stabiliți criterii de reușită pe care oamenii le pot verifica: codurile de produs rămân neschimbate, o traducere neaprobată nu poate fi trimisă, o solicitare eșuată este vizibilă, iar revizorul poate reveni la textul sursă. Cereți unui revizor calificat să evalueze sensul și tonul. Notați defectele și repetați aceleași teste după modificări.
Pregătiți o cerere de ofertă clară
Trimiteți fluxul de lucru, exemple de câmpuri, perechile de limbi, volumul estimat, regulile pentru date și testele de acceptare. Marcați fiecare element ca necesar la lansare sau potrivit pentru o versiune ulterioară. Cereți în scris ipotezele și excluderile.
Vavus oferă definirea în scris a specificațiilor pentru proiectele personalizate. [4] Folosiți pagina de ofertă pentru a descrie aplicația existentă și sarcina pe care doriți să o îmbunătățiți. Integrarea, implementarea și testarea propuse ar trebui confirmate în specificația proiectului dumneavoastră.