Где я должен делать локализацию (на стороне сервера или на стороне клиента)?

В настоящее время я занимаюсь разработкой нового веб-приложения на основе богатого клиента JavaScript, который взаимодействует с несколькими веб-службами REST на моем сервере. Это приложение предназначено для использования как минимум в двух странах с разными языками, поэтому нам нужно его локализовать.

У меня вопрос: где мне управлять локализацией: должны ли службы REST получать запрос и отправлять ответ с локализованными данными, или клиент должен получать и отправлять общие данные и затем нести ответственность за локализацию?

Ваш REST API будет проще использовать другим, если вы предоставите идентификаторы строк вместо переведенных строк. Использовать API, который возвращает "E_NOT_AUTHORIZED", более просто, чем если бы он возвращал какой-то человеческий язык и даже локализованную строку.

Кроме того, вы можете захотеть изменить локализованные строки в будущих версиях, что будет серьезным изменением API. При использовании метода идентификатора строки вы все равно возвращаетесь "E_NOT_AUTHORIZED", сохраняя совместимость API.

Если вы используете фреймворк, такой как Angular.js , легко реализовать горячее переключение языка, если вы используете подход с идентификатором строки. Вы просто загружаете другую строковую таблицу, и все строки автоматически меняют свой язык, потому что вы просто используете некоторую логику фильтра в своих шаблонах, например {{errorStringID | loc}}.

Еще одно соображение: чтобы снизить нагрузку на сервер, сделайте свой бэкэнд максимально простым. Вы сможете обслуживать больше клиентов с одинаковым количеством серверов. Доставьте ваши stringtables через CDN, и сделайте локализацию во внешнем интерфейсе.

Пусть клиенты отправляют стандартизированный Accept-Languageзаголовок в запросах, затем локализуются на сервере и включают Content-Languageзаголовок в ответы. См. RFC 7231, раздел 5.3.5 для деталей.

Локализация на стороне сервера приводит к меньшему количеству обращений и использованию полосы пропускания, чем отправка метаданных локализации клиентов. Но сервер не может предположить, какой язык хочет клиент, потому что, если этот клиент является прокси-сервером, обслуживающим его кому-то еще? Что если между клиентом и сервером существует слой кэширования? Как сервер должен «просто выяснить», какой язык следует использовать для какого-либо произвольного запроса?

Попытка ответить на эти вопросы сложна, поэтому вместо этого потребуйте, чтобы запросы были информативными и использовали стандартный заголовок, чтобы клиенты могли договориться о том, какой язык они хотят. Это называется согласованием контента. Accept-LanguageЗаголовок является формой активного контента переговоров , когда клиент говорит сервер , что это предпочтение, то сервер решает , что ответить на основе этих предпочтений. Реактивное согласование контента - это когда клиент отправляет запрос, спрашивая сервер, какой тип контента существует, обычно получает ответ, содержащий список ссылок, а затем выбирает, какой из них он хотел бы, выбрав ссылку для перехода.

Я бы сказал как можно больше на стороне сервера, если вы собираетесь поддерживать несколько устройств.

Каждое устройство, конечно, будет использовать некоторые переводы самостоятельно, но общий контент, так как сообщения об ошибках от API и т. Д. Будут одинаковыми независимо от устройств.

Это вопрос личного вкуса, но если вы делаете что-то на стороне клиента, вы сэкономите на нагрузке на сервер (при условии использования статических или кэшированных словарей) и сможете использовать независимые от языка инструменты для тестирования службы.