Dove devo fare la localizzazione (lato server o lato client)?

Attualmente sto sviluppando una nuova applicazione Web basata su un client JavaScript avanzato che comunica con più servizi Web REST sul mio server. Tale applicazione deve essere utilizzata in almeno due paesi con lingue diverse, pertanto è necessario localizzarla.

La mia domanda è dove devo gestire la localizzazione: i servizi REST dovrebbero ricevere richieste e inviare risposte con dati localizzati oppure il cliente dovrebbe ricevere e inviare dati generici e quindi essere responsabile di fare la localizzazione?

L'API REST sarà più facile da usare da parte di altri se fornisci ID stringa anziché stringhe tradotte. L'uso di un'API che restituisce "E_NOT_AUTHORIZED"è più semplice che se restituisce un linguaggio umano e persino una stringa localizzata.

Inoltre, potresti voler cambiare le stringhe localizzate nelle versioni future, il che sarebbe una rottura dell'API. Con l'approccio ID stringa, si ritorna ancora "E_NOT_AUTHORIZED", mantenendo compatibile l'API.

Se si utilizza un framework come Angular.js , è facile implementare la commutazione automatica della lingua se si utilizza l'approccio ID stringa. Devi semplicemente caricare un altro stringable e tutte le stringhe cambiano automaticamente la loro lingua perché usi semplicemente una logica di filtro nei tuoi modelli, come {{errorStringID | loc}}.

Un'altra considerazione: per ridurre il carico del server, mantenere il back-end il più semplice possibile. Sarai in grado di servire più client con lo stesso numero di server. Distribuisci le tue stringhetable attraverso un CDN e fai la localizzazione nel front-end.

Chiedi ai client di inviare l' Accept-Languageintestazione standardizzata nelle richieste, quindi localizzarli sul server e includere Content-Languageun'intestazione nelle risposte. Vedere RFC 7231 Sezione 5.3.5 per i dettagli.

La localizzazione sul lato server comporta un minor numero di round trip e consumi di larghezza di banda rispetto all'invio di metadati di localizzazione dei client. Ma un server non può assumere quale lingua desidera un client, perché se quel client fosse un proxy che lo serve a qualcun altro? Cosa succede se esiste un livello di memorizzazione nella cache tra client e server? In che modo si suppone che un server "capisca" quale linguaggio dovrebbe essere usato per qualche richiesta arbitraria?

Cercare di rispondere a queste domande è complicato, quindi è invece necessario che le richieste siano auto-descrittive e utilizzino l'intestazione standard in modo che i clienti possano negoziare quale lingua desiderano. Si chiama negoziazione dei contenuti. L' Accept-Languageintestazione è una forma di negoziazione proattiva del contenuto in cui un client dice a un server quali sono le sue preferenze, quindi il server decide con cosa rispondere in base a tali preferenze. La negoziazione di contenuto reattiva è quella in cui un client invia una richiesta chiedendo al server che tipo di contenuto ci sia, in genere riceve una risposta contenente un elenco di collegamenti, quindi sceglie quale preferire selezionando un collegamento da seguire.

Direi il più possibile sul lato server se hai intenzione di supportare più dispositivi.

Ovviamente ogni dispositivo utilizzerà alcune traduzioni per conto proprio, ma cose condivise poiché i messaggi di errore dell'API ecc. Saranno gli stessi indipendentemente dai dispositivi.

È molto una questione di gusti personali, ma se fai cose sul lato client, risparmierai sul carico del server (assumendo dizionari statici o memorizzati nella cache) e puoi utilizzare strumenti di linguaggio indipendente per testare il servizio.