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

Question

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

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

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

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

Вариант А:

---

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

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

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

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

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

• Нет унифицированных средств модерации. Я должен был бы войти в каждое приложение, войти в систему, получить доступ к панели администратора и умерить оттуда.

• Затрудняюсь сменить изменения/обновления для всех версий страницы. Мне пришлось бы вручную перейти в каждую папку приложения IIS и скопировать опубликованные файлы для каждой локализованной версии.

Вариант B:

---

Я хотел бы создать единое приложение 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), увидит другие испанский контент и комментарии, сделанные пользователями, и не другие версии. I не означает перевод их содержимого и предоставление его конечному пользователю.

Answer 1

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

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

Answer 2

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

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

Например:

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

Answer 3

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

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

МИНУСЫ:

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