Globalisierung und Lokalisierung von Excel-Lösungen
Dieser Abschnitt enthält besondere Überlegungen zu Microsoft Office Excel-Projektmappen, die auf Computern ausgeführt werden, die über nicht englische Einstellungen für Windows verfügen. Die meisten Aspekte bei der Globalisierung und Lokalisierung von Microsoft Office-Projektmappen sind mit denen identisch, die beim Erstellen von anderen Arten von Projektmappen mit Visual Studio auftreten. Allgemeine Informationen finden Sie unter Globalisieren und Lokalisieren von Anwendungen.
Die Hoststeuerelemente in Microsoft Office Excel funktionieren standardmäßig in allen regionalen Windows-Einstellungen ordnungsgemäß, solange alle mithilfe von verwaltetem Code übergebenen oder geänderten Daten als „Englisch (USA)“ formatiert werden. In Projekten, die auf .NET Framework 4 oder .NET Framework 4.5 abzielen, wird dieses Verhalten von der Common Language Runtime (CLR) gesteuert.
Gilt für: Die Informationen in diesem Thema gelten für Projekte auf Dokumentebene und VSTO-Add-In-Projekte für Excel. Weitere Informationen finden Sie unter features available by Office-App lication and project type.
Formatieren von Daten in Excel mit verschiedenen regionalen Einstellungen
Sie müssen sämtliche Daten, die gebietsschemaabhängige Formatierungen aufweisen, z. B. Datumsangaben und Währungen, mit dem Datenformat „Englisch (USA)“ (Gebietsschema-ID 1033) formatieren, bevor Sie sie an Microsoft Office Excel übergeben oder die Daten in Ihrem Office-Projekt aus Code lesen.
Standardmäßig erwartet das Excel-Objektmodell bei der Entwicklung einer Office-Projektmappe in Visual Studio die Datenformatierung mit Gebietsschema-ID 1033 (dies wird auch als Sperren des Objektmodells für Gebietsschema-ID 1033 bezeichnet). Dieses Verhalten entspricht der von Visual Basic for Applications verwendeten Vorgehensweise. Allerdings können Sie dieses Verhalten in Ihren Office-Projektmappen ändern.
Verstehen, wie das Excel-Objektmodell immer gebietsschema-ID 1033 erwartet
Standardmäßig sind von Ihnen mit Visual Studio erstellte Office-Projektmappen nicht von den Gebietsschemaeinstellungen des Endbenutzers betroffen, und sie verhalten sich immer so, als ob das Gebietsschema „Englisch (USA)“ verwendet würde. Wenn Sie z. B. die Value2 -Eigenschaft in Excel abrufen oder festlegen, müssen die Daten so formatiert sein, wie es die Gebietsschema-ID 1033 erwartet. Wenn Sie ein anderes Datenformat verwenden, erhalten Sie möglicherweise unerwartete Ergebnisse.
Auch wenn Sie das Format „Englisch (USA)“ für Daten verwenden, die von verwaltetem Code übergeben oder geändert werden, interpretiert Excel die Daten gemäß der Gebietsschemaeinstellung des Endbenutzers und zeigt die Daten ordnungsgemäß an. Excel kann die Daten ordnungsgemäß formatieren, da der verwaltete Code die Gebietsschema-ID 1033 zusammen mit den Daten übergibt, wodurch angegeben wird, dass die Daten im Format „Englisch (USA)“ vorliegen und daher neu formatiert werden müssen, um mit der Gebietsschemaeinstellung des Benutzers übereinzustimmen.
Wenn Endbenutzer z. B. ihre regionalen Optionen auf das Gebietsschema Deutsch (Deutschland) festgelegt haben, erwarten sie, dass das Datum „29. Juni 2005“ folgendermaßen formatiert wird: 29.06.2005. Wenn Ihre Projektmappe das Datum jedoch als Zeichenfolge an Excel übergibt, müssen Sie das Datum gemäß dem Format „Englisch (USA)“ formatieren: 6/29/2005. Wenn die Zelle als Datumszelle formatiert ist, zeigt Excel das Datum im Format „Deutsch (Deutschland)“ an.
Übergeben anderer Gebietsschema-IDs an das Excel-Objektmodell
Die Common Language Runtime (CLR) übergibt die Gebietsschema-ID 1033 automatisch an alle Methoden und Eigenschaften im Excel-Objektmodell, die gebietsschemaabhängige Daten akzeptieren. Es gibt keine Möglichkeit, dieses Verhalten automatisch für alle Aufrufe des Objektmodells zu ändern. Sie können jedoch eine andere Gebietsschema-ID an eine bestimmte Methode übergeben, indem Sie InvokeMember zum Aufrufen der Methode und Übergeben der Gebietsschema-ID an den culture -Parameter der Methode verwenden.
Lokalisieren von Dokumenttext
Das Dokument, die Vorlage oder die Arbeitsmappe in Ihrem Projekt umfasst wahrscheinlich statischen Text, der getrennt von der Assembly und anderen verwalteten Ressourcen lokalisiert werden muss. Eine einfache Möglichkeit hierzu stellt das Erstellen einer Kopie des Dokuments und das anschließende Übersetzen des Texts mithilfe von Microsoft Office Word oder Microsoft Office Excel dar. Diese Vorgehensweise funktioniert auch, wenn Sie keine Änderungen am Code vornehmen, da eine beliebige Anzahl von Dokumenten mit derselben Assembly verknüpft werden kann.
Sie müssen weiterhin sicherstellen, dass jeder Teil des Codes, der mit dem Dokumenttext interagiert, stets mit der Sprache des Texts übereinstimmt, und dass sich Lesezeichen, benannte Bereiche und andere Anzeigefelder allen neuen Formatierungen des Office-Dokuments anpassen, die hinsichtlich einer anderen Grammatik und Textlänge geändert werden mussten. Für Dokumentvorlagen, die relativ wenig Text enthalten, können Sie erwägen, den Text in Ressourcendateien zu speichern und dann zur Laufzeit zu laden.
Textrichtung
In Excel können Sie eine Eigenschaft des Arbeitsblatts festlegen, um den Text von rechts nach links zu rendern. Hoststeuerelemente oder steuerelemente mit einer RightToLeft Eigenschaft, die im Designer platziert werden, stimmen diese Einstellungen zur Laufzeit automatisch ab. Word verfügt nicht über eine Dokumenteinstellung für bidirektionalen Text (Sie ändern einfach die Ausrichtung von Text), sodass die Steuerelemente dieser Einstellung nicht zugeordnet werden können. Stattdessen müssen Sie die Ausrichtung des Texts für jedes Steuerelement festlegen. Es ist möglich, Code zu schreiben, um alle Steuerelemente zu durchlaufen und für diese zu erzwingen, dass sie den Text von rechts nach Links rendern.
Kultur ändern
Ihr Anpassungscode auf Dokumentebene teilt in der Regel den primären UI-Thread von Excel. Daher wirken sich alle Änderungen, die Sie an der Threadkultur vornehmen, auf alles andere aus, das in diesem Thread ausgeführt wird. Die Änderung ist nicht auf Ihre Anpassung beschränkt.
Windows Forms-Steuerelemente werden initialisiert, bevor VSTO-Add-Ins der Anwendungsebene von der Hostanwendung gestartet werden. In diesen Situationen sollte die Kultur vor dem Festlegen der UI-Steuerelemente geändert werden.
Installieren der Sprachpakete
Wenn Sie über nicht englische Einstellungen für Windows verfügen, können Sie die Visual Studio-Tools für Office-Runtime-Sprachpakete installieren, um Visual Studio-Tools für Office-Laufzeitnachrichten in derselben Sprache wie Windows anzuzeigen. Wenn Benutzer Ihre Projektmappen mit anderen Einstellungen als „Englisch“ für Windows ausführen, müssen sie über das richtige Sprachpaket verfügen, um Laufzeitmeldungen in derselben Sprache wie Windows anzeigen zu können. Die Visual Studio-Tools für Office-Laufzeit-Sprachpakete stehen im Microsoft Download Center zur Verfügung.
Darüber hinaus sind die verteilbaren .NET Framework Language Packs für ClickOnce-Meldungen erforderlich. Die .NET Framework-Sprachpakete sind im Microsoft Download Center verfügbar.
Regionale Einstellungen und Excel-COM-Anrufe
Sobald ein verwalteter Client eine Methode für ein COM-Objekt aufruft und dabei kulturspezifische Informationen übergeben muss, erfolgt dies über CurrentCulture (Gebietsschema), das mit dem aktuellen Threadgebietsschema übereinstimmt. Das aktuelle Threadgebietsschema wird standardmäßig von den regionalen Einstellungen des Benutzers geerbt. Wenn Sie jedoch aus einer Excel-Projektmappe, die mithilfe von Office-Entwicklungstools in Visual Studio erstellt wurde, einen Aufruf an das Excel-Objektmodell senden, wird das Datenformat „Englisch (USA)“ (Gebietsschema-ID 1033) automatisch an das Excel-Objektmodell übergeben. Sie müssen sämtliche Daten, die gebietsschemaabhängige Formatierungen aufweisen, z. B. Datumsangaben und Währungen, mit dem Datenformat „Englisch (USA)“ formatieren, bevor Sie sie an Microsoft Office Excel übergeben oder die Daten aus Ihrem Projektcode lesen.
Überlegungen zum Speichern von Daten
Um sicherzustellen, dass Ihre Daten ordnungsgemäß interpretiert und angezeigt werden, sollten Sie ebenfalls berücksichtigen, dass Probleme auftreten können, wenn eine Anwendung Daten, z. B. Excel-Arbeitsblattformeln, in Zeichenfolgenliteralen (hartcodiert) anstatt in stark typisierten Objekten speichert. Sie sollten Daten verwenden, die unter Annahme eines kulturinvarianten Formats oder des Formats „Englisch (USA)“ (LCID-Wert 1033) formatiert werden.
Anwendungen, die Zeichenfolgenliterale verwenden
Hartcodierte Werte können z. B. Datumsliterale im Format „Englisch (USA)“ und Excel-Arbeitsblattformeln sein, die lokalisierte Funktionsnamen enthalten. Eine weitere Möglichkeit ist z. B. eine hartcodierte Zeichenfolge, die eine Zahl wie „1,000“ enthält. In einigen Kulturen wird dies als eintausend interpretiert, während es in anderen Kulturen als eine „1“ mit drei Nachkommastellen interpretiert wird. Mit dem falschen Format ausgeführte Berechnungen und Vergleiche führen möglicherweise zu falschen Daten.
Excel interpretiert alle Zeichenfolgen gemäß der LCID, die mit der Zeichenfolge übergeben wird. Dies kann ein Problem darstellen, wenn das Format der Zeichenfolge nicht mit der übergebenen LCID übereinstimmt. Excel-Projektmappen, die mithilfe der Office-Entwicklungstools in Visual Studio erstellt werden, verwenden beim Übergeben sämtlicher Daten die LCID 1033 (en-US). Excel zeigt die Daten gemäß den regionalen Einstellungen und der Sprache der Excel-Benutzeroberfläche an. Visual Basic for Applications (VBA) funktioniert auch auf diese Weise. Zeichenfolgen werden als „en-US“ formatiert und VBA übergibt fast immer den Wert „0“ (sprachneutral) als LCID. Der folgende VBA-Code zeigt beispielsweise einen korrekt formatierten Wert für den 12. Mai 2004 gemäß der aktuellen Gebietsschemaeinstellung des Benutzers an:
'VBA
Application.ActiveCell.Value2 = "05/12/04"
Wenn derselbe Code in einer Projektmappe verwendet wird, die mit den Office-Entwicklungstools in Visual Studio erstellt und über COM-Interop an Excel übergeben wurde, liefert er dieselben Ergebnisse, wenn das Datum mit dem Format „en-US“ formatiert ist.
Beispiel:
Sie sollten anstelle von Zeichenfolgenliteralen nach Möglichkeit stattdessen mit stark typisierten Daten arbeiten. Anstatt ein Datum z. B. in einem Zeichenfolgenliteral zu speichern, speichern Sie es als Doubleund konvertieren es dann zur Bearbeitung in ein DateTime -Objekt.
Das folgende Codebeispiel übernimmt ein Datum, das von einem Benutzer in Zelle A5 eingegeben wird, speichert es als Doubleund konvertiert es zum Anzeigen in ein DateTime -Objekt in Zelle A7. Zelle A7 muss formatiert werden, damit sie ein Datum anzeigt.
private void ConvertDate_Click(object sender, EventArgs e)
{
try
{
double dbl = (double)(this.Range["A5"].Value2);
System.DateTime dt = System.DateTime.FromOADate(dbl);
this.Range["A7"].Value2 = dt;
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
}
Excel-Arbeitsblattfunktionen
Die Namen von Arbeitsblattfunktionen werden für die meisten Sprachversionen von Excel intern übersetzt. Aufgrund potenzieller Sprach- und COM-Interopprobleme wird jedoch empfohlen, nur englische Funktionsnamen in Ihrem Code zu verwenden.
Anwendungen, die externe Daten verwenden
Möglicherweise ist auch jeglicher Code, der externe Daten öffnet oder anderweitig verwendet, betroffen, z. B. Dateien mit durch Trennzeichen getrennten Werten (CSV-Dateien), die aus einem Legacysystem exportiert wurden, wenn diese Dateien in einem anderen Format als „en-US“ exportiert werden. Der Zugriff auf die Datenbank ist möglicherweise nicht beeinträchtigt, da alle Werte im binären Format vorliegen sollten, sofern die Datenbank die Daten nicht als Zeichenfolgen speichert oder Vorgänge ausführt, die kein binäres Format verwenden. Wenn Sie SQL-Abfragen mithilfe von Daten aus Excel erstellen, müssen Sie zudem möglicherweise sicherstellen, dass diese in Abhängigkeit von der verwendeten Funktion im Format „en-US“ vorliegen.