Каков правильный способ присвоения имен свойств сообщений в i18n?
У нас есть веб-сайт, который должен быть переведен на разные языки. Некоторые из формулировок содержатся в файлах свойств сообщений, готовых к переводу. Теперь я хочу добавить остальную часть текста в эти файлы.
Что такое хороший способ назвать текстовые блоки?
<view>.<type>.<name>
У нас в основном есть веб-страницы, а некоторые элементы/модули повторяются на некоторых сайтах.
Ответы
Ответ 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