Должен ли я использовать английские сообщения или имена сообщений в коде для интернационализации?

Question

Мы с другом начинаем новый программный проект (на Java), и мы думаем о том, как сделать интернационализацию для GUI.Хотя я бы предпочел, чтобы в коде были английские строки с заполнителями:

gettext("$name invites you to join $room", invitation.whose, invitation.roomname)

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

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

Answer 1

Это зависит . В вашем вопросе много вещей, и я не уверен, правильно ли я это понимаю.

1. Ваш друг хочет отделить логику программирования от переводимых строк. Ну, вот как работают стандартные ресурсы I18n Java (через ResourceBundle). Если вы хотите использовать стандартные инструменты или команды (например, Externalize Strings в Eclipse), то, честно говоря, это единственный путь.
   Однако некоторые люди думают, что наличие ключей в исходных файлах и много rb.getString(key) отравляет код. Конечно, код, содержащий английские строки, более читабелен. И они у вас уже есть, так что вы не рискуете видеть ключи вместо реальных сообщений. Со всеми плюсами и минусами этой ситуации.
   Если вы придерживаетесь gettext, некоторые инструменты могут сообщать об этих строках как о жестко закодированных ...

2. Интересно, что вы подразумеваете под "Хотя я бы предпочел иметь английские строки с заполнителями в коде, подобном этому" ... Ваш друг предпочитает не использовать заполнители? Это не будет хорошей идеей. Из-за грамматических правил целевого языка, людям может потребоваться изменить порядок предложений во время перевода, поэтому в вашем примере «$ room» может стоять перед «$ name».

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

Answer 2

Я предпочитаю подход gettext, мои причины перечислены на странице github моей собственной библиотеки i18n под заголовком «Зачем использовать gettext вместо комплектов свойств»:

• Необходимость придумывать ключ для каждого сообщения прерывает поток программистов. Иногда уже довольно сложно думать о значимых именах переменных, думать о чем-то совершенно не связанном с кодом, например перевод еще больше отвлекает программиста.

• Обработка множественного числа в gettext лучше для некоторых языков, имеющих больше чем две формы множественного числа . Для простых случаев можно использовать множественное число, используя ChoiceFormat, но языки вроде польского требуют более сложных правил. Кроме того, синтаксис для ChoiceFormat, вероятно, является сложным для не-разработчиков.

• Существуют специализированные редакторы для редактирования файлов gettext, которые также может использоваться непрограммистами. Эти редакторы имеют широкие возможности для поддержки переводчик, как запоминание уже переведенной строки или содержащий база терминологических данных.

Answer 3

В экосистеме Java gettext GNU широко не используется; имеет свои собственные механизмы i18n , основанные на классе ResourceBundle, который несколько абстрагирован и охватывает не только текст.

Наиболее распространенный способ определения комплектов ресурсов для текста - в файлах свойств, и ключи в них не могут содержать пробелов, что в основном исключает ваш предпочтительный стиль.

Мне действительно нравится стиль gettext в GNU, но не стоит использовать стандарт платформы.

Answer 4

Твой друг прав. Если ваши сообщения жестко запрограммированы в источниках Java, как вы хотите реализовать i18n ? В коде у вас должны быть только заполнители:

gettext("invitation_message", invitation.whose, invitation.roomname)

и у вас должны быть отдельные файлы перевода где-то за пределами кодовой базы:

• messages_en.properties:

  invitation_message=$name invites you to join $room
  

• messages_pl.properties

  invitation_message=$name zaprasza cię do wstąpienia do $room
  

См. Также официальный Учебник по интернационализации .