Локализация (i18N) в мультитенантном SaaS-приложении ASP.Net

Question

Сценарий проблемы:

Реализация локализации ASP.Net в приложении на основе SaaS.

Дополнительная сложность: арендатор должен иметь возможность редактировать локализованный контент. Таким образом, если размещенное приложение имеет 10 арендаторов, каждый из которых поддерживает 5 языков, мы можем получить 50 единиц контента перевода.

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

Ниже перечислены подходы, использовавшиеся в прошлом (для других моих приложений), и почему они не актуальны сейчас:

Вариант 1: Файлы ресурсов ASP.Net

Проблема: Для каждого локализуемого ресурса создается только один языковой файл (страница ASPX). Следовательно, невозможно иметь один файл Home.aspx.resx для каждого перевода арендатора. Хотя ключи resx можно изменить, чтобы они содержали TenantId (lblFirstName_44) и сохранялись в одном и том же файле resx, но это будет трудно поддерживать, и мы можем получить большие файлы.

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

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

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

Вариант 3: Сторонние решения с открытым исходным кодом, такие как FairlyLocal

Проблема: Хотя он очень прост в реализации, он обладает тем же недостатком, что и файлы .resx, - он не предназначен для того, чтобы позволить конечному пользователю изменять содержимое и поддерживать несколько версий (для арендатора) одного и того же файла.

Примечание. В случае отсутствия другого решения, мы, вероятно, выберем вариант 2

.

Answer 1

Первый вариант (сохранение переводимых текстов в файлы ресурсов) отсутствует. Это приведет к совершенно неуправляемому беспорядку.

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

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

Answer 2

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

Меня удивляет, почему Microsoft не задумывалась над решением этой проблемы специально с помощью своей инициативы Azure.

Answer 3

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

. Вы можете легко найти хорошего поставщика ресурсов, такого как westwind one, или написать собственного поставщика.