java - programador - ¿Internacionalización de mensajes de error de API en el front-end o back-end?

programador backend

Question

Actualmente, mi equipo está trabajando en un proyecto web en el que el front-end usa json api proporcionado por el back-end. La tecnología que usamos es Spring Boot y AngularJS. La API tiene el formato de error estándar que se ve así:

{
    "errorCode": "1111",
    "message": "Error occurred: some error message",
    "developerMessage": "message for developer"
}

La respuesta de error también puede contener una lista opcional de errores de validación de campo. La pregunta es ¿dónde debemos hacer la traducción de los mensajes de error del usuario? En caso de que la parte trasera devuelva un mensaje ya traducido según la configuración regional de la solicitud, o la parte delantera debe usar el código de error y su mecanismo i18n. Tenemos mecanismos i18n tanto en el back-end (soporte Spring i18n) como en el front-end (angular-translate).

cual es la mejor practica? ¿Cuáles son los pros y los contras de cada enfoque? Cualquier consejo es apreciado.

Answer 1

Lo haría localizando todo en la interfaz. Backend enviaría identificadores que aplicaciones de cliente luego traducen a cadenas.

Tenga en cuenta que para admitir aplicaciones de cliente múltiples, es posible que necesite la transformación de resx durante el proceso de agrupamiento en su compilación. Creará archivos de recursos en el formato requerido por el cliente para que pueda mantener una sola fuente de traducciones

Beneficios:

• única fuente de traducción para todo: botones, información sobre herramientas, etc. y los mensajes de error
• compatibilidad con el formato : es posible que necesite hacer algunas partes del mensaje en negrita / clicable / etc. que debe hacerse en la interfaz
• validación solo para el cliente: los mensajes de error para la validación del lado del cliente deben ser los mismos que los del lado del servidor para el mismo error (con la localización de back-end puede terminar la duplicación de algunas traducciones)
• pruebas agnósticas de idiomas son posibles
• backend independiente del lenguaje es posible - no hay necesidad de locale en el backend solo por el bien de la traducción
• en sincronía con la recomendación general de localizar lo más cerca posible del cliente
• elimina el incentivo de hacer más traducciones back-end en el futuro

Inconvenientes:

• la traducción de nuevos errores no es posible. Si se definió un error en el back-end después de que las aplicaciones del cliente se hubieran agrupado, los clientes tendrían que mostrar el mensaje genérico (pero si es necesario, puede mostrar el nuevo ID de error).
• agrupación más compleja

Answer 2

Si tuviera que hacer esto, lo habría hecho en el back-end, principalmente porque dado que el backend tiene la configuración regional, y también está generando los errores, tiene sentido esperar errores localizados de la misma. También desacoplaría los sistemas, de modo que, si se realiza una nueva función / cambio en el back-end, y se agrega un nuevo error, no es necesario que libere la pieza frontal solo por el error.

Además, una vez que esto se amplía, y usted tiene múltiples sistemas backend, el enfoque anterior simplemente funciona bien, ya que todos los generadores de errores son responsables de cuidar sus respectivas localizaciones.