Правильно ли разделить словарь i18n по значению перевода вместо бизнес-логики?

Question

Например, в моем приложении есть различные типы объектов: человек и клиент.

Приложение содержит словарь, содержащий метки и переводы для нескольких языков.

const en = {
  firstName: 'First name',
  lastName: 'Last name',
  address: 'Address'
};

const ru = {
  firstName: 'Имя',
  lastName: 'Фамилия',
  address: 'Адрес'
}

const dictionary = createDictionary({ en, ru });

AsВы можете видеть, что нет разницы между метками для person или client, если они имеют одинаковый перевод.

Стоит ли разделять метки по типу сущности?

Answer 1

Если это одно и то же слово и оно переводится как одно и то же слово, нет необходимости проводить различие.Вероятно, в вашем приложении есть много мест, где вы переводите слово «Okay» на кнопке, и вам не нужно выделять каждую кнопку «Okay», чтобы получить 200 отдельных переводов, которые все идентичны.

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

#: signup-form.html:42 admin/user-details.html:69
msgid "First name"
msgstr "Имя"

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

#: signup-form.html:42
msgctxt "Label addressing the user in signup form"
msgid "First name"
msgstr "お客様の名"

#: admin/user-details.html:69
msgctxt "Label for user data in admin view"
msgid "First name"
msgstr "名"

Теперь это две отдельные строки, которые можно переводить по отдельности.

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