Com definir l'abast de la integració de traducció en una aplicació empresarial existent
Planifiqui la traducció a la seva aplicació empresarial. Defineixi contingut, idiomes, revisió, normes de dades, gestió d'errors i proves d'acceptació abans de demanar un pressupost.
Comenci per una tasca completa que el seu equip hagi de fer en un altre idioma. Després defineixi com encaixa la traducció en aquesta tasca. Així el proveïdor de programari té una base més clara per fer una estimació que no pas amb una simple petició d'afegir un botó de traducció.
L'abast ha de cobrir el text, les persones, les dades i el resultat. També ha d'explicar què passa quan la traducció falla. Faci servir els passos següents per preparar aquest abast abans de triar un enfocament tècnic.
Triï un sol flux de treball per a la primera versió
Anoti d'on prové el text d'origen i on ha d'anar la traducció aprovada. Per exemple, un empleat d'atenció al client pot haver de llegir un missatge entrant i preparar una resposta en l'idioma del client. Aquest és un requisit il·lustratiu, no l'informe d'una instal·lació de Vavus.
Enumeri cada pas: obrir el missatge, sol·licitar una traducció, llegir el text d'origen al costat del resultat, editar la resposta i aprovar-la per enviar-la. Decideixi si la traducció comença automàticament o només quan un empleat la selecciona.
Mantingui petita la primera versió. Una sola pantalla i una sola tasca empresarial clara són més fàcils de provar que tots els camps de text d'una aplicació.
Identifiqui les necessitats de contingut i d'idiomes
Faci una llista dels camps que s'han de traduir. Separi les etiquetes breus, el text lliure, els documents i la veu. Poden requerir un processament i unes proves diferents. Enumeri també els camps que han de quedar sense canvis, com ara els números de comanda i els codis de producte.
Especifiqui els idiomes d'origen i de destinació, incloses les variants regionals, si n'hi ha. Anoti la llargada habitual dels textos i el volum diari previst. Pregunti quines combinacions d'idiomes i quins formats d'entrada admet el servei proposat.
En els textos breus, el context pot ser important. Per exemple, l'API de text de DeepL admet un paràmetre de context que pot influir en la traducció sense que el context mateix es tradueixi. La seva documentació també indica que les entrades de text separades d'una mateixa sol·licitud no comparteixen context. [1] L'abast ha d'indicar d'on prové el context útil.
Defineixi la terminologia i la revisió humana
Reculli els termes que la seva empresa fa servir sovint. Inclogui les traduccions preferides, els noms de producte i les paraules que no s'han de modificar. Assigni una persona perquè mantingui aquesta llista.
Alguns serveis de traducció admeten glossaris. Google Cloud Translation descriu el seu glossari com un diccionari personalitzat per mantenir una terminologia especialitzada coherent. [2] Comprovi la funció per a les seves combinacions d'idiomes exactes i per al servei triat. Un glossari no demostra que tot el missatge sigui correcte.
Decideixi quins resultats necessiten un revisor lingüístic qualificat. Doni al revisor accés al text original. Estableixi un pas d'aprovació clar abans que s'enviïn o es publiquin textos adreçats als clients.
Estableixi normes de dades i d'accés
Descrigui quina informació gestiona el flux de treball. Faci servir exemples artificials en les primeres proves. Eviti copiar registres reals de clients en una prova només per veure si un botó funciona.
Pregunti on es processarà el text, què desarà l'aplicació, qui el podrà llegir i quan s'eliminarà. Inclogui els registres i les còpies de seguretat en aquesta conversa. Confirmi les condicions actuals del proveïdor i els controls disponibles en el pla triat.
Una interfície a mida no fa, per si sola, que un servei de traducció extern sigui privat o funcioni fora de línia. Si el seu projecte requereix processament local, indiqui aquest requisit des del principi i provi tot el flux de dades en funció d'aquest requisit.
Prevegi retards i errors
Anoti el temps de resposta previst i què ha de fer el personal si el servei no està disponible. L'aplicació ha de mostrar un estat clar, com ara «en espera», «llest per revisar» o «error». Conservi el text original.
Demani al desenvolupador que distingeixi entre les fallades temporals i els errors que requereixen un canvi. Per exemple, DeepL documenta reintents diferits per als errors de límit de sol·licituds, mentre que una quota esgotada requereix una resposta diferent. [3] Les sol·licituds repetides no han de crear accions de negoci duplicades, com ara enviar la mateixa resposta dues vegades.
Acordi les alertes d'ús i qui és responsable del suport. Quan compari els costos del projecte, inclogui les tarifes del servei, el manteniment i els canvis futurs.
Escrigui les proves d'acceptació abans del desenvolupament
Triï exemples representatius per a cada combinació d'idiomes necessària. Inclogui missatges llargs, caràcters poc habituals, camps buits i termes de la seva llista aprovada. Provi tota la tasca, des del registre d'origen fins al resultat desat o enviat.
Estableixi criteris de superació que les persones puguin comprovar: els codis de producte no canvien, no es pot enviar una traducció no aprovada, una sol·licitud fallida és visible i el revisor pot tornar al text d'origen. Faci que un revisor qualificat avaluï el sentit i el to. Registri els defectes i repeteixi les mateixes proves després dels canvis.
Prepari una sol·licitud de pressupost clara
Enviï el flux de treball, camps d'exemple, les combinacions d'idiomes, el volum estimat, les normes de dades i les proves d'acceptació. Marqui cada element com a necessari per al llançament o adequat per a una versió posterior. Demani per escrit les hipòtesis i les exclusions.
Vavus ofereix la definició per escrit de l'abast dels projectes a mida. [4] Faci servir la pàgina de pressupost per descriure la seva aplicació existent i la tasca que vol millorar. La integració, el desplegament i les proves proposats s'han de confirmar en l'abast del seu projecte.
Demani un pressupost per escrit