Файлы ресурсов, строка. Формат и заполнители в .NET - PullRequest
3 голосов
/ 20 марта 2012

Насколько я знаю, лучший способ обработки динамических данных в локализованной строке с использованием файлов ресурсов в .NET - это иметь вашу локализованную строку в файле resources.resx с заполнителем: Lorem {0} ipsum. и в вашем коде, чтобы справиться с этим следующим образом: string.Format(Resources.My_Localized_Key, myValue);.

Мои проблемы следующие:

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

2 / Если позже, по некоторым причинам, локализованная строка изменится на Lorem {0} ipsum {1}. , как мы можем гарантировать, что все используетэта строка в приложении будет обновлена?

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

Ответы [ 2 ]

1 голос
/ 21 марта 2012

На практике, для проблемы 1 разработчики вряд ли будут повторно использовать строку без проверки ее содержимого, и если бы они это сделали, они, вероятно, заметили бы заполнитель при запуске своего кода (или QA). Так что это маловероятно и не станет концом света.

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

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

0 голосов
/ 20 марта 2012

Я думаю, что вы можете написать свой собственный инструмент для Visual Studio (http://www.codeproject.com/Articles/31257/Custom-Tools-Explained), который генерирует класс Resources из resx-файла и использует его вместо стандартного. В вашем инструменте вы можете анализировать локализованную строку, и если она имеет заполнители, тогда выможет генерировать метод вместо свойства Resources.My_Localized_Key. Метод может выглядеть как Resources.My_Localized_KeyFormat(object param) с соответствующим количеством параметров в соответствии с количеством заполнителей.

Но это всего лишь идея, и я не реализовал ее сам (но яреализовал пользовательский инструмент для генерации кода для resx-файлов, и он работает нормально).

Или вы можете использовать F #, который проверяет params для его версии string.Format во время компиляции.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...