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

Ответ 1

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

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

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

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

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

preferences.password_area.label.username=User name

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

Ответ 2

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

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

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

Примеры:

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

Ключи содержания:

projectName.uiPath.messageOrContentType.n. *

Где:

• имя_проекта - это краткое имя проекта (или производное имя из пакета Java)
• uiPath - это путь навигации по пользовательскому интерфейсу к ключу содержимого.
• messageOrContentType (например, добавленный, удаленный, обновленный, информация, предупреждение, ошибка, заголовок, контент и т.д.) следует добавлять на основе типа контента. Пример сообщений: (1) Страница обновлена. (2) Произошла ошибка при обработке вашего запроса.
• n. * обрабатывает следующие случаи: когда на одной странице есть несколько областей содержимого (например, когда содержимое разделено, изображение и т.д.), когда контент находится в нескольких абзацах или когда контент находится в (un) упорядоченном списке - должен быть добавлен числовой идентификатор. Пример: ... 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 = Ваша личная информация обновлена.

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

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

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

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

Ответ 3

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

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

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

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

Ответ 4

Я предлагаю нижеприведенное соглашение

functionalcontext.subcontext.key
logicalcontext.subcontext.key

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

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