Ресурсы C #: отображать имена строк ресурсов вместо локализованных значений

Наличие довольно большого проекта с использованием ресурсов для интернационализации (следуя этому руководству: Полное руководство по локализации ASP.NET MVC 2, используя такие вещи, как атрибуты данных и т. Д.), Мы сталкиваемся с необходимостью перевода файлов ресурсов. В начале проекта я выбрал подход, чтобы иметь много небольших файлов ресурсов - для каждого представления, модели представления, контроллера ... Так что в итоге у меня были сотни ресурсов. Во время переводов (что выполняется нашими партнерами с использованием инструмента ResXManager мы сталкиваемся с проблемой определения контекста строки (где она отображается, чтобы выяснить, какая форма перевода имеет смысл при отображении).

Поэтому меня попросили внести изменения в приложение, которые отображают не локализованные значения, а ключи (или имена строк). Например. имея строку в ресурсах TBL_NAME, используемую где-то в представлении, например @ResX.TBL_NAME, и переведенную на английский как "Name", я хотел бы показать ее в этой специальной мутации как "TBL_NAME", чтобы переводчик мог видеть контекст - где именно эта строка используется . Лучше всего, если бы это была не специальная сборка приложения, а другой «язык» приложения, доступный для переводчиков, чтобы он мог переключаться между английским и этим «нелокализованным» языками.

Я ищу несколько простых идей, как это сделать. До сих пор я думал об этих подходах:

  1. Переопределение ResourceManager.GetString - нельзя использовать, потому что мы используем сгенерированные классы конструктора для массового доступа к строкам, и пока я не нашел способа изменить созданный ResourceManager (см. ответ). Я что-то пропустил?
  2. Создайте ресурсы для какого-то неиспользуемого языка, который будет содержать пары string name/translated value как TBL_NAME/TBL_NAME - жизнеспособно, но очень утомительно, поскольку у нас есть сотни ресурсов. Также добавление нового ресурса потребует от нас помнить, что нам нужно добавить этот неиспользуемый языковой ресурс, который будет иметь то же имя строки. Вам также придется проделать в два раза больше работы при добавлении одной строки в приложение.

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


person Zoka    schedule 20.06.2016    source источник
comment
Вот почему я не люблю файлы ресурсов. От них можно получить всевозможные зависимости, которые сложно или невозможно высмеять. Это не очень полезно, потому что ваши файлы ресурсов уже созданы, но я использовал эту библиотеку, которая использует совершенно другой подход. Он даже включает параметр конфигурации для возврата ключа ресурса (который представляет собой непереведенный текст) вместо перевода для целей отладки. Или вы можете просто добавить несколько символов в перевод, чтобы проверить влияние на макет.   -  person Scott Hannen    schedule 20.06.2016
comment
Вы ищете только решения, которые можно кодировать, или вы бы также подумали о покупке программного обеспечения, которое позволяет переводчикам работать в контексте?   -  person Jenszcz    schedule 21.06.2016
comment
@Jenszcz: возможны оба пути. Я был бы признателен, если у вас есть совет по хорошему программному обеспечению для процесса перевода. Искал на старте проекта, но не нашел подходящего.   -  person Zoka    schedule 21.06.2016


Ответы (1)


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

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

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

person Jenszcz    schedule 22.06.2016
comment
Спасибо @Jenszcz: это не ответ (вопрос был другим), но похоже, что это решение проблемы, причем совсем по-другому. Что мне не нравится, так это загадочность на связанной странице, а также ваша, я ничего не могу сказать о стоимости ... - это, по крайней мере, подозрительно :-). Но я посмотрю на страницу, на которую вы указали ссылку, чтобы узнать больше. - person Zoka; 22.06.2016
comment
@Zoka, я нахожусь в техническом положении и не имею ничего общего с покупками, бюджетами и т. Д.: Вот почему я ничего не могу сказать о стоимости. Я думаю, что у разработчиков Rigi нет модели с фиксированной ценой. - person Jenszcz; 22.06.2016