Software-Lokalisierung

Diese Dienstleistung unterscheidet sich von der Website-Lokalisierung. Auf einer Website stehen meist flüssige Texte mit klarem Zusammenhang; in Software dagegen stehen die Texte als kurze, verstreute und aus dem Zusammenhang gelöste Bruchstücke in den Quelldateien. Einzelne Wörter wie „Save“, „Open“ oder „None“ werden übersetzt, ohne dass sichtbar ist, wo sie auf dem Bildschirm erscheinen. Diese Loslösung ist die entscheidendste Schwierigkeit der Software-Lokalisierung.

Der Text steht getrennt vom Code

In einer lokalisierbaren Software werden alle für Nutzer sichtbaren Texte aus dem Code herausgelöst und in gesonderten Quelldateien gesammelt. Der Übersetzer arbeitet nicht mit dem Code, sondern mit diesen Dateien. Diese Dateien enthalten jedoch besondere Elemente: Platzhalter, in die Variablen eingesetzt werden, Pluralendungen und Formatierungszeichen. Werden sie verändert, stürzt die Anwendung ab. Software-Lokalisierung setzt deshalb das Wissen voraus, was übersetzt wird und was unangetastet bleibt.

In einer agglutinierenden Sprache wie dem Türkischen bereiten Plural- und Kasusendungen ein eigenes Problem. Ein Ausdruck, der im Englischen einfach an eine Variable angehängt wird, ändert sich im Türkischen je nach dem letzten Laut des Wortes. Deshalb liefern Konstruktionen, die eine Variable mitten in den Satz setzen, häufig ein fehlerhaftes Ergebnis; solche Stellen sollten während der Lokalisierung erkannt und der Entwicklung gemeldet werden.

Wie läuft der Prozess ab?

Der Prozess der Software-Lokalisierung ähnelt eher einer Ingenieursdisziplin als einer Übersetzung; in jedem Schritt werden sprachliche und technische Richtigkeit zugleich beachtet. Der folgende Ablauf stellt die Tatsache in den Mittelpunkt, dass die Texte als aus dem Zusammenhang gelöste Bruchstücke ankommen: Deshalb ist das Sammeln von Kontext ein ebenso wichtiger Schritt wie die Übersetzung selbst. Der Erhalt der Platzhalter und Formatcodes ist eine Regel, die während des gesamten Prozesses unverändert gilt. Der Test am Ende der Schritte ist das entscheidendste Glied des Prozesses; denn ob eine Übersetzung wirklich richtig ist, zeigt sich erst, wenn man sie in der Anwendung sieht.

1. Übernahme der Quelldateien. Die Sprachdateien mit den Texten sowie, sofern vorhanden, Bildschirmfotos oder Kontextnotizen werden gesammelt.
2. Terminologie- und Stilleitfaden. Die Grundbegriffe des Produkts werden festgelegt; es wird entschieden, mit welcher Entsprechung nah beieinanderliegende Begriffe wie „delete“, „remove“ und „cancel“ wiedergegeben werden.
3. Übersetzung. Die Texte werden unter Beachtung der Platzhalter und der Zeichenbegrenzungen übersetzt; für Bruchstücke mit unklarem Zusammenhang wird eine Rückfrage an die Entwicklung gestellt.
4. Test am Build. Die Übersetzung wird in die Anwendung eingesetzt und auf den echten Bildschirmen betrachtet; überlaufende, falsch platzierte und aus dem Zusammenhang gerissene Texte werden korrigiert.
5. Versionspflege. In einer neuen Version werden die geänderten Texte markiert und nur diese aktualisiert; es wird nicht bei jeder Version von vorn begonnen.

Lieferform

Die Lieferung erfolgt in Form der Quelldateien mit eingesetzter Übersetzung; die Entwicklung kann sie unmittelbar in den Build übernehmen. Platzhalter, Formatcodes und Dateistruktur bleiben unbeschädigt erhalten. Wurde eine Testphase gewünscht, werden auch die Liste der auf dem Bildschirm festgestellten Probleme und die vorgeschlagenen Korrekturen berichtet. Sollen auch die Dokumentation und die Hilfetexte des Produkts übersetzt werden, werden diese in Terminologieeinheit mit der Oberfläche bearbeitet.

Besondere Aufmerksamkeitspunkte dieser Dienstleistung

