Подтвердить что ты не робот

Есть ли проблемы с производительностью или оговорки с файлами ресурсов (.resx)?

Файлы ресурсов кажутся отличными для локализации ярлыков и сообщений, но являются ли они идеальными?

Например:

  • Есть ли лучшее решение, если есть огромное количество ресурсов? Как 100 000 строк в файле .resx? (Теоретически, у меня на самом деле нет этой проблемы)
  • Является ли это хорошим методом для хранения других типов данных, таких как изображения, значки, аудиофайлы, обычные файлы и т.д.?
  • Лучше всего хранить ваши .resx файлы в автономном проекте для упрощения обновления/компиляции?
  • Есть ли какие-либо другие проблемы, с которыми вы столкнулись при использовании .resx файлов?
4b9b3361

Ответ 1

  1. Есть ли лучшее решение, если есть огромное количество ресурсов? Как 100 000 строк в файле .resx? (Теоретически, у меня на самом деле нет этой проблемы)

Я использовал Alfresco в качестве альтернативного репозитория контента для проектов Java. Файлы RESX с точки зрения поддержки (из-за проблем с кодировкой, которые, как я полагаю) могут действительно вонять.

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

Я видел, как он работает с изображениями... но это так. (не уверены в других носителях/файлах)

  3. Рекомендуется ли хранить ваши .resx файлы в автономном проекте для упрощения обновления/компиляции?

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

  4. Существуют ли какие-либо другие проблемы, с которыми вы столкнулись при использовании .resx файлов?

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

Ответ 2

Недавно я использовал файл .resx с 5 миллионами строк (нормальная длина, как и это предложение), скомпилированный в разных DLLS размером около 1 Он по-прежнему отлично работает в веб-проекте Azure.

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

Ответ 3

Мы использовали файлы ресурсов в относительно большом приложении .NET Windows Forms (более 500 различных форм, примерно 20 строк ресурсов для каждой формы), и у нас не было проблем с производительностью в отношении ресурсов из файлов .resx. Мы использовали Babylon.NET как инструмент для управления переводами (имеет бесплатную версию только для переводчиков). Вы не указали, будет ли ваш проект веб-или настольным приложением. Одна функциональность, которую предоставляют файлы ресурсов для настольных приложений, - это возможность локализовать позиции управления и размер, которые IMHO невозможно использовать с помощью других инструментов (если вы не используете что-то вроде управления компоновкой DevExpress, которое имеет автоматическую калибровку).

Ответ 4

У меня было две проблемы с файлами ресурсов, как о производительности переводчиков (люди), так и скорости поиска строк.

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

Поэтому они просто использовали Excel для редактирования переводов. Поэтому мы могли бы также сохранить переведенные строки как CVS файл, поэтому избегаем копировать переведенные строки в файлы ресурсов.

Необходимо создать новую сборку, чтобы нужен эффект от любых переводов.

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


Таким образом, мы могли бы использовать пользовательскую реализацию поставщика ресурсов и поддерживать стандартную систему поиска ресурсов ASP.NET. Или просто игнорируйте стандартную систему поиска ресурсов, если это не помогает в вашем случае - это зависит от того, как написаны ваши страницы.


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

Ответ 5

Для точки № 4.
Я использую файлы .resx для всех строк на нашем сайте, которые должны быть локализованы на многие языки и не имеют каких-либо серьезных проблем с ними.

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

Ответ 6

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

Когда мы вначале искали пример, мы обнаружили Создание Data Resource Provider поставщика и редактора ресурсов локализации ASP.NET.

Ответ 7

Вот мои файлы ресурсов:

  • Я бы предположил, что если есть БОЛЬШОЕ количество строк, то использование базы данных может быть лучшим методом, позволяющим осуществлять поиск и сортировку данных. Вероятно, было бы не слишком сложно учитывать несколько языков в таблице ресурсов, и скорость должна быть максимально быстрой.

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

  • Я читал в другом вопросе (не знаю), что использование файлов ресурсов во внешнем проекте является хорошей практикой, потому что вам не придется перекомпилировать весь проект при изменении ресурсов. Просто перекомпилируйте ресурсный проект. Это также позволило бы (справедливо) легко редактировать клики, где им нужен только "исходный код" для проекта ресурса, а не ваш другой реальный код (код API и т.д.).

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

Ответ 8

Никогда не возникало проблем с ресурсами resx, они отлично кэшируются. Мы использовали их в WinForms, asp.net mvc, wpf и т.д....

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

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

и он работает с отраслевым стандартным форматом xlf!

Если вы зарегистрируетесь с Azure api, вы можете даже автоматически переводить ресурсы (у вас есть несколько тысяч слов без ежемесячного кредита на лазурь). См. Https://multilingualapptoolkit.uservoice.com/knowledgebase/articles/1167898-microsoft-translator-moves-to-the-azure-portal

вы даже можете увидеть, сколько работы уже сделано в проекте:

enter image description here

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

enter image description here

Для начала:

  1. установить расширение MAT Visual Studio
  2. Перейдите в свой проект в Visual Studio
  3. Нажмите "Свойства" → "Открыть AssemblyInfo.cs".
  4. Добавьте этот атрибут: [сборка: System.Resources.NeutralResourcesLanguage("en")]
  5. Выберите свой проект в обозревателе решений и в Visual Studio, чтобы [Инструменты] → [Многоязычный набор приложений] → [Включить выбор]
  6. Это добавит новую папку "MultilingualResources" в ваш проект
  7. Щелкните правой кнопкой мыши ваш проект → [Многоязычный набор инструментов для приложений] → [Добавить языки перевода...] → выберите язык, который вы хотите перевести (например, голландский).
  8. В папке "MultilingualResources" вы увидите новый файл ".... nl.xlf", дважды щелкните его, он откроется с помощью многоязычного редактора. (если не щелкните правой кнопкой мыши и измените значение по умолчанию "Открыть с" в многоязычном редакторе)

Теперь вы добавляете строки только к файлу Resources.resx по умолчанию (язык должен быть таким же, как и "NeutralResourcesLanguage", который вы добавили в AssemblyInfo.cs. Для переводов вы НЕ добавляете строки в файлы... nl.resx, вы работаете с файлы.xlf, расположенные в папке MultiLingualResources.

(после того, как вы сделали много переводов, может потребоваться перестройка, чтобы переведенные файлы.xlf обновили переведенные файлы.resx)

Где это получить: