Softwarelokalisierung: Ablauf, Kosten und Vorbereitung
Softwarelokalisierung läuft in acht Schritten ab: Code für andere Sprachen vorbereiten, Strings in übersetzbare Dateien exportieren, Kontext liefern, Terminologie festlegen, übersetzen und revidieren, mit Pseudolokalisierung und Prüfung im Kontext testen, ausliefern und bei jedem Update wiederholen. Die Kosten hängen vor allem von neuem gegenüber wiederverwendetem Text, der Zahl der Sprachen und dem Release-Rhythmus ab. DEMA Solutions lokalisiert Software und Dokumentation für europäische Technologieunternehmen.
Für wen dieser Leitfaden gedacht ist
Dieser Leitfaden richtet sich an alle, die ein Produkt in mehreren Sprachen ausliefern müssen, ohne die Entwicklung auszubremsen: Produktmanager, die das erste mehrsprachige Release planen, Entwicklungsleiter, die für die String-Dateien verantwortlich sind, und Lokalisierungsmanager, die einen Prozess übernommen haben, der meistens funktioniert. Er richtet sich auch an Maschinen- und Anlagenbauer, deren Produkte inzwischen mit Software ausgeliefert werden, etwa mit einem Konfigurator, einem Kundenportal oder einer Begleit-App, und die feststellen, dass sich Software anders übersetzen lässt als ein Handbuch.
Die Fragen sind praktischer Natur: Was muss im Code passieren, welche Dateien gehen an den Anbieter, wie wird das Ergebnis getestet und warum unterscheiden sich Angebote so stark? Die folgenden Abschnitte folgen dem Ablauf in der Reihenfolge, in der Sie ihm begegnen.
Was ist Softwarelokalisierung, und worin unterscheiden sich Übersetzung und Lokalisierung?
Bei der Lokalisierung von Software werden die sichtbaren Texte, Formate und das Verhalten eines Programms so angepasst, dass es sich für Nutzer in einer anderen Sprache und einem anderen Markt selbstverständlich anfühlt. Die Übersetzung ist dabei der zentrale Teil, aber eben nur ein Teil. Ein lokalisiertes Produkt zeigt außerdem Datum, Zahlen, Währungen und Einheiten so an, wie es die Nutzer vor Ort erwarten, beherrscht Pluralformen, die das Englische nicht kennt, bringt längere Texte in denselben Schaltflächen und Dialogen unter und verwendet in Oberfläche, Hilfecenter und Dokumentation dieselben Begriffe.
Der Unterschied zwischen Übersetzung und Lokalisierung ist deshalb wichtig, weil er bestimmt, wer beteiligt ist. Ein Dokument können Linguisten allein übersetzen. Bei Software geht das nicht: Die Entwicklung entscheidet, wie Strings gespeichert und zusammengesetzt werden, das Design, wie viel Platz ein Label bekommt, und das Produktmanagement, welche Märkte wann ausgeliefert werden. Werden diese Entscheidungen mit Blick auf andere Sprachen getroffen, verläuft die Übersetzung schnell und planbar. Wenn nicht, erhalten Übersetzer Fragmente ohne Kontext, und die Probleme zeigen sich spät, im Release-Build, in einer Sprache, die im Team niemand liest. Bei Maschinen kommen Zeichenlimits, Alarmtexte und die Abstimmung mit der Betriebsanleitung hinzu, die unser Beitrag zur Software-Übersetzung für HMI im Detail behandelt.
Zuerst kommt die Internationalisierung
Vor der Lokalisierung steht die Internationalisierung, also die technische Arbeit, die ein Produkt für jede Sprache vorbereitet. Sie ist die häufigste Ursache für langsame und teure Lokalisierung und liegt fast vollständig in der Hand des Entwicklungsteams.
Alle sichtbaren Strings auslagern. Fest im Quellcode verankerter Text lässt sich ohne Codeänderung weder exportieren noch aktualisieren. Labels, Meldungen, Tooltips, E-Mail-Vorlagen und Fehlertexte gehören in Ressourcendateien, referenziert über stabile Keys.
Keine Sätze aus Bausteinen zusammensetzen. Code, der „You have “ + count + “ new messages“ verkettet, setzt die englische Wortstellung voraus. Verwenden Sie vollständige Sätze mit benannten Platzhaltern und lassen Sie jede Sprache sie selbst anordnen.
Pluralregeln unterstützen. Das Englische und das Deutsche kommen mit zwei Pluralformen aus, viele Sprachen brauchen mehr, mit jeweils anderen Kategorien. Nachrichtenformate mit Pluralkategorien, etwa die ICU-Message-Syntax, erlauben es Übersetzern, jede benötigte Form zu liefern.
Platz für Textlänge einplanen. Übersetzte Texte sind oft länger als das Englische, und gerade deutsche Komposita sprengen kurze Labels. Flexible Layouts und vereinbarte Zeichenbegrenzungen dort, wo der Platz wirklich fix ist, verhindern die meisten abgeschnittenen Texte.
Gebietsschemata und Unicode durchgängig nutzen. Datum, Zahlen und Sortierung sollten aus den Gebietsschema-Einstellungen kommen, und jede Ebene, von der Datenbank bis zur Schrift, muss die Zeichen der Zielsprachen verarbeiten.
Nichts davon ist Übersetzungsarbeit, aber jede Lücke wird zum Übersetzungsproblem. Ein guter Anbieter weist auf Internationalisierungsfehler hin, die er in Ihren Dateien findet; beheben kann er sie in Ihrem Code nicht.
Der Ablauf der Softwarelokalisierung Schritt für Schritt
Von außen betrachtet heißt Lokalisierung „Strings schicken, Strings zurückbekommen“. Der Ablauf, der in der Praxis funktioniert, hat mehr Schritte, und die meisten finden vor oder nach der Übersetzung statt.
1. Umfang und Sprachen festlegen. Bestimmen Sie, welche Komponenten (Oberfläche, Onboarding, Benachrichtigungen, Hilfecenter, Dokumentation) in welcher Sprache und mit welchem Release erscheinen.
2. Strings exportieren. Liefern Sie Ressourcendateien, die der Anbieter ohne manuelles Kopieren verarbeiten kann, mit intakten Keys, Strukturen und Zeichenkodierungen.
3. Pseudolokalisieren. Testen Sie den Build mit generiertem, verlängertem Text, bevor die eigentliche Übersetzung beginnt.
4. Kontext vorbereiten. Screenshots, String-Kommentare und Zeichenbegrenzungen zeigen dem Übersetzer, wo jeder String erscheint.
5. Terminologie und Stil festlegen. Glossar und Styleguide werden erstellt oder aktualisiert und von jemandem freigegeben, der das Produkt im jeweiligen Markt kennt.
6. Übersetzen und revidieren. Muttersprachliche Linguisten übersetzen neue und geänderte Strings, freigegebene Übersetzungen werden wiederverwendet, und ein zweiter Linguist revidiert das Ergebnis.
7. Im Kontext testen. Die übersetzten Strings werden auf den echten Bildschirmen auf Bedeutung, Abschneiden und Einheitlichkeit geprüft.
8. Ausliefern und pflegen. Jede Korrektur fließt in Translation Memory und Glossar zurück, damit das nächste Release auf der korrigierten Fassung aufbaut.
Die folgenden Abschnitte behandeln die Schritte, an denen die meisten Projekte scheitern.
String-Dateien und Formate: was Ihr Anbieter erhalten sollte
Ressourcenformate unterscheiden sich je nach Plattform, und jedes hat seine eigenen Risiken. Ihr Anbieter muss Ihr Build-System nicht kennen, aber er braucht Dateien, die er öffnen, übersetzen und in exakt derselben Struktur zurückgeben kann. Am häufigsten sind diese Formate:
- XLIFF, der XML-Austauschstandard für die Lokalisierung, der Ausgangstext, Zieltext und Notizen zusammenhält;
- JSON, verbreitet in Web- und Mobile-Frontends, oft verschachtelt und ohne eigenes Kommentarfeld, sodass der Kontext separat mitgeliefert werden muss;
- RESX für .NET-Anwendungen, mit einem Kommentarelement pro String;
- PO-Dateien aus gettext, die Übersetzerkommentare, Nachrichtenkontext und Pluralformen unterstützen;
- .strings- und .stringsdict-Dateien für iOS-Apps sowie XML-String-Ressourcen für Android, jeweils mit eigener Pluralsyntax.
Unabhängig vom Format müssen bestimmte Elemente unverändert zurückkommen: Keys, Platzhalter wie {name} oder %s, Markup-Tags, Escape-Zeichen und die Zeichenkodierung. Platzhalter dürfen innerhalb des Satzes wandern, weil sich die Wortstellung ändert, aber sie dürfen nie übersetzt, gelöscht oder verdoppelt werden. Automatisierte Prüfungen fangen die meisten dieser Fehler vor der Lieferung ab, und die Frage, wie ein Anbieter einen beschädigten Platzhalter erkennt, ist ein schneller Test seines Prozesses.
Eine Gewohnheit spart viel Zeit: Schicken Sie nur neue und geänderte Strings, oder kennzeichnen Sie klar, was sich seit der letzten Lieferung geändert hat. Wer jedes Mal komplette Dateien ohne diese Information sendet, zwingt jemanden, das Neue erst wieder zu finden, und genau dort schleichen sich versehentliche Änderungen an freigegebenen Strings ein.
Kontext: Screenshots, Kommentare und Zeichenbegrenzungen
Die meisten Lokalisierungsfehler sind Kontextfehler, keine Sprachfehler. „Update“ kann ein Verb auf einer Schaltfläche oder ein Substantiv in einer Meldung sein, und im Deutschen heißt das eine „Aktualisieren“, das andere „Aktualisierung“ oder schlicht „Update“. Ein String wie „%d items“ kann Produkte im Warenkorb oder Einträge im Protokoll meinen. Ohne Kontext muss auch ein sorgfältiger Übersetzer raten.
Drei Arten von Kontext machen den Unterschied. Screenshots zeigen, wo ein String steht und wie viel Platz er hat. String-Kommentare erklären, was ein Key bewirkt und was jeder Platzhalter enthalten wird. Zeichenbegrenzungen für Schaltflächen, Tabellenköpfe und Benachrichtigungen sagen dem Übersetzer, wann eine kürzere Formulierung nötig ist, bevor ein Tester das abgeschnittene Label findet.
Sie brauchen nicht alle drei für jeden String. Ein Hinweis bei mehrdeutigen Keys, aktuelle Screenshots pro Release und Begrenzungen dort, wo der Platz wirklich fix ist, beseitigen den größten Teil des Ratens, und Teams, die Keys gleich beim Anlegen kommentieren, bekommen später kaum noch Rückfragen.
Terminologie und Stil: eine Stimme in jeder Sprache
Eine Benutzeroberfläche ist ein kleiner Wortschatz, der tausendfach verwendet wird. Wird „Workspace“ in App, Hilfecenter und Onboarding-E-Mails dreimal unterschiedlich übersetzt, halten Nutzer das für drei verschiedene Dinge. Ein Glossar der Produktbegriffe, mit der freigegebenen Übersetzung je Sprache und einem Hinweis auf Begriffe, die Englisch bleiben, verhindert diesen Wildwuchs. Unser Beitrag zum zentralen Terminologiemanagement über Übersetzer und Anbieter hinweg erklärt, wie Sie ein solches Glossar aufbauen und pflegen.
Der Stil ist ebenso wichtig. Siezt oder duzt die Oberfläche ihre Nutzer? Stehen auf Schaltflächen Infinitive wie „Speichern“ oder Substantive wie „Speicherung“? Wie sind Fehlermeldungen formuliert? Ein kurzer Styleguide pro Sprache beantwortet diese Fragen einmal für alle Übersetzer und Prüfer. Bei größeren Produktfamilien macht ein strukturiertes Terminologiemanagement aus dem Glossar eine gepflegte Terminologiedatenbank, die alle Anbieter und internen Teams nutzen können.
Übersetzung und Revision
Sind Dateien, Kontext und Terminologie vorbereitet, ist die Übersetzung der am besten planbare Schritt. Muttersprachliche Linguisten mit Erfahrung in Softwarekonventionen übersetzen die neuen und geänderten Strings, freigegebene Übersetzungen aus der Translation Memory werden überall dort wiederverwendet, wo sich der Ausgangstext nicht geändert hat, und ein zweiter Linguist prüft jede Übersetzung am Ausgangstext auf Bedeutung, Terminologie, Platzhalter und Länge.
Maschinelle Übersetzung hat ihren Platz, vor allem bei umfangreichen Hilfecentern, Wissensdatenbanken und Dokumentations-Updates. Sie funktioniert am besten auf Ihrem eigenen Glossar und Ihrer freigegebenen Translation Memory, mit einem qualifizierten Linguisten, der das Ergebnis nachbearbeitet. Oberflächen-Strings sind kurz, mehrdeutig und auf jedem Bildschirm sichtbar, deshalb brauchen sie meist von Anfang an einen menschlichen Übersetzer. Auf der Seite zum Post-Editing maschineller Übersetzungen erklären wir, welche Inhalte sich dafür eignen.
Pseudolokalisierung und linguistische QA im Kontext
Zwei Arten von Tests schützen ein lokalisiertes Release, und sie finden unterschiedliche Probleme.
Die Pseudolokalisierung läuft vor der Übersetzung und testet den Code, nicht die Sprache. Ein Skript ersetzt jeden Ausgangsstring durch eine verlängerte Version mit Akzentzeichen in sichtbaren Markierungen, sodass aus „Save changes“ etwa [Šåvé çhåñgéš !!!] wird. Wer sich durch diesen Build klickt, sieht sofort, welcher Text fest codiert ist (er bleibt normales Englisch), welche Labels abgeschnitten werden (die schließende Markierung fehlt) und welche Zeichen kaputtgehen. Sie kostet wenig, braucht keine Übersetzer und findet genau die Fehler, deren Behebung in zehn Sprachen gleichzeitig am teuersten wäre.
Die linguistische QA im Kontext läuft nach der Übersetzung, auf einem Build oder einer Staging-Umgebung mit den echten Strings. Ein Linguist oder Prüfer im Zielmarkt geht die wichtigsten Nutzerwege durch und prüft, was keine dateibasierte Revision sehen kann: ob eine Übersetzung in ihren Kontext passt, ob Text abgeschnitten wird, ob Datum und Zahlen korrekt erscheinen und ob jeder Begriff auf jedem Bildschirm gleich lautet. Korrekturen fließen in die Translation Memory, nicht nur in den Build, damit sie im nächsten Release nicht wieder auftauchen.
Beim ersten Launch lohnen sich beide Tests in jeder Sprache; bei Routine-Releases genügen meist automatisierte Prüfungen plus Kontextprüfung neuer Funktionen.
Kontinuierliche Lokalisierung bei häufigen Releases
Produkte, die alle ein bis zwei Wochen ausgeliefert werden, lassen sich nicht in gelegentlichen großen Paketen lokalisieren; bis ein Paket zurückkommt, hat sich der Ausgangstext schon wieder geändert. Kontinuierliche Lokalisierung ersetzt das Paket durch einen stetigen Fluss: Neue und geänderte Strings werden pro Release erfasst und übersetzt, solange der Sprint noch läuft, sodass jede Sprache mit dem Ausgangstext erscheint und nicht Wochen später.
Das hängt weniger vom Tempo als von Disziplin ab. Strings sollten als stabil markiert sein, bevor sie in die Übersetzung gehen, sonst wird derselbe Text dreimal übersetzt, während die Formulierung noch reift. Der Kontext muss jedes Paket begleiten, weil der Übersetzer Ihre Feature-Demo nicht gesehen hat. Terminologieentscheidungen brauchen einen Verantwortlichen, der schnell antwortet, und die Translation Memory muss mit jeder Lieferung aktualisiert werden.
Der Nutzen ist greifbar: Kleine Pakete lassen sich leichter prüfen, Fehler werden korrigiert, bevor sie sich verbreiten, und jedes Release kostet nur das, was sich tatsächlich geändert hat. Hier laufen die meisten bewährten Praktiken der Softwarelokalisierung zusammen: wenig und oft lokalisieren, mit Kontext, auf einer Translation Memory und einem Glossar.
Oberfläche, Hilfe und Dokumentation einheitlich halten
Nutzer unterscheiden nicht zwischen Oberfläche und Dokumentation. Steht auf der Schaltfläche das eine und im Hilfeartikel das andere, verlieren sie das Vertrauen in beides. Trotzdem entstehen diese Texte oft in verschiedenen Teams, Formaten und Zeitplänen, manchmal bei verschiedenen Anbietern.
Die Lösung: Behandeln Sie alles als einen zusammenhängenden Inhalt. Dasselbe Glossar und dieselbe Translation Memory sollten Oberfläche, Hilfecenter, Release Notes, API-Dokumentation und, bei Herstellern, die Betriebsanleitung bedienen. Handbücher und Installationsanleitungen zu einem Softwareprodukt folgen derselben Logik wie Ihre übrigen technischen Übersetzungen, und wer gerade eine Bedienungsanleitung übersetzen lässt, sollte die Begriffe der Oberfläche übernehmen statt sie neu zu erfinden.
Liegen Ihre bisherigen Übersetzungen in alten Dateien statt in einer Translation Memory, lassen sie sich trotzdem nutzen. Beim Translation Memory Alignment werden frühere Übersetzungen ihren Ausgangstexten zugeordnet, sodass freigegebene Formulierungen schon ab dem ersten Release mit einem neuen Anbieter wiederverwendbar sind.
Was die Kosten der Softwarelokalisierung bestimmt
Softwarelokalisierung wird meist pro Wort angeboten, doch der Wortpreis erklärt weniger von den Gesamtkosten, als viele Einkäufer erwarten. Diese Faktoren bewegen die Zahl.
Neuer gegenüber wiederholtem Text. Strings, die bereits freigegeben in der Translation Memory stehen oder im Produkt mehrfach vorkommen, kosten deutlich weniger als neuer Text, Teiltreffer liegen dazwischen. Bei einem reifen Produkt ist der Großteil jedes Releases Wiederverwendung, beim ersten Launch ist fast alles neu.
Nutzung der Translation Memory. Ein Anbieter, der mit Ihrer bestehenden Translation Memory arbeitet, berechnet nur, was wirklich neu ist; einer, der sie nicht nutzen kann, berechnet alles noch einmal. Deshalb ist es so wichtig, dass die Translation Memory Ihnen gehört und exportierbar ist.
Anzahl der Sprachen. Die Kosten steigen nahezu linear mit den Sprachen, prüfen Sie also, ob wirklich jede Komponente jede Sprache braucht.
Release-Rhythmus und Paketgröße. Jedes Paket bringt fixen Aufwand für Dateihandling, Prüfungen und Projektmanagement mit sich. Regelmäßige, geplante Pakete sind effizient, einzeln verschickte Strings nicht.
Kontext, Dateiqualität und Testumfang. Saubere Dateien mit Kommentaren und Screenshots werden schneller und mit weniger Rückfragen übersetzt. Fehlender Kontext wird doppelt bezahlt, einmal in Rückfragen und noch einmal in Korrekturen nach dem Test. QA im Kontext und Prüfung im Zielmarkt verursachen Aufwand, der geplant und nicht erst entdeckt werden sollte.
Ein einfaches Beispiel zeigt, warum die Wiederverwendung dominiert. Angenommen, ein Release ändert 2.000 Wörter Oberflächentext: 1.200 neu, 500 Teiltreffer und 300 bereits in der Translation Memory. Über zehn Sprachen sind das 12.000 neue Wörter zum Übersetzen, 5.000 zum Anpassen und 3.000 zum Prüfen, nicht 20.000 Wörter von Grund auf. Ein Anbieter, der diese Aufteilung bei jeder Lieferung ausweist, macht die Kosten jedes Releases nachvollziehbar.
Typische Fehler und was sie kosten
Übersetzen, bevor die Strings stabil sind. Text, der noch umgeschrieben wird, wird übersetzt, neu übersetzt und wieder geändert, und jede Runde kostet Geld.
Strings ohne Kontext verschicken. Mehrdeutige Labels werden geraten, die Vermutungen klingen plausibel, und Kunden finden die Fehler vor den Testern.
Jeden Anbieter seine eigene Translation Memory führen lassen. Wechseln Sie den Anbieter, oder gehen App und Handbuch an verschiedene Dienstleister, gehen freigegebene Formulierungen verloren und die Terminologie läuft auseinander.
Was Sie Ihrem Anbieter schicken und wie Sie ihn auswählen
Ein vollständiges Briefing, oft Lokalisierungskit genannt, ermöglicht ein genaues Angebot und einen Start ohne Rückfragerunde. Für ein Software-Release sollte es enthalten:
- die Ressourcendateien mit gekennzeichneten neuen und geänderten Strings, dazu Hilfe oder Dokumentation im Umfang;
- Zielsprachen und Gebietsschemata und welche Komponenten jeweils benötigt werden;
- Kontext: Screenshots oder Zugang zu einem Test-Build, String-Kommentare und Zeichenbegrenzungen;
- Ihr Glossar, Ihren Styleguide und Ihre bestehende Translation Memory, falls vorhanden;
- den Release-Plan, die Paketfrequenz und Ihren Ansprechpartner für Rückfragen.
Stellen Sie beim Vergleich von Anbietern Fragen, die zeigen, wie sie arbeiten. Können sie Ihre Dateiformate nativ verarbeiten und ohne beschädigte Keys oder Platzhalter zurückgeben? Welche automatisierten Prüfungen laufen vor der Lieferung? Wird jede Übersetzung von einem zweiten qualifizierten Linguisten revidiert? Arbeiten sie mit Ihrer bestehenden Translation Memory, können Sie diese jederzeit exportieren, und wie weisen sie Neues und Wiederverwendetes aus? Weitere Fragen finden Sie in unserem Leitfaden, wie Sie ein technisches Übersetzungsbüro auswählen, und unser Beitrag zur Qualitätssicherung bei Übersetzungen zeigt, welche Nachweise Sie verlangen sollten.
Wie DEMA Solutions Software lokalisiert
Unsere Leistungen für Software-Lokalisierung und Übersetzung in der Technologiebranche sind für Produktteams ausgelegt, die kontinuierlich ausliefern. Neue und geänderte Strings werden pro Release übersetzt, abgestimmt auf Ihren Sprint-Rhythmus statt in gelegentlichen Großprojekten gebündelt. JSON-, XML- und andere Ressourcendateien kommen in ihrer Originalstruktur zurück, ohne manuellen Extraktionsschritt und ohne beschädigte Keys, und automatisierte Prüfungen suchen nach beschädigten Variablen, abgeschnittenen Strings und Formatierungsfehlern, bevor etwas in einen Release-Build gelangt.
Unsere Übersetzer sind muttersprachliche technische Linguisten, die mit Software- und Entwicklerterminologie arbeiten, und der Prozess ist nach ISO 17100 zertifiziert, mit einem zweiten qualifizierten Linguisten, der jede Übersetzung revidiert, wie auf unserer Qualitätsseite beschrieben. Ihre Entwickler und Produktmanager können direkt in der Übersetzungsumgebung prüfen statt in exportierten Tabellen, sodass Korrekturen sofort in die Translation Memory gelangen. Translation Memory und Glossare bleiben Ihr Eigentum, jederzeit exportierbar in portablen Formaten wie TMX und TBX, und Auswertungen zur Wiederverwendung zeigen, welcher Anteil jedes Releases aus bereits freigegebenem Text stammt. Unsere Teams in Italien, Serbien und Spanien betreuen auch Hilfeinhalte, API-Dokumentation, Release Notes und Handbücher, mit einem eigenen DTP-Team für Layoutformate, damit Oberfläche und Dokumente dieselbe Terminologie sprechen.
Wo TUBE ins Spiel kommt
Für Produkte mit kontinuierlichen Releases ist TUBE unsere Lösung, um jeden Lokalisierungszyklus unter Ihrer Kontrolle zu halten. Ihr Glossar und Ihre Translation Memory steuern die maschinelle Übersetzung, jede freigegebene Übersetzung fließt in eine Translation Memory, die Ihnen gehört und die Sie exportieren können, und Auswertungen zur Wiederverwendung zeigen, welcher Anteil jedes Updates aus bereits freigegebenem Text stammt.
Häufige Fragen
Code internationalisieren, Strings exportieren, pseudolokalisieren, Kontext vorbereiten, Terminologie und Stil festlegen, übersetzen und revidieren, den übersetzten Build im Kontext testen, dann ausliefern und Korrekturen in die Translation Memory zurückführen. Bei häufigen Releases wiederholt sich der Zyklus nur für neue und geänderte Strings.
Die Internationalisierung macht das Produkt für jede Sprache bereit: ausgelagerte Strings, Pluralunterstützung, gebietsschemaabhängige Formate und flexible Layouts. Die Lokalisierung passt es an eine bestimmte Sprache und einen Markt an, einschließlich Übersetzung und Test. Das eine geschieht einmal und wird gepflegt, das andere wiederholt sich für jede Sprache und jedes Release.
Das Format, das Ihr Build-System zuverlässig erzeugt und das Keys, Platzhalter und Kontext unverändert lässt. XLIFF ist das robusteste Austauschformat; JSON, RESX, PO und plattformspezifische String-Dateien funktionieren gut, wenn Platzhalter einheitlich sind und Kontext mitgeliefert wird.
Sie ersetzt Ausgangsstrings durch verlängerten Text mit Akzentzeichen in sichtbaren Markierungen, sodass fest codierter Text, abgeschnittene Labels und Kodierungsfehler sichtbar werden, bevor die eigentliche Übersetzung beginnt. Sinnvoll ist sie vor den ersten Sprachen und immer dann, wenn größere neue Funktionen hinzukommen.
Das hängt davon ab, wie viel Text wirklich neu ist, wie viel aus einer Translation Memory wiederverwendet werden kann, von der Zahl der Sprachen, dem Release-Rhythmus und dem Testumfang. Verlangen Sie Angebote, die neuen, teilweise übereinstimmenden und wiederverwendeten Text getrennt ausweisen, damit Sie Anbieter auf derselben Grundlage vergleichen können.
Sie kann umfangreiche, wiederkehrende Inhalte wie Hilfecenter und Dokumentation unterstützen, wenn sie auf einem freigegebenen Glossar und einer Translation Memory läuft und ein qualifizierter Linguist das Ergebnis nachbearbeitet. Kurze Oberflächen-Strings sind mehrdeutig und gut sichtbar, deshalb brauchen sie in der Regel einen menschlichen Übersetzer und eine Revision.
Markieren Sie Strings vor der Übersetzung als stabil, schicken Sie nur neue und geänderte Strings mit Kontext, nutzen Sie eine Translation Memory und ein Glossar für alle Inhalte und vereinbaren Sie mit Ihrem Anbieter eine feste Bearbeitungszeit pro Paket.
Ihr nächstes mehrsprachiges Release planen
Bereiten Sie ein erstes lokalisiertes Release vor, oder kommt Ihr bisheriger Prozess mit Ihren Sprints nicht mehr mit? Erzählen Sie uns von Ihrem Produkt, Ihren Dateiformaten und Zielsprachen. Wir sehen uns Ihre Dateien an und schlagen einen Lokalisierungsablauf vor, der zu Ihrem Release-Zyklus passt.
Wie können wir helfen?
Sagen Sie uns, was Sie brauchen, und wir melden uns mit passenden Lösungen bei Ihnen.