Когда локализация (или отсутствие) это плохо? - PullRequest
0 голосов
/ 18 декабря 2018

Следующий код возвращает сообщение, в котором указывается, является ли входное значение палиндромом:

(ради этого поста синтаксис не важен или написан на каком-либо конкретном языке)

function isPalindrome(
    value: string, 
    successMessage: string = "Is palindrome", 
    failureMessage: string = "Is not palindrome"): string {

    return value.reverse() == value ? successMessage : failureMessage;
}

Обратите внимание, что в приведенном выше коде сообщения по умолчанию написаны на английском языке, однако, поскольку они предоставляются в качестве параметров, этот метод может быть легко локализован, и поскольку метод имеет значения по умолчанию длясообщения, это не заставляет разработчика предоставлять их;например:

isPalindrome("level") // returns "Is palindrome"

Однако мы можем продемонстрировать локализацию;например, на испанском:

isPalindrome("level", "es palíndromo", "no es palíndromo") // returns "es palíndromo"

Это заставило меня задуматься, когда должен ли код быть разработан с учетом локализации?

Другой пример будет с исключениями;например:

class PalindromeException : Exception("Is not a palindrome")

function validatePalindrome(value: string): void {
    if (value.reverse() != value) {
        throw PalindromeException();
    }
}

Обратите внимание, что в этом примере нет способа локализовать сообщение в исключении.Я знаю, что это можно легко исправить, используя те же принципы, что и в первом примере, но он был специально разработан для демонстрации отсутствия глобализации.

Поэтому, когда следует применять глобализацию к коду, чтобы он мог бытьлокализованы?Когда это имеет значение, а когда нет?

Ответы [ 4 ]

0 голосов
/ 06 января 2019

Единственное место, где должна происходить локализация - это пользовательский интерфейс.Если вы придерживаетесь MVC принципа разделения интересов (или чего-то похожего на MVP или тому подобное), то локализация происходит исключительно в части View ,Ваша функция isPalindrome больше похожа на бизнес-логику, принадлежащую детали Model , и поэтому ее вообще не следует касаться i18n.Также не следует беспокоиться об исключениях, так как никакие исключения не должны быть напечатаны в пользовательском интерфейсе как есть (за исключением предоставления отладочной информации, которая не должна быть / не должна быть локализована).

Ваша функция должна возвращать только true или false, и совершенно отдельная часть пользовательского интерфейса должна преобразовывать это в нечто, с чем сталкивается пользователь, потенциально локализуя его в процессе.То же самое за исключением того, что оно должно быть поймано чем-то, что загружает соответствующим образом локализованный пользовательский интерфейс, объясняющий проблему пользователю.

0 голосов
/ 06 января 2019

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

Однако я бы предложил следующие шаблоны:

  1. Все сообщения журнала (обасервер и клиент) должны быть на английском языке
  2. Все ответы API об ошибках всегда должны содержать описание на английском языке и уникальный код ошибки, который можно перевести в дружеское сообщение на стороне клиента
  3. .чтобы обеспечить хороший UX, все клиентские сообщения должны быть на языке пользователя

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

0 голосов
/ 06 января 2019

Все метки необходимо перевести.

Для этого определения текст - это информация, прочитанная конечным пользователем.В этом контексте метка представляет собой фрагмент текста , который в то же время не является пользовательским вводом или пользовательских данных .

Например, в диалоговом окне «Сохранить как» имя файла будет пользовательский ввод , содержимое файла пользовательских данных и Сохранить и Отмена на двух кнопках будут метками (и, следовательно, нуждающихся в переводе),

Учитывая это определение, правило выглядит следующим образом:

Только код пользовательского интерфейса необходимо перевести, и он переводит все метки .Напротив, код бизнес-логики , не имеющий прямого отношения к конечным пользователям (таким как библиотеки или серверные службы), не должен переводиться вообще.Кроме того, ни бизнес-логика реализация , ни бизнес-логика API не обрабатывают текст, отличный от пользовательского ввода или пользовательских данных .

Таким образом, правило также подразумевает чистое отделение кода бизнес-логики от кода интерфейса пользователя .Это очень удобно для тестирования.

Для примера с палиндромом функция будет бизнес-логика , и она не будет возвращать текст , но что-то более подходящее, например,логическое или перечисление. код пользовательского интерфейса затем оценит возврат и переведет соответствующим образом.То же относится и к исключению.

0 голосов
/ 04 января 2019

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

...