Grundlegendes zur Lokalisierung in ASP.NET AJAX

Artikel
07/13/2023

Lokalisierung ist der Prozess zum Entwerfen und Integrieren der Unterstützung für eine bestimmte Sprache und Kultur in eine Anwendung oder eine Anwendungskomponente. Die Microsoft ASP.NET-Plattform bietet umfassende Unterstützung für die Lokalisierung von Standardanwendungen ASP.NET durch Integration des .NET-Standardlokalisierungsmodells. Das Microsoft AJAX Framework verwendet das integrierte Modell, um die verschiedenen Szenarien zu unterstützen, in denen die Lokalisierung durchgeführt werden kann.

Einführung

Die ASP.NET Technologie von Microsoft bringt ein objektorientiertes und ereignisgesteuertes Programmiermodell und vereint es mit den Vorteilen von kompiliertem Code. Das serverseitige Verarbeitungsmodell hat jedoch mehrere Nachteile, die der Technologie innewohnen, von denen viele durch die neuen Features im System.Web.Extensions-Namespace behoben werden können, der die Microsoft AJAX-Dienste im .NET Framework 3.5 kapselt. Diese Erweiterungen ermöglichen viele umfangreiche Clientfeatures, die zuvor als Teil der ASP.NET 2.0 AJAX-Erweiterungen verfügbar waren, jetzt aber Teil der Framework-Basisklassenbibliothek sind. Steuerelemente und Features in diesem Namespace umfassen das teilweise Rendern von Seiten, ohne dass eine vollständige Seitenaktualisierung erforderlich ist, die Möglichkeit, über Clientskript (einschließlich der ASP.NET-Profilerstellungs-API) auf Webdienste zuzugreifen, und eine umfangreiche clientseitige API, die zum Spiegel vieler Steuerungsschemas im ASP.NET serverseitigen Steuerelementsatz entwickelt wurde.

In diesem Whitepaper werden die Lokalisierungsfeatures im Microsoft AJAX Framework und der Microsoft AJAX-Skriptbibliothek im Kontext der geschäftlichen Anforderungen an Lokalisierungsunterstützung und die bereits integrierte Unterstützung für die Lokalisierung in Webanwendungen untersucht, die vom .NET Framework bereitgestellt werden. Die Microsoft AJAX-Skriptbibliothek verwendet das RESX-Dateiformat, das bereits von .NET-Anwendungen verwendet wird, was integrierte IDE-Unterstützung und einen freigegebenen Ressourcentyp bietet.

Dieses Whitepaper basiert auf der Beta 2-Version von Microsoft Visual Studio 2008. In diesem Whitepaper wird auch davon ausgegangen, dass Sie mit Visual Studio 2008 und nicht mit Visual Web Developer Express arbeiten und exemplarische Vorgehensweisen gemäß der Benutzeroberfläche von Visual Studio bereitstellen. Einige Codebeispiele verwenden Projektvorlagen, die in Visual Web Developer Express möglicherweise nicht verfügbar sind.

Lokalisierungsbedarf

Insbesondere für Entwickler von Unternehmensanwendungen und Komponentenentwickler ist die Fähigkeit, Tools zu erstellen, die sich der Unterschiede zwischen Kulturen und Sprachen bewusst sein können, immer notwendiger. Das Entwerfen von Komponenten mit der Fähigkeit, sich an das Gebietsschema des Clients anzupassen, erhöht die Produktivität der Entwickler und reduziert den Arbeitsaufwand, der für die Anpassung einer Komponente zur globalen Funktion erforderlich ist.

Lokalisierung ist der Prozess zum Entwerfen und Integrieren der Unterstützung für eine bestimmte Sprache und Kultur in eine Anwendung oder eine Anwendungskomponente. Die Microsoft ASP.NET-Plattform bietet umfassende Unterstützung für die Lokalisierung von Standardanwendungen ASP.NET durch Integration des .NET-Standardlokalisierungsmodells. Das Microsoft AJAX Framework verwendet das integrierte Modell, um die verschiedenen Szenarien zu unterstützen, in denen die Lokalisierung durchgeführt werden kann. Mit dem Microsoft AJAX Framework können Skripts entweder lokalisiert werden, indem sie in Satellitenassemblys bereitgestellt werden oder eine statische Dateisystemstruktur verwenden.

