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 2/2009.

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

Statten Sie eine Anwendung mit mehrsprachigen Menüs und Meldungsfenstern aus.

Techniken

Formulare, Datenmodellierung, Menüleisten, VBA

Voraussetzungen

Access 2000 oder höher

Beispieldateien

Mehrsprachigkeit2.mdb

Shortlink

661

Mehrsprachige Anwendungen, Teil 2

André Minhorst, Duisburg

Im ersten Teil dieser Beitragsreihe haben wir uns mit der mehrsprachigen Gestaltung von Elementen der Benutzeroberfläche, wie Formularen und Berichten, beschäftigt. Das reicht natürlich längst nicht für eine Anwendung, die alle relevanten Texte in mehreren Sprachen anzeigt. In diesem Beitrag geht es weiter: mit der Übersetzung von Meldungsfenstern, Menüs, Ribbons und mehr.

Im Beitrag Mehrsprachige Anwendungen (Shortlink 611) haben wir eine recht bequeme Möglichkeit vorgestellt, um die Beschriftungen bestehender Formulare und Berichte sowie ihrer Steuerelemente in Tabellen einzulesen, diese zu übersetzen und die Beschriftungen bei Bedarf mit dem Text in der gewünschten Sprache auszustatten.

Eine Access-Anwendung liefert aber weitaus viel mehr Stellen, deren Texte flexibel angepasst werden müssen. Die schlechte Nachricht ist, dass sich die meisten nicht so einfach einlesen lassen wie Formulare, Berichte und Steuerelemente: hier ist Handarbeit gefragt.

Bevor wir in die übrigen Elemente von Access einsteigen, die noch nicht im ersten Teil unserer Beitragsreihe erläutert wurden, noch ein Nachtrag zum ersten Teil.

Das Beispiel für den Einsatz der dort verwendeten Routine SpracheEinstellen verwendete ein Kombinationsfeld, mit dem Sie die Sprache auswählen können und die nach dem Aktualisieren eine Ereignisprozedur auslöst. Diese wiederum stellt die Sprache der Steuerelemente des Formulars entsprechend dem im Kombinationsfeld ausgewählten Eintrag ein.

Normalerweise stellen Sie die Sprache natürlich an zentraler Stelle ein, etwa über einen Menüpunkt, und speichern sie in einer globalen Variablen oder noch besser in einer Optionentabelle, damit diese Einstellungen sitzungsübergreifend wirken.

Die Übersetzung der Eigenschaften von Formularen, Berichten und Steuerelementen erfolgt dann zwar auch durch einen Aufruf der Routine SpracheEinstellen - diese wird jedoch direkt beim Öffnen des jeweiligen Objekts aufgerufen, etwa über die Ereignisprozedur Beim Laden eines Formulars:

Private Sub Form_Load()

    SpracheEinstellen Me, cSprache

    End Sub

In diesem Fall wird die Sprache aus einer Konstanten namens cSprache eingelesen, was eine Alternative zum flexiblen Einstellen der Anwendungssprache darstellt: Möglicherweise möchten Sie die Anwendung ja auch einfach in verschiedenen Sprachen veröffentlichen, ohne dass der Benutzer diese selbstständig anpassen kann.

Wohin mit der aktuellen Spracheinstellung?

Je nachdem, ob Sie dem Kunden tatsächlich eine mehrsprachige Anwendung präsentieren möchte, deren Sprache dieser selbst einstellen kann, oder ob Sie einfach nur die Möglichkeit haben möchten, die Anwendung in der einen oder anderen Sprachversion zu vertreiben, wählen Sie eine von mehreren Varianten zum Einstellen der Sprache.

Wenn der Kunde selbst die Einstellung vornehmen soll, bieten Sie beispielsweise ein Formular an, das diese und andere Optionen enthält, deren Einstellungen in einer Optionentabelle gespeichert werden.

Informationen über das Speichern von Optionen in Tabellen erhalten Sie beispielsweise im Beitrag Anwendungsoptionen in Tabellen speichern (Shortlink 617). Dort erfahren Sie auch, wie Sie die gespeicherten Informationen zur Laufzeit wieder verfügbar machen.

Wenn Sie die Anwendung zwar für mehrere Sprachen auslegen, jedoch nur in jeweils einer Sprache ausliefern möchten, sodass der Benutzer nur die voreingestellte Sprache verwenden kann, speichern Sie die ID der Sprache am einfachsten in einer Konstanten.

MsgBox und InputBox

Meldungsfenster und InputBox-Fenster sind zwei Elemente der Benutzeroberfläche, die nur per VBA-Code (eigentlich auch per Makros, aber dieses behandeln wir hier nicht) angezeigt werden können und deren Aussehen erst zur Laufzeit festgelegt wird.

Wir veranschaulichen die Vorgehensweise zur Internationalisierung der beiden Meldungsfensterarten anhand der MsgBox.Die mit der InputBox-Anweisung erzeugten Exemplare behandeln Sie analog.

Prinzipiell müssen Sie den üblicherweise verwendeten Aufruf des Meldungsfensters durch eine Variante ersetzen, welche die aktuelle Übersetzung des Texts aus einer Funktion liefert:

