Kontakt & Service
Jetzt Beratung vereinbaren

In wenigen Schritten einen Beratungs­termin mit unseren Experten buchen.

Anwender Helpdesk

Hilfestellung bei Problemen in Ihren SAP-Systemen.

Schulungen

Unser Schulungsangebot. Jetzt informieren!

Webinare

Unser Webinarangebot. Jetzt informieren!

Übersetzungen SAP S/4HANA

News & Wissen Übersetzungen im SAP S/4HANA - von App bis Z-Tabelle

Wenn eine Anwendung im SAP-Umfeld mehrsprachig genutzt werden soll, ist es wichtig, sich schon vor der Entwicklung darüber im Klaren zu sein, wie die Texte dynamisch gestaltet werden können. Dabei gibt es eine Vielzahl von Möglichkeiten, Texte übersetzbar anzulegen. Und wer unterschiedliche Entwicklungsobjekte wie SAP Fiori Apps, Dynpros, SAP Adobe Forms etc. anlegt, wird nicht mit einer dieser Optionen auskommen. Dieser Blogartikel gibt eine Überblick über sprachenabhängig pflegbare Textelemente im SAP und deren Nutzungsmöglichkeiten.

Die SE63 ist dabei die zentrale Transaktion, über die sich fast alle hier vorgestellten Texte übersetzen lassen. Der Einstieg über den Transaktionscode ist allerdings oft umständlich, da man sich erst durch eine Liste klicken muss, um zu dem Objekt zu gelangen, das übersetzt werden soll. Dazu muss man wissen, um was für einen Objekttyp es sich handelt. Teils werden dabei auch Objektnamen, -nummern, oder -ids abgefragt, die man sich vorher aus einer anderen Transaktion oder einer Tabelle erschließen muss.

Komfortabler ist es, aus der Ansicht des Objektes (etwa in der SE80) direkt in die Übersetzung zu springen. Das funktioniert bei nahezu allen Objekten, Ausnahmen sind unten aufgeführt.

Abbildung 1: In der SE63 gelangt man erst über mehrere Menüpunkte an das gewünscht Objekt

Abbildung 2: Schneller geht es mit „Springen->Übersetzen“

Die Verwendung dynamischer Texte dient aber nicht nur der Übersetzbarkeit, sondern hilft auch, die Übersicht über die in einem Programm verwendeten Texte zu behalten - und ist in jedem Fall einem Hardcoden vorzuziehen.

Datenelemente

Bei Datenelementen denkt man zunächst an die Verwendung in Datenbanktabellen, dabei können Sie auch für Übersetzungen eine wichtige Rolle spielen. An verschiedenen Stellen kann man nämlich auf Datenelemente referenzieren, um ihre Feldbezeichner zu verwenden. Diese werden wiederum immer in der Systemsprache angezeigt, sofern eine Übersetzung vorhanden ist.

Bei der Pflege sollte man darauf achten, dass es Bezeichnungen in verschiedenen Längen gibt. Womöglich sollte man die SAP Standard-Datenelemente nutzen, da diese mit den Sprachpaketen bereits die entsprechenden Übersetzungen erhalten.

Abbildung 3: Feldbezeichnung eines Datenelementes

Verwendung in ALV Grids

In einem dynamisch aufgebauten Feldkatalog eines ALV Grids kann man die Spaltenüberschriften aus Datenelementen beziehen.

Beispiel: In einem BADI wollen wir den Feldkatalog mit einer Spalte für die Materialart erweitern. Wir beziehen uns in der Feldkatalogstruktur auf die MARA-MTART und bekommen in der zusätzlichen Spalte gleich eine übersetzbare Überschrift. In diesem Fall referenzieren wir auf ein Element aus dem Standard und brauchen uns um die Übersetzung nicht mehr zu kümmern.

Abbildung 4: Feldkatalog mit Referenz auf Datenelement

Mit einer selbst angelegten Struktur von Datenelementen kann direkt ein ALV Grid aufgebaut werden, das die entsprechenden Datenelemente als Spalten hat und die entsprechenden Texte als Überschriften, zum Beispiel mit der Klasse „cl_salv_table“. Wenn das Spaltenlayout nicht definiert wird, richtet sich die Spaltengröße nach dem Inhalt und die Überschrift wiederum nach der Spaltengröße, wobei immer die längste mögliche Bezeichnung verwendet wird.

Abbildung 5: ALV Grid mit einer Z-Struktur

Verwendung in Dynpros

Textelemente in Dynpros können direkt mit einem Datenelement verknüpft werden. Sie beziehen dann ihren Text aus dem Feldbezeichner und werden automatisch übersetzt.

Praktisch: Es kann gewählt werden, welcher der Feldbezeichner verwendet werden soll. Auch Buttons können Ihre Beschriftung aus Textelementen erhalten.