Einbetten von Skripts mit Satellitenassemblys

Gemäß der Standardstrategie .NET Framework Lokalisierung können Ressourcen in Satellitenassemblys eingeschlossen werden. Satellitenassemblys bieten mehrere Vorteile gegenüber der herkömmlichen Ressourceneinschluss in Binärdateien: Jede bestimmte Lokalisierung kann aktualisiert werden, ohne das größere Image zu aktualisieren, zusätzliche Lokalisierungen können einfach durch die Installation von Satellitenassemblys im Projektordner bereitgestellt werden, und Satellitenassemblys können bereitgestellt werden, ohne dass die Standard Projektassemblys neu geladen werden. Dies ist insbesondere bei ASP.NET-Projekten von Vorteil, da dadurch die Menge an Systemressourcen, die durch inkrementelle Updates genutzt werden, erheblich reduziert werden kann und die Nutzung von Produktionswebsites minimal beeinträchtigt wird.

Skripts werden in Assemblys eingebettet, indem sie in verwaltete RESX-Dateien (oder kompilierte RESSOURCEN) eingeschlossen werden, die zur Kompilierzeit in die Assembly eingeschlossen werden. Ihre Ressourcen werden dann über Attribute auf Assemblyebene für die Skriptanwendung über von DER AJAX-Runtime generierten Code zur Verfügung gestellt.

Benennungskonventionen für eingebettete Skriptdateien

Die Skriptverwaltung von Microsoft AJAX Framework unterstützt eine Vielzahl von Optionen für die Verwendung bei der Bereitstellung und zum Testen von Skripts, und es werden Richtlinien bereitgestellt, um diese Optionen zu erleichtern.

So erleichtern Sie das Debuggen:

Releaseskripts (Produktionsskripts) sollten den .debug Qualifizierer nicht im Dateinamen enthalten. Skripts, die für das Debuggen entwickelt wurden, sollten im Dateinamen enthalten .debug sein.

So erleichtern Sie die Lokalisierung:

Neutrale Kulturskripts sollten keinen Kulturbezeichner im Namen der Datei enthalten. Für Skripts, die lokalisierte Ressourcen enthalten, sollte der ISO-Sprachcode im Dateinamen angegeben werden. Steht beispielsweise es-CO für Spanisch, Kolumbien.

In der folgenden Tabelle sind die Dateibenennungskonventionen mit Beispielen zusammengefasst:

Dateiname	Bedeutung
Script.js	Ein kulturneutrales Skript der Releaseversion.
Script.debug.js	Ein kulturneutrales Skript mit Debugversion.
Script.en-US.js	Eine Releaseversion englisch, USA Skript.
Script.debug.es-CO.js	Ein Skript in der Debugversion Spanisch, Columbia.

Exemplarische Vorgehensweise: Erstellen eines lokalisierten eingebetteten Skripts

Hinweis: Diese exemplarische Vorgehensweise erfordert die Verwendung von Visual Studio 2008, da Visual Web Developer Express keine Projektvorlage für Klassenbibliotheksprojekte enthält.

Erstellen Sie ein neues Websiteprojekt mit ASP.NET integrierten AJAX-Erweiterungen. Erstellen Sie ein anderes Projekt, ein Klassenbibliotheksprojekt, innerhalb der Projektmappe mit dem Namen LocalizingResources.
Fügen Sie dem LocalizingResources-Projekt eine Jscript-Datei namens VerifyDeletion.js sowie RESX-Ressourcendateien namens DeletionResources.resx und DeletionResources.es.resx hinzu. Erstere werden kulturneutrale Ressourcen enthalten; letztere enthält Ressourcen in spanischer Sprache.
Fügen Sie den folgenden Code VerifyDeletion.js hinzu:

function VerifyDeletion(fileName)
{
 if (confirm(Message.VerifyDelete.replace(/FILENAME/, fileName)))
 {
 Delete(fileName);
 return true;
 }
 return false;
}
function Delete(fileName)
{
 alert (Message.Deleted.replace(/FILENAME/, fileName));
}

