Angebot anfordern
Angebot anfordern
1. Was gehört zu einer Softwarelokalisierung?
Eine Softwarelokalisierung passt Ihr Softwareprodukt an Sprache, Kultur und Gewohnheiten eines neuen Markts an. Übersetzung und Lokalisierung hängen dabei eng zusammen: Die Übersetzung der Texte ist ein wichtiger Teil, aber nicht der einzige. Das W3C trennt die Begriffe klar: Lokalisierung ist die Anpassung an einen Zielmarkt, Internationalisierung die Gestaltung der Software, die diese Anpassung leicht macht.
Für Ihr Lokalisierungsprojekt heißt das: Wer Ihre Software lokalisiert, braucht sprachliches und technisches Wissen zugleich. Eine gute Fachübersetzung trifft die Begriffe Ihrer Branche und passt trotzdem in die Felder und Menüs Ihrer Benutzeroberfläche.
Für Lokalisierung, Internationalisierung und verwandte Begriffe begegnen Ihnen in Fachtexten Kurzformen. L10N steht für Lokalisierung (L, zehn Buchstaben, N), I18N für Internationalisierung, G11N für Globalisierung und T9N für Übersetzung.
Benutzeroberfläche, Hilfetexte und Dokumentation
Lokalisiert wird fast jeder Text, den Ihre Nutzer sehen. Das gilt für Programme auf dem Desktop genauso wie für Webanwendungen und Apps. Zu diesen Texten gehören zum Beispiel:
- Die Benutzeroberfläche mit Menüs, Dialogen, Schaltflächen und Meldungen.
- Tastenkombinationen und Zugriffstasten in den Menüs.
- Online-Hilfe, Installationsanleitung und Versionsinformationen.
- Lizenzvereinbarung, Nutzungsbedingungen und Datenschutzhinweise.
Handbuch und Online-Hilfe erklären dieselben Funktionen wie die Benutzeroberfläche. Sie müssen deshalb dieselben Begriffe verwenden: Heißt eine Schaltfläche „Exportieren“, darf die Hilfe nicht von „Ausgeben“ sprechen. Wenn Sie mit dem Softwareprodukt auch Ihre technische Dokumentation übersetzen lassen, passen Oberfläche und Anleitung zusammen.
Lizenz- und Nutzungsbedingungen gehören ebenfalls zur Lokalisierung. Weil sie Verträge mit Ihren Kunden sind, können Sie sie wie Ihre AGB übersetzen lassen. Für Datenschutzhinweise verlangt Art. 12 DSGVO eine klare und einfache Sprache; eine bestimmte Landessprache schreibt der Artikel nicht vor. Klar ist ein Hinweis für Ihre Nutzer aber meist erst in ihrer eigenen Sprache, und dafür sind juristische Übersetzungen der sichere Weg.
Bei Translate-Trade ist die Softwarelokalisierung Teil unserer Übersetzungsdienste: Oberfläche, Hilfe und Rechtstexte Ihres Softwareprodukts übersetzen wir in einem gemeinsamen Auftrag.
Datum, Zahlen und Währungen im Zielmarkt
Datum, Zahlen und Preise sehen in jedem Markt anders aus. In Deutschland steht zum Beispiel 21.10.2026 und 1.234,50 €, in den USA dagegen 10/21/2026 und $1,234.50. Ein fest eingebautes Format bleibt bei der Lokalisierung deshalb stehen und wirkt im Zielmarkt sofort fremd.
Gut gebaute Software legt diese Formate nicht selbst fest. Sie nutzt die Daten des Unicode CLDR (Common Locale Data Repository), einer Sammlung mit Formaten für Datum, Zahlen, Währungen und Maße je Sprache und Region. Auch Sortierung und Pluralregeln stehen dort. Übersetzt wird dann nur der Text rund um ein Datum; die Anpassung des Formats an jede Sprache übernimmt die Software selbst.
2. Wie Translate-Trade Ihre Software übersetzt, ohne den Code anzufassen
Damit bei der Lokalisierung Ihrer Software Format und Länge stimmen, brauchen wir Ihre Texte so, wie Ihr Programm sie speichert: als Sprachdateien. Sie schicken uns diese Dateien, wir übersetzen die Texte darin, und Ihr Code bleibt unberührt. Möglich macht das der Aufbau der Dateien: Jeder Text hat einen festen Schlüssel, den Ihre Software aufruft, und nur der Wert dahinter ändert sich je Sprache.
Lokalisierung von Software: Vom Export bis zur Zieldatei
Die Lokalisierung von Software beginnt meist mit einem Export, der sich in agilen Teams mit jedem Sprint wiederholt. Ihr Team zieht die Texte aus dem Projekt in eine Sprachdatei, zum Beispiel als JSON oder XLIFF. Wir übersetzen die Werte, Schlüssel und Struktur bleiben stehen. Aus der lokalisierten Fassung entsteht für jede Sprache eine Zieldatei, die Ihre Entwickler wieder ins Projekt übernehmen.
Ein eigenes Lokalisierungstool brauchen Sie dafür nicht. Sie können uns jedes gängige Dateiformat oder auch PDF schicken. Lokalisierungstools lohnen sich vor allem, wenn Ihr Team viele Sprachen und Versionen selbst verwaltet. Ein Lokalisierungstool schützt Schlüssel, Tags und Code, zeigt beim Übersetzen Kontext und Länge und schlägt Treffer aus dem Translation Memory vor.
Moderne Übersetzungstechnologie arbeitet nach demselben Prinzip: Bearbeitet wird nur der Text, alles Technische ist gesperrt, damit die Funktionalität erhalten bleibt.
Ist Ihr Softwareprodukt eine Web-App, gehört auch die Website dazu. Dann können Sie mit der Oberfläche zugleich Ihre Website übersetzen lassen.
Dateiformate wie JSON, XLIFF, RESX und PO
Die gängigen Dateiformate unterscheiden sich vor allem darin, wo der übersetzbare Text steht:
| Format | Herkunft | Was übersetzt wird |
|---|---|---|
| XLIFF | Standard von OASIS | Zieltext (target) zu jedem Ausgangstext (source) |
| RESX | .NET von Microsoft | der Wert, der Name bleibt |
| PO | GNU gettext | „msgstr“ zu jedem „msgid“ |
| JSON, YAML | häufig in Web-Projekten | der Wert zu jedem Schlüssel |
In einer PO-Datei ist „msgid“ die Zeile mit dem Ausgangstext, „msgstr“ die Zeile für die Übersetzung. Kommt dasselbe Wort in zwei Bedeutungen vor, trennt „msgctxt“ die beiden Meldungen nach ihrem Kontext. Bei RESX bekommt jede Sprache eine eigene Datei, etwa Resources.fr-FR.resx für Französisch in Frankreich.
Bei XLIFF lohnt ein Blick auf die Version. Es gibt die Versionen 1.2, 2.0 und 2.1, und Dateien nach 2.x sind nicht zugleich zu 1.2 konform. Nennen Sie uns deshalb die Version, die Ihr Lokalisierungstool erwartet.
Wer übersetzt, und wie tauschen wir Dateien aus?
Für die Softwarelokalisierung setzt Translate-Trade Übersetzer mit langjähriger Erfahrung im jeweiligen Fachgebiet ein. Bei uns entstehen viele Texte als KI-Übersetzung mit Post-Editing: Zuerst übersetzt eine Maschine, danach bearbeitet ein Mensch jeden Satz. Anschließend prüfen und lektorieren muttersprachliche Übersetzer jeden übersetzten Text.
Firmenkunden tauschen Dateien bei uns über ein Kundenportal aus. Dort laden Sie Ihre Sprachdateien hoch, geben Übersetzungen frei und sehen Terminologie und Translation Memory Ihres Lokalisierungsprojekts ein. Ihre Daten verarbeiten wir DSGVO-konform; mehr dazu lesen Sie unter Datenschutz und Sicherheit.
Schicken Sie uns mit Ihrer Anfrage zur Lokalisierung gern eine Ihrer Sprachdateien. So sehen wir Format und Umfang gleich und können Ihr Angebot genau darauf abstimmen.
3. Kontext, Variablen und Textlänge: Worauf es bei Strings ankommt
Ein String ist ein einzelner Text Ihrer Oberfläche, etwa die Beschriftung einer Schaltfläche oder eine Fehlermeldung. Anders als ein Satz im Dokument steht er in der Sprachdatei ohne seine Umgebung. Der Übersetzer sieht nicht, wo er erscheint, was davor steht und wie viel Platz er hat.
Strings ohne Zusammenhang: Was heißt Open?
Das englische Wort Open zeigt das Problem. Auf einer Schaltfläche heißt es „Öffnen“, als Status eines Tickets „Offen“ und am Eingang eines Geschäfts „Geöffnet“. In der Sprachdatei steht nur das Wort, ohne Hinweis auf seine Rolle.
Jeder mehrdeutige String braucht deshalb Kontext. Die Android-Dokumentation empfiehlt Kommentare direkt am String, etwa „Schaltfläche, höchstens 30 Zeichen“. Screenshots der Oberfläche oder ein Lokalisierungstool mit Vorschau helfen zusätzlich. Hier beginnt bei der Lokalisierung die Zusammenarbeit zwischen Übersetzer und Kunde: Je mehr Kontext Ihre Entwickler mitgeben, desto weniger Rückfragen gibt es.
Mehrzahl, Geschlecht und zusammengesetzte Sätze
Variablen stehen im String in Form von Platzhaltern, zum Beispiel für einen Namen oder eine Anzahl. Android nummeriert sie wie „%1$s“ und „%2$d“, damit Übersetzer ihre Reihenfolge ändern können. Aus „%1$s shared %2$s“ wird im Deutschen etwa „%2$s wurde von %1$s geteilt“. Die Reihenfolge von Platzhaltern darf der Übersetzer ändern, die Zeichen darin nicht.
ICU MessageFormat setzt Variablen in geschweifte Klammern, etwa „{0}“ oder „{host}“. In einer einzigen Meldung regelt es auch Mehrzahl (plural) und Geschlecht (select). Das ist für die Lokalisierung nötig, weil „1 Datei, 2 Dateien“ nicht für jede Sprache reicht. Das Unicode CLDR kennt sechs Pluralkategorien: zero, one, two, few, many und other.
| Sprache | Formen | Beispiel |
|---|---|---|
| Deutsch, Englisch | one und other | 1 Datei, 2 Dateien |
| Polnisch | drei Formen nach der Zahl | 1 plik, 2 bis 4 pliki, 5 bis 21 plików, 22 bis 24 pliki |
| Arabisch | alle sechs Kategorien | zero, one, two, few, many, other |
| Chinesisch, Japanisch, Koreanisch | nur other | eine Form für jede Zahl |
Liefert Ihre Datei nur one und other, fehlen in solchen Sprachen Formen. Im Polnischen ergänzt unser Übersetzungsbüro Polnisch die fehlenden Formen. Ähnlich ist es im Russischen, wo sich die Form eines Wortes ebenfalls nach der Zahl richtet; dort übernimmt das unser Übersetzungsbüro Russisch. Im Arabischen füllt unser Übersetzungsbüro Arabisch alle sechs Kategorien.
Schwierig wird es auch, wenn Ihre Software Sätze erst zur Laufzeit aus Bruchstücken zusammensetzt. Im Englischen funktioniert „Delete the“ mit einem Objekt für jedes Wort. Im Deutschen heißt es aber „die Datei löschen“ und „den Ordner löschen“, denn Genus und Kasus ändern den Artikel. Ganze Sätze mit Platzhaltern und select-Regel vermeiden solche Fehler.
Passt der Zieltext noch auf die Schaltfläche?
Oft nicht ohne Weiteres, denn Zieltexte werden gegenüber dem Englischen meist länger. Microsoft rechnet als Faustwert mit 40 Prozent mehr Länge gegenüber dem englischen Ausgangstext. Bei sehr kurzen Strings sind es 200 bis 400 Prozent: Aus „Tab“ wird in deutschen Oberflächen zum Beispiel „Registerkarte“. Das betrifft die Lokalisierung ins Deutsche ebenso wie ins Französische.
Für den Übersetzer heißt das: Er braucht die erlaubte Länge, um passend zu formulieren. Steht eine Zeichengrenze im Kommentar oder im Lokalisierungstool, sucht er bei der Anpassung ein kürzeres Wort oder eine knappere Form. So bleibt die lokalisierte Beschriftung lesbar, statt auf der Schaltfläche abgeschnitten zu werden.
4. Software lokalisieren ohne Nacharbeit: Was Entwickler vorbereiten
Bei der Softwarelokalisierung sparen Ihre Entwickler am meisten Zeit vor dem ersten übersetzten Text, denn wer die Software früh für mehrere Sprachen auslegt, muss später nichts nachbauen. Das W3C rät deshalb, die Internationalisierung von Anfang an einzuplanen, weil Nachrüsten teuer wird.
Internationalisierung als Voraussetzung
Internationalisierung heißt: Die Software kann jede Sprache aufnehmen, ohne dass sich Code oder Funktionalität ändern. Ihre Entwickler sollten dafür vor allem diese Punkte prüfen:
- Unicode durchgängig verwenden, damit jede Schrift dargestellt wird.
- Keine Oberflächentexte fest in den Code schreiben, sondern in Ressourcendateien auslagern.
- Bidirektionalen Text unterstützen, also Sprachen, die von rechts nach links laufen.
- Formatbibliotheken für Datum, Zahlen und Währungen nutzen.
- Im Layout Platz für längere Texte lassen.
Auch Groß- und Kleinschreibung hängt von der Sprache ab. Im Türkischen gibt es ein i mit und eines ohne Punkt: Aus i wird groß İ, aus ı wird I. Lassen Sie Ihre Software ins Türkische übertragen, etwa über unser Übersetzungsbüro Türkisch, sollte Ihr Code Großbuchstaben deshalb nach den Regeln der jeweiligen Sprache bilden.
Wie wichtig eine vollständige Standardsprache ist, zeigt Android. Die Standarddatei „res/values/strings.xml“ muss alle Strings enthalten, sonst bricht die App mit einem Fehler ab. Sprachdateien dürfen dagegen nur einen Teil enthalten: Fehlt dort ein Text, zeigt die App ihn einfach in der Standardsprache an.
Ob Ihre Benutzeroberfläche für die Lokalisierung bereit ist, zeigt ein Test mit Pseudo-Lokalisierung, den wir weiter unten bei der Qualitätssicherung erklären.
Ausgangstexte kurz und eindeutig halten
Viele Rückfragen in der Lokalisierung entstehen schon beim Ausgangstext. Kurze, eindeutige Texte kann ein Übersetzer sicher übertragen, lange Sätze mit mehreren Aussagen nicht. Bilden Sie ganze Sätze mit Platzhaltern, statt Sätze aus Bruchstücken zusammenzusetzen. Geben Sie mehrdeutigen Textbausteinen außerdem einen Kommentar mit, der Rolle und Länge nennt.
Prüfen Sie auch Ihre Produktnamen, bevor die Lokalisierung beginnt. Ein Name, der im Deutschen gut klingt, kann im Zielmarkt eine ungewollte Bedeutung haben. Wer das vor dem Launch klärt, muss Logo, Oberfläche und Werbung später nicht ändern.
Wann Sie den Sprachdienstleister einbinden
Binden Sie den Sprachdienstleister am besten ein, bevor Sie die ersten Dateien exportieren. Klären Sie mit Ihrer Übersetzungsagentur dann Sprachen, Dateiformat, Lokalisierungstool, Termine und ein vorhandenes Translation Memory. So passt der Export von Anfang an, und niemand muss Dateien nachträglich umbauen. Arbeiten Ihre Entwickler agil, legen Sie auch fest, wie neue Texte aus jedem Sprint zu uns kommen.
Bei Translate-Trade nehmen wir diese Angaben gern mit Ihrer Anfrage auf. Schreiben Sie uns, welche Sprachen und welches Format Sie planen, dann sagen wir Ihnen, was wir für Übersetzung und Lokalisierung von Ihnen brauchen.
5. Qualitätssicherung: Was Translate-Trade prüft und was Sie testen
Bevor die lokalisierte Fassung Ihres Softwareprodukts live geht, teilen sich zwei Seiten die Prüfung. Wir sorgen als Sprachdienstleister dafür, dass jede Übersetzung sprachlich stimmt. Ihre Entwickler prüfen, ob die übersetzte Software funktioniert und richtig aussieht.
Sprachliche Prüfung bei Translate-Trade
Bei Translate-Trade prüft eine zweite Person jede Übersetzung, bevor sie zu Ihnen geht. Dieses Vier-Augen-Prinzip gilt für jeden Auftrag, auch für ein kleines Paket neuer Texte aus einem agilen Sprint. Möchten Sie zusätzlich vorhandene Texte prüfen lassen, etwa Ihre englischen Ausgangsstrings, gibt es dafür unser Lektorat und Korrektorat.
Bei der Lokalisierung von Software kommen eigene Prüfpunkte dazu: Länge, Tags, gleiche Begriffe für gleiche Funktionen und der Umgang mit Platzhaltern. Viele dieser Fehler finden Lokalisierungstools und Prüfwerkzeuge automatisch, zum Beispiel eine fehlende Variable.
Zu jeder Lieferung bekommen Sie von uns ein Qualitätsprotokoll. Es belegt, dass Ihre Übersetzung nach dem ISO-Prozess entstanden ist. In Ihrem eigenen ISO-Audit legen Sie es als Nachweis vor. Grundlage ist unsere Zertifizierung: Wir sind ein dreifach zertifiziertes Übersetzungsbüro, nach ISO 9001, ISO 17100 und ISO 18587. Diese Normen regeln den Übersetzungsprozess, den Test Ihrer Software ersetzen sie nicht.
Technische Prüfung und Funktionstest bei Ihnen
Ob die lokalisierte Benutzeroberfläche funktioniert, sieht nur, wer die Software startet. Deshalb testen Sie die Funktionalität in Ihrer eigenen Umgebung. Passen die Texte auf jede Schaltfläche? Stehen Namen und Zahlen an der richtigen Stelle? Öffnet sich jeder Dialog wie in der Ausgangssprache?
Viele Fehler finden Sie schon, bevor übersetzt wird, mit einer Pseudo-Lokalisierung. Microsoft nutzt dafür die Pseudolocales qps-ploc, qps-plocm für gespiegelte Oberflächen und qps-ploca für ostasiatische Zeichen. Jeder String steht dort in Klammern und ist verlängert, so fällt ein abgeschnittener Text sofort auf.
Android bietet en-XA mit Akzenten und längeren Texten sowie ar-XB für die Schreibrichtung von rechts nach links. Beide zeigen abgeschnittene Layouts, fest codierte Texte und zusammengesetzte Strings. Diese Tests mit Werkzeugen der Hersteller ersetzen keine Prüfung der echten Übersetzung.
Prüfen Sie außerdem Handbuch und Hilfe mit. Nach dem neuen Produkthaftungsgesetz gilt auch Software als Produkt, und Anleitungen für den Gebrauch werden bei der Beurteilung eines Fehlers berücksichtigt. Laut Gesetzesbeschluss tritt es am 09.12.2026 in Kraft. Wenn Sie mit der Software auch die Bedienungsanleitung übersetzen lassen, prüfen wir sie ebenfalls nach dem Vier-Augen-Prinzip.
Am Ende halten Sie für jedes Lokalisierungsprojekt beides in der Hand: das Qualitätsprotokoll als Nachweis der sprachlichen Prüfung und die Ergebnisse Ihres eigenen Funktionstests.
6. Was ist bei Apps anders als bei Software für den Desktop?
Auch bei Apps stecken die Texte in Sprachdateien, nur sind die Pakete kleiner, die Bildschirme enger und die Geräte zahlreicher. Sie können Ihre App deshalb genauso übersetzen lassen, denn sie folgt denselben Regeln wie die Lokalisierung von Software für den Desktop. Spricht man bei Apps von Lokalisierung, ist übrigens nicht die Ortung gemeint, sondern die Anpassung an Sprache und Markt.
Kleine Bildschirme und viele Geräte
Auf einem Smartphone fehlt der Platz, den eine Oberfläche auf dem Desktop bietet. Ein deutscher Text, der auf einem großen Bildschirm passt, wird auf einem kleinen Gerät schnell abgeschnitten. Dazu kommen Android, iOS und Web, oft mit eigenen Texten je Plattform. Testen Sie Darstellung und Funktionalität der lokalisierten App deshalb auf kleinen und großen Geräten, und nennen Sie uns Zeichengrenzen und Kontext für knappe Stellen wie Tabs und Schaltflächen.
In einer Android-App liegen die übersetzten Strings je Sprache in einem eigenen Verzeichnis, etwa „res/values-fr/strings.xml“ für Französisch oder „values-en-rGB“ für britisches Englisch. Viele Lokalisierungstools lesen diese Verzeichnisse direkt ein.
Nicht nur der Bildschirm bestimmt die Texte einer App, sondern auch ihr Fachgebiet. Banking- und Finanz-Apps haben eigene Fachbegriffe, zum Beispiel Lastschrift, Depot oder Freigabe per TAN. Bei der Lokalisierung müssen diese Begriffe im Zielmarkt so lauten, wie Kunden sie von ihrer Bank kennen. Dafür gibt es unsere Finanzübersetzungen.
Store-Beschreibung, Screenshots und Push-Nachrichten
Zur Lokalisierung einer App gehören auch Texte, die gar nicht in der App selbst stehen. Unsere Übersetzer bearbeiten diese Texte rund um Ihre App ebenfalls, zum Beispiel die Beschreibung im Store, Texte in Screenshots und Push-Nachrichten. Sie sollen in wenigen Wörtern überzeugen und sind damit eher Werbung als Oberfläche.
Hier passt deshalb eine Marketing-Übersetzung mit einer Anpassung von Ton und Wirkung an die Zielsprache. Für Screenshots schicken Sie uns am besten die Texte als Datei, nicht nur das Bild. Senden Sie Sprachdateien und Store-Texte gern in einem Lokalisierungsprojekt zusammen, dann lauten die Begriffe dank Translation Memory in App und Store gleich.
7. Agile Lokalisierung: Was bei jedem Update neu übersetzt wird
Bei einem Update müssen Sie nicht alles neu übersetzen lassen. Zu bearbeiten sind meist nur die Strings, die neu dazukommen oder sich geändert haben. Viele Teams lokalisieren deshalb im Takt ihrer Sprints, in kleinen Paketen und oft in vielen Sprachen zugleich. Man spricht dann von agiler oder kontinuierlicher Lokalisierung.
Neue und geänderte Strings
Wie erkennt man bei der Lokalisierung Übersetzungen, die nach einer Änderung nicht mehr passen? Bei gettext übernimmt das msgmerge. Das Werkzeug gleicht nach einem Update die alten Übersetzungen mit den neuen Ausgangstexten ab und markiert unsichere Treffer mit dem Flag „fuzzy“. Der Übersetzer prüft diese Stellen und entfernt das Flag, sobald die Übersetzung wieder stimmt.
Lokalisierungstools arbeiten ähnlich mit einem Translation Memory, einem Speicher für bereits übersetzte Sätze. Es erkennt wiederkehrende Strings, sodass in jedem agilen Sprint nur Neues bearbeitet werden muss. Bei Translate-Trade laden Firmenkunden die neuen Texte einfach im Kundenportal hoch und geben die Übersetzungen dort frei.
Einheitliche Begriffe über alle Versionen
Ein Begriff, der in Version 1 „Projektmappe“ heißt, sollte in Version 5 nicht plötzlich „Lösung“ heißen. Sonst finden Nutzer die Funktion in Hilfe und Oberfläche nicht wieder. Als Firmenkunde halten Sie mit unserem Terminologiemanagement und einem Translation Memory Ihre Fachbegriffe von Version zu Version und in allen Sprachen gleich.
Terminologie lässt sich als TBX-Datei zwischen Lokalisierungstools austauschen, einem Format nach ISO 30042:2019. Microsoft stellt zum Beispiel seine IT-Terminologie in fast 100 Sprachen so bereit. Für deutsche Oberflächen legt der Microsoft German Localization Style Guide auch die Anrede fest: „Sie“ im Imperativ, etwa „Klicken Sie auf OK.“ Das gilt bei Microsoft. Für Ihr Softwareprodukt entscheiden Sie selbst, wichtig ist nur, dass die Anrede in jeder Version gleich bleibt.
Eilfall vor dem Release
Gerade in agilen Projekten kommen kurz vor dem Release oft noch neue Texte dazu, etwa eine geänderte Fehlermeldung oder ein neuer Hinweis. Für solche Fälle bieten wir eine Express-Übersetzung gegen Aufschlag an. Je kleiner das Paket und je klarer der Kontext, desto schneller hat der Übersetzer die Texte lokalisiert.
Nennen Sie uns in Ihrer Anfrage die Release-Termine Ihrer Lokalisierungsprojekte. Dann sehen wir gleich, ob ein Eilauftrag nötig ist, und finden mit Ihnen den passenden Weg.
8. Software für China, Japan, Korea und die arabische Welt
Die Lokalisierung von Software gelingt auch mit ganz anderen Schriften. Voraussetzung ist ein Programm, das Unicode durchgängig verarbeitet und die Anpassung des Layouts an die Sprache erlaubt. Dann lassen sich Ihre Softwareprodukte für Asien, den arabischen Raum und Europa aus derselben Codebasis lokalisieren.
Englisch ist die Sprache, die wir am häufigsten übersetzen. Für viele deutsche Hersteller ist die englische Fassung deshalb der erste Schritt der Softwarelokalisierung, etwa mit unserem Übersetzungsbüro Deutsch-Englisch. Wer danach weitere Märkte in Europa erschließt, findet bei unserem Übersetzungsbüro Französisch und unserem Übersetzungsbüro Spanisch dieselbe Arbeitsweise.
Für die Niederlande hilft unser Übersetzungsbüro Deutsch-Niederländisch, für Italien unser Übersetzungsbüro Italienisch. Alle diese europäischen Sprachen laufen wie Deutsch von links nach rechts. Gespiegelt wird die Oberfläche dort nicht, es geht vor allem um Textlänge und Formate.
Chinesisch, Japanisch und Koreanisch: Zeichen und Textlänge
Chinesisch, Japanisch und Koreanisch nutzen eigene Zeichensätze. Chinesische und japanische Texte sind in Zeichen gezählt oft kürzer als englische. Bei der Lokalisierung brauchen sie aber eine Schriftart, die alle Zeichen darstellt, und meist eine größere Schrift, damit sie gut lesbar bleiben. Für diese Märkte arbeiten unser Übersetzungsbüro Chinesisch, unser Übersetzungsbüro Japanisch und unser Übersetzungsbüro Koreanisch direkt mit Ihren Sprachdateien.
Arabisch: Schreibrichtung von rechts nach links
Arabisch und Hebräisch laufen von rechts nach links. Dann wird die ganze Oberfläche gespiegelt: Menüs stehen rechts, und Pfeile für Vor und Zurück zeigen in die andere Richtung. Schwierig sind gemischte Texte mit Zahlen, Markennamen in lateinischer Schrift oder Platzhaltern.
Ihre Anordnung regelt der Unicode Bidirectional Algorithm (UAX #9), den die Software unterstützen muss. Weil die Schreibrichtung eine Anpassung des Layouts verlangt, brauchen wir die Texte als bearbeitbare Sprachdateien und nicht als Bild.
Dokumentation und Shop-Texte zum Launch
Zur Lokalisierung für den Launch gehören mehr Texte als die Oberfläche. Verkaufen Sie Ihr Softwareprodukt über einen eigenen Shop, können Sie den Onlineshop übersetzen lassen, mit Produktdaten und Beschreibungen. Damit die Produktseiten dort auch gefunden werden, berücksichtigt eine SEO-Übersetzung die Suchbegriffe der Nutzer. Handbücher entstehen als technische Übersetzungen.
Steuert Ihre Software eine Maschine, gilt ab Januar 2027 die Maschinenverordnung (EU) 2023/1230. Sie verlangt Betriebsanleitung und Sicherheitsinformationen in der Sprache, die der jeweilige Mitgliedstaat festlegt, auch in digitaler Form in der Software der Maschine.
Für Medizin-Software gilt die Medizinprodukteverordnung (EU) 2017/745, ebenfalls mit Informationen in der Amtssprache, die der Mitgliedstaat festlegt. Dafür gibt es unsere Übersetzungen für die Medizintechnik. Verlangt eine Behörde etwa einen Lizenzvertrag in beglaubigter Form, erhalten Sie bei uns eine beglaubigte Übersetzung, die in Deutschland anerkannt wird.
Bei Lokalisierungsprojekten für mehrere Märkte gehören Übersetzung und Lokalisierung von Oberfläche, Handbuch und Shop-Texten in einen gemeinsamen Zeitplan.
