App-Lokalisierung für SaaS und mobile Apps: Übersetzen im Takt kontinuierlicher Releases
App-Lokalisierung funktioniert auch bei wöchentlichen Releases, wenn die Übersetzung Teil der Auslieferungskette wird: Neue und geänderte Strings gehen an die Übersetzer, sobald sie stabil sind, kommen über dasselbe Repository zurück, werden im Kontext geprüft und erscheinen zusammen mit der Ausgangssprache. Ein Translation Memory und ein Glossar halten jedes Release konsistent. DEMA Solutions lokalisiert Apps, Hilfeinhalte und Release Notes für europäische Softwareteams.
Für wen dieser Leitfaden gedacht ist
Dieser Leitfaden richtet sich an alle, die in einem Softwareunternehmen für Mehrsprachigkeit sorgen, das nie aufhört auszuliefern: Produktmanager, die Funktionen in mehreren Märkten gleichzeitig versprechen, Entwicklungsleiter, die Build und String-Dateien verantworten, und Lokalisierungsmanager, die zwischen beiden und dem Übersetzungsdienstleister vermitteln. Er setzt voraus, dass Sie die Grundlagen kennen, die wir im Beitrag zum Ablauf der Softwarelokalisierung beschreiben, etwa ausgelagerte Strings und Ressourcendateien, und konzentriert sich darauf, was sich ändert, wenn das Produkt jede Woche oder jeden Sprint erscheint.
Die Fragen sind operativ: Freeze oder Fluss, wie die Dateien reisen, wie Sie testen, was Sie nicht lesen können, und was ein Release kosten sollte. Wenn Ihr Produkt Maschinensoftware ist, etwa ein Bedienpanel oder eine Steuerungsoberfläche, die mit der Anlage ausgeliefert wird, gelten eigene Regeln, die unser Leitfaden zur Software-Übersetzung für HMI und Maschinen behandelt.
Was SaaS-Lokalisierung bedeutet, wenn Sie jede Woche ausliefern
In einem klassischen Projekt beginnt die Lokalisierung, wenn der Inhalt fertig ist. Ein SaaS-Produkt ist nie fertig: Die Oberfläche ändert sich in kleinen Schritten, Funktionen werden zuerst für einzelne Kunden freigeschaltet, Onboarding-Abläufe laufen in Varianten, und das Hilfecenter wächst mit jedem Release.
Die SaaS-Lokalisierung hat deshalb eine andere Arbeitseinheit. Sie ist kein Dokument, sondern ein Änderungspaket: die Strings, die seit der letzten Lieferung hinzugekommen oder geändert worden sind, dazu die Hilfeartikel, Benachrichtigungen und Release Notes, die sie beschreiben. Daraus folgen drei Dinge. Geschwindigkeit entsteht durch Fluss, nicht durch Kraftakte: Stabile Strings, die pro Sprint verschickt werden, kommen innerhalb des Sprints zurück, während ein Quartalspaket immer zu spät erscheint. Konsistenz hängt an gemeinsamen Ressourcen, denn wer heute übersetzt, hat nicht unbedingt im letzten Monat übersetzt. Und die Kosten pro Release werden zur entscheidenden Kennzahl, weil das Budget laufend ausgegeben wird.
String-Freeze oder kontinuierlicher Fluss: das passende Release-Modell
Es gibt zwei grundsätzliche Wege, die Übersetzung in einen Release-Zyklus einzubauen, und die meisten erfahrenen Teams landen bei einer Mischung.
Ein String-Freeze legt vor jedem Release einen Termin fest, ab dem sich kein sichtbarer Text mehr ändern darf. Alles, was eingefroren ist, geht in die Übersetzung, kommt zurück, wird getestet und ausgeliefert. Das Modell ist einfach, planbar und leicht zu budgetieren. Es passt zu Produkten mit monatlichen oder quartalsweisen Releases, zu Inhalten, deren Wortlaut freigegeben werden muss, und zu Teams, die zum ersten Mal lokalisieren. Seine Schwäche ist die Lücke, die es erzeugt: Liegt der Freeze drei Tage vor dem Release, Übersetzung, Prüfung und Test brauchen aber fünf, erscheinen die Sprachen zu spät, oder der Freeze rückt nach vorn und die Entwicklung verliert Spielraum.
Die kontinuierliche Lokalisierung schafft den Freeze als einmaliges Ereignis ab. Strings gehen in die Übersetzung, sobald sie als bereit markiert sind, meist wenn ein Feature-Branch gemergt oder ein Pull Request freigegeben wird, und die Übersetzungen fließen im selben Rhythmus zurück. Am Release-Tag ist der größte Teil des Textes bereits übersetzt und geprüft; offen sind nur noch Änderungen in letzter Minute. Genau das bedeutet agile Lokalisierung in der Praxis: Die Übersetzung läuft neben der Entwicklung, nicht hinter ihr.
Der kontinuierliche Fluss verlangt mehr Disziplin als ein Freeze, nicht weniger. Strings müssen wirklich stabil sein, bevor sie das Repository verlassen, sonst wird derselbe Satz dreimal übersetzt, während sich die Formulierung noch einpendelt. Ein Kennzeichen „bereit zur Übersetzung“ oder eine kurze Wartezeit nach dem Merge löst das meistens.
Die Entscheidung hängt davon ab, wie oft Sie ausliefern, wie viel Text sich ändert, wie schnell jemand auf Ihrer Seite Rückfragen beantwortet und welches Risiko eine fehlende Übersetzung birgt. Ein bewährter Kompromiss ist der kontinuierliche Fluss für Oberflächentexte und Hilfeinhalte, kombiniert mit einem kurzen Freeze für Release Notes und Store-Texte, die zuletzt geschrieben und zuerst gelesen werden.
Repository und Übersetzungsprozess verbinden
Der häufigste Engpass bei der kontinuierlichen Lokalisierung ist nicht die Übersetzungsgeschwindigkeit, sondern der Umgang mit Dateien. Wenn ein Entwickler Strings von Hand exportiert, per E-Mail verschickt, wartet und die zurückgegebene Datei in den richtigen Ordner kopiert, kostet jedes Release einen Tag und birgt das Risiko, etwas zu überschreiben. Was für jeden Übersetzungsprozess ohne E-Mail und Tabellen gilt, gilt hier erst recht: Strings sollten ohne manuelle Schritte zwischen Ihrem Code-Repository und der Übersetzungsumgebung wandern.
Im einfachsten Muster exportiert ein zeitgesteuerter Job neue und geänderte Strings aus dem Hauptzweig an einen gemeinsamen Ablageort, und die übersetzten Dateien landen dort wieder, wo der Build sie abholt. In einer engeren Variante ist die Übersetzungsumgebung direkt mit dem Repository verbunden: Sie erkennt Änderungen in den Dateien der Ausgangssprache, legt Übersetzungsaufgaben an und öffnet, sobald eine Sprache fertig ist, einen Pull Request, den Ihre Entwickler wie jede andere Änderung prüfen und mergen.
Welches Muster Sie auch wählen, drei Regeln machen es sicher. Zieldateien sollten ausschließlich vom Übersetzungsprozess geschrieben werden, damit manuelle Änderungen bei der nächsten Synchronisierung nicht verschwinden. Keys müssen stabil bleiben, denn ein umbenannter Key sieht für jedes System aus wie ein gelöschter String plus ein neuer, und die vorhandene Übersetzung geht verloren. Und die Branch-Strategie gehört vorab geklärt: Wer jeden Feature-Branch übersetzt, investiert in Funktionen, die nie erscheinen; wer nur den Release-Branch übersetzt, hat zu wenig Zeit. Viele Teams übersetzen deshalb nach dem Merge aus dem Hauptzweig.
Fragen Sie Ihren Anbieter genau, wie die Dateien zu ihm gelangen und wie sie zurückkommen. Wer JSON, XML und plattformspezifische String-Dateien in ihrer Originalstruktur verarbeitet und ohne beschädigte Keys oder geänderte Kodierung zurückgibt, beseitigt eine ganze Klasse von Build-Fehlern.
Translation Memory und Glossar über alle Releases hinweg
Ein Produkt mit fünfzig Releases im Jahr erzeugt fünfzig kleine Übersetzungslieferungen. Ohne ein gemeinsames Translation Memory dahinter sammelt das Produkt nach und nach drei Übersetzungen für „Workspace“, zwei Arten, den Nutzer anzusprechen, und uneinheitliche Verben auf den Schaltflächen.
Das Translation Memory macht die kontinuierliche Lokalisierung wirtschaftlich und konsistent. Jede freigegebene Übersetzung wird mit ihrem Ausgangstext gespeichert; taucht ein String unverändert oder leicht geändert wieder auf, wird die freigegebene Formulierung wiederverwendet und nur der Unterschied übersetzt. Es sollte Ihnen gehören, nicht dem Dienstleister, und jederzeit in einem portablen Format exportierbar sein. Warum die Frage, wem das Translation Memory gehört, bei SaaS-Produkten besonders schwer wiegt, liegt auf der Hand: Kaum ein anderer Inhalt wird so oft in so kleinen Teilen aktualisiert.
Das Glossar leistet dasselbe für Begriffe. Ein SaaS-Produkt hat einen kleinen, intensiv genutzten Wortschatz: Funktionsnamen, Tarifnamen, Objekttypen, Aktionen. Jeder Begriff braucht eine freigegebene Übersetzung pro Sprache und eine Entscheidung darüber, welche Namen englisch bleiben. Das Produktmarketing benennt Funktionen gern um; das Glossar braucht deshalb eine verantwortliche Person, die es aktualisiert, bevor neue Strings hinausgehen. Wie Sie ein solches Glossar aufbauen und pflegen, zeigt unser Beitrag zum zentralen Terminologiemanagement über Übersetzer und Lieferanten hinweg.
Stilentscheidungen gehören direkt daneben. Siezen oder duzen Sie Ihre Nutzer? Sind Schaltflächen als Verb oder als Substantiv formuliert? Wie lauten Fehlermeldungen? Für deutschsprachige Märkte ist die Anrede eine der ersten Fragen, die geklärt sein muss, denn ein Wechsel zwischen „Sie“ und „du“ innerhalb derselben App wirkt unprofessionell. Ein kurzer Styleguide pro Sprache beantwortet diese Fragen einmal für alle Übersetzer und Prüfer.
Kontext, Prüfung im Kontext und Lokalisierungstests
Oberflächentexte sind kurz und mehrdeutig. „Archive“ kann ein Verb oder ein Substantiv sein, „Free“ kann sich auf den Preis oder die Verfügbarkeit beziehen. Bei der kontinuierlichen Lokalisierung wächst das Risiko, weil Übersetzer pro Paket nur eine Handvoll Strings sehen, nicht das ganze Produkt. Mit jedem Änderungspaket sollte deshalb Kontext mitreisen: ein Kommentar zu jedem mehrdeutigen Key, ein Hinweis darauf, was jeder Platzhalter enthält, die maximale Länge, wo der Platz begrenzt ist, und idealerweise ein Screenshot oder ein Link zur Staging-Umgebung.
Lokalisierungstests machen aus korrekten Übersetzungen ein korrektes Produkt. Sie bestehen aus zwei Teilen. Funktionale Prüfungen stellen sicher, dass der lokalisierte Build funktioniert: kein fest codierter englischer Text, keine abgeschnittenen Labels, keine beschädigten Platzhalter, korrekte Datums-, Zahlen- und Währungsformate, keine Zeichen, die nicht dargestellt werden. Viele dieser Prüfungen lassen sich automatisieren und bei jedem Build ausführen. Die sprachliche Prüfung im Kontext übernimmt dagegen ein Mensch, der die Sprache liest: Er geht die wichtigsten Nutzerwege in der Staging-Umgebung durch und prüft, ob jede Übersetzung zu ihrem Kontext passt, ob die Terminologie von Bildschirm zu Bildschirm einheitlich ist und ob nichts wie ein Fragment wirkt.
Sie brauchen nicht jede Woche einen vollständigen Sprachtest in jeder Sprache. Bewährt hat sich ein Rhythmus aus automatisierten Prüfungen bei jedem Build, einer Prüfung neuer Funktionen im Kontext und einem vollständigen Durchlauf bei großen Releases oder neuen Sprachen. Jede Korrektur muss zurück ins Translation Memory, nicht nur in den Build, sonst kehrt der Fehler mit der nächsten Synchronisierung zurück. Wie Sie einen Prüfschritt aufsetzen, der verwertbares Feedback statt persönlicher Vorlieben liefert, erklärt unser Beitrag zur Qualitätssicherung von Übersetzungen.
Mobile Oberflächen: Länge, Plural, Genus und Rechts-nach-links-Schriften
Mobile Apps bringen Einschränkungen mit, die Weboberflächen oft auffangen: wenig Platz auf dem Bildschirm, Beschriftungen in der Navigationsleiste und dynamische Schriftgrößen.
Länge. Übersetzte Texte sind oft länger als der englische Ausgangstext, und kurze Strings wachsen anteilig am stärksten: Eine Schaltfläche mit zwei Wörtern kann auf Deutsch doppelt so lang werden. Legen Sie Zeichenbegrenzungen für Strings in festen Bereichen fest, testen Sie früh mit der längsten Sprache und erlauben Sie Übersetzern, eine kürzere Formulierung vorzuschlagen, statt eine Abkürzung zu erzwingen, die niemand versteht.
Plural. Das Englische braucht zwei Formen („1 file“, „2 files“). Viele Sprachen brauchen mehr: Polnisch unterscheidet zwischen eins, wenige und viele, Arabisch kennt bis zu sechs Kategorien. Beide großen mobilen Plattformen und die gängigen Nachrichtenformate unterstützen Pluralkategorien, aber nur, wenn die Entwicklung sie nutzt, statt eine Zahl und ein Wort aneinanderzuhängen.
Genus und Kongruenz. Im Deutschen, in den romanischen und in den slawischen Sprachen richten sich Adjektive, Partizipien und teilweise Verben nach dem Genus des Substantivs oder der Person. Ein String wie „{name} wurde eingeladen“ funktioniert im Deutschen, braucht aber im Italienischen oder Polnischen je nach Person unterschiedliche Formen. Wo das Produkt das Genus oder den Objekttyp kennt, ermöglichen getrennte Strings oder Auswahlformate korrekte Sätze; wo nicht, müssen die Übersetzer es wissen, um eine neutrale Formulierung zu finden.
Rechts-nach-links-Schriften. Arabisch und Hebräisch spiegeln das Layout: Navigation, richtungsweisende Symbole und Fortschrittsanzeigen werden umgedreht, während Zahlen und eingebettete lateinische Texte weiter von links nach rechts laufen. Die Unterstützung für Rechts-nach-links-Schriften ist eine Entwicklungsaufgabe, die auf echten Geräten getestet werden muss, bevor sich die Übersetzung beurteilen lässt.
Store-Einträge, Release Notes und Hilfecenter
Die Oberfläche ist nur ein Teil dessen, was Nutzer lesen. Bei einer mobilen App ist der Store-Eintrag der erste lokalisierte Text, den ein Kunde sieht: Titel, Untertitel, Kurz- und Langbeschreibung, Suchbegriffe und Beschriftungen der Screenshots. Jeder Store legt eigene Zeichenbegrenzungen fest, und der Eintrag ist Werbetext, kein Oberflächentext. Wer eine App übersetzen lassen möchte, sollte ihn deshalb einem Übersetzer geben, der innerhalb dieser Grenzen überzeugend schreibt und prüft, wie Menschen im jeweiligen Markt nach Apps wie Ihrer suchen. Die Beschriftungen der Screenshots werden leicht vergessen, weil sie in Bilddateien stehen und nicht in String-Dateien.
Release Notes entstehen in letzter Minute und werden von Ihren aktivsten Nutzern gelesen. Planen Sie dafür ein kurzes, festes Übersetzungsfenster ein und verwenden Sie die Terminologie der Oberfläche, damit die Funktion, die in den Notes genannt wird, auch die ist, die Nutzer in der App finden.
Das Hilfecenter wächst meist schneller als die Oberfläche. Seine Artikel sind lang, wiederholen sich und werden oft aktualisiert. Das macht sie zu guten Kandidaten für maschinelle Übersetzung mit Post-Editing durch qualifizierte Linguisten, sofern die Maschine mit Ihrem freigegebenen Glossar und Translation Memory arbeitet. Auf unserer Seite zum Post-Editing maschineller Übersetzungen erklären wir, wie wir diese Entscheidung je Inhaltstyp treffen. Oberflächentexte sind ein anderer Fall: kurz, mehrdeutig und auf jedem Bildschirm sichtbar, deshalb brauchen sie in der Regel von Anfang an einen menschlichen Übersetzer. Ihre Website folgt wiederum einer eigenen Logik, die wir im Beitrag zum Thema Website übersetzen lassen vergleichen.
Wiederverwendung und Kosten pro Release messen
Bei der kontinuierlichen Lokalisierung erklärt der Wortpreis weniger vom Budget als die Zusammensetzung jedes Releases. Jedes Änderungspaket enthält echten neuen Text, Text, der einer vorhandenen Übersetzung ähnelt, und Text, der mit einer freigegebenen Übersetzung identisch ist, etwa ein String, der auf einen anderen Bildschirm verschoben wurde. Der Anteil des wiederverwendeten Textes heißt Leverage und ist die nützlichste Kennzahl, um Kosten zu verstehen.
Ein Rechenbeispiel zur Veranschaulichung: Ein Sprint ändert 1.500 Wörter an Oberflächen- und Hilfetext. Davon sind 700 neu, 500 Teiltreffer (Fuzzy Matches) zu vorhandenen Übersetzungen und 300 exakte Wiederholungen. Bei sechs Sprachen sind das 4.200 neue Wörter zu übersetzen, 3.000 anzupassen und 1.800 zu prüfen, statt 9.000 Wörter von Grund auf zu übersetzen. Weist der Anbieter diese Aufteilung bei jeder Lieferung aus, sehen Sie, warum ein Sprint mehr gekostet hat als ein anderer, und erkennen Probleme früh: Ein plötzlicher Einbruch der Leverage bedeutet oft, dass Keys umbenannt oder Dateien umstrukturiert wurden und das Translation Memory Text nicht mehr erkennt, den es längst enthält.
Drei weitere Faktoren bewegen die Kosten pro Release. Paketgröße: Jede Lieferung bringt festen Aufwand für Dateihandling und Prüfungen mit, einzeln verschickte Strings sind daher teuer. Änderungsquote: Text, der nach der Übersetzung umgeschrieben wird, wird zweimal bezahlt. Testumfang: Prüfungen im Kontext gehören pro Release eingeplant, nicht erst nach einer Beschwerde entdeckt. Nach einigen Monaten geben Berichte pro Release dem Produktmanagement eine verlässliche Grundlage, um neue Sprachen und Funktionen zu budgetieren.
Der Ablauf der App-Lokalisierung in einem Sprint
So läuft die App-Lokalisierung typischerweise in einem zweiwöchigen Sprint, sobald die Grundlagen stehen.
Zu Beginn des Sprints legen Produkt und Design fest, welche Funktionen erscheinen und welche Märkte sie erhalten. Neue Begriffe, etwa ein Funktionsname, kommen mit ihren Übersetzungen ins Glossar, bevor der erste String geschrieben wird.
Während der Entwicklung legen die Entwickler Keys mit Kommentaren und Zeichenbegrenzungen an. Wird ein Feature-Branch gemergt, werden neue und geänderte Strings automatisch erfasst, und die Übersetzung beginnt. Rückfragen der Übersetzer gehen an eine benannte Person in Ihrem Team, die innerhalb eines Tages antwortet.
In der Mitte des Sprints kommen die Übersetzungen über das Repository zurück, als Pull Request oder als Dateien am vereinbarten Ort. Automatisierte Prüfungen laufen auf dem Build: Platzhalter, Länge, Kodierung und fehlende Übersetzungen.
Vor dem Release geht eine prüfende Person die neuen Funktionen in jeder Sprache in der Staging-Umgebung durch. Release Notes, Store-Texte und Hilfeartikel werden in einem kurzen, festen Fenster übersetzt. Korrekturen erfolgen in der Übersetzungsumgebung, damit sie im Translation Memory landen.
Nach dem Release meldet der Anbieter die Leverage pro Sprache, und wiederkehrende Probleme, etwa fehlender Kontext, werden für den nächsten Sprint behoben.
Typische Fehler bei der kontinuierlichen Lokalisierung
Zieldateien von Hand bearbeiten. Ein Entwickler korrigiert einen Tippfehler direkt in der deutschen Datei; die nächste Synchronisierung überschreibt ihn, oder die Korrektur erreicht das Translation Memory nie, und der Fehler kehrt im nächsten Release zurück.
Keys beim Refactoring umbenennen. Für ein Übersetzungssystem ist ein umbenannter Key ein neuer String. Die Leverage sinkt, Übersetzungen werden neu gemacht, und freigegebene Formulierungen ändern sich, ohne dass jemand es entschieden hat.
Jedes Team oder jeden Lieferanten ein eigenes Translation Memory führen lassen. Werden App, Hilfecenter und Website getrennt übersetzt, driftet die Terminologie auseinander, und ein späterer Anbieterwechsel kostet Jahre an freigegebenen Übersetzungen. Wenn Sie einen Wechsel erwägen, zeigt unser Leitfaden, wie Sie den Übersetzungsdienstleister wechseln, ohne Ihr Translation Memory zu verlieren, und was Sie vorher sichern sollten.
Den passenden Anbieter für die App-Lokalisierung wählen
Der richtige Anbieter für einen kontinuierlichen Release-Zyklus ist derjenige, dessen Arbeitsweise zu Ihrer Auslieferungskette passt, nicht einfach der mit dem niedrigsten Wortpreis. Diese Fragen zeigen das Wesentliche:
- Wie gelangen die Dateien zu Ihnen und zurück, und verarbeiten Sie unsere Ressourcenformate nativ, ohne Keys oder Platzhalter zu beschädigen?
- Welche Bearbeitungszeit sagen Sie für ein typisches Sprint-Paket zu, und wie gehen Sie mit dringenden Strings um?
- Welche automatisierten Prüfungen laufen vor der Lieferung, und wird jede Übersetzung von einem zweiten qualifizierten Linguisten revidiert?
- Können unsere Entwickler oder Produktmanager Übersetzungen im Kontext prüfen, und fließen ihre Korrekturen ins Translation Memory?
- Wem gehören Translation Memory und Glossar, und können wir beides jederzeit in einem Standardformat exportieren?
- Weisen Sie pro Release und Sprache neuen Text, Teiltreffer und Wiederverwendung getrennt aus?
Die Antworten wiegen mehr als jedes Zertifikat auf einer Website, auch wenn ein zertifizierter Prozess nach ISO 17100 zeigt, dass die Revision durch einen zweiten Linguisten Standard ist und kein optionales Extra.
Wie DEMA Solutions SaaS- und App-Teams unterstützt
Unsere Software-Lokalisierung für die Technologiebranche ist für Produktteams gemacht, die kontinuierlich ausliefern. Neue und geänderte Strings werden pro Release erfasst und übersetzt, abgestimmt auf Ihren Sprint-Rhythmus, statt in gelegentlichen Großprojekten gebündelt zu werden. JSON-, XML- und andere Ressourcendateien werden eingelesen und in ihrer Originalstruktur zurückgegeben, ohne manuellen Extraktionsschritt und ohne beschädigte Keys. Automatisierte Prüfungen erkennen beschädigte Variablen, abgeschnittene UI-Strings und Formatierungsfehler, bevor sie in einen Release-Build gelangen.
Unsere Übersetzer sind muttersprachliche technische Linguisten, die mit Software- und Entwicklerterminologie arbeiten. Ihre Entwickler und Produktmanager können direkt in der Übersetzungsumgebung prüfen statt in exportierten Tabellen, sodass Terminologiekorrekturen sofort im Translation Memory landen. Der Prozess ist nach ISO 17100 zertifiziert, und ein zweiter qualifizierter Linguist revidiert jede Übersetzung, wie auf der Seite zu unserer Übersetzungsqualität beschrieben.
Translation Memory, Glossare und Terminologiedatenbanken entstehen aus der Terminologie Ihres Produkts und bleiben Ihr Eigentum, jederzeit auf Anfrage exportierbar in portablen Formaten wie TMX und TBX. Ein Leverage-Bericht zeigt, wie viel von jedem Release wiederverwendet wurde. Über die Oberfläche hinaus übersetzen unsere Teams in Italien, Serbien und Spanien Hilfecenter und Wissensdatenbanken, API- und Entwicklerdokumentation, Release Notes und Changelogs, sodass das Produkt und alles, was dazugehört, eine gemeinsame Terminologie verwenden.
Wo TUBE ins Spiel kommt
TUBE ist unsere Lösung für Produkte mit kontinuierlichen Releases, bei denen jeder Sprint einen weiteren Lokalisierungszyklus bedeutet. Ihr Glossar und Ihr Translation Memory steuern die maschinelle Übersetzung, jede freigegebene Übersetzung fließt in ein Translation Memory, das Ihnen gehört und das Sie exportieren können, und die Leverage-Auswertung zeigt, wie viel von jedem Update aus Text stammt, den Sie bereits freigegeben haben.
Häufige Fragen
App-Lokalisierung ist die Anpassung einer mobilen oder webbasierten Anwendung an Nutzer in anderen Sprachen und Märkten: Oberfläche, Onboarding, Benachrichtigungen, Hilfecenter, Release Notes und Store-Eintrag. Neben der Übersetzung gehören Formate, Pluralformen, Textlänge und Tests im Kontext dazu.
Bei der kontinuierlichen Lokalisierung gehen neue und geänderte Strings in die Übersetzung, sobald sie stabil sind, statt bis zu einem String-Freeze vor jedem Release gesammelt zu werden. Die Übersetzungen kommen im selben Rhythmus zurück, sodass jede Sprache mit der Ausgangssprache erscheinen kann.
Nicht unbedingt für das ganze Produkt. Viele Teams lassen Oberflächentexte und Hilfeinhalte kontinuierlich fließen und behalten einen kurzen Freeze für besonders sichtbare oder kurzfristige Texte wie Release Notes, Preisseiten und Store-Einträge.
Funktionale Prüfungen stellen sicher, dass der lokalisierte Build funktioniert: kein fest codierter Text, keine Abschneidungen, keine beschädigten Platzhalter, keine falschen Formate. Die sprachliche Prüfung kontrolliert auf echten Bildschirmen, ob jede Übersetzung zu ihrem Kontext passt und die Terminologie einheitlich ist.
Mit einem Translation Memory und einem Glossar für alle Produktinhalte, einem Glossar, das vor dem Auftauchen neuer Begriffe aktualisiert wird, Korrekturen in der Übersetzungsumgebung statt in den Zieldateien und stabilen String-Keys.
Am besten pro Release statt pro Jahr, auf Basis des Volumens an neuem Text, Teiltreffern und Wiederverwendung je Sprache. Leverage-Berichte früherer Releases sind die verlässlichste Grundlage, um die Kosten neuer Funktionen und Sprachen zu schätzen.
Für Hilfeartikel und Dokumentation oft ja, wenn die Maschine mit Ihrem freigegebenen Glossar und Translation Memory arbeitet und ein qualifizierter Linguist das Ergebnis nachbearbeitet. Kurze Oberflächentexte und Store-Einträge brauchen in der Regel von Anfang an einen menschlichen Übersetzer.
Lokalisierung, die mit Ihren Releases Schritt hält
Wenn Ihre Sprachversionen später erscheinen als die Ausgangssprache oder jedes Release neue Inkonsistenzen mit sich bringt, erzählen Sie uns von Ihrem Produkt, Ihrem Release-Rhythmus und Ihren Zielsprachen. Wir sehen uns Ihre Ressourcendateien an und schlagen einen Lokalisierungsablauf vor, der in Ihre Sprints passt.
Wie können wir helfen?
Sagen Sie uns, was Sie brauchen, und wir melden uns mit passenden Lösungen bei Ihnen.