Многоязычное приложение MVC 4

Ответ 1

Я написал сообщение в блоге, используя следующий аспект многоязычного приложения asp.net mvc:

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

Маршруты URL: Я обычно поддерживаю культуру в URL-адресе таким образом, что вы получаете хорошо проиндексированный сайт ML.

routes.MapRoute(
  name: "ML",
  url: "{lang}/{controller}/{action}/{id}",
  defaults: new { lang = "en-CA", controller = "Home", action = "Index", id = UrlParameter.Optional }
);

Из класса базового контроллера вы можете сделать эти параметры {lang} доступными для вашего контроллера. Подробнее см. В блоге.

Запрос ваших данных:. Вы просто передадите Культуру в свой репозиторий или контекст базы данных. Идея состоит в том, чтобы создать модель представления, которая объединит две таблицы, которые вы разделили для перевода.

public ActionResult Index(string id)
{
    var vm = pages.Get(id, Language); // Language is the {lang} from the route
    return View(vm);
}

Ваши представления: Используйте файл .NET Resources с общим двухбуквенным кодом языка, например: HomePage.en.resx, HomePage.fr.resx. Локаль en * -US *, en * -CA * полезен для форматирования валюты, дат, чисел и т.д. Ваш файл ресурсов, скорее всего, будет одинаковым для английского языка США, Канады и т.д.

Изображения: Используйте формат, например imagename-en.png, imagename-fr.png. Из вашего представления сделайте параметр маршрута {lang} доступным с помощью метода расширения и отобразите ваши изображения следующим образом:

<img src="/content/logos/[email protected]()" />

У вас также может быть полная отдельная папка для вашего языка. Пример:/content/en/imagename.png,/content/fr/imagename.png.

JavaScript:. Обычно я создаю имя папки LanguagePacks и JS файлов Lang-en.js, Lang-fr.js. Идея заключается в создании "статического" класса, который вы можете использовать во всех своих JS файлах:

// lang-en.js
var Lang = {
  globalDateFormat = 'mm-dd-yy';
  greeting: 'Hello'  
};

В ваших представлениях вы загружаете правильный языковой файл

<script type="text/javascript" src="/content/js/languagepacks/[email protected](this.CurrentLanguage()).js"></script>

Из модуля JavaScript

// UI Module
var UI = function() {

  function notify() {
    alert(Lang.greeting);
  }
  return {
    notify: notify
  }
};

Нет никакого способа сделать многоязычное веб-приложение. Используйте ресурсы для перевода текста, они могут быть быстро заменены во время выполнения. У вас есть несколько редакторов, которые могут открывать те, которые вы можете передать переводчику и т.д.

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

Ответ 2

У меня есть подход для себя на основе db, однако он может не подходить для приложений большого масштаба.

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

Итак, всякий раз, когда я хочу визуализировать представление, сначала я извлекаю соответствующий перевод из db, а затем передаю его в представление как модель:

var t = dbCtx.Translations.Find(langID);
// ...
return View(t);

И в представлении я представляю содержимое следующим образом:

<tr>
    <td>@Html.DisplayFor(m => m.WelcomeMessage)</td>
    <td>@Url.Action(Model.EnterSite, "Index", "Home")</td>
</tr>

И о получении соответствующего ответа, ну, у вас есть несколько способов. Вы можете использовать сеанс:

Session["Lang"] = "en";
// ...
var lang = (string)Session["Lang"] ?? "en";

Или путем передачи его через строку запроса или их комбинацию.

Для автоматического определения языка вы должны решить следующее:

a) Обнаружение из браузера

b) Обнаружение из пользовательского IP и угадывание геолокации его/нее и установка соответствующего языка для него/нее

Ответ 3

У меня есть ощущение, что у этого вопроса нет прямого ответа. Для форматирования и того, что вы не должны всегда использовать Culture и UICulture такие вещи, как "en-GB" для британского английского и "en-US" для американского английского (да, есть разница). Все .Net построено вокруг него, и таким образом вы можете использовать локальное форматирование, не думая об этом.

Вы также можете проверить пространство имен System.Globalization для получения дополнительной информации: http://msdn.microsoft.com/en-us/library/system.globalization%28v=vs.110%29.aspx

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

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

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

В действительности это действительно зависит от проекта. вам просто нужно сделать свои собственные плюсы и минусы и решить для себя... извините. Но если это вообще поможет, я могу рассказать вам, как обстоят дела в моей компании. Мы делаем несколько приложений, которые используют одни и те же фразы в разных веб-приложениях. Раньше у нас это было в БД, но произошло то, что переводы продолжали идти массивом, то есть клиент попросил улучшить перевод на испанском языке для одного приложения, но это не имело никакого смысла, что когда-либо было на других. Это произошло больше, чем вы могли подумать. Затем мы перешли к ресурсам, но произошло то, что когда обновление одного приложения было обновлено, никто не помнил, чтобы обновлять другие приложения, и на самом деле случилось, что 3 разных приложения перевели один и тот же термин тремя разными способами. В конце концов мы решили вернуться к БД, потому что способность менять все переводы сразу означала для нас больше, а то, что внешнее влияние не могло повлиять на нее.

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

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

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

Ответ 4

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

Но я решил пойти с решением Майкла Чамбо, которое вы связали в своем вопросе. Причин для этого было то, что его было легко реализовать, дал мне url, который я хотел, и так как я все еще не уверен на 100%... легко заменить в будущем.

В дополнение к этому я буду использовать jquery globalize для форматирования на стороне клиента.

Было бы действительно интересно узнать, какое решение вы решили?