#c# #asp.net #localization
#c# #asp.net #локализация
Вопрос:
Я ищу лучшее решение, позволяющее легко добавлять новые языки в asp.net веб-сайт без развертывания / сборки существующей базы кода.
Из того, что я исследовал, кажется, что вы можете скомпилировать файлы ресурсов «на лету» в вспомогательные сборки, но я не уверен, как заставить приложение использовать эти DLL после создания?
Другой вариант, который я видел, заключается в сохранении переводов в базе данных и написании пользовательского ресурсоснабжающего устройства, чтобы можно было использовать встроенные методы локализации, абстрагируя фактическую реализацию (в данном случае базу данных).
В любом случае, интерфейс для этого сайта будет таким же (meta:resourcekey для элементов управления и т.д.).
Но я затрудняюсь решить, какой подход будет проще всего поддерживать. Например, перезапускает ли публикация новой вспомогательной сборки пул приложений или все работает нормально?
Редактировать
Переводы будут предоставляться сторонним API, поэтому качество обслуживания персоналом не важно. Я подумал, что добавлю это из-за полученных ответов.
Ответ №1:
С Asp.Net (в настоящее время) вам не нужно компилировать самостоятельно, вы можете просто развернуть файлы resx (в App_LocalResources или App_GlobalResources папку) и Asp.Net позаботится о компиляции их в вспомогательные сборки. Это круто.
При подходе к базе данных вы рискуете столкнуться с проблемами синхронизации: как вы узнаете, переведена ли данная строка ресурса? Кроме того, исправить их не очень просто (для переводчиков / инженеров по локализации). И вам все равно нужно было бы подготовить скрипт «install». Если это то, что вы собираетесь предоставить переводчикам, удачи. Вы столкнулись бы с множеством чрезмерных переводов, и вам пришлось бы исправлять их (вручную?).
Файлы Resx (являющиеся простым XML) немного проще проверять (это либо допустимый XML с точки зрения заданного XSD, либо нет). Кроме того, это стандартная технология, вам не нужно будет ничего внедрять самостоятельно. Вот почему я бы рекомендовал это.
Редактировать
Другой проблемой с ресурсами, управляемыми базой данных, может быть кодировка символов. Вам нужно будет создать свой собственный набор переводов. По моему опыту, результат может быть в нескольких разных кодировках. Особенно, если вы хотите использовать обычный текстовый файл. С другой стороны, кодировкой XML-файлов по умолчанию является UTF-8…
Комментарии:
1. Итак, я удаляю .resx в папку, и приложение подберет язык, не вызывая никакого другого эффекта, кроме добавления языка? Я этого не знал, звучит как серьезный претендент…..
2. Честно говоря, я не уверен, что это так. Может потребоваться перезапуск сервера (но, как я уже сказал, я не уверен в этом).
3. Мне действительно нравится простота этого. Я посмотрю, будут ли файлы .resx подобраны автоматически. Если нет, моим следующим шагом будет перезапуск / запуск перезапуска пула приложений из ASP.Net (В идеале я хотел бы, чтобы все это было автоматизировано).
4. Этот метод работает нормально. Приложение получило файл ресурсов, хотя пул приложений перезапускается, я могу справиться с такой проблемой для такого простого решения.
Ответ №2:
RESX
Имея более 30 языков в mit Windows Forms и приложении Web Forms (этот, если мне будет разрешено разместить ссылку), я, наконец, добился наибольшего успеха с простыми файлами RESX в App_LocalResources .
Однако я обнаружил, что компиляция была чрезвычайно медленной в VS.NET то же самое сделал немного измененный подход:
- Иметь только файлы RESX на английском языке в VS.NET решение.
- Иметь теневую структуру веб-сайта с только
App_LocalResourcesдля всех языков, включая английский, в отдельной папке, не видимой для VS.NET . - Напишите простой CMD-скрипт для копирования реальных ресурсов на английском языке в отдельную папку.
- Используйте мой бесплатный инструмент Zeta Resource Editor, чтобы фактически перевести внутри отдельной папки.
- Есть скрипт публикации, который копирует реальные веб-файлы (такие как ASPX, ASAX, MASTER и т.д.) На веб-сайт, А также копирует ресурсы на веб-сайты.
Такой подход делает компиляцию действительно быстрой и по-прежнему позволяет мне разделять компиляцию и переводы.
Недостатком является то, что первый вызов веб-приложения в реальном времени компилируется довольно долго, до сих пор я не нашел способа ускорить это / предварительно скомпилировать (хотя я верю, что это возможно).
База данных
Я также выполнил несколько проектов с локализацией в базе данных и пользовательских <%#...%> блоках для загрузки языков.
Сегодня я бы проголосовал против этого, поскольку это нестандартно. Хотя компиляция, вероятно, была бы такой же быстрой, независимо от того, задействован 1 или 50 языков.
сторонние инструменты
Вы также могли бы использовать коммерческий продукт для выполнения перевода, если бы я мог себе это позволить, я бы, скорее всего, тоже это сделал.
Только мои два цента…