Именование ключей в передовой практике файлов ресурсов

Ответ 1

Я префикс моих литералов с помощью usecase или action classname. например:

PlaceOrder.invalidId=Invalid id for order {0}
PlaceOrder.success=Your order {0} was successful
PlaceOrder.fail.visa=Your visa was ...
PlaceOrder.fail.communications=We could not...
PlaceOrder.submit=Buy now

Login=Login
Login.fail=Your credentials did not...
Login.alread=You are already logged in

Таким образом вы избегаете столкновений:

EditStudent=Edit
EditClass=Edit
EditCourse=Edit Course

... и также может найти то, что вам нужно.

Другим способом я группируюсь по сущности:

Person.id=#
Person.name=First name
Person.surname=Surname

Они могут отображаться как заголовки таблиц с объектами. Он сохраняет вас в таких случаях:

Person.id=#
Class.id=#
Course.id=Course Id

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

no=no

который использовался в качестве заголовка таблицы id (#) в верхней левой ячейке, но наш французский переводчик сделал это для французского языка:

no=non

... он думал, что это слово "нет" (отрицание да).:)

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

Ответ 2

Мы основываем его на английской версии термина. Пример: EditUser Это было легко читаемо нашими разработчиками и может быть повторно использовано в нескольких местах, что требуется во всем приложении.

Ответ 3

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

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

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

Ответ 4

+1 для ответа @cherouvim, но он всегда сводится к документации.

Документируйте каждое значение (используя любой механизм комментариев, поддерживаемый форматом файла источника ресурсов), включая тип данных каждого параметра, если строка является форматируемой. Например, редактор VS для формата .resx предоставляет поле комментариев, которое делает его очень легким.

Итак, сообщение вроде:

Невозможно запланировать задание {0} до {1}.

будет задокументировано как-то вроде:

Записанное сообщение об ошибке, {0}: имя задания, {1} дата/время в формате ISO 8601.

Ответ 5

Я думаю, что в первую очередь вам нужно использовать какие-то файлы XML для хранения таких данных.

Что-то вроде:

<? xml version = "1.0" encoding = "utf-8" standalone = "yes"? >

   
        <править >
            <пользователь > *** Изменить пользователя *
            <группa > Изменить группу
         
   
**

И затем используйте класс "translate", чтобы получить (и установить/сохранить) текст.

Что-то вроде:

myTranslateClass.load('translate.xml');
myTranslateClass.get('button', 'edit', 'user');

Это простой пример.