Как правильно именовать свойства сообщений в i18n?

Question

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

Как правильно именовать текстовые блоки?

<view>.<type>.<name>

У нас в основном есть веб-страницы, и некоторые элементы / модули повторяются на некоторых сайтах.

Answer 1

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

property file name: <module>.properties
resource keys: <view or dialog>[.<sub-context>].<control-type>.<name>

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

Что касается ключевой стратегии именования: для переводчика важно (звучит как фильм с почетным губернатором Арнольдом С., не так ли?) Иметь контекст. Перевод может на самом деле зависеть от этого, то есть на польском языке вы перевели бы сообщение другим способом, если это заголовок страницы / диалога / любого другого названия, и совершенно другим способом, если это текст кнопки.

Одним из примеров такого ключа ресурса может быть:

preferences.password_area.label.username=User name

Он дает достаточно подсказок переводчику о том, что он на самом деле, что может привести к правильному переводу ...

Answer 2

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

Ключи меток (метки форм, названия страниц / форм / приложений,и т. д., т. е. не полные предложения; используется в нескольких местах пользовательского интерфейса):

Если метка представляет поле Java (т. е. поле формы) и соответствует метке формы: label.nameOfField Иное: label.sameAsValue

Примеры:

• label.firstName = Имя
• label.lastName = Фамилия
• label.applicationTitle = Название приложения
• label.editADocument = Редактировать документ

Ключи содержимого:

projectName.uiPath.messageOrContentType.n. *

Где:

• projectName - краткое имя проекта (или производное имя из пакета Java)
• uiPath - это путь навигации пользовательского интерфейса к ключу содержимого
• messageOrContentType (например, добавлен, удален, обновлен, информация, предупреждение, ошибка), заголовок, контент и т. д.) следует добавлять в зависимости от типа контента.Примеры сообщений: (1) Страница была обновлена.(2) Произошла ошибка при обработке вашего запроса.
• n. * обрабатывает следующие случаи: когда на одной странице имеется несколько областей содержимого (например, когда содержимое разделено, изображение и т. д.), когда содержимое находится в нескольких абзацах или если содержимое находится в (не) упорядоченном списке - необходимо добавить числовой идентификатор.Пример: ... content.1 , ... content.2 Когда на странице имеется несколько областей содержимого, и одна или несколько областей требуют дальнейшего разделения (на основе приведенного выше примера HTML), к ключу может быть добавлен вторичный числовой идентификатор.Пример: ... content.1.1 , ... content.1.2

Примеры:

• training.mySetup.myInfo.content.1 = Это первое предложение контента 1. Это второе предложение контента 1. Этот контент будет окружен тегами абзаца.
• training.mySetup.myInfo.content.2 =Это первое предложение контента 2. Это второе предложение контента 2. Этот контент также будет окружен тегами абзаца.
• training.mySetup.myInfo.title = Моя информация
• training.mySetup.myInfo.updated = Ваша личная информация была обновлена.

Преимущества / недостатки :

---

+ Ключи меток можно легко использовать повторно;расположение не имеет значения.+ Для ключей содержимого, которые не используются повторно, поиск страницы в пользовательском интерфейсе будет простым и логичным.

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

---

Отзывы об этом соглашении- особенно отзывы, которые улучшат его - будут очень благодарны, так как в настоящее время мы обновляем наши пакеты ресурсов!:)

Answer 3

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

, например: print (T ("Hello world"))

, в этом случае T будет искать ключ"Привет, мир".Если он не найден, то ключ возвращается, в противном случае значение ключа.

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

Answer 4

Я бы предложил следующее соглашение

functionalcontext.subcontext.key
logicalcontext.subcontext.key

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

order.id=Order Id
order.submission.submit=Submit Order
name.last=Last Name