В каком слое должен работать i18n / многоязычный?

Question

Проект, над которым мы работали, состоит из 3 уровней: уровня представления, уровня бизнес-логики и уровня данных, я буду называть их здесь спереди, в середине и сзади.

Фронт написан на PHP и взаимодействует с серединой через веб-сервис (XML-RPC, SOAP и т. Д.). Пользователи могут также написать своих собственных клиентов, чтобы поговорить с серединой. Nid разработан на Java, он выполняет бизнес-логику и предоставляет данные на фронт, он также может выдавать исключение на фронт.

Вопрос, который у меня возникает, состоит в том, если я хочу иметь многоязычную поддержку в будущем, где я буду развивать i18n? Имеет смысл быть впереди из-за всех текстов, которые у него есть, как насчет исключений и других сообщений, приходящих с середины?

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

Answer 1

Это зависит от вашего приложения.

Если вы думаете, локализация пользовательского интерфейса, презентации определенно затронуты.

Я бы сказал, что средний уровень не должен генерировать никаких сообщений. Исключения предназначены для разработчиков, а не для пользователей. Поэтому в презентации запишите исключение и представьте его пользователю в локализованном виде, сказав что-то вроде: «Произошла фатальная ошибка 12313, отправьте этот отчет ...» (может быть, даже приятнее, вы вообще не показываете текст исключения, предлагаете пользователю кнопку «Отправить отчет о сбое», а также кнопку «Показать отчет», чтобы вы могли видеть, что вы не отправляете какие-либо личные данные).

Но если вы относитесь к вещам, выходящим за рамки пользовательского интерфейса, то это может повлиять и на другие. Бизнес-логика может быть затронута (например, то, как налоговые системы работают в разных странах). И это не зависит от пользовательского интерфейса (Канада или Австралия имеют другую налоговую систему, чем США, даже если пользовательский интерфейс все еще английский). Поэтому вы можете захотеть сделать этот слой очень модульным.

Содержание базы данных также может быть затронуто. Представьте, что у вас есть продукты, которые недоступны (или запрещены) в определенных странах. Так что вам может понадобиться дополнительные поля (или таблицы) для переноса этой информации.

Итак, в конце ответ: «Вы должны думать о i18n на каждом уровне!» и спросите себя "что если"

Answer 2

Я хотел бы задать вам вопрос: данные i18n будут обрабатываться на заднем уровне (уровень данных)? Если вы скажете «да», значит, вы получили его, но если вы скажете «нет», я бы поместил его в средний уровень (уровень бизнес), потому что средние и крупные проекты используют для взаимодействие с I18N (исключения, валюты, форматы сообщений , часовые пояса, кодировки и т.д ...)

Я бы поместил его в передний слой (уровень представления) для небольших проектов.

Привет.

Answer 3

Если вы хотите полностью интернационализироваться, исключения и другие сообщения среднего уровня не должны содержать текст. Вы должны указать код, который клиент должен найти в таблице, чтобы понять.