Einschränkung: Wenn der Button auch ein Icon enthalten soll, kann die Größe des Buttons nicht mehr manuell geändert werden, sondern richtet sich dann nach der Länge des Feldbezeichners.

Reports / Programme

Die Beschreibungen der Datenelemente befinden sich in der Tabelle DD04T, aus der sie theoretisch auch innerhalb eines Programmes sprachenabhängig gelesen werden können.

Abbildung 6: Bezeichner von Datenelementen in der DD04T

Fiori Launchpad

Das Übersetzen des Fiori Launchpads gehört zu den umständlicheren Aufgaben, denn hier gibt es keinen komfortablen Direkteinstieg in die Übersetzung. Und in der SE63 kommt man an die Kachel- und Gruppentexte nur mit einer ID, die bekannt sein muss.

Um diese zu finden, rufen wir die Transaktion „/ui2/flc“ auf. Hier geben wir den Katalog ein, in dem sich die Kachel befindet, wählen die Anpassungsschicht „Customizing“ und setzen den Haken unten bei „Mit Text-ID“. In der Ausgabetabelle blenden wir die Spalte „WD-EigKonfigSchlüssel“ ein, welche die Konfigurations-ID enthält.

Der Vollständigkeit halber sei erwähnt, dass dies Übersetzungen im CUST Scope betrifft; für den CONF Scope verwenden wir den Objektnamen „WDY_CONFIG_COMPT" und wählen die Anpassungsschicht „Konfiguration“.

Abbildung 7: Transaktion /UI2/FLC

In einem SAP S/4HANA-System ab 1709 SP02 gibt es die Transaktion /ui2/flt, über die sich Texte mit einem Textfilter finden lassen.

In der SE63 wählen wir im Reiter „Übersetzung->ABAP Objekte->Kurztexte“ die „00 Metaobjekte->TABL Tabellen“ aus. Dort geben wir als Objektnamen „WDY_CONF_USERT2“ an und bekommen nach Auswahl von „Bearbeiten“ eine Selektionsmaske zu sehen.

Abbildung 8: Fiori-Kacheltexte in der SE63 finden

In dieser finden wir mit Hilfe der eben beschafften Konfigurations-ID den entsprechenden Text. Der Benutzerscope ist dabei A und der Konfigurationstyp 07.

I18n Texte für SAPUI5-Apps

In SAPUI5-Anwendungen werden Textdateien mit einer bestimmten Namenskonvention verwendet, um übersetzbare Texte anzulegen. Diese Texte werden über ein Model vom Typ RessourceModel eingebunden, das in der manifest.json wie folgt definiert wird:

Die Bezeichnung I18n steht für Internationalization (I+18 Buchstaben+n). Im Unterordner „i18n“ können wir jetzt für jede Sprache Dateien mit folgenden Namenskonventionen anlegen:

  • Die Datei „i18n.properties“ als Standarddatei und Fallback, falls keine passende Sprache gefunden wurde
  • Für eine Sprache eine Datei „i18n_“ + Sprachschlüssel + „.properties“, also z. B. „i18n_en.properties“. für die englische Übersetzung
  • Für eine Sprache in einem spezifischen Landesdialekt lautet der Dateiname:  „i18n_“ + Sprachschlüssel + „_“ + Länderkennzeichen + „.properties“, also zum Beispiel . „i18n_en_US.properties“ für amerikanisches Englisch

Die Texte werden in den Dateien untereinander weg ohne Trennzeichen in dem Format  „Schlüssel  = Text“ geschrieben. Da für jede Sprache eine Datei gepflegt werden muss, müssen neue Textschlüssel dann auch in alle I18n Dateien eingepflegt werden. Wird ein Schlüssel in einer sprachspezifischen Datei nicht gefunden, versucht das Model den default-Wert aus der i18n.properties zu lesen.

Abbildung 9: Aufbau einer i18n-Datei

In den Apps werden die Übersetzungen in den XML Views durch Data Binding eingebunden. In der Text Property des entsprechenden Controls wird auf den Textschlüssel in der I18n verwiesen.

Abbildung 10: Data Binding an das I18n-Model

Im Controller können die Texte aus dem I18n Model mit folgender Methode ausgelesen werden:

this.getView().getModel("i18n").getResourceBundle().getText("Schlüssel");

Es bleibt zu beachten, dass die Browsersprache zur Wahl der Übersetzung herangezogen wird und diese sich eventuell von der des SAP-Nutzers, der die Backendservices aufruft, unterscheidet.

Nachrichtenklassen

