Globalisierung und Lokalisierung von Office-Projektmappen

Artikel
04/28/2010

Aktualisiert: November 2007

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.

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

Da Ihre Codeanpassung normalerweise den gleichen primären UI-Thread wie Word oder Excel verwendet, wirken sich Änderungen an der Thread-Kultur auf alles aus, was auf diesem Thread ausgeführt wird. Die Änderung ist nicht auf Ihre Anpassung beschränkt.

Windows Forms-Steuerelemente werden vor dem Start von Visual Studio Tools for Office-Add-Ins durch Hostanwendungen 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 Visual Studio Tools for Office-Sprachpakete installiert werden, um die Visual Studio Tools for Office-Laufzeitmeldungen in der auch für Windows verwendeten Sprache anzuzeigen. Wenn Endbenutzer Ihre Projektmappen mit anderen Windows-Einstellungen als Englisch ausführen, benötigen sie das richtige Sprachpaket, um Laufzeitmeldungen in der für Windows eingestellten Sprache anzuzeigen. Die Visual Studio Tools for Office-Sprachpakete sind zum Herunterladen 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 einen Aufruf des Excel-Objektmodells ausführen, übergibt Visual Studio Tools for Office automatisch einen nicht von der Kultur abhängigen Gebietsschemabezeichner (LCID). Alle Daten mit gebietsschemaabhängigen Formatierungen, z. B. Datumsangaben und Währungen, müssen mit dem Datenformat Englisch (USA) (LCID 1033) formatiert sein, bevor sie an Microsoft Office Excel übergeben oder durch Code im Visual Studio Tools for Office-Projekt ausgelesen werden. Weitere Informationen hierzu finden Sie unter Formatieren von Daten in Excel mit verschiedenen regionalen Einstellungen.

Dieses Verhalten wird vom Attribut ExcelLocale1033Attribute gesteuert. Indem Sie für ExcelLocale1033Attribute den Wert false festlegen, können Sie das Verhalten so ändern, dass die Daten unter Verwendung des LCIDs des aktuellen Threads übergeben werden. Anschließend können Sie eigenen Code schreiben, um die Interaktion zwischen Excel und verwaltetem Code zu behandeln. Weitere Informationen finden Sie unter Gewusst wie: Sicherstellen der richtigen regionalen Verwendung von Zeichenfolgenliteralen in Excel mithilfe der Reflektion.

Überlegungen zum Speichern von Daten

Um sicherzustellen, dass Ihre Daten korrekt interpretiert und angezeigt werden, sollten Sie bedenken, dass Probleme auftreten können, wenn Anwendungen Daten in Zeichenfolgenliteralen (hartcodiert) anstatt in stark typisierten Objekten speichern. Dies schließt Excel-Arbeitsblattformeln ein. Sie sollten Daten verwenden, die als nicht von einer Kultur abhängig oder als Englisch (USA) (LCID-Wert: en-US) 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. Visual Studio Tools for Office verwendet beim Übergeben aller Daten die LCID 1033 (en-US). Excel zeigt die Daten entsprechend den regionalen Einstellungen und der Sprache der Excel-Benutzeroberfläche an. In Visual Basic for Applications (VBA) werden 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"

Derselbe Code erzeugt beim Verwenden in einer Visual Studio Tools for Office-Projektmappe und beim Übergeben an Excel mithilfe von COM-Interop die gleichen Ergebnisse, wenn das Datum als en-US formatiert ist.

Beispiel:

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

this.Range["A1", missing].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", missing].Value2);
        System.DateTime dt = System.DateTime.FromOADate(dbl);
        this.Range["A7", missing].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.