Como definir o alcance dunha integración de tradución nunha app empresarial existente
Planifique a tradución na súa app empresarial. Defina contido, idiomas, revisión, regras de datos, xestión de erros e probas de aceptación antes de pedir orzamento.
Comece por unha tarefa completa que o seu equipo teña que facer noutro idioma. Despois defina como encaixa a tradución nesa tarefa. Isto dálle a un provedor de software unha base máis clara para facer unha estimación ca unha simple petición de engadir un botón de tradución.
O alcance debe cubrir o texto, as persoas, os datos e o resultado. Tamén debe explicar que pasa cando falla a tradución. Use os pasos seguintes para preparar ese alcance antes de escoller un enfoque técnico.
Escolla un fluxo de traballo para a primeira versión
Anote de onde vén o texto de orixe e a onde debe ir a tradución aprobada. Por exemplo, un empregado de atención ao cliente pode ter que ler unha mensaxe recibida e preparar unha resposta no idioma do cliente. Este é un requisito ilustrativo, non o informe dunha instalación de Vavus.
Enumere cada paso: abrir a mensaxe, solicitar unha tradución, ler o orixinal xunto ao resultado, editar a resposta e aprobala para o envío. Decida se a tradución comeza automaticamente ou só despois de que un empregado a seleccione.
Manteña pequena a primeira versión. Unha pantalla e unha tarefa empresarial clara son máis fáciles de probar que todos os campos de texto dunha aplicación.
Identifique o contido e as necesidades de idioma
Faga unha lista dos campos que precisan tradución. Separe as etiquetas curtas, o texto libre, os documentos e a voz. Poden requirir procesamentos e probas diferentes. Enumere tamén os campos que deben quedar sen cambios, como os números de pedido e os códigos de produto.
Especifique os idiomas de orixe e de destino, incluídas as variantes rexionais. Anote a lonxitude habitual dos textos e o volume diario previsto. Pregunte que combinacións de idiomas e formatos de entrada admite o servizo proposto.
O contexto pode importar nos textos curtos. A API de texto de DeepL, por exemplo, admite un parámetro de contexto que pode influír na tradución sen que se traduza o propio contexto. A súa documentación tamén indica que as entradas de texto separadas dunha mesma petición non comparten contexto. [1] O seu alcance debe indicar de onde sae o contexto útil.
Defina a terminoloxía e a revisión humana
Reúna os termos que a súa empresa usa a miúdo. Inclúa as traducións preferidas, os nomes de produtos e as palabras que deben quedar sen cambios. Asigne a unha persoa o mantemento desta lista.
Algúns servizos de tradución admiten glosarios. Google Cloud Translation describe o seu glosario como un dicionario personalizado para manter unha terminoloxía coherente nun ámbito específico. [2] Comprobe a función para os seus pares de idiomas exactos e para o servizo escollido. Un glosario non demostra que toda a mensaxe sexa correcta.
Decida que resultados necesitan un revisor lingüístico cualificado. Dea ao revisor acceso ao texto orixinal. Estableza un paso de aprobación claro antes de enviar ou publicar textos dirixidos aos clientes.
Estableza regras para os datos e o acceso
Describa que información manexa o fluxo de traballo. Use exemplos ficticios nas primeiras probas. Evite copiar rexistros reais de clientes nunha proba só para ver se un botón funciona.
Pregunte onde se procesará o texto, que gardará a aplicación, quen poderá lelo e cando se eliminará. Inclúa os rexistros do sistema e as copias de seguridade nesta conversa. Confirme as condicións actuais do provedor e os controis dispoñibles no plan seleccionado.
Unha interface personalizada non fai por si soa que un servizo de tradución externo sexa privado nin que funcione sen conexión. Se o seu proxecto require procesamento local, indique ese requisito desde o principio e probe todo o fluxo de datos con respecto a el.
Planifique os atrasos e os erros
Anote o tempo de resposta previsto e o que debe facer o persoal se o servizo non está dispoñible. A aplicación debe mostrar un estado claro, como en espera, listo para revisión ou fallido. Conserve o texto orixinal.
Pídalle ao programador que distinga os fallos temporais dos erros que requiren un cambio. DeepL, por exemplo, documenta reintentos con espera para os erros por límite de peticións, mentres que unha cota esgotada require unha resposta diferente. [3] As peticións repetidas non deben crear accións empresariais duplicadas, como enviar a mesma resposta dúas veces.
Acorde as alertas de uso e quen se encarga do soporte. Inclúa as tarifas do servizo, o mantemento e os cambios futuros cando compare os custos do proxecto.
Redacte as probas de aceptación antes do desenvolvemento
Escolla exemplos representativos para cada par de idiomas necesario. Inclúa mensaxes longas, caracteres pouco habituais, campos baleiros e termos da súa lista aprobada. Probe a tarefa completa, desde o rexistro de orixe ata o resultado gardado ou enviado.
Estableza criterios de aceptación que as persoas poidan comprobar: os códigos de produto non cambian, unha tradución sen aprobar non se pode enviar, unha petición fallida queda visible e o revisor pode volver ao orixinal. Pida a un revisor cualificado que avalíe o significado e o ton. Anote os defectos e repita as mesmas probas despois dos cambios.
Prepare unha solicitude de orzamento clara
Envíe o fluxo de traballo, campos de exemplo, os pares de idiomas, o volume estimado, as regras de datos e as probas de aceptación. Marque cada elemento como imprescindible para o lanzamento ou axeitado para unha versión posterior. Pida por escrito os supostos e as exclusións.
Vavus ofrece unha definición de alcance por escrito para proxectos á medida. [4] Use a páxina de orzamento para describir a súa aplicación actual e a tarefa que quere mellorar. A integración, o despregamento e as probas propostos deben confirmarse no alcance do seu proxecto.
Solicitar un orzamento por escrito