Ansicht
Dokumentation

ABENORIGINAL_LANGU_GUIDL - ORIGINAL LANGU GUIDL

TXBHW - Original Tax Base Amount in Local Currency   ABAP Short Reference  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Originalsprache

Beim Anlegen eines neuen Repository-Objekts (beispielsweise eines Programms, einer Klasse oder einer Datenbanktabelle im ABAP Dictionary) muss seine Originalsprache festgelegt werden. Dies passiert implizit durch die aktuelle Anmeldesprache. Alle während der Entwicklung angelegten übersetzungsfähigen Texte des Entwicklungsobjektes, wie zum Beispiel beschreibende Kurz und Langtexte, die Textelemente eines Programms und auch die Dokumentation von Datentypen oder Schnittstellen, werden der angegebenen Originalsprache zugeordnet. Die Erstellung der Texte in anderen Sprachen erfolgt durch einen von der Entwicklung losgelösten Übersetzungsvorgang aus der Originalsprache in die Zielsprachen.

Derzeit gibt es keine technische Unterstützung für die projektweite Ersetzung einer einmal gewählten Originalsprache durch eine andere Sprache.

Originalsprache auf Projektebene festlegen

Legen Sie vor Beginn der Implementierung eine sorgfältig ausgewählte Originalsprache auf Projektebene für die Repository-Objekte fest. Entwickler dürfen ihre Entwicklungsobjekte nur in der für das jeweilige Projekt (oder in Ausnahmefällen für ein Teilprojekt) festgelegten Originalsprache anlegen.

Bei der Festlegung der Originalsprache soll wie folgt vorgegangen werden:

• Bei einsprachiger Besetzung aller an einem Projekt beteiligten Entwicklungsgruppen ist die Originalsprache aller Entwicklungsobjekte die Muttersprache aller beteiligten Entwickler (einsprachige Entwicklung).

• Bei mehrsprachiger Besetzung der Entwicklungsgruppen

• ist die Originalsprache aller Entwicklungsobjekte entweder eine von allen Beteiligten verstandene Sprache - in der Regel Englisch - (einsprachige Entwicklung)

• oder richtet sich die Originalsprache von Entwicklungsobjekten in Teilen des Projektes nach der Muttersprache der hauptsächlich daran arbeitenden Entwickler (mehrsprachige Entwicklung).

Einsprachige Entwicklungsgruppen stellen sozusagen den Idealfall dar, sind heutzutage aber nicht immer zu realisieren. Die beiden möglichen Einstellungen für mehrsprachige Entwicklergruppen - einsprachige und mehrsprachige Entwicklung - erfüllen zwei unterschiedliche Anforderungen, die sich aber widersprechen:

• Bei der Anmeldung an einem System in einer anderen Sprache als der Originalsprache lässt sich im Allgemeinen nicht sinnvoll mit einem in der Entwicklung befindlichen oder neu entwickelten Produkt arbeiten, bis eine Übersetzung der relevanten Texte in die jeweilige Zielsprache vorliegt. Die Übersetzung erfolgt in der Regel in einem nachgelagerten Übersetzungssystem und muss in das Entwicklungssystem zurücktransportiert werden. Aus diesem Grund ist eine effiziente Entwicklung, insbesondere in international besetzten Entwicklungsgruppen (die eventuell auch noch über mehrere Standorte verteilt sind), nur dann möglich, wenn zu Beginn projektweit eine einheitliche Originalsprache festgelegt wird, die es allen am Entwicklungs- und Validierungsprozess beteiligten Personen erlaubt, das Produkt zumindest testweise zu verwenden. Bei einsprachiger Entwicklung in mehrsprachigen Entwicklungsgruppen müssen daher einige, wenn nicht gar alle Entwickler eines Projektes Texte in einer Sprache anlegen, die nicht ihre Muttersprache ist.

• Für die sprachliche und stilistische Überprüfung von Oberflächentexten und Dokumentationen, die von Entwicklern in anderen Sprachen als ihrer Muttersprache angelegt werden, gibt es in der Regel keine Unterstützung in Form von Werkzeugen oder definierten Abläufen. Daher wäre es wünschenswert, dass die an der Entwicklung von Benutzerdialogen und Dokumentationen beteiligten Entwickler idealerweise in ihrer Muttersprache arbeiten und diese Texte dann von geschulten Übersetzern anhand von vorgegebener Terminologie in deren Muttersprache übersetzt werden.

Der zweite Punkt ist der Grund, warum nicht Englisch als allumfassende einheitliche Originalsprache für alle Entwicklungsprojekte gefordert wird, sondern dass einsprachige Entwicklungsgruppen durchaus in ihrer Muttersprache mit eventueller nachgelagerter Übersetzung arbeiten sollten.

Bei mehrsprachigen Entwicklungsgruppen kommt es letztendlich auf den konkreten Fall an, welche Originalsprache für jedes Entwicklungsobjekt festgelegt wird. In der Regel wiegt der erste Punkt schwerer, sodass bei internationaler Entwicklung eine einsprachige Entwicklung durchgeführt werden muss, um die Entwicklungsressourcen für ein Projekt möglichst effektiv zu nutzen. In Einzelfällen kann es bei Teilprojekten, in denen besonders viel Text angelegt werden muss, durchaus auch sinnvoll sein, die Originalsprache gemäß der Muttersprache der Entwickler festzulegen. Dies betrifft insbesondere die SAP-eigene Entwicklung, bei der nach wie vor größere Anteile von deutschsprachigen Entwicklern ausgeführt werden.

Bei mehrsprachigen Projekten sollten betriebswirtschaftlich zusammengehörige Funktionen sprachenrein entwickelt werden, zumindest auf Paketebene. Auch Tabelleninhalte sollten in einer einheitlichen Sprache angelegt werden.

Hinweise

• Da die Originalsprache beim Anlegen eines Repository-Objekts durch die Anmeldesprache festgelegt wird, muss für das Anlegen und Bearbeiten von Repository-Objekten ganz bewusst die Entscheidung für eine Anmeldesprache getroffen werden.

• Unabhängig davon, ob eine ein- oder mehrsprachige Entwicklung innerhalb eines Projektes durchgeführt wird, muss vor Entwicklungsbeginn immer eine einheitliche Terminologie für alle im Projekt angelegten Texte erstellt und diese durchgängig befolgt werden. Bei einer mehrsprachigen Entwicklung sollte die Übersetzung der Terminologiebegriffe in die verwendeten Sprachen möglichst vor Beginn der Entwicklung vorgenommen werden, damit sie von den Entwicklern verwendet werden können. Zudem müssen immer die existierenden Standards für Oberflächentexte und Dokumentation befolgt werden.

SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   BAL_S_LOG - Application Log: Log header data  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 6918 Date: 20240523 Time: 093330     sap01-206 ( 156 ms )