Когда я начал локализовать веб-сайт в первый раз, когда я просто сделал локализацию как это:
<%= Resources.ResourceFile.ResourceName %>
и это, кажется, работает превосходное. Однако бета ReSharper 5.0 делает это как это:
<asp:Localize Text="<%$ Resources: ResourceFile, ResourceName %>" runat="server">
Value
</asp:Localize>
Это имеет значение, какой путь это сделано?
Кроме того, почему ReSharper держит оригинальный текст внутри локализовать управление? Я думал, что это было там в случае, если Значение в Файле ресурсов было пусто, это могло показать текст "по умолчанию". Это, кажется, не имеет место. Действительно ли безопасно удалить его, и просто сам закрывают локализовать управление?
ну, вы не можете использовать тег сервера <% =%> на серверном элементе управления asp.
, поэтому
<asp:Localize Text="<%= Resources.ResourceFile.ResourceName %>" runat="server">
Value
</asp:Localize>
приведет к ошибке компиляции.
К сожалению, вы не можете передавать динамические данные в свойства серверного элемента управления, если это не привязка к данным, в которой вы можете применить серверный тег <% #%>
, например:
<asp:Repeater runat="server">
...
<asp:Localize Text="<%# Resources.ResourceFile.ResourceName %>" runat="server">
Value
</asp:Localize>
...
</asp:Repeater>
Вы всегда можете переместить это в программный код, но это отстой .
<% $%>
«вещь» работает, однако, если вы пройдете мимо нее, приготовьтесь войти в аду техобслуживания (если, конечно, мы не говорим о трехстраничном приложении ...)
Лично Я использую <% =%>
и никогда не использую re-sharper для глобализации / локализации своих приложений.
Кроме того, я никогда не использовал серверный элемент управления
, и у меня не было проблем ...
Первый подход создает отдельный Rsource файл для каждой страницы (модуля), а второй подход создает один (или несколько) и помещает все resourcekeys на него.
Второй подход позволит вам легко создавать новые языки для вашего приложения, потому что все строки собраны в одном месте, и вы можете отдать их кому угодно для перевода.
Следующую информацию я нашел на msdn, которая может помочь вам понять разницу, которую вы хотите
Для получения глобальных ресурсов с использованием сильной типизации
Resources.ResourceFile.ResourceName используется для получения глобальных ресурсов с использованием сильной типизации
Ресурсы компилируются в пространство имен Resources, и каждый ресурс по умолчанию становится членом класса Resources. Например, если вы создали файл ресурсов по умолчанию WebResources.resx и файл содержит ресурс с именем WelcomeText, вы можете ссылаться на этот ресурс в коде, как показано в следующем коде
String welcome; welcome = Resources.WebResources.WelcomeText;
подробнее : http://msdn.microsoft.com/en-us/library/ms227982.aspx
Явная локализация
<asp:Button ID="Button1" runat="server"
Text="<%$ Resources:WebResources, Button1
Caption %>
Выражение ресурса принимает следующую форму, где Class является необязательным, если только ресурс не является глобальным, а ResourceID является обязательным:
Значение Class определяет файл ресурса, который следует использовать при использовании глобальных ресурсов. Когда компилируются файлы .resx, имя базового файла без расширений используется в качестве имени класса результирующей сборки в явном виде. Если вы хотите использовать ресурсы из локального файла ресурсов (тот, который соответствует имени текущей страницы), вам не нужно включать имя класса. Это происходит потому, что ASP.NET сопоставляет класс страницы с классом ресурса.
Значение ResourceID - это идентификатор ресурса для чтения. В предыдущем примере свойство Text для кнопки считывается из файла глобального ресурса WebResources.resx (или соответствующей локализованной версии). В этом файле ASP.NET использует значение для ресурса с идентификатором Button1Caption и для самой страницы. Для задания свойств страницы можно использовать выражения ресурсов в директиве @ Page
подробнее об этом : http://msdn.microsoft.com/en-us/library/ms227427(v=VS.100).aspx
Ага, разница есть, и дело во времени.
Я не подтверждал это, но я действительно ожидал, что <% $ произойдет намного раньше в жизненном цикле страницы.