Asp.net Mvc, бритва и локализация - PullRequest
17 голосов
/ 18 марта 2011

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

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

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

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

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

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

Плюсы:

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

Минусы:

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

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

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

Плюсы:

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

Минусы:

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

Локализованные виды

Плюсы:

  • Все представления являются обычными HTML. Нет ресурсов для чтения.

Минусы:

  • Повсюду дублируется HTML. Мне даже не нужно объяснять, как это полностью зло.
  • Приходится вручную кодировать все неприятные символы, такие как могильные гласные, кавычки и т. Д.

Выводы

Смесь вышеперечисленных технек унаследовала плюсы и минусы, но все равно ничего хорошего. Передо мной стоит задача найти правильное продуктивное решение, хотя все вышеперечисленное считается «непрактичным» и «трудоемким».

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

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

Ответы [ 3 ]

7 голосов
/ 18 марта 2011

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


Опция Sexier:

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

EDIT

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

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

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

РЕДАКТИРОВАТЬ # 3 - Пример помощника HTML

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 голосов
/ 18 марта 2011

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

0 голосов
/ 18 марта 2011

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...