Каковы преимущества использования локализации .resx для приложения ASP.NET MVC?
-
03-07-2019 - |
Вопрос
На этом сайте есть ряд вопросов, связанных с как получить доступ файлы RESX в приложении ASP.NET MVC и лучшие практики их использования.
Однако после прочтения (добавим, впервые) Статья MSDN о ресурсах Мне остается задаться вопросом, есть ли какие-либо преимущества в использовании файлов RESX, поскольку я не собираюсь использовать элементы управления сервером.Есть все эти разговоры о «неявной» и «явной» локализации, но с MVC я не собираюсь получать от этого никакой пользы.
В конечном итоге моему приложению потребуются строковые ресурсы для кнопок и пунктов меню, а также гораздо более длинные элементы HTML для более длинного различного контента.Я хотел бы использовать CMS для более длинных элементов, потому что я почти уверен, что не хочу вставлять их в файл RESX.
Существуют ли какие-либо веские причины использовать или не использовать ресурсы ASP.NET в новый приложение.Я предполагаю, что любые будущие улучшения MVC или RESX будут гармонично работать вместе, но сейчас я просто получаю прославленный IDictionary, насколько я могу судить.
Должен ли я продолжить работу с RESX или поискать другое место?Стоит ли мне вообще рассматривать CMS для тех ресурсов, для которых предназначен RESX?
Любые извлеченные уроки будут оценены по достоинству.
Решение
Инфраструктура RESX имеет несколько преимуществ:
- вам не нужно загружать соответствующие ресурсы для каждого языка.Как только локаль потока установлена, CLr позаботится о поиске соответствующей сборки и загрузке ресурсов.
- легко передать ресурсы, специфичные для локали, для локализации третьим лицам.
- существует резервный механизм по умолчанию для нелокализованных ресурсов.
У подхода RESX также есть один конкретный недостаток:
- сложно поддерживать модель перевода, при которой пользователи переводят ваши ресурсы за вас.
Я хотел бы немного остановиться на последнем пункте.Возьмем, к примеру, модель перевода Facebook.Facebook предлагает довольно простой способ предоставления людям переводов различных ресурсов и голосования за них.Если они хранятся в базе данных, их можно будет использовать после надлежащего процесса редактирования без пересборки и повторного развертывания приложения.При использовании модели RESX сборки ресурсов придется перестраивать и перераспределять, что может иметь достаточно высокую стоимость в зависимости от процесса развертывания.
Таким образом, прежде чем решить, какой процесс локализации использовать, я бы рассмотрел решение о том, кто будет выполнять локализацию и каким будет процесс развертывания локализованных ресурсов после того, как основное приложение уже развернуто.
РЕДАКТИРОВАТЬ: Я забыл упомянуть, что эти соображения ортогональны выбору платформы ASP.NET (MVC или WebForms).
Другие советы
Я бы сказал «да», файлы resx по-прежнему являются хорошим вариантом для новых приложений.Я не думаю, что ASP.NET MVC что-то особенно меняет в хранении ваших строк.
Что хорошо в использовании ресурсов, так это
- ими довольно легко управлять
- локализовать свой сайт гораздо проще, чем без ресурсов (подчеркиваю, много Полегче)
- вы можете заменить хранилище ресурсов в любое время, поскольку ресурсы используют модель поставщика.Вы можете отключить файлы resx для записей базы данных, не меняя реализацию вашего сайта.
Я рекомендую файлы ресурсов для «строк сайта», которые отличаются от больших блоков данных, которые вы можете часто редактировать.Итак, в качестве полной рекомендации я бы посоветовал использовать файлы ресурсов (resx для запуска) для кнопок, меток и т. д., а также CMS для более подробного контента.
Если вы собираетесь использовать Resx, а не элементы управления сервером, как в MVC, почему бы не расширить методы MVC Helper, чтобы вы могли создавать локализованные метки и текст?Затем просто вызовите текст из ресурса во вспомогательном методе.
например'<%=Html.CultureLabel("ResouceId") %>'
или '< %= html.culturebutton ("имя", "resouceid", htmlbuttontype.button) %>'
Просто мысль.
Кроме того, управлять глобализацией сайта НАМНОГО проще с помощью resx для текста.