Où dois-je faire la localisation (côté serveur ou côté client)?
Je développe actuellement une nouvelle application Web basée sur un client JavaScript riche qui communique avec plusieurs services Web REST sur mon serveur. Cette application est destinée à être utilisée dans au moins deux pays avec des langues différentes, nous devons donc le localiser.
Ma question est de savoir où dois-je gérer la localisation: les services REST doivent-ils recevoir la demande et envoyer la réponse avec des données localisées, ou le client doit-il recevoir et envoyer des données génériques, puis être responsable de la localisation?
Votre REST sera plus facile à utiliser par d'autres si vous fournissez des ID de chaîne au lieu de chaînes traduites. Utilisation d'une API qui renvoie "E_NOT_AUTHORIZED" est plus simple que s'il renvoie du langage humain, et même une chaîne localisée.
En outre, vous souhaiterez peut-être modifier les chaînes localisées dans les versions futures, ce qui constituerait un changement d'API de rupture. Avec l'approche de l'ID de chaîne, vous retournez toujours "E_NOT_AUTHORIZED", en gardant votre API compatible.
Si vous utilisez un framework comme Angular.js , il est facile d'implémenter le changement de langue à chaud si vous utilisez l'approche de l'ID de chaîne. Vous chargez simplement une autre stringtable et toutes les chaînes changent automatiquement leur langue car vous utilisez simplement une logique de filtrage dans vos modèles, comme {{errorStringID | loc}}.
Autre considération: pour réduire la charge de votre serveur, gardez votre back-end aussi simple que possible. Vous pourrez servir plus de clients avec le même nombre de serveurs. Livrez vos stringtables via un CDN et effectuez la localisation dans le front-end.
Demandez aux clients d'envoyer l'en-tête Accept-Language Standardisé dans les demandes, puis de le localiser sur le serveur et d'inclure un en-tête Content-Language Dans les réponses. Voir RFC 7231 Section 5.3.5 pour plus de détails.
La localisation côté serveur entraîne moins d'allers-retours et de consommation de bande passante que l'envoi de métadonnées de localisation aux clients. Mais un serveur ne peut pas supposer quelle langue un client veut, et si ce client est un proxy qui le sert à quelqu'un d'autre? Et s'il y a une couche de mise en cache entre le client et le serveur? Comment un serveur est-il censé "juste comprendre" quelle langue doit être utilisée pour une requête arbitraire?
Il est compliqué d'essayer de répondre à ces questions, alors exigez plutôt que les demandes soient auto-descriptives et utilisez l'en-tête standard pour que les clients puissent négocier quelle langue ils désirent. C'est ce qu'on appelle la négociation de contenu. L'en-tête Accept-Language Est une forme de négociation de contenu proactive où un client indique à un serveur quelles sont ses préférences, puis le serveur décide quoi faire répondre en fonction de ces préférences. La négociation de contenu réactive est l'endroit où un client envoie une demande demandant au serveur quels types de contenu il y a, reçoit généralement une réponse contenant une liste de liens, puis choisit lequel il souhaite en sélectionnant un lien à suivre.
Je dirais autant que possible côté serveur si vous allez prendre en charge plusieurs appareils.
Chaque appareil utilisera bien sûr certaines traductions par lui-même, mais des éléments partagés, car les messages d'erreur de l'API, etc. seront les mêmes quels que soient les appareils.
C'est une question de goût personnel, mais si vous faites des choses côté client, vous économiserez sur la charge du serveur (en supposant des dictionnaires statiques ou mis en cache) et pourrez utiliser des outils indépendants de la langue pour tester le service.