Die Grundlage für die Sprachsteuerung in Portalen sind die zweistelligen Sprachkürzel nach ISO 3166-1.
Mehrsprachigkeit bedeutet nicht nur die sprachabhängige Darstellung von Texten, sondern auch die
Darstellung von Zahlen- und Datumswerten im jeweiligen Land. Auch Farben können kulturell bedingt
unterschiedlich interpretiert werden. Grafiken mit Schriftzügen bekommen ebenfalls einen sprachabhängigen
Aspekt. Auch die Richtung der Schriftzeichenwiedergabe kann ins Spiel kommen. Bei mehrsprachigen Portalen
sind also einige Details zu berücksichtigen und umzusetzen – unabhängig von der eingesetzten Technologie.
Hier finden Sie die nötigen Informationen zum Thema.
2. Portaleigenschaften - Ländereinstellungen
In den Portaleigenschaften, die Sie im Hauptmenü Portal / Portaleigenschaften
erreichen, finden Sie die
Ländereinstellungen. Hier kann das Portal für den internationalen Einsatz konfiguriert werden. Informationen zu
den einzelnen Einstellungen finden Sie hier:
Für die Umschaltung auf ein anderes Format, mit dem z.B. das Datum entsprechend formatiert
angezeigt wird, wird die Zusatzkontrolle
Localeumschalter aus dem
Modul Design verwendet.
Die auswählbaren Formate müssen in den
Ländereinstellungen
aktiviert sein.
4. Titel von Elementen finden und übersetzen
Im den Modulen Applikationen,
Design und
Prozesse
kann nach Elementen, die noch keinen Titelin einer der Portalsprachen haben,
gesucht werden. Die kompletten
Titel aller Elemente von Applikationen und Prozessen
können über das jeweilige Hauptmenü
in Form einer XML-Datei exportiert, übersetzt und wieder importiert werden.
5. Sprachumschaltung in Modulen
Die Sprache, in denen die Titel von Elementen im Portal Manager
in den einzelnen Modulen
angezeigt werden, kann über das Weltkugelsymbol in der
Symbolleiste umgeschaltet werden.
6. Portalmenü
Bei Applikationen, die in der Menüstruktur
eingebunden sind, kann eingestellt werden, dass der Titel der Applikation als Menüpunkt übernommen wird. Ist der
Titel dort bereits
mehrsprachig hinterlegt, so werden auch die Werte für die jeweiligen Portalsprachen übernommen.
Wird die Einstellung Titel von der Applikation übernehmen
deaktiviert, muss für den Menüpunkt der Titel an dieser Stelle mehrsprachig hinterlegt werden.
Für alle anderen Objekte wie Menüordner, Links oder Trenner sind ebenfalls mehrsprachige Titel definierbar, die dann den Menüpunkt
in der jeweils eingestellten Spracheinstellung des
Benutzers ergeben.
7. Layout
Da sich jedes Portal-Layout
aus verschiedenen Containern zusammensetzt, die insbesondere bei barrierefreien Konzepten
per Screenreader ausgewertet werden, müssen die mehrsprachigen Titel
der Container ebenfalls berücksichtigt werden. Im Layout können keine eigenen
Sprachkonstanten verwendet werden. Die einzelnen Elemente im Layout
verwenden entsprechend definierte Portalkonstanten.
Die Einstellungen hier für Zeitzone, Sprache, Format und Layout sind vorrangig zu den Einstellungen, die
in den länderspezifischen Portal-Eigenschaften
gesetzt sind.
9. Applikationen
9.1. Sprachkonstanten in Applikationen
Im Modul Applikationen ist der Einsatz von
Sprachkonstanten in Applikationen nicht nur für mehrsprachige Applikationen sinnvoll –
auch einsprachige Applikationen profitieren vom Einsatz der Konstanten. Da Texte an vielen Stellen wiederholt
auftreten, sind sie über eine zentrale Konstante schneller änderbar. United Planet empfiehlt daher,
Applikationen bereits von Grund auf auf der Basis von Applikationskonstanten zu entwickeln.
Applikationsbezogene Konstanten
können über das Hauptmenü Applikation / Sprachkonstanten verwalten
hinzugefügt, bearbeitet und gelöscht werden.
9.2. Mehrsprachige Titel von Elementen
Wie Sie die Titel von Elementen in mehreren Sprachen hinterlegen können,
erfahren Sie hier.
Der angezeigte Wert aus Konstante und der gespeicherte Wert müssen in diesem Fall identisch sein.
9.4. Mehrsprachige Datensätze
Wie Sie Datensätze in verschiedenen Sprachen erfassen und abhängig von der jeweiligen Spracheinstellung
des Portals in der richtigen Sprache anzeigen, erfahren Sie im Tipps & Tricks-Beitrag
Mehrsprachige Datensätze.
9.5. Mehrsprachige Daten mit doppeltem Primärschlüssel
Mehrsprachige Daten können mit einem doppelten Primärschlüssel
in einer Datengruppe gespeichert werden. Dieser setzt sich aus einem Key und einem ISO-Sprachcode zusammen.
Bei Steuertabellen wie z.B. dem Status, sollte der Key ein sprechender String sein. Bei anderen Daten sollte eine
GUID verwendet werden.
Vor dem Speichern der Applikation kann der Datentyp des vorhandenen Primärschlüssels auf dem Reiter
Expert auf String geändert werden,
damit hier später eine GUID gespeichert werden kann. Für den zweiten Primärschlüssel wird ebenfalls vor dem
Veröffentlichen der Applikation ein neues Datenfeld mit dem Titel Sprache angelegt.
Wenn neue Datensätze angelegt werden, müssen beide Primärschlüssel mit Werten gefüllt werden, damit kein Fehler
in der Datenverarbeitung auftritt. Dazu kann das Sprach-Datenfeld mit einem
Eingabefeld im versteckten Bereich
verbunden werden. Das Eingabefeld wird mit dem Expert-Attribut customdefault,
Wert $lang, mit der aktuellen Portalsprache vorbelegt.
Soll auch der Hauptschlüssel automatisch mit einer
GUID erzeugt werden, wird hier im Expert-Attribut customdefault der Wert
$Unique.newGuid() eingetragen und das Feld ebenfalls in den versteckten Bereich verschoben.
Ein häufiges Szenario ist die Verwendung von mehrsprachigen Stammdaten wie z.B. Status oder Kategorien über
eine Referenz in Bewegungsdatensätzen. Wird eine Referenz
auf eine Datengruppe mit zwei Primärschlüsseln erzeugt, muss für den Sprachschlüssel die Sessionvariable
Sprache zugeordnet werden. Der andere Primärschlüssel wird auf automatisch erstellt belassen.
Intrexx liefert nun über die Referenz immer den entsprechenden Sprachtext im Browser.
9.6. Mehrsprachige Daten mit einem Kerndatensatz als Bezug
Diese Variante ist sinnvoll, wenn neben mehrsprachigen Texten viele weitere Daten, die sprachunabhängig sind, zu einem Datensatz
definiert werden. D.h. im Kerndatensatz befinden sich alle sprachunabhängigen Daten und im Sprachdatensatz alle Textinformationen.
Die Texte-Datengruppe wird in der Datengruppe des Baumes referenziert und die Sprache auf die aktuelle Portalsprache eingestellt.
Wichtig ist, dass die in der Beschriftungstabelle gespeicherten Einträge als Hauptschlüssel die ID des Baumeintrages erhalten,
um eine Synchronität zwischen den beiden Datengruppen und den Datensätzen herzustellen.
In der Konfiguration der Baumkontrolle wird dann als Titel der Beschriftungstext über die Referenz zugeordnet.
Dieser wird automatisch anhand der eingestellten Portalsprache ermittelt und angezeigt.
Zur Anlage eines neuen Baumeintrags muss in dieser Konstellation ein spezielles Verfahren angewendet werden,
da in der Datengruppe des Baums keine Bezeichnung gespeichert wird. Dazu wird eine Eingabeseite mit einem
Eingabefeld ohne Datenfeldverknüpfung angelegt.
Beim Speichern wird mit JavaScript der erfasste Text als Request-Parameter an einen Prozess übermittelt.
function newTreeEntry(oAction)
{
var oDescription = getElement("GUID_EINGABEFELD");
oAction.oUp.oTarget.addParam = Helper.setQsValueByParam(
"rq_customDescription", oDescription.value, oAction.oUp.oTarget.addParam);
return true;
}
Im Prozess wird der Requestwert über einen Datengruppen-Ereignisbehandler, der auf das Einfügen eines neuen Baumeintrags hört,
mit Groovy-Skript ausgelesen und in der Beschriftungstabelle der entsprechende Eintrag angelegt. Zeitgleich werden die Datensätze
für die Sprachvarianten erzeugt. Zudem wird der Referenzwert in der Baumdatengruppe auf den Datensatz in der
Beschriftungstabelle eingetragen.
In der Regel wird ein mehrsprachiger Datensatz immer ausgehend von einer Sprache erzeugt. Hat der Ersteller
sein Portal in der englischen Spracheinstellung, wird der Datensatz in Englisch erzeugt. Alle weiteren
Sprachvarianten müssen dann zusätzlich erstellt werden. Dies kann manuell erfolgen, was jedoch bei mehrsprachigen Portalen
einen entsprechenden Aufwand darstellt. Hier kann ein Prozess die Vorarbeit übernehmen und für jede Sprache
im Portal automatisch die Datensätze für die jeweilige Sprachvariante erzeugen. Die Weiterentwicklung eines Portals kann
auch das Hinzufügen weiterer Portalsprachen umfassen. Auch hier kann ein Prozess die Datensätze für die neuen
Sprachvarianten nachträglich erzeugen. Insbesondere bei Stammdaten wie z.B. Statusdefinitionen ist dies
wichtig, um die Funktionsfähigkeit der Applikation unter der neuen Sprache zu gewährleisten.
Das nachfolgende Groovy-Script zeigt exemplarisch, wie beim Einfügen neuer Portalsprachen in einer
Datengruppe Datensätze noch fehlender Sprachvarianten erzeugt werden.
def conn = g_dbConnections.systemConnection
// Ermittelt alle vorhandenen Sprachen des Portals
def l_aLanguages = g_portal.defaultLocale.languages
// Für jede Portalsprache
l_aLanguages.each
{
// Prüfung, ob für diese Sprache in einer der Applikationstabellen
// mindestens ein Eintrag existiert
def l_strIsoLanguage = it
def l_intLanguageDetect = g_dbQuery.executeAndGetScalarIntValue(conn,
"SELECT COUNT(*) FROM DATAGROUP('GUID_DATENGRUPPE') WHERE LANG = ?", 0) {
setString(1, l_strIsoLanguage)
}
if(l_intLanguageDetect == 0)
{
// Language not exist in data, add language Variants
def stmtData = g_dbQuery.prepare(conn,
"SELECT STRID FROM
DATAGROUP('GUID_DATENGRUPPE')")
def rsData = stmtData.executeQuery()
while (rsData.next())
{
def l_strTypeId = rsData.getStringValue(1)
g_dbQuery.executeUpdate(conn, "INSERT INTO
DATAGROUP('GUID_DATENGRUPPE')
(TREEID, LANG, STRNAME) VALUES (?,?,?)")
{
setString(1, l_strTypeId)
setString(2, l_strIsoLanguage)
setString(3, "Translate")
}
}
rsData.close()
stmtData.close()
}
}
11. Mehrsprachige Suche
11.1. Sprachisolierte Suche
Die sprachisolierte Suche orientiert sich an der eingestellten Portalsprache und liefert nur Inhalte,
die dieser Sprache entsprechen, im Suchergebnis zurück. Dazu muss die Sprache des Portals in der Suchkonfiguration
gefiltert werden. Das Datenfeld Sprache wird mit dem Systemwert Sprache verglichen. Nur bei Gleichheit werden die jeweiligen Suchtreffer angezeigt.
11.2. Suche mit Sprachauswahl durch den Anwender
Die Sprachauswahl durch den Anwender kann mit Hilfe von Facetten
erfolgen. Dazu wird zunächst die Facette "Sprache" definiert.
Die Facette wird in der Suchkonfiguration mit dem Datenfeld "Sprache" verknüpft.
Sie bietet nun alle Sprachen, die bei der Suche gefunden werden, zur Filterung des Suchergebnisses an.
Da die Suchmaschine die Facetten nicht interpretieren kann, werden in der Auswahl die ISO-Sprachcodes aufgelistet.
12. Mehrsprachige E-Mails
12.1. E-Mail an einen einzelnen Empfänger
Sendet ein Benutzer eine E-Mail ab, so kann dessen Spracheinstellung in einem Prozess ermittelt werden.
Der Prozess kann dann die ermittelte Sprache in einer E-Mailaktion
auf die zu versendende E-Mail anwenden.
Der Betreff kann durch entsprechende Übersetzung des sprachabhängigen Betreffs definiert werden.
Um die Sprachsteuerung individueller zu gestalten, kann vor der Ausführung der E-Mail-Aktion
die Sprache mit Groovy-Skript ermittelt und in den Verarbeitungskontext geschrieben werden, um die E-Mail-Aktion
damit zu steuern.
// Sprache des aktuellen Benutzers
def l_strLanguage = Locale.forLanguageTag(g_language).getDisplayLanguage(new Locale(g_language))
// Sprache eines beliebigen Benutzers
// (über dessen GUID und das Benutzerobjekt)
def l_objUser = g_om.getUser(l_strUserGuid)
def l_strLanguage = objUser.getDefaultLanguage()
// Sprache in den Verarbeitungskontext legen
g_sharedState.maillanguage = strLanguage
Im Eigenschaftendialog der E-Mail-Aktion kann auf
dem Reiter Expert der Parameter language
hinzugefügt und die aus dem Verarbeitungskontext ermittelte Sprache als Wert mit
urn.sharedState.maillanguage übergeben werden.
Der Betreff kann auch über eine
Sprachkonstante definiert werden.
Dazu wird mit der entsprechenden Groovy-Methode der Inhalt der Sprachkonstante unter Angabe der zuvor ermittelten Sprache ausgelesen.
// Betreff aus Sprachkonstante ermitteln und in
// den Verarbeitungskontext legen
g_sharedState.subject = g_i18n.application("APP_GUID").language(l_strLanguage)["MYMAILSUBJECT"]
Der Wert aus dem Verarbeitungskontext wird dann mit urn.sharedState.subject
in den statischen, sprachunabhängigen Betreff der E-Mail-Aktion eingetragen.
Wenn die E-Mail auch per CC und BCC an jeweils einen Empfänger mit unterschiedlichen Sprachen versendet wird, kann diese
Vorgehensweise nicht angewendet werden. Hier wäre die separate Behandlung mit jeweils eigenen E-Mail-Aktionen in der
Prozesskette notwendig. Der Nachrichtentext könnte ebenfalls in der vorangestellten Groovy-Aktion ermittelt und in den
Verarbeitungskontext gelegt werden. Der Verarbeitungskontext kann dann in Velocity ausgelesen und daraus der E-Mail-Body erzeugt werden.
12.2. E-Mail an Verteiler
Um die Mehrsprachigkeit beim Versand von E-Mails an einen Verteiler zu berücksichtigen, gibt es
zwei Lösungsansätze:
Pro Sprache wird eine E-Mail-Aktion erstellt, in der die Empfänger nach ihrer eingestellten Sprache selektiert werden.
Die E-Mail wird mit Groovy-Skript unter Berücksichtigung der Sprache des jeweiligen Empfängers erzeugt.
Hier muss der Body der Nachricht jedoch selbst konstruiert werden.
Ein mögliches Grundkonstrukt ist nachfolgend aufgeführt. Allerdings dürfen als Empfänger über den Verteiler
in diesem Fall nur Benutzerobjekte bestehen.
import de.uplanet.lucy.util.TextUtil
import de.uplanet.lucy.server.mail.GroovyMailBuilder
import de.uplanet.lucy.server.mail.MailUtil
import de.uplanet.lucy.server.portalserver.PortalServerPath
import de.uplanet.lucy.server.composer.UrlBuilder
// Inhalt einer Verteilerkontrolle (GUIDs der Empfänger)
def l_strRecipients = g_record["640...DAC"].value
def l_aReceipients = TextUtil.stringToList(strRecipients)
aReceipients.each {
def strEmail = g_dbQuery.executeAndGetScalarStringValue(conn, "SELECT
STRMAILBIZ FROM VBLUSER WHERE STRGUID = ?", null) {
setString(1, it)
}
if(strEmail != null && strEmail != "")
{
def mail = new GroovyMailBuilder().composeMail {
headers = [
"X-IX-Share": "intrexx-share-notification",
]
from = MailUtil.getDefaultSenderAddress()
to = strEmail
subject = l_mailHelper.getMailTitle()
contentType = "text/html; charset=UTF-8"
body << """<html> … </html>"""
}
mail.drop()
}
}
13. Sprachweichen
Mit Sprachkonstanten
kann der Einsatz von Sprachweichen in Programmcodes weitgehend vermieden werden. Für besondere Fälle können die folgenden Konstrukte dennoch nützlich sein.
Um eine Sprachweiche in JavaScript zu realisieren, muss zunächst die eingestellte Sprache des Portals mit
dem oHtmlRoot-Objektermittelt werden.
var l_lang = oHtmlRoot.oUp.oFormatInfo.lang;
switch(l_lang)
{
case "de":
// Code für deutsche Sprache
break;
case "en":
// Code für englische Sprache
break;
:
default:
// Fallback, falls Sprache fehlt (Standardsprache des Portals)
}
if(l_lang == "de")
{
// Code für deutsche Sprache
}
else if(l_lang == "en")
{
// Code für englische Sprache
}
:
else
{
// Fallback, falls Sprache fehlt (Standardsprache des Portals)
}
Über das oHtmlRoot-Objekt kann auch die eingestellte Standardsprache
des Portals ermittelt werden.
var l_defaultLang = oHtmlRoot.oUp.oFormatInfo.defaultLang;
Um im Velocity-Kontext sprachabhängige Weichen zu konstruieren, kann die Intrexx-Systemvariable $lang verwendet werden, die die aktuell eingestellte Portalsprache enthält.
#if($lang == "de")
// Sprachabhängiger Code
#elseif($lang == "en")
// Sprachabhängiger Code
#else
// Fallback bei fehlender Sprache
#end
Um Daten in Groovy-Skript mehrsprachig zu erzeugen bzw. anhand der Sprache bestimmte Aktionen zu steuern
stehen verschiedene Möglichkeiten zur Verfügung.
// Aktuelle Portalsprache
g_language
// Standardsprache des Portals
g_defaultLanguage
// Aktuelle Portalsprache über den Requestparameter rq_Lang
g_request.get("rq_Lang")
// Standardsprache Benutzers aus der aktuellen Session
g_session.user.getDefaultLanguage()
Über eine switch-case-Konstruktion lässt sich eine Sprachweiche für verschiedene Zwecke gestalten.
switch(g_language)
{
case "de":
return german
break
case "en":
return english
break
default:
return english
}
14. Mehrsprachige Grafiken
Werden Grafiken über Datengruppen verwaltet, so können diese pro sprachabhängigem Datensatz definiert werden.
Schwieriger wird die Anzeige von sprachabhängigen Grafiken im Layout, da dies technisch nicht vorgesehen ist.
Hier gibt es den Lösungsansatz, die Grafik im Dateinamen mit dem ISO-Sprachcode zu versehen und mit der im
Portal eingestellten Sprache die URL mit Velocity-Skript zu konstruieren. Das folgende ActionControl erzeugt
einen DIV-Container mit einem Link auf die Startseite des Portals sowie der sprachabhängigen Einbettung
einer Grafik. Wichtig ist die Benennung der Grafik mit logo_<iso-sprachkürzel>.png.
Die Kontrolle baut den Dateinamen dynamisch unter Verwendung der eingestellten Portalsprache
$lang zusammen.
In allen Sprachkonstanten vom Typ
Sprachkonstante wird als Velocity-Ausdruck evaluiert
können bei Verwendung auf Applikationsseiten Velocity-Variablen eingebettet werden. Voraussetzung für die
korrekte Funktion ist die Verfügbarkeit der Variable im Seitenkontext. Im folgenden Beispiel ist die Variable
$Rooms im Text eingebaut, damit der reine Text um eine dynamische Angabe
– hier die Anzahl der Räume – ergänzt wird.
Konstantentext:
Es existieren $Rooms Räume/Raum zu diesem Gebäude!
Ausgabe: Es existieren 10 Räume/Raum zu diesem Gebäude!
16. Sprachumschalter mit Flaggen
Ein Sprachumschalter mit Flaggen macht nur bei wenigen Portalsprachen Sinn, und auch nur in Kombination mit
dem Sprachnamen. Bei Sprachen wie Englisch, die durch mehrere Länder und somit Flaggen belegt sind,
ein Flaggen-Sprachumschalter ebenfalls nicht immer ideal. Intrexx liefert bereits ein Set an Grafiken
mit Flaggen, die als Namen das ISO-Sprächkürzel besitzen. Fügen Sie zunächst im
Portal-Verzeichnis internal\system\vm\html\actioncontrol eine neue Datei mit dem Namen
"languageswitch_flag.vm" ein und kopieren Sie den nachfolgenden Velocity-Code in diese Datei.
Nach dem Neustart des Portal Managers kann die Zusatzkontrolle nun entsprechend ausgewählt und im Layout hinzugefügt werden.
17. XML-Exportformat für Sprachkonstanten
Das XML-Format für
Import bzw. Export von Sprachkonstanten fasst alle Textkonstanten im Block <texts> zusammen.
Jede Konstante wird über ein <element> definiert. Als Key wird der Konstantenname angegeben,
wobei der Wert des type immer constant lauten muss. Die einzelnen
Sprachvarianten werden als <text>-Elemente unter dem <element> notiert.
Neben dem ISO-Sprachcode im language-Parameter wird der Bereitstellungsmodus
(ALL, VELOCITY, JAVASCRIPT) der Konstanten definiert.
Direkt an den Kontrollen definierte Sprachtexte werden im <element>-Tag mit den Parametern
type (Kennung des Objekts) und dem key (GUID der Kontrolle) kenntlich gemacht.
Im <text>-Tag werden weitere Angaben zum Export über die Parameter
timestamp (Export-Zeitstempel), (application oder portal),
guid (GUID der Applikation) und refLanguage (Bezugssprache) definiert.
Parameter
Wert
Beschreibung
timestamp
YYYYMMTTHHMMSS
Export-Zeitstempel
type
application portal
Unterscheidung, ob Export aus einer Applikation oder dem Portal stammt.