In Nachrichtenklassen werden Strings in jeweils einer Länge von 73 Zeichen mit einer zugehörigen ID gespeichert. In diesen 73 Zeichen können mehrere Platzhalter für Variablen enthalten sein, so dass die tatsächliche Nachricht länger als 73 Zeichen werden kann. Die Texte einer Nachrichtenklasse lassen sich mit einer Zeile Code auslesen und kommen dabei praktischerweise direkt in der Systemsprache zurück. Besonders für Fehlermeldungen, Popuptexte etc. sind Nachrichtenklassen sehr gut geeignet.

Beispiel:

Wir haben in unserer Nachrichtenklasse folgende Nachricht:

Abbildung 11: Nachricht in einer Nachrichtenklasse

Wählen wir die Zeile aus, kommen wir über „Springen->Übersetzen“ nach Auswahl der Sprache direkt in die Übersetzung; bei Nachrichtenklassen kann auf diese Art immer nur eine Nachricht zur Zeit übersetzt werden.

Abbildung 12: Übersetzung eines Nachrichtenkurztextes

In unserem Code können wir diesen Text mitsamt Variablen direkt in der Systemsprache beziehen und verwenden zum Beispiel als Text für eine Ausnahme:

Abbildung 13: Aufruf eines Nachrichtenkurztextes im Code

Auch für Programm / klassenübergreifende GUI Elemente (z. B. Buttons und Titel in Pop-ups) kann man sich eine eigene Nachrichtenklasse anlegen. Wenn Texte nur innerhalb eines Programms oder einer Klasse verwendet werden bieten sich allerdings eher Textelemente dafür an.

Textelemente

Klassen und Programmen können eine eigene kleine Sammlung von Texten zugeordnet werden, die innerhalb dieser recht einfach verwendet werden können. Nach Auswahl einer Klasse oder eines Programmes in der SE80 kann man über die Symbolleiste oder „Springen->Textelemente“ die Textelemente bearbeiten. Springen / Übersetzen wiederum listet dann alle Textelemente zur Übersetzung auf, womit diese wesentlich komfortabler zu übersetzen sind als Nachrichtenklassen. Dafür sind Textelemente in ihrer Länge wesentlich beschränkter und auf die Verwendung in einem Programm / einer Klasse beschränkt. Die Texte können im Code mit „TEXT-Nummer“ verwendet werden, also Text mit Index 001 mit „TEXT-001“ usw.

In Programmen gibt es zudem extra Textelemente für Selektionstexte, also die in den Select Options definierten Variablen. Werden diese mit einem Tabellenfeld verknüpft, bekommen sie einen Dictionary-Bezug und damit wieder eine automatische Übersetzung aus dem Datenelement.

Im folgenden Beispiel wird für die Überschrift des Selektionsblockes das Textelement 002 verwendet. Die Select Options nehmen Bezug auf Tabellenelemente und sind so mit den entsprechenden Datenelementen verknüpft:

Abbildung 14: Verwendung eines Textelementes in einem Selektionsbild

So sehen entsprechend die Textsymbole und die Selektionstexte aus:

Abbildung 15: Textelemente eines Programmes

Und das Selektionsbild nach Anmeldung in Deutsch oder Englisch, die Blocküberschrift „Selektionskriterien“ entspricht dem Textsymbol 002 und die Select Options sind mit den Selektionstexten verknüpft:

Abbildung 16: Selektionsbildschirm mit Übersetzung durch Textelemente

ScreenPainter-Texte

Oben wird erklärt, wie man Dynpro-Buttons und Textelemente mit Datenelementen verknüpfen kann, um diese übersetzbar zu gestalten. Nun gibt es aber auch Texte für GUI-Elemente oder andere Texte, für die man kein Datenelement anlegen möchte. Kein Problem - für alle nicht dynamischen Texte in einem Dynpro werden automatisch Screenpainter-Texte angelegt, die zentral übersetzt werden können. Dazu wählt man in der SE80 das Dynpro-Bild aus und geht auf „Springen->Übersetzen“. Nach Auswahl der Zielsprache wird entweder direkt eine Liste der Screenpainter-Texte oder – wenn vorhanden - zunächst eine Auswahl zwischen Texten und Header angezeigt. Die mögliche Länge der Texte kann dabei durch das Layout, etwa die fixe Größe eines Buttons, eingeschränkt sein.

Abbildung 17: Übersetzung von Screen Painter-Texten

Abbildung 18: Übersetzung von Screen Painter-Texten

SapScript- und Smartforms-Texte

SapScript und Smartforms sind als Formulartechnologien im SAP die Vorgänger von Adobe Forms. Sie haben jeweils ihre eigene Art von Textobjekten. Adobe Forms selbst hat keine eigenen Textobjekte und kann SapScript- und Smartforms-Texte nutzen.

Diese sind auf die Nutzung in Formularen ausgelegt und können sehr lange Texte, Variablen und Formatierungen enthalten. Dennoch ist es auch denkbar, sie für kürzere Texte - etwa Tabellenüberschriften - in einem Formular zu verwenden, vor allem bei Texten, die in mehreren Formularen benötigt werden. So ist immer nur die Übersetzung an einer Stelle notwendig.

