Software-Lokalisierung Ein Interface, in jeder Sprache bedienbar.
Software-Lokalisierung übersetzt UI-Strings, Fehlermeldungen und Benachrichtigungen, die in Ressourcendateien und im Code stecken. Wir liefern die übersetzten Strings im Originalformat zurück, mit erhaltenen Platzhaltern und Pluralregeln, bereit für den nächsten Build. Unverbindlich anfragen.
4-fach ISO-zertifiziertÜbersetzungspartner für anspruchsvolle Unternehmen
- Was es ist: Die Anpassung einer Anwendung an einen Sprachmarkt: UI-Strings, Meldungen und In-App-Texte, sprachlich, kulturell und technisch.
- Formate: Arbeit direkt in Ressourcendateien wie JSON, XLIFF, PO, RESX, .strings, Android XML, ARB und Properties.
- Integration: Continuous Localization per API und Systemintegration, getaktet auf Ihre Releases.
- Abgrenzung: Für den öffentlichen Webauftritt im CMS ist die Webseitenübersetzung zuständig, hier geht es um das Produkt selbst.
Dateiformate und Plattformen
Wir arbeiten dort, wo Ihre Strings liegen
Software-Texte liegen selten als fertiges Dokument vor. Sie stecken in Ressourcendateien, die Schlüssel und Wert trennen und den Code von der Sprache lösen. Wir übersetzen direkt in diesen Dateien, ohne Struktur, Tags oder Platzhalter zu zerstören, und geben sie im selben Format zurück. So lässt sich das Ergebnis ohne Nacharbeit in den nächsten Build übernehmen.
| Plattform / Umgebung | Typische Formate | Besonderheit |
|---|---|---|
| Web-Apps & SaaS | JSON (i18next), XLIFF, YAML, PO | Schlüsselbasierte Strings, oft ohne Kontext |
| iOS & macOS | .strings, .stringsdict, XLIFF | Pluralregeln über stringsdict |
| Android | strings.xml, XLIFF | Plurals und Platzhalter im XML |
| .NET / Windows | RESX, XLIFF | Ressourcen pro Kultur (de-DE, fr-FR) |
| Java / Flutter / sonstige | .properties, ARB, XML, YAML | ICU MessageFormat für Plurale |
Auch eingebettete Systeme, Firmware-Oberflächen und Industriesteuerungen lokalisieren wir. Falls Ihr Format hier nicht steht, ordnen wir es im Vorgespräch zu. Mehr zur technischen Seite finden Sie unter tolingo API und Systemintegration. Hintergründe zu einem konkreten Format zeigt unser Beitrag zur YAML-Lokalisierung.
Die typischen Stolpersteine
Woran Software-Lokalisierung scheitert, wenn sie wie Textübersetzung behandelt wird
Wer Software wie ein Dokument übersetzt, produziert Fehler, die erst im laufenden Produkt auffallen. Fünf Punkte tauchen immer wieder auf, und genau hier setzt unser Prozess an.
- Stringlänge sprengt die Oberfläche
Deutsch ist oft 30 Prozent länger als Englisch, Japanisch deutlich kürzer. Ein Button, der im Original passt, wird übersetzt abgeschnitten. Wir prüfen Längen im Kontext und kürzen, wo die Oberfläche es verlangt.
- Platzhalter und Variablen gehen verloren
In einem String wie „Hallo, {name}" oder „%d Artikel" darf der Platzhalter nicht übersetzt oder verschoben werden, sonst stürzt die Anzeige ab. Unsere Übersetzer kennen diese Syntax und lassen den Code unangetastet.
- Pluralregeln werden ignoriert
Andere Sprachen haben andere Pluralformen. Arabisch unterscheidet sechs, Polnisch drei. Eine Datei mit einer einzigen Mehrzahlform ist im Zielmarkt schlicht falsch. Wir lokalisieren über ICU MessageFormat und plattformeigene Plural-Mechanismen.
- Fehlender Kontext führt zu Fehlgriffen
Ein einzelnes „Open" kann Verb oder Zustand sein. Ohne Kontext rät die Übersetzung. Wir arbeiten mit Schlüsselnamen, Kommentaren und auf Wunsch Screenshots oder einem Test-Build, damit jeder String richtig sitzt.
- Leserichtung und Format bleiben unbeachtet
Bei Arabisch und Hebräisch muss die Oberfläche gespiegelt werden, dazu kommen lokale Datums-, Zahlen- und Währungsformate. Diese kulturelle und technische Anpassung gehört für uns zur Lokalisierung dazu, nicht erst zur Nacharbeit.
Internationalisierung und Continuous Localization
Lokalisierung als laufender Kreislauf, nicht als Einmalprojekt
Software steht nie still: Mit jedem Release ändern sich Strings. Damit die Lokalisierung Schritt hält, trennt die Internationalisierung (i18n) zuerst Texte vom Code. Danach läuft sie als Kreislauf, neue Strings gehen per API automatisch in die Übersetzung und kommen einsatzfertig zurück. Ein Translation Memory senkt die Folgekosten um bis zu 70 Prozent.
Von der Ressourcendatei zur lokalisierten App
Drei Schritte, vom Export bis zum einsatzfertigen Build
Strings & Kontext
Ihre Ressourcendateien, die Zielsprachen und die Plattform. Auf Wunsch Screenshots oder einen Test-Build, damit jeder String im Kontext sitzt.
Übersetzung plus LQA
Muttersprachliche Fachübersetzer übertragen die Strings, Platzhalter und Pluralregeln bleiben intakt. In der Linguistic Quality Assurance prüfen wir Länge und Kontext.
Dateien im Originalformat
Die lokalisierten Ressourcendateien im selben Format wie geliefert, bereit für Deployment oder den nächsten Build. Auf Wunsch automatisiert per API.
Nativ bedienbar im Zielmarkt Eine Anwendung, die sich in jeder Sprache anfühlt, als wäre sie dafür gebaut. Grundlage ist eine saubere Fachübersetzung nach ISO 17100.
Bereit, Ihre Software global einsetzbar zu machen?
Beschreiben Sie Ihr Projekt: Plattform, Formate, Zielsprachen und Release-Rhythmus. Wir empfehlen den passenden Weg und nennen Umfang und Preis.
Kostenlos · Unverbindlich · Antwort in ~10 Minuten (Geschäftszeiten)Häufige Fragen zur Software-Lokalisierung
Abgrenzung, Formate, Kontext, KI und Kosten
Was ist Software-Lokalisierung?
Software-Lokalisierung ist die Anpassung einer Anwendung an einen Sprachmarkt. Übersetzt werden die Texte in der Software selbst, also UI-Strings, Fehlermeldungen, Onboarding und Benachrichtigungen. Dazu kommen kulturelle und technische Anpassungen wie Datums- und Zahlenformate, Maßeinheiten, Pluralregeln und Leserichtung. Die Arbeit findet direkt in Ressourcendateien statt, nicht in einem Textdokument.
Was ist der Unterschied zur Webseitenübersetzung?
Die Webseitenübersetzung überträgt Ihren öffentlichen Webauftritt im CMS, also Seiten, Produkttexte, Blog und Meta-Daten. Die Software-Lokalisierung betrifft das Produkt selbst, also die Texte in der Anwendung. Eine SaaS hat oft beides: eine Marketing-Website und die eigentliche App. Dann laufen die zwei Projekte parallel, mit je eigenem Prozess.
Welche Dateiformate und Plattformen unterstützt ihr?
Wir arbeiten in JSON, XLIFF, PO, RESX, .strings und .stringsdict, Android strings.xml, ARB, Properties und YAML. Damit decken wir Web-Apps und SaaS, iOS und macOS, Android, .NET, Java und Flutter sowie eingebettete Systeme ab. Falls Ihr Format hier nicht steht, ordnen wir es im Vorgespräch zu.
Wie bekommt der Übersetzer den Kontext zu einzelnen Strings?
Schlüsselbasierte Strings sind ohne Kontext mehrdeutig, ein „Open" kann Verb oder Zustand sein. Wir nutzen Schlüsselnamen, Entwickler-Kommentare und auf Wunsch Screenshots oder einen Test-Build. In der abschließenden Linguistic Quality Assurance prüfen wir die Strings im Kontext der Oberfläche.
Muss meine Software für die Lokalisierung vorbereitet sein?
Idealerweise ja. Bei der Internationalisierung (i18n) werden Texte vom Code getrennt, in Ressourcendateien ausgelagert und es wird Platz für längere Übersetzungen eingeplant. Ist das erledigt, läuft die Lokalisierung planbar. Wir beraten bei der Vorbereitung, falls die Trennung noch nicht vollständig ist.
Kann KI meine Software lokalisieren?
Maschinelle Übersetzung hilft bei großen, gleichförmigen String-Mengen, scheitert aber oft an fehlendem Kontext, Platzhaltern und Pluralregeln. Für sicht- und bedienbare Texte empfehlen wir Post-Editing nach ISO 18587 oder eine reine Fachübersetzung. So bleibt die Geschwindigkeit der KI erhalten, ohne dass die Oberfläche bricht.
Was kostet eine Software-Lokalisierung und wie lange dauert sie?
Abgerechnet wird nach Wortanzahl: Post-Editing ab 0,05 €/Wort, Fachübersetzung ab 0,12 €/Wort. Über Translation Memory sparen Sie bei wiederkehrenden Strings bis zu 70 %. Dauer und Preis hängen von Umfang, Plattform und Zielsprachen ab. Nach einer kurzen Analyse erstellen wir Zeitplan und Angebot, innerhalb der Geschäftszeiten meist in wenigen Minuten.
Glossar
Begriffe rund um die Software-Lokalisierung
- Internationalisierung (i18n)
- Technische Vorbereitung einer Software auf mehrere Sprachen: Texte werden vom Code getrennt, in Ressourcendateien ausgelagert und es wird Platz für längere Strings eingeplant.
- Lokalisierung (L10n)
- Anpassung der vorbereiteten Software an einen konkreten Markt: Übersetzung der Strings plus Formate, Pluralregeln, Leserichtung und kulturelle Konventionen.
- String / Ressourcendatei
- Ein per Schlüssel angesprochener Textbaustein und die Datei, in der diese Bausteine liegen, etwa JSON, XLIFF oder strings.xml.
- Pseudolokalisierung
- Testverfahren, das Strings künstlich verlängert und mit Sonderzeichen versieht, um Platzprobleme und fehlende Auslagerung vor der echten Übersetzung zu finden.
Software, die sich überall wie zu Hause anfühlt.
Schicken Sie uns Ihre Ressourcendateien und Zielsprachen. Wir lokalisieren Strings, Formate und Oberfläche und geben alles einsatzfertig im Originalformat zurück.
ISO 17100 · ISO 18587 · Translation Memory inklusive · Antwort in ~10 Minuten (Geschäftszeiten)