Für diejenigen, die mit der JavaScript Regex-Syntax nicht vertraut sind, bezeichnet Text innerhalb einzelner Schrägstriche (im vorherigen Beispiel ist /FILENAME/ ein Beispiel) ein RegExp-Objekt. Die MSDN Library enthält eine umfangreiche JavaScript-Referenz, und Ressourcen zu nativen JavaScript-Objekten können online gefunden werden.

Fügen Sie DeleteResources.resx die folgenden Ressourcenzeichenfolgen hinzu:

VerifyDelete: Möchten Sie FILENAME wirklich löschen?

Gelöscht: FILENAME wurde gelöscht.
Fügen Sie DeleteResources.es.resx die folgenden Ressourcenzeichenfolgen hinzu:

VerifyDelete: Est seguro que desee quitar FILENAME?

Gelöscht: FILENAME se ha quitado.
Fügen Sie der AssemblyInfo-Datei die folgenden Codezeilen hinzu:

[assembly: System.Web.UI.WebResource("LocalizingResources.VerifyDeletion.js",
 "text/javascript")]
[assembly: System.Web.UI.ScriptResource("LocalizingResources.VerifyDeletion.js",
 "LocalizingResources.DeletionResources", "Message")]

Fügen Sie dem Projekt LocalizingResources Verweise auf System.Web und System.Web.Extensions hinzu.
Fügen Sie einen Verweis auf das Projekt LocalizingResources aus dem Websiteprojekt hinzu.
Aktualisieren Sie in default.aspx unter dem Websiteprojekt das ScriptManager-Steuerelement mit dem folgenden zusätzlichen Markup:

<asp:ScriptManager ID="ScriptManager1" runat="server" EnableScriptLocalization="true">
 <Scripts>
 <asp:ScriptReference Assembly="LocalizingResources" Name="LocalizingResources.VerifyDeletion.js"/>
 </Scripts>
</asp:ScriptManager>

Fügen Sie in default.aspx an einer beliebigen Stelle auf der Seite das folgende Markup ein:

<asp:Button ID="btnDelete" runat="Server" OnClientClick="VerifyDeletion('a.txt');" Text="Delete" />

Drücken Sie F5. Wenn Sie dazu aufgefordert werden, aktivieren Sie das Debuggen. Wenn die Seite geladen wird, drücken Sie die Schaltfläche Löschen. Beachten Sie, dass Sie in englischer Sprache zur Bestätigung aufgefordert werden (es sei denn, Ihr Computer ist standardmäßig auf spanischsprachige Ressourcen festgelegt).
Schließen Sie das Browserfenster, und kehren Sie zu default.aspx zurück. Ersetzen Sie in der @Page Header-Direktive auto für Culture und UICulture durch es-ES. Drücken Sie erneut F5, um die Webanwendung im Browser erneut zu starten. Beachten Sie dieses Mal, dass Sie aufgefordert werden, die Datei auf Spanisch zu löschen:

