Globalisierung und Lokalisierung von Excel-Lösungen

Artikel
03/22/2013

Dieser Abschnitt enthält Informationen zu Besonderheiten in Microsoft Office Excel-Projektmappen, die auf Computern ausgeführt werden, bei denen unter Windows andere Einstellungen als Englisch ausgewählt wurden.Die meisten Aspekte der Globalisierung und Lokalisierung von Microsoft Office-Projektmappen finden Sie auch beim Erstellen von anderen Projektmappen mit Visual Studio.Allgemeine Informationen finden Sie unter Globalisieren und Lokalisieren von Anwendungen.Globalisierungs- und Lokalisierungsinformationen finden Sie auch auf der MSDN-Webseite Globalization and Localization Issues for Solutions Created with Microsoft Visual Studio Tools for the Microsoft Office System.

In der Standardeinstellung funktionieren Hoststeuerelemente in Microsoft Office Excel mit jeder regionalen Einstellung unter Windows fehlerfrei, wenn alle Daten, die die in verwaltetem Code übergeben oder bearbeitet werden, im Format Englisch (USA) vorliegen.In Projekten, die .NET Framework 4 oder .NET Framework 4.5 abzielen, wird dieses Verhalten durch die Common Language Runtime (CLR) gesteuert.

Betrifft: Die Informationen in diesem Thema betreffen Projekte auf Dokument- und auf Anwendungsebene für Excel 2013 und Excel 2010. Weitere Informationen finden Sie unter Verfügbare Funktionen nach Office-Anwendung und Projekttyp.

Formatierungs-Daten in Excel mit unterschiedlichen regionalen Einstellungen

Alle Daten mit gebietsschemaabhängigen Formatierungen, z. B. Datumsangaben und Währungen, müssen mit dem Datenformat Englisch (USA) (Gebietsschema-ID 1033) formatiert sein, bevor sie an Microsoft Office Excel übergeben oder durch Code im Office-Projekt ausgelesen werden.

Standardmäßig wird beim Entwickeln einer Office-Lösung in Visual Studio vom Excel-Objektmodell eine Datenformatierung mit Gebietsschema-ID 1033 erwartet (wird auch als Sperren des Objektmodells in Gebietsschema-ID 1033 bezeichnet).Dieses Verhalten entspricht der Methode, die auch für Visual Basic for Applications (VBA) verwendet wird.Dieses Verhalten kann in den Office-Lösungen jedoch geändert werden.

Grundlegendes dazu, wie das Excel-Objektmodell immer Gebietsschema-ID 1033 erwartet

Standardmäßig werden mit Visual Studio erstellte Office-Lösungen vom Gebietsschema des Endbenutzers nicht beeinflusst. Sie verhalten sich stets, als wäre das Gebietsschema Englisch (USA).Wenn Sie beispielsweise die Value2-Eigenschaft in Excel abrufen oder festlegen, müssen die Daten gemäß Gebietsschema-ID 1033 formatiert sein.Ein anderes Datenformat führt u. U. zu unerwarteten Ergebnissen.

Obwohl Sie für Daten, die durch verwalteten Code übergeben oder geändert werden, das Format Englisch (USA) verwenden, werden die Daten in Excel gemäß den lokalen Einstellungen des Endbenutzers interpretiert und angezeigt.Excel kann die Daten korrekt formatieren, weil der verwaltete Code zusammen mit den Daten den Gebietsschema-ID 1033 übergibt, sodass klar ist, dass die Daten das Format Englisch (USA) besitzen und entsprechend den lokalen Einstellungen des Benutzers neu formatiert werden müssen.

Wenn Endbenutzer z. B. ihre Regionaloptionen auf das Gebietsschema Deutsch (Deutschland) festgelegt haben, erwarten sie, dass das Datum 29. Juni 2005 folgendermaßen formatiert wird: 29.06.2005.Wenn die Lösung jedoch das Datum als Zeichenfolge an Excel übergibt, muss das Datum gemäß dem Format Englisch (USA) formatiert werden: 6/29/2005.Wenn die Zelle als Datumszelle formatiert wird, zeigt Excel das Datum im Format Deutsch (Deutschland) an.

Übergeben von anderen Gebietsschema-IDs an das Excel-Objektmodell

Die CLR (Common Language Runtime) übergibt Gebietsschema-ID 1033 automatisch an alle Methoden und Eigenschaften im Excel-Objektmodell, die gebietsschemaabhängige Daten akzeptieren.Es gibt keine Möglichkeit, dieses Verhalten für alle Aufrufe im Objektmodell automatisch zu ändern.Sie können jedoch unter Verwendung von InvokeMember zum Aufrufen der Methode und durch Übergeben der Gebietsschema-ID an den culture-Parameter der Methode eine andere Gebietsschema-ID übergeben.

