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

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

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

Se utilizzi un framework come Angular.js , è facile implementare la commutazione a caldo della lingua se si utilizza l'approccio ID stringa. Devi solo caricare un'altra stringa e tutte le stringhe modificano automaticamente la lingua perché utilizzi solo una logica di filtro nei tuoi modelli, ad esempio {{errorStringID | loc}} .

Un'altra considerazione: per ridurre il carico del tuo server, mantieni il back-end il più semplice possibile. Sarai in grado di servire più clienti con lo stesso numero di server. Distribuisci i tuoi archi attraverso un CDN e esegui la localizzazione nel front-end.

I client inviano l'intestazione Accept-Language standardizzata nelle richieste, quindi localizzano sul server e includono un'intestazione Content-Language nelle risposte. Per i dettagli vedi RFC 7231 Sezione 5.3.5 .

La localizzazione sul lato server comporta un minor numero di round trip e consumo di larghezza di banda rispetto all'invio dei metadati di localizzazione dei client. Ma un server non può assumere quale lingua vuole un cliente, perché cosa succede se quel client è un proxy che lo serve a qualcun altro? Cosa succede se c'è un livello di memorizzazione nella cache tra il client e il server? Come si suppone che un server "capisca" quale linguaggio debba essere usato per alcune richieste arbitrarie?

Cercare di rispondere a queste domande è complicato, quindi richiede che le richieste siano autodescrittive e usino l'intestazione standard in modo che i clienti possano negoziare quale lingua desiderano. Si chiama negoziazione del contenuto. L'intestazione Accept-Language è una forma di negoziazione del contenuto proattiva in cui un client indica al server quali sono le sue preferenze, quindi il server decide su cosa rispondere in base a tali preferenze. La negoziazione di contenuti reattiva è dove un client invia una richiesta chiedendo al server quali tipi di contenuto ci sono, in genere riceve una risposta contenente un elenco di collegamenti, quindi sceglie quale desidera selezionare un collegamento a seguire.

Direi il più possibile sul lato server se vuoi supportare più dispositivi.

Ogni dispositivo utilizzerà ovviamente alcune traduzioni per conto proprio, ma i contenuti condivisi come messaggi di errore da api etc saranno uguali indipendentemente dai dispositivi.

È una questione di gusti personali, ma se fai qualcosa dal lato del client, risparmierai sul carico del server (assumendo dizionari statici o memorizzati nella cache) e potrai usare gli strumenti agnostici della lingua per testare il servizio.