Локализация динамического пользовательского контента. Мнения об этих двух вариантах?

Question

Локализация динамического пользовательского контента. Мнения об этих двух вариантах?

Я создаю веб-сайт, который позволит людям создавать контент и оставлять комментарии к контенту.

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

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

Вот два варианта, которые я задумал реализовать. И то и другое решило бы мою проблему локализации и представления пользовательского контента моим пользователям.

Вариант А:

Я хотел бы создать несколько копий всего приложения MVC3 и поместить каждую локализацию в свое собственное приложение IIS.

foobar.com
es.foobar.com
ru.foobar.com

И мне просто нужно изменить файл web.config, чтобы использовать разные базы данных для каждой локализации.

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

Если пользователь входит в foobar.com и он должен был посетить свою локализованную версию сайта, он не будет авторизован, так как это два совершенно разных приложения.
Нет унифицированных инструментов модерации. Я должен был бы войти в каждое приложение, войти, получить доступ к панели администратора и модерировать оттуда.
Сложно проталкивать изменения / обновления на все версии страницы. Я должен был бы вручную войти в каждую папку приложения IIS и скопировать опубликованные файлы для каждой локализованной версии.

Вариант Б:

Я хотел бы создать одно приложение MVC3 и в базе данных базы данных создать несколько полей для каждой локализации.

Например:

Car
------
CarID
Name
esName
ruName
Make
esMake
ruMake
..and so on..

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

foobar.com
es.foobar.com
ru.foobar.com

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

Буду признателен за некоторые предложения о том, как реализовать локализацию для пользовательского контента в приложении MVC3.

То есть пользователь посещает испанскую версию (es.foobar.com) будет видеть другой испанский контент и комментарии, сделанные пользователями, а не другие версии. Я не имею в виду перевод их контента и представление его конечному пользователю.

0

c# asp.net-mvc-3 localization user-generated-content

Источник

user699978 30 июн '12 в 21:10

3 ответа

Другие вопросы по тегам c# asp.net-mvc-3 localization user-generated-content

user607163 02 июл '12 в 13:37 2012-07-02 13:37 · Answer 1 · 2012-07-02 13:37

Другим вариантом было бы иметь одно приложение MVC, локализованное обычным способом и с переключателем языка (который можно вызвать с помощью маршрутизации URL, например, es.foobar.com установил бы язык на "es", или через accept-languages заголовок или через селектор пользовательского интерфейса).

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

Например:

Car
----------
CarID
LanguageID
Name
Make

user7720 02 июл '12 в 13:59 2012-07-02 13:59 · Answer 2 · 2012-07-02 13:59

Я думаю, что вы могли бы сделать это:

Сделайте только один сайт MVC3 (один сайт IIS)
Используйте.rsx для статического контента, меняющего язык как обычно
База данных локализации: одна на язык.
Если вам нужна база данных для других вещей, которые не являются локализацией, это должна быть отдельная база данных (не одна на язык)
Как только пользователь заходит на локализованный сайт, вы используете соответствующую строку подключения

МИНУСЫ:

Вам нужно будет запускать обновления баз во всех базах

user443927 30 июн '12 в 22:21 2012-06-30 22:21 · Answer 3 · 2012-06-30 22:21

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

CarId | Name | Make
123   | 0099 | 0100

Тогда есть таблица, которая содержит локализованные строки.

TextId | Lang | String
0099   | en   | "Escape"
0099   | ru   | "Russian Name"
0100   | en   | "Ford"
0100   | ru   | "Russian Ford"

В таблице локализованных строк создайте составной первичный ключ для TextId и Lang. Таким образом, ваши таблицы доменов / данных остаются простыми, и при выборе данных вы можете просто присоединиться к таблице локализованных строк. Есть смысл? Я мог бы написать быстрый SQL-запрос, чтобы дать вам идею, если вам это нужно.

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

Erick