Asp.net Mvc, Razor и локализация

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

Локализация в .net и в mvc выполняется двумя способами, которые могут быть даже смешаны:

Файлы ресурсов (локальные или глобальные)
Локализованные представления с возможностью просмотра соответствующего представления на основе культуры

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

Текст в файлах ресурсов, все теги в представлении

В этом решении я бы разместил каждый текст в ресурсах и каждый тег в представлении, даже встроенные теги, такие как [strong] или [span].

Плюсы:

Чистое разделение, без какой бы то ни было структуры в локализации.
Простая кодировка: все, что возвращается с ресурса, получает html-кодировку.

Минусы:

Если у меня есть параграф с некоторыми сильными сторонами, несколько ссылок и т.д., я должен разбить его во многих ключах ресурсов. Считается, что это слишком непроницаемое представление, а также слишком много времени для его создания.
По той же причине, что и выше, если на двух разных языках [сильный] текст находится в разных местах (например, "Il cane di Marco" и "Marcos собака" ), Я не могу этого достичь, поскольку все мои теги находятся в представлении.

Текстовые и встроенные теги в файлах ресурсов через параметры

Этот метод будет содержать ресурсы, содержащие некоторые заполнители для string.Format, и те заполнители будут заполнены встроенными тегами post-encoding.

Плюсы:

Чистое разделение с просто заполнителями в тексте, поэтому, если я когда-либо заменю [strong] на [em], я делаю это в представлении, где передаю его как параметр, и он изменяется на каждом языке.

Минусы:

Кодирование немного сложнее, мне нужно предварительно кодировать значение из ресурса, а затем использовать string.Format и, наконец, вернуть его как MvcHtmlString, чтобы заставить движок просмотра не перекодировать его при показе.
По той же причине, что и выше, включая, например, параметр ActionLink в качестве параметра. Скажем, я получаю текст для моего actionlink с ресурса. Мой метод уже кодирует его. Но тогда метод ActionLink снова перекодирует его. Мне нужен отдельный метод для получения ресурсов без их кодирования или новых вспомогательных методов, которые получают MvcHtmlString вместо строки в качестве текстового параметра, но оба они довольно непрактичны.
Все еще занимает много времени, чтобы создавать представления, создавать все ключи ресурсов и затем заполнять их.

Локализованные представления

Плюсы:

Все представления - это простой html. Нет ресурсов для чтения.

Минусы:

Дублированный html везде. Мне даже не нужно объяснять, как это совершенно зло.
Необходимо вручную кодировать все неприятные символы, такие как серьезные гласные, цитаты и т.д.

Выводы

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

Чтобы все ухудшилось, я обнаружил, что нет ни одного инструмента, который рефакторирует "текст" из представлений/страниц aspx или cshtml (или даже html) в ресурсы. Все инструменты там могут реорганизовать экземпляры System.String в файлах кода (.cs или .vb) только в ресурсы (например, resharper и пару других, которые я не могу запомнить сейчас).

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

Ответ 1

Мне лично нравится идея сохранять встроенные теги в файле ресурсов. Однако я делаю это немного иначе. Я храню очень простые теги, такие как <span class='emphasis'>dog</span>, а затем я использую CSS для правильного стиля тегов. Теперь вместо того, чтобы "пропускать" тег в качестве параметра, я просто стиль span.emphasis в моем CSS соответствующим образом. Изменение переносится на все языки.

Вариант Sexier:

Другим вариантом, о котором я подумал и которым очень нравится, является использование языка "читаемой разметки", такого как StackOverflow, самого собственного MarkdownSharp. Таким образом, вы не храните какой-либо HTML файл в файле ресурсов, а только текст разметки. Таким образом, в вашем ресурсе у вас будет **dog**, а затем он будет отключен через уценку в представлении (я создал для этого помощника (Usage: Html.Markdown(string text)). Теперь вы не храните теги, вы храните общий читаемый пользователем язык разметки. Источник markdownsharp - это один файл .CS, и его легко изменить. Таким образом, вы всегда можете изменить способ отображения конечного HTML. Это дает вам полный контроль над всеми вашими ресурсами без хранения HTML и без дублирования представлений или куски HTML.

ИЗМЕНИТЬ

Это также дает вам контроль над кодировкой. Вы можете легко убедиться, что содержимое ваших файлов ресурсов не содержит допустимого HTML. Синтаксис Markdown (как вы знаете из-за использования) не содержит тегов HTML и, следовательно, может быть закодирован без вреда. Затем вы просто используете свой помощник для преобразования синтаксиса Markdown в действительный HTML.

РЕДАКТИРОВАТЬ № 2

Есть одна ошибка в уценке, которую я должен был исправить. Любое обнаружение уценки должно быть отображено, поскольку блок "code" будет закодирован в HTML. Это проблема, если вы уже кодировали HTML весь контент, передаваемый в уценку, поскольку что-либо в кодовых блоках будет по существу перекодировано, что превращает > в &gt; и полностью закручивает текст в блоках кода. Чтобы исправить это, я изменил файл markdown.cs, чтобы включить опцию boolean, которая останавливает уценку из текста кодирования в блоках кода. См. эту проблему для файла .cs, который был добавлен в проект MarkdownSharp.

РЕДАКТИРОВАТЬ № 3 - образец Html Helper

public static class HtmlHelpers
{
    public static MvcHtmlString Markdown(this HtmlHelper helper, string text)
    {
        var markdown = new MarkdownSharp.Markdown
        {
            AutoHyperlink = true,
            EncodeCodeBlocks = false, // This option is my custom option to stop the code block encoding problem.
            LinkEmails = true,
            EncodeProblemUrlCharacters = true
        };
        string html = markdown.Transform(markdownText);
        return MvcHtmlString.Create(html);
    }
}

Ответ 2

Ничто не мешает вам хранить HTML в файлах ресурсов, а затем вызывает @Html.Raw(MyResources.Resource).

Ответ 3

Считаете ли вы, что используете локализованные модели, ваше представление будет сильно соответствовать IMyModel, а затем передать в надлежащим образом оформленную модель, тогда вы можете использовать/изменить, как легко сделать вашу локализацию, изменив присвоенную модель.

он чистый, очень гибкий и очень прост в обслуживании.

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