Zur Hauptseite ... Zum Onlinearchiv ... Zum Abonnement ... Zum Newsletter ... Zu den Tools ... Zum Impressum ... Zum Login ...

Achtung: Dies ist nicht der vollständige Artikel, sondern nur ein paar Seiten davon. Wenn Sie hier nicht erfahren, was Sie wissen möchten, finden Sie am Ende Informationen darüber, wie Sie den ganzen Artikel lesen können.

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Gedrucktes Heft

Diesen Beitrag finden Sie in Ausgabe 3/2008.

Unser Angebot für Sie!

Lesen Sie diesen Beitrag und 500 andere sofort im Onlinearchiv, und erhalten Sie alle zwei Monate brandheißes Access-Know-how auf 72 gedruckten Seiten! Plus attraktive Präsente, zum Beispiel das bald erscheinende Buch 'Access 2010 - Das Grundlagenbuch für Entwickler'!

Diesen Beitrag twittern

Zusammenfassung

Erweitern Sie bestehende Anwendungen um Mehrsprachigkeit.

Techniken

VBA

Voraussetzungen

Access 2000 und höher

Beispieldateien

Mehrsprachigkeit.mdb

Shortlink

611

Mehrsprachige Anwendungen

André Minhorst, Duisburg

Wer seine Anwendung nicht nur mit einer Sprache ausstatten möchte, sondern diese auch in anderen Ländern verfügbar machen will, hat zwei Möglichkeiten: Entweder er erstellt für jede Sprache eine andere Version oder er bringt einer einzigen Anwendung bei, auf Knopfdruck die Sprache zu wechseln. Erfahren Sie, welche Version sinnvoller ist und wie Sie eine mehrsprachige Anwendung in die Tat umsetzen.

Vorausgesetzt, Ihre Anwendung ist so ausgereift, dass sie ganz sicher nicht mehr geändert wird, dann können Sie diese einfach kopieren und die enthaltenen Texte an eine andere Sprache anpassen. Da aber spätestens beim Wechsel zu einer anderen Access-Version Änderungen anstehen, sollten Sie vorsichtig damit sein: Diese müssen Sie nämlich dann in jeder Sprachversion separat durchführen.

Anders sieht es aus, wenn Sie eine Anwendung mit Funktionen versehen, die je nach gewünschter Sprache die passenden Texte anzeigen. Der Aufwand, diese Funktionen zu implementieren, ist zwar unumgänglich, und auch bei Erweiterungen oder Änderungen der Datenbank fällt ein wenig mehr Arbeit an, aber je mehr Sprachen man unterstützt, desto weniger Aufwand ergibt sich gegenüber der erstgenannten Lösung bei Änderungen.

Betroffene Bereiche

Wichtig ist beim Implementieren von Mehrsprachigkeit, sich zunächst genau zu überlegen, wo sich dieses Feature bemerkbar macht und mit welchem Aufwand die Anpassungen verbunden sind. Die folgende Liste zeigt, was Sie beachten müssen:

  • Dokumentation (PDF, gedruckt), Onlinehilfe
  • Elemente der Benutzeroberfläche: Menüs, Formulare, Berichte, Steuerelemente, Beschriftungen; insbesondere Größe der Elemente in Abhängigkeit von der Länge der Texte in den verschiedenen Sprachen
  • Datenmodell: In welcher Sprache werden Tabellen und Felder benannt?
  • VBA-Code: In welcher Sprache werden Konstanten, Variablen und Routinen sowie Klassen benannt und der Code dokumentiert?
  • Access-Objekte: In welcher Sprache werden Abfragen, Formulare, Berichte und Module benannt?
  • Liegt Access jeweils in der richtigen Sprache vor? Dies ist vor allem in Hinblick auf die Verwendung von MsgBox und InputBox wichtig.
  • Zahlen-, Währungs- und Datumsformate müssen den jeweiligen Gegebenheiten angepasst werden.
  • Daten: Welche Daten müssen in allen Sprachen vorliegen - beispielsweise Anreden, Währungen, sonstige Texte?

