Именование ключей в лучшей практике файлов ресурсов
Я также обнаружил, что System.Windows.Threading.Dispatcher.CurrentDispatcher.Invoke() не всегда является диспетчером целевого контроля, точно так же, как dotNet пишет в своем ответе. У меня не было доступа к диспетчеру управления, поэтому я использовал Application.Current.Dispatcher, и он решил проблему.
5 ответов
Я снабжаю префиксом свои литералы именем класса действия или вариантом использования. например:
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
, который использовался в качестве идентификатора (#) заголовок таблицы на вершине, оставленной ячейку, но наш французский переводчик сделал это для французского языка:
no=non
... он думал, что это было слово "нет" (отрицательный из да).:)
Последний (но не в последнюю очередь) снабжающий префиксом имя класса поможет Вам, когда Вы захотите осуществить рефакторинг/переименовать классы и быстро обновить эти ключи свойства, не имея необходимость смотреть на шаблоны.
Мы основываем его на английской версии термина. Ex:EditUser, Который был этим, легко читаем нашими разработчиками и может быть снова использован в нескольких местоположениях, что термин требуется всюду по приложению.
Основывайте его на английском тексте, но префикс с window/dialogue/what имеет Вас, в которых появляются слово или фраза. По крайней мере, когда пространство расположения ограничено, можно не хотеть падать в прерывании наличия точно той же строки везде: это препятствует тому, чтобы Вы сократили для получения достойных разметок, особенно на многосложных языках как финский язык.
, Конечно, необходимо все еще стремиться быть последовательными в именовании материала. Увеличение числа строк также увеличит затраты на перевод при выполнении этого коммерчески.
И не игнорируют опасность омонимов. Обеспечение контекста помогает предотвратить это. Не бойтесь, делают имя ресурса дольше, чем фактический английский термин, это может помочь переводчикам существенно.
+1 для ответа @cherouvim, но это всегда сводится к документации.
Документ каждое значение (использующий любой механизм комментария поддерживается форматом исходного файла ресурса), включая тип данных каждого параметра, если строка formattable. Например, редактор VS для формата .resx представляет поле комментария, которое делает его очень легким.
Так сообщение как:
Неспособный запланировать {0} задание прежде {1}.
был бы зарегистрирован как что-то как:
Зарегистрированное сообщение об ошибке, {0}: имя задания, {1} дата/время в формате ISO 8601.
Я думаю, что во-первых необходимо использовать некоторые XML-файлы, чтобы хранить такие данные.
Что-то как:
<? версия xml = "1.0" кодирование = "utf-8" автономный = "да"? >
< xml>
< button>
< edit>
< user> Пользователь Редактирования **** </user>
< group> группа Редактирования </group>
</edit>
</button>
</xml> **
И затем используют "переводить" Класс, чтобы получить (и установить/сохранить) текст.
Что-то как:
myTranslateClass.load ('translate.xml');
myTranslateClass.get ('кнопка', 'редактирование', 'пользователь');
Это - простой пример.