.resx против базы данных и настраиваемого решения для обеспечения локализации/глобализации

Ответ 1

Rick Strahl (MS MVP) имеет отличный набор инструментов для управления локализацией через БД - предлагает возможность обновлять и изменять по требованию через контролируемую среду и делает большую часть тяжелой работы для вас. Histoolkit предлагает следующие функции:

поставщик ресурсов локализации данных, управляемый данными

• Локализация, основанная на базе данных, позволяет хранить ресурсы в базе данных SQL Server.
• Интерактивный веб-ресурс Adminstration предоставляет встроенную администрацию в Интернете, которая может редактировать и обновлять ресурсы во время работы приложения.
• Управление редактированием ресурсов связывает значки с каждым локализуемым элементом управления и позволяет перейти непосредственно к форме администрирования с выбранным текущим идентификатором ресурса и локали.
• Resx Import and Export позволяет импортировать существующие ресурсы Resx, интерактивно редактировать их с помощью поставщика данных, а затем экспортировать их как ресурсы Resx.
• Утилиты локализации, такие как обработчик ресурсов JavaScript, позволяют внедрять локализованные значения script и многое другое.

Он также очень хорошо разбирается в проблемах здесь (здесь были вставлены некоторые хорошие фрагменты), а не моя собственная работа!)

В Resx или не в Resx

Механизм хранения ресурсов по умолчанию в .NET. использует ресурсы Resx. Resx относится к расширению файла XML файлы, которые служат как исходный вход для ресурсов, которые являются родными для.СЕТЬ. Хотя XML - это формат входного хранилища, который вы видите в Visual Studio и .Resx, окончательный формат ресурса является двоичным format (.Resources), который скомпилирован в сборках .NET с помощью компилятор. Эти скомпилированные ресурсы могут храниться либо вместе с кода в бинарных сборках или самостоятельно на ресурсном спутнике сборок, единственной целью которых является предоставление ресурсов. Обычно в .NET Инвариантные ресурсы культуры встроены в базу сборка с любыми другими культурами, размещенными в спутниковых сборках, хранящихся в подкаталогах, специфичных для культуры.

Если вы используете Visual Studio процесс компиляции ресурсов в значительной степени автоматичен - когда вы добавить файл .Resx в проект. VS.NET автоматически компилирует ресурсов и встраивает их в сборки и создает спутник сборок вместе с необходимой структурой каталогов для каждой из поддерживаемых локалей. ASP.NET 2.0 расширяет этот базовый процесс автоматизация модели обслуживания ресурсов и автоматическая компиляция Ресурсы Resx, которые находятся в App_GlobalResources и App_LocalResources и сделать их доступными для приложения с помощью Поставщик ресурсов, специфичный для ASP.NET. Поставщик ресурсов упрощает и упрощает доступ к ресурсам изнутри ASP.NET Программы.

Сама среда .NET использует ресурсы .Resx для обслуживания поэтому представляется естественным, что инструменты framework предоставляет инструменты для создания ресурсов для обслуживания эта же модель.

Resx работает достаточно хорошо, но его не очень гибкий когда дело доходит до фактического редактирования ресурсов. Поддержка инструмента в Visual Studio действительно неадекватна для поддержки локализации потому что VS не обеспечивает простой способ перекрестных справочных ресурсов через несколько локалей. И хотя редактор проектов ASP.NET может помочь с генерированием ресурсов изначально для всех элементов управления на странице - через Generate Local Resources Tool - он работает только с данными в файл переменной Invariant Culture Resx.

Ресурсы Resx также являются статическими - они все собраны в сборку. Если вы хотите сделать изменения ресурсов, которые вам нужно будет перекомпилировать, чтобы увидеть эти изменения. ASP.NET 2.0 представляет глобальные и локальные ресурсы, которые можно хранить на сервере и может обновляться динамически - компилятор ASP.NET могут фактически скомпилировать их во время выполнения. Однако, если вы используете прекомпилированная модель развертывания в Интернете, ресурсы по-прежнему в конечном итоге статические и не могут быть изменены во время выполнения. Итак, как только вы закончите с компиляция ресурсов исправлена.

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

Использование ресурсов базы данных

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

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

Хорошей новостью является то, что схемы ресурсов в .NET не фиксированы, и вы можете их расширить..NET и ASP.NET 2.0 позволяют вам создавать собственные диспетчеры ресурсов (основная среда выполнения .NET) и ресурс провайдеров (ASP.NET 2.0) для обслуживания ресурсов из любого места, включая базы данных.

Ответ 2

Как вы, возможно, знаете, метод по умолчанию (который на самом деле является лучшей в отрасли) для локализации приложений .Net использует файлы ресурсов (в этом случае -.resx). Если вы хотите использовать базу данных, вам придется написать свой собственный ResourceManager.

Отсюда следует, что ответ должен быть очевиден: используйте стандарт и не изобретайте велосипед повторно.

Возможно, вам интересно, почему локализация через файлы ресурсов стала стандартом всей отрасли. Ну, есть много причин (слишком много, чтобы упомянуть здесь), большинство из них относится к процессу локализации. Ключевым является то, что очень сложно обновить (то есть исправить или установить) переводы для локализации базы данных. Подумайте, что вам нужно для его установки - некоторые SQL script. Вы знаете, что произойдет, если вы отправите это для перевода? Или даже ошибочно обновить его? Эти файлы не очень безопасны для работы (и они имеют тенденцию быть очень большими), поэтому либо вам нужно будет создать какой-то генератор (с ресурсоподобным файлом в качестве ввода, который полностью разрядит цель...), или вам нужно быть очень осторожным (и молиться, чтобы переводчик не нарушил файл).

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

Ответ 3

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

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

Ответ 4

Использование resx - лучший подход для некоторых статических значений, которые не нужно манипулировать с помощью пользовательского интерфейса приложения, но если ваши значения должны быть обновлены, управляемый БД был бы лучшим для него. Для меня это еще один случай к делу. Но один из блогов, которые я видел в Интернете, сделал файлы resx обновляемыми через пользовательский интерфейс. http://sandblogaspnet.blogspot.com/2009/11/updating-resource-file.html.. надеюсь, это поможет вам.

Ответ 5

Как и все вышеизложенное, я хочу добавить дополнительные сведения.

Я стараюсь использовать локализацию на основе .resx при работе над проектами " статические", такими как панели мониторинга или другие небольшие веб-сайты, которые ориентированы на определенную группу пользователей.

При работе с более крупными и более " динамическими" проектами, такими как магазины, сервисные предложения и т.д. (особенно при локализации контента - не только для меток) Мне нравится использовать локализацию базы данных.

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