MsgBox HoleUebersetzungµ

("Meldungsfenstertext"), ..., µ

HoleUebersetzungµ

("Meldungsfenstertitel")

Im Gegensatz zu den Formularen, Berichten und Steuerelementen hat eine MsgBox-Anweisung keine eindeutige ID (ein Steuerelement hat beispielsweise ein Host-Objekt wie ein Formular oder einen Bericht und einen Namen), über die man die entsprechenden Übersetzungen holen könnte.

Also legt man selbst eine ID fest, die entweder eine Zahl oder ein String ist und als Parameter der oben aufgeführten Funktion HoleUebersetzung angegeben wird. Diese Funktion liefert dann beispielsweise aus einer Tabelle die Übersetzung des Texts in der aktuellen Anwendungssprache.

Den Text können Sie in der bereits vorhandenen Tabelle tblUebersetzungen unterbringen. Dort verwenden Sie als BegriffID am besten negative Zahlen, damit Sie diese von den übrigen für Formulare, Berichte und Steuerelemente vorgesehenen Übersetzungen unterscheiden können (und damit es eine Möglichkeit gibt, diese beim Neueinlesen der notwendigen Informationen per VBA zu löschen, ohne die Übersetzungen für Meldungsfenster und Co. zu berühren).

Dies könnte wie in Abb. 1 aussehen. Legen Sie einfach die Übersetzungen für die in der Tabelle tblSprachen gespeicherten Sprachen an und tragen Sie die entsprechenden Bedeutungen ein (mangels allzu umfangreicher Fremdsprachenkenntnisse belässt es der Autor bei Platzhaltertexten).

pic002.png

Abb. 1: Die Übersetzungen für die Texte in Meldungsfenstern, Menüleisten und Co. können Sie ebenfalls in die Tabelle tblUebersetzungen schreiben.

Fehlt nur noch die Funktion HoleUebersetzung, die lediglich aus einer einfachen DLookup-Anweisung besteht:

Public Function HoleUebersetzung(lngBegriffID _

    As Long) As String

    HoleUebersetzung = DLookup("Begriff", _

    "tblUebersetzungen", "BegriffID = " _

    & lngBegriffID & " AND SpracheID = " _

    & cSprache)

End Function

Auch hier verwenden wir eine Konstante als Lieferant der ID der Sprache. Wenn Sie die Sprache in einer Optionentabelle oder in einer globalen Variablen vorhalten möchten, müssen Sie cSprache durch einen entsprechenden Ausdruck oder eine Funktion ersetzen.

Der Aufruf des Meldungsfensters würde nun beispielsweise so aussehen:

MsgBox HoleUebersetzung(-1), vbOkOnly,

HoleUebersetzung(-2)

Menüs

Bei Menüs gibt es ebenfalls verschiedene Texte, die zum Beispiel in den Eigenschaften Caption und ToolTipText gespeichert werden.

Menüs erstellt man typischerweise entweder über die Benutzeroberfläche, indem man den Anpassen-Dialog öffnet und die gewünschten Menüs zusammenstellt, oder man erzeugt diese komplett per VBA.

Bezüglich der Mehrsprachigkeit ergeben sich ebenfalls mehrere Möglichkeiten. Da man durchaus per VBA auf die vorhandenen Menü-, Symbol- und Kontextmenüs zugreifen kann, wäre es theoretisch kein Problem, deren Texte genau wie bei Formularen, Berichten und Steuerelementen auszulesen und diese zusammen mit den Übersetzungen in die bereits vorhandenen Tabellen zu schreiben.

Genauso können Sie beim Öffnen der Anwendung die Menüs mit den in den Tabellen gespeicherten Texten für die aktuell verwendete Sprache versehen.

Die zweite Variante für das Erstellen von Menüs ist VBA: Manch ein Entwickler erstellt alle Menüs beim Start der Anwendung oder auch zur Laufzeit. In diesem Fall könnte man die jeweiligen Übersetzungen direkt beim Erstellen der Menüs zuweisen. Allerdings braucht man hier eine weitere Routine, welche beim Wechsel der Spracheinstellungen zur Laufzeit auch die Menüs anpasst - am einfachsten ist es dann wohl, die Menüs komplett neu zu erstellen und mit den entsprechenden Texten zu versehen.

Menütexte einlesen

Wir gehen im Folgenden davon aus, dass die Menüs, die mit einer Mehrsprachigkeitsfunktion ausgestattet werden sollen, bereits vorhanden sind, also entweder per Anpassen-Dialog oder per VBA erzeugt wurden.

Unser Beispielmenü sieht wie in Abb. 2 aus und enthält ein paar verschachtelte Elemente. Nach dem Ändern der Sprache sollen alle Elemente mit neuen Texten ausgestattet sein, wie Abb. 3 zeigt.

pic003.png

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

Auswahlfelder im Ribbon

Vertikale Menüleisten

Platzhalterauswahl per Kontextmenü

Platzbedarf für Text ermitteln

Dynamische Ribbons

Kontextmenüs von A bis Z

Tipps und Tricks

Tipps und Tricks

© 2003-2015 André Minhorst Alle Rechte vorbehalten.