Globalisierung und Lokalisierung von Office-Projektmappen

Artikel
08/10/2011

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.

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

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 die Codeanpassung auf Dokumentebene normalerweise den gleichen primären UI-Thread wie Word oder Excel verwendet, wirken sich Änderungen an der Threadkultur auf alle Objekte aus, die auf diesem Thread ausgeführt werden. Die Änderung ist nicht auf Ihre 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 for Office-Laufzeit installiert werden, um Visual Studio Tools for Office-Laufzeit-Meldungen in der auch für Windows verwendeten Sprache anzuzeigen. Wenn Endbenutzer die Projektmappen mit einer anderen Spracheinstellung als Englisch für Windows ausführen, benötigen sie das richtige Language Pack, um Laufzeitmeldungen in derselben Sprache wie Windows anzuzeigen. Die Visual Studio Tools for 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. Weitere Informationen finden Sie unter Formatieren von Daten in Excel mit verschiedenen regionalen Einstellungen.

Ü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 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", 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.

Siehe auch

Freigeben über