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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вам следует использовать расширение Microsoft MAT (Multilingual App Toolkit) для Visual Studio.

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

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

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

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

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

Для начала:

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», дважды щелкните по нему, он откроется в Multilingual Editor. (если не щелкнуть правой кнопкой мыши и изменить значение по умолчанию "Открыть с помощью" на многоязычный редактор)

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

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

Где взять:

• обратная связь: https://multilingualapptoolkit.uservoice.com/
• расширение Visual Studio: https://marketplace.visualstudio.com/items?itemName=MultilingualAppToolkit.MultilingualAppToolkit-18308
• база знаний: https://multilingualapptoolkit.uservoice.com/knowledgebase
• github Кэмерона (Microsoft), который управляет этим проектом: https://github.com/TheMATDude

Вот мой взгляд на файлы ресурсов:

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

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

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

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