Onde devo fazer a localização (do lado do servidor ou do cliente)?

Atualmente, estou desenvolvendo um novo aplicativo Web baseado em um cliente JavaScript avançado que se comunica com vários serviços Web REST no meu servidor. Esse aplicativo deve ser usado em pelo menos dois países com idiomas diferentes, portanto, precisamos localizá-lo.

Minha pergunta é onde devo gerenciar a localização: os serviços REST devem receber solicitação e enviar resposta com dados localizados ou o cliente deve receber e enviar dados genéricos e, em seguida, ser responsável pela localização?

Sua API REST será mais fácil de usar por outras pessoas se você fornecer IDs de sequência em vez de sequências traduzidas. O uso de uma API que retorna "E_NOT_AUTHORIZED"é mais simples do que se ele retornar alguma sequência em linguagem humana e até localizada.

Além disso, convém alterar as cadeias localizadas em versões futuras, o que seria uma alteração de API de quebra. Com a abordagem do ID da string, você ainda retorna "E_NOT_AUTHORIZED", mantendo sua API compatível.

Se você usar uma estrutura como o Angular.js , será fácil implementar a comutação a quente de idiomas se você usar a abordagem de ID de cadeia. Você acabou de carregar outra tabela de strings, e todas as strings alteram automaticamente seu idioma porque você usa alguma lógica de filtro em seus modelos, como {{errorStringID | loc}}.

Outra consideração: para reduzir a carga do servidor, mantenha o back-end o mais simples possível. Você poderá atender mais clientes com o mesmo número de servidores. Entregue suas tabelas de string através de uma CDN e faça a localização no front-end.

Os clientes enviam o Accept-Languagecabeçalho padronizado nas solicitações, localizam no servidor e incluem um Content-Languagecabeçalho nas respostas. Consulte a Seção 5.3.5 da RFC 7231 para obter detalhes.

A localização no lado do servidor resulta em menos viagens de ida e volta e consumo de largura de banda do que o envio de metadados de localização de clientes. Mas um servidor não pode assumir o idioma que um cliente deseja, e se esse cliente for um proxy que o serve a outra pessoa? E se houver uma camada de cache entre o cliente e o servidor? Como um servidor deve "descobrir" qual idioma deve ser usado para alguma solicitação arbitrária?

Tentar responder a essas perguntas é complicado; portanto, exija que as solicitações sejam auto-descritivas e use o cabeçalho padrão para que os clientes possam negociar qual idioma desejam. Isso é chamado de negociação de conteúdo. O Accept-Languagecabeçalho é uma forma de negociação proativa de conteúdo, em que um cliente informa ao servidor quais são suas preferências e decide o que responder com base nessas preferências. Negociação de conteúdo reativa é o local em que um cliente envia uma solicitação perguntando ao servidor que tipos de conteúdo existem, normalmente recebe uma resposta contendo uma lista de links e escolhe qual gostaria selecionando um link a seguir.

Eu diria o máximo possível no lado do servidor, se você for dar suporte a vários dispositivos.

É claro que cada dispositivo usará algumas traduções por conta própria, mas os itens compartilhados, pois as mensagens de erro da API etc serão as mesmas, independentemente dos dispositivos.

É uma questão de gosto pessoal, mas se você fizer coisas do lado do cliente, economizará na carga do servidor (assumindo dicionários estáticos ou armazenados em cache) e poderá usar ferramentas independentes de idioma para testar o serviço.