Lokalisieren von Dokumenttext

Das Dokument, die Vorlage oder die Arbeitsmappe des Projekts enthalten wahrscheinlich statischen Text, der getrennt von der Assembly und anderen verwalteten Ressourcen lokalisiert werden muss.Am einfachsten kopieren Sie hierzu das Dokument und übersetzen den Text mithilfe von Microsoft Office Word oder Microsoft Office Excel.Dieser Vorgang funktioniert auch, wenn Sie keine Änderungen am Code vornehmen, da beliebig viele Dokumente mit einer Assembly verknüpft werden können.

Sie müssen jedoch sicherstellen, dass alle Codeteile, die eine Interaktion mit dem Dokumenttext erfordern, weiterhin der Sprache des Textes entsprechen. Außerdem müssen Lesezeichen, benannte Bereiche und andere Anzeigefelder eine Umformatierung des Office-Dokuments zulassen, wenn dieses an eine andere Grammatik oder Textlänge angepasst wird.Bei Dokumentvorlagen mit verhältnismäßig wenig Text können Sie den Text auch in Ressourcendateien speichern und dann zur Laufzeit laden.

Textrichtung

In Excel können Sie eine Eigenschaft des Arbeitsblatts festlegen, damit der Text von rechts nach links gerendert wird.Hoststeuerelemente oder andere Steuerelemente mit einer RightToLeft-Eigenschaft, die im Designer platziert werden, übernehmen diese Einstellungen zur Laufzeit automatisch.In Word gibt es keine Dokumenteinstellung für bidirektionalen Text (Sie können einfach die Textausrichtung ändern), d. h. die Steuerelemente können der Einstellung nicht zugeordnet werden.Stattdessen müssen Sie die Textausrichtung für jedes Steuerelement einzeln festlegen.Es besteht die Möglichkeit, mittels Code alle Steuerelemente zu durchlaufen und sie zu einer Textdarstellung von rechts nach links zu zwingen.

Ändern der Kultur

Codeanpassung auf Dokumentebene normalerweise den UI-Thread von Excel verwendet, wirken sich Änderungen, die Sie an der Threadkultur auf anderen aus, die auf diesem Thread ausgeführt; die Änderung wird nicht an die Anpassung beschränkt.

Windows Forms-Steuerelemente werden vor dem Start von Add-Ins auf Anwendungsebene durch die Hostanwendung initialisiert.In diesen Situationen sollte die Kultur vor Festlegen der Benutzeroberflächen-Steuerelemente geändert werden.

Installieren der Sprachpakete

Wurden für Windows andere Spracheinstellungen als Englisch festgelegt, können die Language Packs für Visual Studio-Tools für Office-Laufzeit installiert werden, um Visual Studio-Tools für Office-Laufzeit-Meldungen in der auch für Windows verwendeten Sprache anzuzeigen.Wenn Endbenutzer die Projektmappen mit andere Spracheinstellungen als Englisch für Windows, benötigen sie das richtige Language Pack verfügen, aus, um Laufzeitmeldungen in derselben Sprache wie Windows anzuzeigen. Die Visual Studio-Tools für Office-Laufzeit Language Packs sind im Microsoft Download Center verfügbar.

Zudem sind verteilbare .NET Framework-Sprachpakete für ClickOnce-Meldungen erforderlich.Die .NET Framework-Sprachpakete sind zum Herunterladen im Microsoft Download Center verfügbar.

Regionale Einstellungen und Excel-COM-Aufrufe

Sobald ein verwalteter Client die Methode eines COM-Objekts aufruft und dabei kulturspezifische Informationen übergeben muss, verwendet er das Gebietsschema (CurrentCulture), das mit dem aktuellen Threadgebietsschema übereinstimmt.Das aktuelle Threadgebietsschema wird standardmäßig von den regionalen Einstellungen des Benutzers geerbt.Wenn Sie jedoch das Excel-Objektmodell von einer Excel-Lösung aus aufrufen, die mithilfe der Office-Entwicklungstools in Visual Studio erstellt wurde, wird das Datenformat Englisch (USA) (Gebietsschema-ID 1033) automatisch an das Excel-Objekt übergeben.Alle Daten mit gebietsschemaabhängigen Formatierungen, zum Beispiel Datumsangaben und Währungen, müssen das Datenformat Englisch (USA) besitzen, bevor sie an Microsoft Office Excel übergeben oder im Projektcode ausgelesen werden.

Überlegungen zum Speichern von Daten

