Oberflächensprache
Ein kurzer String
kann eine lange Erklärung erfordern
‚Open‘ kann einen Status beschreiben oder eine Handlung anweisen. ‚Save‘ kann einen Datensatz speichern oder eine kommerzielle Ersparnis meinen. Eine Liste von Zeichenfolgen ohne Kontext verbirgt diese Unterschiede. Softwarelokalisierung braucht die Funktion des Textes, das Objekt, auf das er sich bezieht, und den Bildschirm, auf dem er erscheint.
Screenshots, stabile Kennungen der Zeichenfolgen und Entwicklerkommentare helfen, diesen Kontext herzustellen. Ein brauchbarer Kommentar erklärt das Verhalten: ob ein Bedienelement ein Fenster öffnet, eine Datei erstellt oder einen Datensatz absendet. Er nennt auch Einschränkungen, die sich aus den Wörtern nicht ableiten lassen, etwa eine feste Beschriftungsbreite oder eine zur Laufzeit eingefügte Variable.
Die Sprachleistung verbindet Beschriftungen der Oberfläche mit Hilfeinhalten, Benutzerhandbüchern und Versionshinweisen. Ein Funktionsname sollte über diese Ebenen hinweg unverändert bleiben. Zugehörige Handbücher gehören zur technischen Übersetzung; öffentliche Produktseiten haben ihre eigenen Anforderungen an die Website-Übersetzung.
Einschränkungen bei der Lokalisierung
Die Funktion schützen
ebenso wie die Bedeutung
| Merkmal der Zeichenfolge | Sprachrisiko | Briefing-Anforderung |
|---|---|---|
| Variablen und Platzhalter | Ein eingefügter Name oder eine eingefügte Zahl kann die Grammatik des umgebenden Satzes verändern. | Geschützte Tokens ermitteln und die Werte erläutern, für die sie stehen. |
| Pluralmeldungen | Nicht alle Sprachen unterscheiden Singular und Plural auf dieselbe Weise. | Die vollständige Meldungsstruktur liefern und die unterstützten Formen erläutern. |
| Gemeinsame Kurzbeschriftungen | Ein Ausgangswort kann in verschiedenen Kontexten unterschiedliche Übersetzungen erfordern. | Jeden Bildschirm und jede Funktion ermitteln, die die gemeinsame Zeichenfolge verwendet. |
| Längenbegrenzungen | Eine korrekte Übersetzung kann mehr Platz beanspruchen als der Ausgangstext. | Tatsächliche Grenzen angeben und Zeichenzahl von visueller Breite unterscheiden. |
| Datums- und Zahlenangaben | Ein vertrautes Ausgangsformat kann in einer anderen Locale mehrdeutig sein. | Angeben, welche Formate die Anwendung steuert und welche bearbeitbarer Text sind. |
Die Beispiele beschreiben Aspekte der Lokalisierung. Akzeptierte Dateiformate, technische Vorbereitung und Prüfungen der Umsetzung werden für das jeweilige Projekt festgelegt.
Terminologieentscheidungen
Die Funktion einmal benennen,
danach konsequent verwenden
Die Terminologie der Oberfläche ist Teil des Produktverhaltens: Sie sagt den Nutzern, was sich auswählen, ändern, löschen oder bestätigen lässt.
Ein Glossar sollte Produktnamen von übersetzbaren Funktionsbezeichnungen unterscheiden und mehrdeutige Begriffe erläutern. Ein „Workspace“ kann zum Beispiel ein Kontobereich, ein gemeinsamer Ordner oder ein physischer Ort sein. Eine freigegebene Entsprechung ohne Definition kann dieselbe Mehrdeutigkeit in jeden übersetzten Bildschirm tragen.
Konsistenz erfordert auch Urteilsvermögen. Ein Menübefehl und ein Satz in einem Hilfeartikel können unterschiedliche grammatische Formen brauchen und dennoch dieselbe Funktion bezeichnen. Einen Begriff wiederzuverwenden heißt nicht, ein flektiertes Wort mechanisch zu kopieren. Muttersprachliche Übersetzer können das Konzept stabil halten und jedes Vorkommen grammatisch korrekt gestalten.
Babylon Translations nutzt CAT-Tools, darunter Trados, und spezielle QA-Software. Das Translation Memory liefert wiederverwendbare zweisprachige Segmente; Terminologieeinträge bezeichnen freigegebene Konzepte. Beides ersetzt nicht das Lesen der Botschaft im Kontext. Der Übersetzungsprozess der Agentur umfasst Korrekturlesen und Überprüfung vor der Lieferung.
Vorbereitung der Veröffentlichung
Das Sprachpaket
releasefähig machen
Ausgangsversion bestimmen
Das Paket sollte eine Release-Kennung tragen und neue, geänderte und entfernte Zeichenfolgen unterscheiden. Stabile Kennungen helfen, Übersetzungsrückfragen der richtigen Meldung zuzuordnen. Frühere freigegebene Übersetzungen sind wertvolle Referenzen, besonders wenn sich der englische Wortlaut geändert hat, die zugrunde liegende Funktion aber nicht.
Produktfragen klären
Einen Produktansprechpartner benennen, der das Verhalten erklären und Terminologie freigeben kann. Eine kompakte Fragendokumentation sollte Zeichenfolgen-Kennung, Kontext und Entscheidung enthalten. Antworten zu gemeinsam genutzten Bedienelementen können mehrere Sprachen betreffen, daher müssen diese Entscheidungen vor der Freigabe jedes betroffene Sprachteam erreichen.
Den umgesetzten Text prüfen
Die sprachliche Revision vergleicht die Übersetzung mit ihrem Ausgangstext. Die Prüfungen des Produktteams in der Anwendung betreffen andere Fragen: abgeschnittenen Text, fehlenden Text, falsche Platzierung von Zeichenfolgen und Laufzeitverhalten. Das Briefing sollte die Verantwortung für jede Prüfung zuweisen und Zeit für daraus folgende Textkorrekturen vorsehen.
Die Aufgabe lokalisieren, nicht eine Folge von Fragmenten
Ein aus mehreren übersetzten Fragmenten zusammengesetzter Satz kann ungrammatisch werden, wenn die Zielsprache Wortstellung, Genus oder Kasus ändert. Vollständige Meldungen geben Übersetzern meist mehr Kontrolle über die Bedeutung. Erfordert die Anwendung Fragmente, muss das Briefing die tatsächlich möglichen Kombinationen zeigen.
Jeder Markt bringt eigene Vorgaben mit: Schriften, Textexpansion, Datums- und Zahlenformate und Anredeformen. Zu den 32 Sprachen und Varianten von Babylon Translations gehören eigene regionale Formen des Englischen, Französischen, Spanischen und Portugiesischen. Wird die vorgesehene Sprachvariante vor der Übersetzung festgelegt, vermeidet dies widersprüchliche Sprachkonventionen innerhalb einer Veröffentlichung.
Fragen zur Softwarelokalisierung
Bevor die Strings
die Entwicklung verlassen
Welche Dateien werden für die Softwarelokalisierung benötigt?
Softwarelokalisierung braucht bearbeitbaren Ausgangstext mit genügend Struktur, um jede Meldung mit ihrer Funktion zu verknüpfen. Dateiformat und Übergabeverfahren sollten vor Beginn der Übersetzung vereinbart werden. Stabile Kennungen, Screenshots, Entwicklerkommentare, Zeichenbegrenzungen und frühere Übersetzungen machen das Paket nützlicher; ein Formatname allein belegt nicht, dass der Kontext vollständig ist.
Wie werden Platzhalter in übersetzter Software behandelt?
Platzhalter sollten als geschützte technische Elemente erkennbar bleiben, während die umgebende Sprache die Werte widerspiegelt, für die sie stehen. Das Briefing muss bearbeitbaren Text von Tokens unterscheiden und etwaige Reihenfolgebeschränkungen erläutern. Eine Platzhalterprüfung kann technische Abweichungen erkennen, doch ein Linguist braucht weiterhin Kontext, um zu beurteilen, ob die fertige Meldung grammatisch und inhaltlich korrekt ist.
Warum brauchen Übersetzer Screenshots für Software-Zeichenfolgen?
Screenshots zeigen die Rolle und den Kontext einer Zeichenfolge, die sonst mehrdeutig sein kann. Sie helfen, Befehle von Statusangaben zu unterscheiden, das beschriebene Objekt zu erkennen und Platzbeschränkungen sichtbar zu machen. Am nützlichsten sind Screenshots, wenn sie mit Kennungen der Zeichenfolgen verknüpft sind und von Erläuterungen zu Interaktionen begleitet werden, die ein statisches Bild nicht zeigen kann.
Kann ein Translation Memory spätere Software-Releases unterstützen?
Ein Translation Memory kann spätere Releases unterstützen, indem es bereits übersetzte Segmente zur Wiederverwendung oder zum Vergleich anbietet. Neue und geänderte Zeichenfolgen müssen dennoch in ihrem aktuellen Kontext beurteilt werden. Ein übereinstimmender Ausgangssatz kann inzwischen eine andere Funktion beschreiben, während eine kleine Änderung im Ausgangstext die Bedeutung so verändern kann, dass eine neue Übersetzungsentscheidung nötig wird.
Ist Softwarelokalisierung dasselbe wie Softwaretest?
Softwarelokalisierung betrifft Sprach- und Länderanforderungen; Softwaretests prüfen das Verhalten der Anwendung. Eine linguistische Prüfung belegt nicht, dass ein übersetzter Build jede Zeichenfolge korrekt anzeigt oder jede Eingabe verarbeitet. Implementierungsprüfungen sollten die tatsächliche Oberfläche abdecken, und das Projektbriefing sollte festhalten, wer den Kontext liefert, die Sprache freigibt und den entstandenen Build prüft.
Wie werden Softwarelokalisierungen bepreist und terminiert?
Ein Angebot für die Softwarelokalisierung hängt von Textvolumen, Sprachkombinationen, vorhandenen Übersetzungen, Kontextqualität und technischen Einschränkungen ab. Kurze Zeichenfolgen können erheblichen Klärungsbedarf erzeugen, daher beschreibt die Wortzahl allein den Aufwand nicht. Ein Veröffentlichungstermin, ein stabiles Ausgangspaket und klare Revisionsverantwortlichkeiten bilden die Grundlage für einen aussagekräftigen Umfang und Zeitplan.