(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Beachten Sie, dass es für diese exemplarische Vorgehensweise mehrere Variationen gibt. Für instance können Skripts beim ScriptManager-Steuerelement programmgesteuert während des Seitenladens registriert werden.

Einschließen einer statischen Skriptdateistruktur

Wenn Sie statische Skriptdateien für die Bereitstellung verwenden, verlieren Sie einige der Vorteile des inhärenten .NET-Lokalisierungsschemas. In erster Linie ist sichtbar, dass Sie den automatischen Typ verlieren, der aus Skriptressourcendateien generiert wird. in der obigen exemplarischen Vorgehensweise wurden Ressourcen beispielsweise durch einen automatisch generierten Typ namens Message aus dem ScriptManager-Steuerelement verfügbar gemacht.

Die Verwendung einer statischen Skriptdateistruktur hat jedoch einige Vorteile. Updates können ausgeführt werden, ohne Satellitenassemblys neu zu kompilieren und erneut bereitzustellen, und die Verwendung einer statischen Dateistruktur kann auch zum Überschreiben eingebetteter Skripts erfolgen, um eine kleinere Funktionalität zu integrieren, die möglicherweise nicht mit einer Komponente ausgeliefert wurde.

Microsoft empfiehlt, ein Problem mit der Versionskontrolle zu vermeiden, indem Ihre Skriptressourcen während der Projektkompilierung automatisch generiert werden. Bei der Verwaltung einer umfangreichen Skriptcodebasis kann es immer schwieriger werden, sicherzustellen, dass Codeänderungen in jedem lokalisierten Skript widerspiegelt werden. Alternativ können Sie einfach ein Logikskript und mehrere Lokalisierungsskripts verwalten und die Dateien beim Erstellen des Projekts zusammenführen.

Da keine Ressourcen vorhanden sind, die deklarativ eingeschlossen werden können, sollte auf statische Skriptdateien entweder durch Hinzufügen <asp:ScriptElement> von Elementen als untergeordnetes Element des <Scripts> Tags des ScriptManager-Steuerelements oder durch programmgesteuertes Hinzufügen ScriptReference von Objekten zur Scripts Eigenschaft des Steuerelements auf der ScriptManager Seite zur Laufzeit verwiesen werden.

Der ScriptManager und seine Rolle bei der Lokalisierung

Der ScriptManager ermöglicht mehrere automatische Verhaltensweisen für lokalisierte Anwendungen:

Skriptdateien werden automatisch basierend auf Einstellungen und Benennungskonventionen gesucht. für instance werden debugfähige Skripts im Debugmodus geladen und lokalisierte Skripts basierend auf der Auswahl der Benutzeroberfläche des Browsers geladen.
Es ermöglicht die Definition von Kulturen, einschließlich benutzerdefinierter Kulturen.
Es ermöglicht die Komprimierung von Skriptdateien über HTTP.
Sie speichert Skripts zwischen, um viele Anforderungen effizient zu verwalten.
Es fügt Skripts eine Indirektisierungsebene hinzu, indem sie über eine verschlüsselte URL geleitet werden.

Skriptverweise können dem ScriptManager-Steuerelement entweder programmgesteuert oder durch deklaratives Markup hinzugefügt werden. Deklaratives Markup ist besonders nützlich bei der Arbeit mit Skripts, die in anderen Assemblys als dem Websiteprojekt selbst eingebettet sind, da sich der Name des Skripts wahrscheinlich nicht ändert, wenn Revisionen übertragen werden.

Zusammenfassung

Wenn Webanwendungen wachsen, um ein größeres Publikum zu erreichen, wird die Notwendigkeit, breitere Kulturen und Gemeinschaften zu erreichen, zum Kern eines Geschäftsmodells. E-Commerce-Webanwendungen müssen in der Lage sein, mit Fremdwährungen umzugehen, Content-Management-Systeme müssen in der Lage sein, nicht nur ihre Inhalte, sondern auch ihre Navigationshinweise und Formularfelder in anderen Sprachen darzustellen, und Unternehmen müssen wissen, dass dieses Bedürfnis zugänglich ist.

Der .NET Framework unterstützt intrinsisch ein umfassendes Lokalisierungsframework, das Satellitenassemblys und XML-Ressourcendateien (.resx) verwendet, um eine einheitliche Möglichkeit zum Suchen von Ressourcenzeichenfolgen und Bildern zu bieten. Die ASP.NET AJAX-Erweiterungen, einschließlich microsoft AJAX Framework und Microsoft AJAX Script Library, bieten Unterstützung für dieses Programmiermodell in clientseitigen Code und ermöglichen so einfache Ressourcenzeichenfolgensuche. Satellitenassemblys unterstützen die automatische Einbindung von Skriptressourcen (tatsächliche .js Dateien) über ScriptResource.axd, solange die Dateinamen einem bestimmten Benennungsschema folgen. Mit dieser Unterstützung vereinfachen die ASP.NET AJAX-Erweiterungen die Lokalisierung von Skripts und die Globalisierung von Anwendungen.

Biografie

Scott Cate arbeitet seit 1997 mit Microsoft-Webtechnologien und ist President von myKB.com (www.myKB.com), wo er sich auf das Schreiben von ASP.NET basierten Anwendungen spezialisiert hat, die sich auf Knowledge Base-Softwarelösungen konzentrieren. Scott kann per E-Mail unter scott.cate@myKB.com oder seinem Blog unter ScottCate.com

Zurück Weiter

Share via