Wenn Software-Lokalisation, dann auch richtig! – Gastbeitrag

Sie sind Softwareentwickler? Dann nehmen sie sich doch einmal eine von Ihnen entwickelte deutschsprachige Software vor und beginnen zu überlegen: Was müsste wohl verändert werden, damit sich diese Software auch gut in Norwegen, China, Brasilien oder in irgendeinem anderen Land verkaufen lässt? Natürlich sollten Texte sorgfältig in die jeweilige Sprache übersetzt werden. Bisweilen reicht das alleine allerdings nicht aus.

Lokalisierung von Software – lohnt sich das überhaupt?

Der Softwaremarkt ist längst auch für kleinere Softwareschmieden nicht mehr auf das eigene Land beschränkt. Es kann sich für sie durchaus lohnen, Software in einer fremden Sprache aufzubereiten und den eigenen Absatzmarkt damit deutlich zu vergrößern. Dieser Prozess nennt sich Lokalisierung. Bevor man eine Lokalisierung plant, sollte man sich den anvisierten Markt allerdings gut ansehen und die Chancen der eigenen Software abklopfen, um Kosten und erwartbare Umsätze in Relation zueinander zu setzen.

•    Bestenfalls gewinnt man den Überblick, wie viele ähnliche Software bereits auf dem Markt existiert und wie hoch der Bedarf im jeweiligen Land an der Software ist, die man lokalisieren möchte.

Lokalisierung von Software ist ein Kosten verursachender Geschäftsprozess, dem man eine Marktanalyse vorausschicken sollte. Wer bereits zu Beginn der Entwicklung seiner deutschen Software intensiver über andere Sprachversionen nachdenkt, sollte zudem Textbausteine auslagern und in den Programmcode einfließen lassen. Eine spätere Übersetzung der Texte einer Software in eine andere Sprache wird dadurch bedeutend einfacher.

Der Kern der Lokalisierung – Übersetzung und Inhaltskontrolle

Wichtig: Der Übersetzer muss den Kontext kennen, in den der zu übersetzende Text in der Software eingebunden ist.

•    Einfaches Beispiel: Nehmen wir an, ein Übersetzer übersetzt eine englische Software ins Deutsche und hat nur das Wort „Copy“ vor sich. In einer Textverarbeitung könnte dieses Wort zum Button gehören, mit dem Text kopiert wird. Alternativ könnte das Wort auch die Anzahl der zu druckenden Exemplare eines Textes im Druckdialog bezeichnen. Was gemeint ist, erschließt sich nur aus dem Kontext. Ähnliches kann beispielsweise beim Wort „Thumbnail“ der Fall sein. Ist ein Daumennagel gemeint. Oder soll das Wort vielleicht besser nicht übersetzt werden, weil es auch im Deutschen für kleine Vorschaubilder steht und in der Software für die Bezeichnung solcher Bilder verwendet werden soll.

Textlänge: Es gibt Beispiele von Software, bei der übersetzter Text nicht mehr lesbar ist, weil das vorhandene Textfeld für diesen Text nicht mehr ausreicht. Sätze mit ein- und derselben Bedeutung haben in unterschiedlichen Sprachen eine unterschiedliche Länge. Wenn ein Engländer beispielsweise „try again“ mit neun Zeichen inklusive Leerzeichen schreibt, heißt es im Deutschen vielleicht „Versuche es erneut“ mit achtzehn Zeichen inklusive Leerzeichen. Bei längeren Textpassagen können sich solche Unterschiede vergrößern und knapp bemessene Textfelder so schnell sprengen.

•    Englischer Text ist also im Allgemeinen kürzer als deutscher, gleiches gilt für tschechischen Text, während etwa Ungarisch meist länger ist als Deutsch.

Bei der Software-Lokalisierung hat man letztlich zwei Möglichkeiten, mit der unterschiedlichen Textlänge von zu übersetzendem und übersetztem Text umzugehen. Entweder man konzipiert die Textfelder von Anfang an großzügig oder bittet den Übersetzer um eine sinngemäße Übersetzung, die aber etwas vom Original abweicht, um in etwa dieselbe Textlänge zu produzieren.

Datum und andere Standards: Letztlich dürfen typische Formate für Zeit- und Datumsangaben nicht vergessen werden. Auch sie müssen Entwickler an das jeweilige Land anpassen, um bei Usern keine Verwirrung aufkommen zu lassen. Der dritte Februar 2011 wird in Deutschland meist 03.02.2011 oder auch 03.02.11 (03/02/11) geschrieben. Typische US-amerikanische Schreibweise des Datums ist jedoch Monat/Tag/Jahr, sodass 03/02/11 als der zweite März 2011 interpretiert würde. Maßeinheiten müssen ebenfalls auf den Prüfstand. Deutsche kennen etwa für die Längenmaße Einheiten wie „Meter“, „Zentimeter“ oder „Kilometer“. In anderen Ländern sind andere Einheiten gebräuchlicher; man stößt auf Einheiten wie „inch“, „foot“, „yard“ oder „mile“.

Letztlich gilt: Jede Übersetzung oder jede nicht übersetzte Maßeinheit, die einen Nutzer der übersetzten Software verwirrt, wird die Marktchancen der Software im Zielland verringern.

Vergleiche: „Der Park eines Herrenhauses ist so groß wie X Fußballfelder.“ Vergleiche dienen dazu, dem Leser das Erfassen von Inhalten zu vereinfachen. Größenangaben werden so besser vorstellbar, als wenn ausschließlich Zahlen und Maßeinheiten verwendet würden. Aber Achtung: In Deutschland und in anderen fußballbegeisterten Nationen ist das Fußballfeld bekannt und für Größenvergleiche tauglich. Aber was, wenn Fußball als Sportart im Zielland keine große Rolle spielt. Wäre dann vielleicht das Football- oder das Cricket-Feld besser?

Oftmals reicht die Textübersetzung alleine nicht!
Neben den textlichen Inhalten einer Software gehören auch alle bildlichen Elemente, Fotos, Symbole und Icons auf den Prüfstand. Wenn Briten die Abbildung eines Tisches („table“) als Symbol für Tabelle nutzen oder das Symbol einer Musiknote für „note“ (Notiz), dann verstehen Deutsche oftmals nicht, was gemeint ist. Das Verstehen oder Nicht-Verstehen von Symbolen ist nicht selten kulturell geprägt. All das zeigt, dass Software-Lokalisierung ohne detaillierte Kenntnisse der jeweiligen Kultur des Ziellandes kaum erfolgreich sein kann. Wer Software produziert, sollte in etwa wissen, wie die anvisierten Nutzer „ticken“. Ansonsten produziert er schnell einen Flop. Und wer will das schon: Sie vielleicht?

Über den Autor: Christian Arno ist der Gründer und Geschäftsführer des internationalen Übersetzungsunternehmens Lingo24, das auch auf Website-Lokalisierung spezialisiert ist.