SapScript-Texte können in der Transaktion „SO10“ bereits in mehreren Sprachen angelegt werden.

Abbildung 19: SapScript-Text in der SO10 anlegen

Sie haben den Nachteil, dass sie standardmäßig nicht in einen Transportauftrag geschrieben werden. Um SapScript-Texte zu transportieren kann bis SAP S/4HANA 1909 die Transaktion „TXBA“ genutzt werden. Hier wählt man als Selektionskriterium Textobjekt „TEXT“, um SapScript-Texte zu erhalten.

Abbildung 20: TXBA zum Transport von SapScript-Texten

Auf neueren HANA-Systemen gibt es diese Transaktion nicht mehr, über die SE38 kann hier der Report „RSTXTRAN“ genutzt werden.

SmartForms-Texte werden in der Transaktion „SMARTFORMS“ angelegt. So wie SmartForms die Folgetechnologie von SapScript ist, gilt dies auch für die Textobjekte.

Smartforms-Texte lassen sich nicht direkt in verschiedenen Sprachen anlegen, für die Übersetzung muss in der SE63 im Menü „Übersetzung->ABAP->andere Texte->B5 SapScript: Formulare und Stile->SAP Smart Form“ gewählt werden.

Abbildung 21: Übersetzung von SmartForms-Texten in der SE63

Verwendung in Adobe Forms

SapScript- oder Smartforms-Texte können in einem Adobe Form durch Anlage eines Textknotens eingebunden werden. Über den Texttyp wird eines der Formate gewählt.

Hinter dem Texttyp „Textbaustein“ steht der SmartForms-Text, dieser wird nur über seinen Namen referenziert.

Abbildung 22: SmartForms-Text als Textknoten in einem Adobe Form

Hinter dem Texttyp „Include“ steht SapScript-Text.

Abbildung 23: SapScript-Text als Textknoten in einem Adobe Form

In beiden Fällen gibt es einen Parameter Textsprache. Für diesen kann eine Variable angegeben werden, um die Sprache zu steuern. In dem Beispiel oben ist es die Variable „GV_LANGU“, die in der Schnittstelle befüllt werden kann. Wenn die Standarddruckprogramme genutzt werden, gibt es dort oft bereits ein Feld mit der Kundensprache.

Adobe Forms-Texte

Ähnlich den Dynpros wird bei Adobe Forms für jedes beschreibbare Objekt (zum Beispiel ein Textfeld) ein übersetzbarer Text angelegt. In der Transaktion SFP gelangt man entsprechend über „Springen->Übersetzen“ dorthin.

Abbildung 24: Übersetzung aus Transaktion SFP

Nach der Übersetzung sollte man das Adobe Form aktivieren, damit die Übersetzung ebenfalls aktiv wird.

Sprachtransporte

Übersetzte Textobjekte werden nicht automatisch in einen Transport geschrieben. Der Transport der Übersetzungen ist mit Hilfe der Transaktion SLXT aber recht einfach möglich.

Beispiel: Wir haben von allen der oben genannten übersetzbaren Objekte mehrere angelegt und diese mit Hilfe der SE63 in Englisch und Italienisch übersetzt. In der Eingabemaske wählen wir in der Zielsprache „alle vorhandenen Sprachen“ und „Sprachtransporte erzeugen“. In der Selektion Transportauftrag geben wir einen Beschreibungstext ein, der hinter alle Sprachtransporte gesetzt wird und wählen „Workbench“. Dann wählen wir als Filter noch unseren SAP-Nutzer, um nur Objekte zu erfassen, die wir selbst bearbeitet haben.

Abbildung 25: Sprachtransport erzeugen in der SLXT

Nach dem Ausführen wird zu jeder Sprache die Anzahl der mit den Selektionskriterien gefundenen Objekte gezeigt.

In der SE01 sind dann die beiden angelegten Sprachtransporte zu finden und über das Baumdiagramm können die enthaltenen Elemente geprüft werden.

Fazit

Ich hoffe, die Übersicht in diesem Artikel hilft Ihnen bei Ihrer nächsten Übersetzungsaufgabe. Bookmarken Sie ihn gerne, um auf das nächste mehrsprachige Projekt vorbereitet zu sein.

Mehrsprachigkeit in SAP ist nicht schwierig, es gilt nur wie so oft: Gewusst wie!

Newsletter Setzen Sie auf fundiertes Wissen aus allen Bereichen unserer Branche. Regelmäßig und stets aktuell.
Beratende Person
Kontakt Haben Sie Fragen oder wünschen weitere Informationen? Unsere Experten beraten Sie gerne.