Dieser Beitrag lässt die Dokumentation und die Onlinehilfe weg, da diese wohl oder übel in jeder Sprache separat erstellt werden müssen. Die internen Elemente einer Datenbank, wie das Datenmodell, die Bezeichnungen der Access-Objekte und die im VBA-Code verwendeten Bezeichnungen, bleiben ebenfalls außen vor, weil der Benutzer mit diesen nicht in Berührung kommt und wir davon ausgehen, dass nur die Benutzer und nicht die Entwickler unterschiedliche Sprachen erwarten. Mit englischen Bezeichnungen fährt man aber hier wohl meist gut. Wie Sie alles Weitere realisieren, erfahren Sie auf den nächsten Seiten.

Wohin mit den Informationen?

Eine wichtige Frage ist, wo Sie die verschiedenen Übersetzungen der in der Anwendung enthaltenen Texte speichern. Man könnte diese in einer Textdatei speichern oder auch aus Ressourcen-Dateien oder der Registry beziehen. Es wäre aber ungünstig, solche Informationen außerhalb der Anwendung zu speichern, wenn dies innerhalb geschehen kann - und zwar in passenden Tabellen, die man auch noch relational miteinander verknüpfen kann.

Datenmodell

Ganz klar zu sein scheint, dass es eine Tabelle mit den verschiedenen Sprachen geben muss. Diese enthält neben dem Primärschlüsselfeld die Bezeichnung der Sprache und gegebenenfalls ein international gültiges Kürzel. Auf die Tatsache, dass der Benutzer die Sprache ja gegebenenfalls beim Auswählen derselben in der jeweiligen Landessprache vorfinden möchte, gehen wir weiter unten ein. Wer gern spielt, kann natürlich auch passende Landesflaggen zur Auswahl anbieten.

Neben den Sprachen gibt es Begriffe beziehungsweise Texte, die für jede Sprache einmal vorhanden sein müssen. Eine Tabelle, die solche Informationen speichert, enthält also mindestens ein Feld mit der jeweiligen Übersetzung, eine eindeutige ID für den Text, sowie ein Feld, mit dem ein Eintrag der gerade beschriebenen Sprachentabelle festgelegt wird. Dabei gibt es einen zusammengesetzten eindeutigen Schlüssel über die beiden Felder BegriffID und SpracheID, damit kein Begriff zweimal in derselben Sprache vorkommt.

Schließlich müssen Sie noch dafür sorgen, dass Steuerelemente, Formulare, Berichte und die anderen Elemente mit den dort gespeicherten Begriffen ausgestattet werden. Dazu brauchen Sie für die unterschiedlichen Ziele verschiedene Tabellen. Die erste kümmert sich um die Formulare, Berichte und Steuerelemente. Sie enthält zwei Felder für die Angabe des Formular- beziehungsweise Berichtsnamens und für den Namen des jeweiligen Steuerelements.

Will man die Formular- oder Berichtstitel festlegen, gibt man dort einfach nur den Objektnamen an und lässt das Steuerelement weg. Ein weiteres Feld enthält die Nummer des Texts, der dort unter Berücksichtigung der gewählten Sprache eingebaut werden soll. Schauen wir uns nun an, wie dieses Datenmodell funktioniert; die Tabellen für die übrigen Objekte folgen später in Zusammenhang mit den jeweiligen Techniken.

Das Datenmodell sieht nun zunächst wie in Abb. 1 aus.

pic001.tif

Abb. 1: Datenmodell für die Ausstattung von Formularen und Berichten mit mehrsprachigen Texten

Formulare, Berichte und Steuerelemente

Alle Beschriftungen von Formularen, Berichten und den enthaltenen Steuerelementen sollen für die entsprechende Sprache angepasst werden. Aber reicht das aus? Nein, es gibt noch eine Reihe weiterer Informationen, die in die jeweilige Sprache übersetzt werden müssen:

  • ControlTipText: Dieser Text wird, soweit vorhanden, beim Überfahren mit der Maus angezeigt.
  • StatusBarText: Diesen Text zeigt Access für das jeweils aktuelle Element in der Statusleiste an.
  • ValidationText: Die Gültigkeitsmeldung zeigt Access an, wenn der Benutzer einen ungültigen Wert eingibt.

Von Deutsch nach ...

