Management von Sprachvarianten am Beispiel unseres iiRDS-Blogs
Verbindung zwischen Sprachvarianten über iirds:InformationObject und iirds:is-version-of
Ein iiRDS topic beschreibt immer ein Set an Metadaten für
eine konkrete Ausprägung in einer Sprache und einer konkreten Version. Jedes iiRDS topic bekommt deshalb eine eigene ID im Attribut
@rdf:about zugewiesen und ist damit versions- und
sprachübergreifend eindeutig identifizierbar.
In unserem Anwendungsfall 'Blog' ist es essentiell zu wissen, in welchen Sprachen und Versionen dieser Inhalt noch im System vorliegt.
Denn wir wollen, dass unsere LeserLeserinnenLeser und LeserinnenLeser:innen in jedem Blogbeitrag auf die anderen Sprachen umschalten können, in die dieser Beitrag übersetzt wurde. Und dazu müssen die Blogbeiträge eine Beziehung zueinander haben.
Wir haben dafür eine Beziehung zu einer allgemeinen, virtuellen Ressource
hergestellt. In iiRDS nennt sich diese Ressource
iirds:InformationObject, zu der eine Beziehung über die
Eigenschaft iirds:is-version-of hergestellt wird.
<iirds:Topic rdf:about="https://www.c-rex.net/ns/iirds/td/cms/c-rex-dts_001_de-DE">
<iirds:title xml:lang="de-DE">Nie wieder Probleme mit Daten im falschen Format</iirds:title>
<iirds:language>de-DE</iirds:Language>
<iirds:revision>001</iirds:Language>
<iirds:is-version-of>
<iirds:InformationObject rdf:about="https://www.c-rex.net/ns/iirds/td/cms#c-rex-dts"/>
</iirds:is-version-of>
</iirds:Topic>
So kann man auf ein konkretes topic zugreifen und kann eine
Abfrage an das System stellen, mit dem z.B. alle topics mit
der selben Basis-ID des iirds:InformationObject abgefragt
werden.
Damit erhält man alle Versionen und Sprachen, die zu dem aktuellen topic in entsprechender Beziehung stehen.
Wenn man die Abfrage weiter eingrenzt, indem man eine konkrete Version und eine konkrete Sprache abfragt, ist es möglich, im Portal zu dem aktuellen topic in einer anderen Sprache zu wechseln.
Vorteile der Nutzung von iiRDS für die Verwaltung von Mehrsprachigkeit
Wer sein Informations-Design so umsetzt, hat den großen Vorteil, dass jede neue Sprache, die hinzukommt, bereits automatisch zugeordnet ist. Sie muss nicht wie in manch anderem System über Eintragungen in config-Dateien oder URL-Mapping-Tabellen händisch gepflegt werden.
Wie eifrige LeserLeserinnenLeser und LeserinnenLeser:innen unseres Blogs wissen, nutzen wir für die Übersetzung Machine Translation.
Wie schnell und einfach wir eine neue Sprache hinzufügen, haben wir in folgendem animierten gif dargestellt. Im Beispiel ist es die Übersetzung und anschließende Publikation des Blogs nach Polnisch über den Aufruf von zwei Transaktionsszenarien, die wir dafür eingerichtet haben. Die beiden Szenarien in der oXygen XML Umgebung sind zur Veranschaulichung gewählt. Die Publikation lässt sich problemlos in einen Daily Build Prozess integrieren und damit voll automatisieren, sobald ein Beitrag freigegeben ist.
Wer das im Detail nachvollziehen möchte, kann das ausführlicher nachlesen in unserem Beitrag Warum wir bei unserem Blog auf iiRDS und c-rex.net IDS setzen.
Oberflächensprache und Sprache der Inhalte
Bei der Umsetzung unseres Blogs mussten wir uns auch über den Unterschied zwischen Sprache der Benutzeroberfläche und Sprache der Inhalte Gedanken machen. Ein signifikanter Unterschied.
Wenn die Sprache im Menü umgeschaltet wird, was erwarten AnwenderAnwenderinnenAnwender und AnwenderinnenAnwender:innen dann? Weiterhin eine deutsche Benutzeroberfläche und die Inhalte in den jeweiligen Sprachen? Oder soll auch die Bedienoberfläche in die ausgewählte Sprache wechseln?
Für einen Blog ist die Frage vermutlich einfach zu beantworten. Wenn AnwenderAnwenderinnenAnwender und AnwenderinnenAnwender:innen den Inhalt in Polnisch im Web finden, möchten sie auch die Seite vollständig in Polnisch sehen. Und deshalb haben wir uns in unserem Blog auch dafür entschieden.
Dennoch kann es auch andere Fälle geben. Es ist gängige Praxis, manche Inhalte in vielen verschiedenen Sprache anzubieten, manche aber auch nur in Englisch.
Für uns als Softwareunternehmen, das Datenroutinen, automatisierte Prozesse nicht nur für sich selbst nutzt, sondern als Leistung für unsere Kunden anbietet, müssen wir bei der Basisimplementierung eines automatisierten Übersetzungsworkflows diese beiden Fälle unterscheiden und es auch ermöglichen, Fallback-Inhalte (Polnisch nicht verfügbar, dann also Englisch) in einer konkret ausgewählten Sprache zur Verfügung zu stellen.