Um sicherzustellen dass die Daten ordnungsgemäß interpretiert und angezeigt werden, sollten Sie auch der Ansicht sein dass Probleme auftreten können, wenn Anwendungen Daten wie Excel-Arbeitsblattformeln, in Zeichenfolgenliteralen (hartcodiert) anstatt in der stark typisierten Objekten speichert.Sie sollten Daten verwenden, die als nicht von einer Kultur abhängig oder als Englisch (USA) (LCID-Wert 1033) formatiert sind.

Anwendungen, die Zeichenfolgenliterale verwenden

Mögliche hartcodierte Werte sind Datumsliterale mit der Formatierung Englisch (Vereinigte Staaten) und Excel-Arbeitsblattformeln mit lokalisierten Funktionsnamen.Eine andere Möglichkeit wäre eine hartcodierte Zeichenfolge, die eine Zahl wie "1,000" enthält. In einigen Kulturen wird diese Zeichenfolge als Eintausend, in anderen als Einskommanull interpretiert.Berechnungen und Vergleiche, die auf der Grundlage eines falschen Formats ausgeführt werden, können zu fehlerhaften Daten führen.

Excel interpretiert alle Zeichenfolgen in Übereinstimmung mit der LCID, die mit der Zeichenfolge übergeben wird.Dies kann ein Problem darstellen, falls das Format der Zeichenfolge nicht der übergebenen LCID entspricht.Für Excel-Lösungen, die mithilfe der Office-Entwicklungstools in Visual Studio erstellt wurden, wird beim Übergeben aller Daten die LCID 1033 (en-US) verwendet.Excel zeigt die Daten entsprechend den regionalen Einstellungen und der Sprache der Excel-Benutzeroberfläche an.In Visual Basic for Applications (VBA) werden ebenfalls Zeichenfolgen als en-US formatiert, und als LCID wird fast immer der Wert 0 (Sprachneutral) übergeben.Beispielsweise zeigt der folgende VBA-Code, der aktuellen Gebietsschemaeinstellung entsprechend, einen richtig formatierten Wert für das Datum 12. Mai 2004 an.

'VBA
Application.ActiveCell.Value2 = "05/12/04"

Der gleiche Code ergibt bei der Verwendung in einer Lösung, die mit den Office-Entwicklungstools in Visual Studio erstellt und über COM-Interop an Excel übergeben wurde, die gleichen Ergebnisse wie bei der Formatierung des Datums im Format "en-US".

Beispiel:

Me.Range("A1").Value2 = "05/12/04"

this.Range["A1"].Value2 = "05/12/04";

Sie sollten so oft es geht stark typisierte Daten anstelle von Zeichenfolgenliteralen verwenden.Anstatt beispielsweise ein Datum als Zeichenfolgenliteral zu speichern, können Sie es als Double speichern und zum Bearbeiten in ein DateTime-Objekt konvertieren.

Im folgenden Codebeispiel wird ein Datum, das der Benutzer in Zelle A5 eingibt, als Double gespeichert und anschließend in ein DateTime-Objekt konvertiert, um es in Zelle A7 anzuzeigen.Zelle A7 muss für die Datumsanzeige formatiert sein.

Private Sub ConvertDate_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) _
    Handles ConvertDate.Click

    Try
        Dim dbl As Double = Me.Range("A5").Value2
        Dim dt As System.DateTime = System.DateTime.FromOADate(dbl)
        Me.Range("A7").Value2 = dt

    Catch ex As Exception
        MessageBox.Show(ex.Message)
    End Try
End Sub

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.Es wird jedoch aufgrund von möglichen Problemen mit Sprache und COM interop empfohlen, in Ihrem Code nur englische Funktionsnamen zu verwenden.

Anwendungen, die externe Daten verwenden

Wenn im Code externe Daten geöffnet oder auf andere Art verwendet werden, z. B. aus einem älteren System exportierte Dateien mit durch Trennzeichen getrennten Werten (CSV-Dateien), kann sich dies bei Verwendung anderer Formate als en-US auf den Code auswirken.Der Datenbankzugriff ist in den meisten Fällen nicht davon betroffen, da alle Werte i. d. R. im Binärformat vorliegen. Das kann sich ändern, sobald in der Datenbank z. B. ein Datum als Zeichenfolge gespeichert wird oder Datenbankvorgänge ausgeführt werden, die nicht das Binärformat verwenden.Beim Erstellen von SQL-Abfragen mit Excel-Daten müssen sie abhängig von der Funktion möglicherweise sicherstellen, dass die Daten im en-US-Format vorliegen.

Siehe auch

Freigeben über