¿Dónde debo hacer la localización (del lado del servidor o del lado del cliente)?

Actualmente estoy desarrollando una nueva aplicación web basada en un rico cliente JavaScript que se comunica con múltiples servicios web REST en mi servidor. Esa aplicación está destinada a ser utilizada en al menos dos países con diferentes idiomas, por lo que debemos localizarla.

Mi pregunta es dónde debo gestionar la localización: ¿deberían los servicios REST recibir solicitud y enviar respuestas con datos localizados, o el cliente debería recibir y enviar datos genéricos y luego ser responsable de hacer la localización?

Su API REST será más fácil de usar por otros si proporciona ID de cadena en lugar de cadenas traducidas. Usar una API que devuelve "E_NOT_AUTHORIZED"es más sencillo que si devuelve un lenguaje humano e incluso una cadena localizada.

Además, es posible que desee cambiar las cadenas localizadas en futuras versiones, lo que sería un cambio de API de última hora. Con el enfoque de ID de cadena, aún regresa "E_NOT_AUTHORIZED", manteniendo su API compatible.

Si usa un marco como Angular.js , es fácil implementar el cambio de idioma si usa el enfoque de ID de cadena. Simplemente carga otra tabla de cadenas, y todas las cadenas cambian automáticamente su idioma porque solo usa algo de lógica de filtro en sus plantillas, como {{errorStringID | loc}}.

Otra consideración: para reducir la carga de su servidor, mantenga su back-end lo más simple posible. Podrá atender a más clientes con la misma cantidad de servidores. Entregue sus tablas de cadenas a través de un CDN y realice la localización en el front-end.

Haga que los clientes envíen el Accept-Languageencabezado estandarizado en las solicitudes, luego localícelo en el servidor e incluya un Content-Languageencabezado en las respuestas. Ver RFC 7231 Sección 5.3.5 para más detalles.

La localización en el lado del servidor da como resultado menos viajes de ida y vuelta y consumo de ancho de banda que el envío de metadatos de localización de los clientes. Pero un servidor no puede asumir qué idioma quiere un cliente, porque ¿qué pasa si ese cliente es un proxy que lo sirve a otra persona? ¿Qué pasa si hay una capa de caché entre el cliente y el servidor? ¿Cómo se supone que un servidor debe "averiguar" qué idioma se debe utilizar para alguna solicitud arbitraria?

Intentar responder esas preguntas es complicado, por lo tanto, requiere que las solicitudes sean autodescriptivas y usen el encabezado estándar para que los clientes puedan negociar qué idioma desean. Eso se llama negociación de contenido. El Accept-Languageencabezado es una forma de negociación de contenido proactiva donde un cliente le dice a un servidor cuáles son sus preferencias, luego el servidor decide con qué responder en función de esas preferencias. La negociación de contenido reactivo es cuando un cliente envía una solicitud preguntándole al servidor qué tipo de contenido hay, generalmente recibe una respuesta que contiene una lista de enlaces, y luego elige cuál desea seleccionar un enlace a seguir.

Diría tanto como sea posible en el lado del servidor si va a admitir múltiples dispositivos.

Por supuesto, cada dispositivo usará algunas traducciones por su cuenta, pero las cosas compartidas como mensajes de error de la API, etc. serán las mismas independientemente de los dispositivos.

Es en gran medida una cuestión de gusto personal, pero si hace cosas del lado del cliente, ahorrará en la carga del servidor (suponiendo diccionarios estáticos o en caché), y puede usar herramientas independientes del lenguaje para probar el servicio.