Das größte Risiko ist die Kontextlosigkeit. Ein Wort, das übersetzt wird, ohne dass sichtbar ist, wo es auf dem Bildschirm erscheint, kann eine falsche Bedeutung tragen: „close“ heißt sowohl „schließen“ als auch „nah“; welche Bedeutung gemeint ist, sagt nur der Zusammenhang. Deshalb sind Bildschirmfotos und ein offener Rückfragekanal zur Entwicklung der entscheidendste Faktor für die Qualität. In einem Projekt, in dem kein Kontext gegeben wird, steigt die Fehlerquote zwangsläufig.

Der zweite Punkt ist, nicht abzuschließen, ohne die echte Oberfläche gesehen zu haben. Eine Übersetzung, die auf dem Papier richtig aussieht, passt möglicherweise nicht in ein schmales Menü oder liest sich wegen einer mitten im Satz stehenden Variablen fehlerhaft. Diese Probleme werden erst durch den Test am Build sichtbar. Soll neben Ihrer Anwendung auch die Website lokalisiert werden, werden beide Arbeiten im Rahmen von unseren Übersetzungsdienstleistungen mit einheitlicher Terminologie durchgeführt.

Internationalisierung und Testzyklus

Der Erfolg der Software-Lokalisierung hängt von einem Schritt ab, der vor der Übersetzung getan wird: der Internationalisierung. Wurde die Anwendung nicht so aufgebaut, dass sie verschiedene Sprachen tragen kann, fällt das Ergebnis fehlerhaft aus, wie gut die Übersetzung auch sein mag. Dass der Text vom Code getrennt ist, dass Datums- und Zahlenformate einstellbar sind und dass die Oberfläche Platz für längeren Text lässt, sind Voraussetzungen, die vor der Übersetzung erfüllt sein müssen. Fehlen sie, muss zuerst die Entwicklungsseite in Ordnung gebracht werden.

Der zweite bestimmende Faktor ist der Testzyklus. Lokalisierung ist keine einseitige Lieferung, sondern ein wiederkehrender Prozess: Die Übersetzung wird eingesetzt, im Build betrachtet, Probleme werden markiert und behoben. Mit neuen Versionen werden nur die geänderten Strings bearbeitet, und derselbe Zyklus wiederholt sich in kleinerem Maßstab. Projekte, die ohne diese Ordnung geführt werden, beginnen bei jeder Aktualisierung von vorn, kosten mehr und verlieren ihre Konsistenz. Eine tragfähige Lokalisierung definiert diesen Zyklus von Anfang an als fortlaufenden Prozess.

Was bestimmt den Preis?

Der erste Kostenfaktor ist der tatsächliche Umfang des zu übersetzenden Textes; dieser Umfang ist in den Quelldateien meist größer, als er erscheint, weil Fehlermeldungen und Hilfetexte übersehen werden. Der zweite ist die Kontextlage: Ein Projekt, zu dem Bildschirmfotos und Notizen bereitgestellt werden, kommt schnell voran, ein blind bearbeitetes Projekt wird langsamer. Der dritte ist der Testumfang; wird eine Prüfung am Build gewünscht, ist das ein gesonderter Aufwand. Ein belastbarer Preis lässt sich ohne Einsicht in die Quelldateien nicht nennen.

Ihre Quelldateien und die Zielsprachen können Sie über das Angebotsformular mit uns teilen. Die Preisstufen finden Sie auf der Preisseite, die Sprachen, mit denen wir arbeiten, auf den Sprachenseiten.

Häufige Situationen

• Textliste ohne Kontext. Eine ohne Bildschirmfotos gesendete Worttabelle; die Situation, die das Risiko einer falschen Bedeutung am stärksten erhöht.
• Beschädigung von Platzhaltern. Das versehentliche Verändern von Variablenzeichen; es führt zum Absturz der Anwendung und wird deshalb unangetastet gelassen.
• Überlaufender Text. Der in der Zielsprache längere Text passt nicht in die schmale Oberfläche; das wird erst durch den Test am Build sichtbar.
• Versionsdurcheinander. Das erneute Übersetzen des gesamten Textes bei jeder Aktualisierung; dabei sollten nur die geänderten Strings bearbeitet werden.

Dieser Inhalt gibt den allgemeinen Rahmen wieder; die Einzelheiten des jeweiligen Vorgangs können abweichen. Da sich die Praxis ändern kann, legen Sie die Bedingung zum Zeitpunkt der Antragstellung zugrunde.