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

В моем офисе у нас были давние дебаты о локализации/глобализации и о том, как с этим справиться. Одна сторона настаивает на маршруте файла ресурсов (.resx), встроенном в ASP.NET, другая сторона настаивает на решении, управляемом базой данных. Третья группа верит в развертывание индивидуального решения.

Конечно, у каждого метода есть свои уникальные преимущества и недостатки, и мы обсуждали их снова и снова, так и не придя к реальному консенсусу.

Итак, я представляю сообществу: по вашему опыту, какой метод обеспечивает наилучшее сочетание следующего по мере роста приложения:

  1. Ремонтопригодность
  2. Расширяемость
  3. Производительность/масштабируемость

Помимо просто советов, нас также интересуют любые проекты с открытым исходным кодом, которые также могут помочь упростить вопрос. Спасибо!


person trelston    schedule 16.10.2011    source источник


Ответы (5)


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

Поставщик ресурсов локализации на основе данных

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

Он также очень хорошо резюмирует проблемы здесь Наша работа!)

Resx или не Resx

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

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

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

Resx работает достаточно хорошо, но не очень гибок, когда дело доходит до фактического редактирования ресурсов. Поддержка инструментов в Visual Studio совершенно недостаточна для поддержки локализации, потому что VS не предоставляет простой способ перекрестной ссылки на ресурсы в разных локалях. И хотя редактор дизайна ASP.NET может помочь с созданием ресурсов изначально для всех элементов управления на странице — с помощью инструмента «Создать локальные ресурсы» — он работает только с данными в файле Invariant Culture Resx по умолчанию.

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

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

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

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

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

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

person Luke Baughan    schedule 17.04.2013

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

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

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

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

person Paweł Dyda    schedule 16.10.2011
comment
Здравствуйте Павел, спасибо за ответ. Ресурсы являются отраслевым стандартом, и мы считаем, что нам придется создать несколько административных страниц для пользователей, если мы будем использовать базу данных. У нас все еще есть дебаты, но я думаю, что ресурсы побеждают. - person trelston; 17.10.2011
comment
Есть еще одна веская причина избегать динамической локализации: поддержка. Если вам необходимо поддержать приложение, согласованный всеми перевод (даже если он немного неверен, и я видел много таких случаев) является ключом к обеспечению эффективной поддержки. - person Andrea Raimondi; 28.04.2018

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

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

person Mohamed Abed    schedule 16.10.2011
comment
Одна колонка для каждого языка — НЕ лучший вариант. Что если вам нужно добавить еще один язык? Родительская таблица с именем ресурса и дочерняя таблица со строкой для каждого ресурса/языка. Трансляция для 5 языков означает 5 строк в дочерней таблице. Это больно делать в Management Studio. Вам нужна утилита, чтобы сделать это проще. - person Tiago Freitas Leal; 04.05.2018

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

person Clyde    schedule 17.04.2013

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

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

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

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

person Nils    schedule 22.02.2016