Die geplante Vorgehensweise sieht so aus:

  • Sie erstellen eine Anwendung, die einmal mehrsprachig werden soll. Am wenigsten Arbeit macht dies bezogen auf Formulare und Berichte wohl, wenn Sie die Anwendung erstmal so weit fertigstellen und dann die Mehrsprachigkeit hinzufügen.
  • Eine Routine durchläuft die bestehenden Formulare und Berichte und deren Steuerelemente. Dabei schreibt sie alle Stellen, an denen zu übersetzende Texte auftauchen, inklusive der vorhandenen Beschriftungen in die entsprechenden Tabellen.
  • Im gleichen Zuge legt sie für alle in der Tabelle tblSprachen vorhandenen Einträge eine Kopie der zuvor gespeicherten Texte an - jeweils mit vorangestelltem Kürzel der Sprache.
  • Die so vorbereiteten Texte werden dann mithilfe eines speziellen Formulars, das die Texte für zwei Sprachen - die Originalsprache und die Zielsprache - enthält, nebeneinander angezeigt und können dort komfortabel übersetzt werden.
  • Beim Öffnen eines Formulars oder Berichts mit zu übersetzenden Texten wird eine Routine aufgerufen, die alle Steuerelemente durchläuft und die in den Übersetzungstabellen enthaltenen Texte für die entsprechenden Eigenschaften einfügt.

Einlesen bestehender Texte

Wenn die Anwendung fertiggestellt ist, rufen Sie einfach die Routine TexteEinlesen auf (s. Listing 1) und geben als Parameter die Sprache der Texte an, mit der Formulare, Berichte und Steuerelemente aktuell ausgestattet sind - zum Beispiel 1 für Deutsch (den entsprechenden Wert entnehmen Sie der Tabelle tblSprachen).

Listing 1: Startroutine zum Einlesen der in Formularen und Berichten bestehenden Texte

Public Sub TexteEinlesen(lngSpracheID As Long)

Dim i As Integer

Dim db As DAO.Database

Dim strObjekt As String

Set db = CurrentDb

db.Execute "DELETE FROM tblElemente"

db.Execute "DELETE FROM tblUebersetzungen"

For i = 0 To CurrentProject.AllForms.Count - 1

    strObjekt = CurrentProject.AllForms(i).Name

    ObjektEinlesen strObjekt, lngSpracheID, "Formular"

Next i

For i = 0 To CurrentProject.AllReports.Count - 1

    strObjekt = CurrentProject.AllReports(i).Name

    ObjektEinlesen strObjekt, lngSpracheID, "Bericht"

Next i

End Sub

Die Routine löscht zunächst alle in den Tabellen tblElemente und tblUebersetzungen enthaltenen Daten. Anschließend durchläuft sie erst alle Formulare der Datenbank und dann alle Berichte. Für all diese Objekte ruft die Prozedur die Routine ObjektEinlesen auf.

Diese wiederum finden Sie in Listing 2. Die Routine erwartet den Namen des Objekts, die ID der Standardsprache der Anwendung sowie den Typ des Objekts als Parameter.

Listing 2: Diese Routine durchläuft alle relevanten Eigenschaften von Formularen, Berichten und deren Steuerelementen und ruft für jedes die Routine UebersetzungSchreiben auf, die alle notwendigen Daten in die Übersctzungstabellen schreibt.

Public Sub ObjektEinlesen(strObjekt As String, lngSpracheID As Long, strTyp As String)

Dim i As Integer

Dim strEigenschaft As String

Dim obj As Object

Sie haben das Ende des frei verfügbaren Teils des Artikels erreicht. Lesen Sie weiter, um zu erfahren, wie Sie den vollständigen Artikel lesen und auf viele hundert weitere Artikel zugreifen können.

Sind Sie Abonnent?Jetzt einloggen ...
 

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Verwandte Beiträge:

Mehrsprachige Vokabeldatenbank

Mehrsprachige Anwendungen, Teil 2

Das Optionsgruppen-Steuerelement

Registersteuerelemente von A-Z

Tipps und Tricks

Flexible Datumstextfelder

TreeView-Elemente im Griff

Access 2007: Bilder und Schaltflächen

© 2003-2015 André Minhorst Alle Rechte vorbehalten.