Best Practices für die Software-Lokalisierung: 10 Schritte mit Beispielen

Dieser Leitfaden führt Sie Schritt für Schritt durch den Software-Lokalisierungsprozess und bietet Best Practices sowie echte Codebeispiele.

Ihre App wurde gerade in Frankreich veröffentlicht. Die Anmeldungen rollen ein, und dann wird Ihr Posteingang von Support-Tickets überflutet. Benutzer können nicht auf die Schaltfläche „Jetzt kaufen“ klicken, da sie abgeschnitten wurde. Navigationsmenüs brechen in zwei Zeilen um. Ihre sorgfältig gestaltete Benutzeroberfläche sieht völlig fehlerhaft aus.

Das passiert, wenn Sie direkt zur Übersetzung übergehen, ohne Ihre Software ordnungsgemäß zu lokalisieren. Der Text wird übersetzt, aber die App wurde nicht dafür entwickelt, damit umzugehen.

Dieser Leitfaden behandelt alles, was Sie wissen müssen, um Software-Lokalisierung richtig zu machen. Sie lernen:

Was ist Software-Lokalisierung?

Software-Lokalisierung ist der Prozess, Ihre Software für einen bestimmten Markt anzupassen. Dies geht über die Übersetzung von Text hinaus. Es bedeutet, alles anzupassen, was beeinflusst, wie Benutzer im Zielmarkt Ihre Software erleben: Datums- und Zahlenformate, Währung, UI-Layout, Bilder und kulturelle Bezüge.

Das Ziel ist es, Ihre Software so wirken zu lassen, als wäre sie von Anfang an für diesen Markt entwickelt worden.

Hier ist ein Beispiel, das zeigt, wie dasselbe Datum je nach Standort Ihres Benutzers zwei verschiedene Dinge bedeuten kann:

Das ist ein kleines Beispiel dafür, was Software-Lokalisierung bewältigt. Multiplizieren Sie es über Daten, Währungen, Formate und kulturelle Bezüge hinweg, und Sie beginnen, den Umfang der Arbeit zu erkennen.

Software-Lokalisierung vs. Übersetzung vs. Internationalisierung

Viele Menschen verwenden diese drei Begriffe synonym, aber sie bedeuten unterschiedliche Dinge und finden in verschiedenen Entwicklungsphasen statt.

Der Software-Lokalisierungsprozess

Software-Lokalisierung ist kein einzelner Schritt, den Sie vor dem Launch abschließen. Es ist ein fortlaufender Prozess, der parallel zur Entwicklung läuft. Hier ist ein Überblick darüber, wie er sich typischerweise aufgliedert:

Die meisten Teams führen den Prozess auf eine von drei Arten durch:

1. Wasserfall
   Die Lokalisierung beginnt nach Abschluss der Entwicklung. Sie beenden die Entwicklung und übergeben dann alles zur Übersetzung in einem Durchgang. Es ist einfach zu verwalten, verzögert aber Ihre Veröffentlichung in anderen Sprachen und macht Fehler in dieser Phase teuer zu beheben.
2. Agile Lokalisierung
   Die Lokalisierung läuft parallel zur Entwicklung. Anstatt eines großen Durchgangs am Ende senden Sie Strings während des gesamten Entwicklungszyklus zur Übersetzung. Das Timing ist besser, aber der Prozess ist immer noch manuell. Jemand in Ihrem Team muss Strings exportieren, Übergaben verwalten und Übersetzungen wieder importieren.
3. Kontinuierliche Lokalisierung
   Die Lokalisierung ist vollständig automatisiert. Ihr Repository ist direkt mit Ihrem Übersetzungstool verbunden, sodass ein String automatisch zur Übersetzung gesendet wird, wenn er sich ändert. Wenn die Übersetzung fertig ist, wird sie automatisch wieder eingefügt.

Best Practices für Software-Lokalisierung

Jedes Projekt ist anders, und Ihre Lokalisierungsanforderungen hängen von Ihrem Stack, Ihren Zielmärkten und Ihrem Team ab. Diese Liste deckt die Grundlagen dessen ab, was Software-Lokalisierung funktionieren lässt.

Wenn Sie Text direkt in Ihren Quellcode fest codieren, können Übersetzungstools ihn nicht finden. Diese Tools funktionieren, indem sie Ressourcendateien wie JSON, PO oder YAML nach zu übersetzenden Strings durchsuchen. Wenn Ihr Text in Ihren JavaScript-, PHP- oder Ruby-Dateien vergraben ist, kommt der Scan leer zurück.

Dies ist der häufigste Grund, warum Lokalisierungsprojekte scheitern. Teams entdecken das Problem erst, wenn sie versuchen zu übersetzen, und feststellen, dass sie zuerst Tausende von Strings refaktorieren müssen.

Deshalb ist es am besten, alle benutzersichtbaren Texte von Anfang an in dedizierte Ressourcendateien zu verschieben. Dies umfasst alles, was Ihre Benutzer sehen können:

• UI-Beschriftungen, Schaltflächen und Menüpunkte
• Fehlermeldungen und Validierungstext
• E-Mail-Vorlagen und Benachrichtigungen
• Hilfetext, Tooltips und Placeholder-Text
• Erfolgs- und Bestätigungsmeldungen

Welches Dateiformat Sie verwenden, hängt von Ihrem Framework ab:

Hier ist ein Vorher-Nachher-Vergleich für jedes wichtige Framework.

React:

<button>Submit</button>

<button>Submit</button>

<button>{t('submit_button')}</button>

<button>{t('submit_button')}</button>

WordPress:

echo 'Submit';

echo 'Submit';

echo __( 'Submit', 'your-textdomain' );

echo __( 'Submit', 'your-textdomain' );

Ruby on Rails:

flash[:notice] = "Profile updated successfully"

flash[:notice] = "Profile updated successfully"

flash[:notice] = t('profile.update_success')

flash[:notice] = t('profile.update_success')

Es ist auch wichtig, Ihren Strings klare, beschreibende Schlüssel zu geben. Ein Schlüssel namens checkout.submit_button sagt einem Übersetzer genau, wo dieser String erscheint und was er tut. Andererseits sagt string_147 ihnen nichts, was zu Fehlübersetzungen führt. Beschreibende Schlüssel erleichtern es auch Ihrem eigenen Team, nachzuverfolgen, welche Strings externalisiert wurden, und alles zu erkennen, was fehlt.

Wenn Ihr Text variable Daten wie den Namen eines Benutzers oder eine Bestellnummer enthält, ist es verlockend, den Satz zu erstellen, indem Sie Textstücke in Ihrem Code zusammenfügen. Dies funktioniert in anderen Sprachen nicht.

Hier ist der Grund:

const message = 'Hello, ' + name + '!';

const message = 'Hello, ' + name + '!';

Dieses Beispiel teilt den Satz in drei Fragmente auf. Im Englischen funktioniert die Wortstellung. Aber in Sprachen wie Japanisch kommt der Name an einer anderen Position im Satz vor. Ihre Übersetzer können Fragmente nicht neu anordnen, sodass der Satz grammatikalisch falsch wird.

Placeholder lösen dies, indem sie den Satz vollständig halten. Ihre Übersetzer oder Ihr Übersetzungstool erhalten den vollständigen Satz zur Bearbeitung, einschließlich einer Markierung, die zeigt, wo die Variable hingehört. Sie können diese Markierung dort platzieren, wo die Grammatik ihrer Sprache es erfordert.

So sehen Placeholder in verschiedenen Dateiformaten aus:

JSON:

{ "greeting": "Hello, {name}!" }

{ "greeting": "Hello, {name}!" }

YAML:

greeting: "Hello, %{name}!"

greeting: "Hello, %{name}!"

PO:

msgid "Hello, %s!"

msgid "Hello, %s!"

Die Syntax variiert je nach Format, aber das Prinzip ist dasselbe.

Die meisten Sprachen sind länger als Englisch. Eine Schaltfläche, die perfekt in Ihre englische Benutzeroberfläche passt, wird oft auf Deutsch, Französisch oder Spanisch abgeschnitten. Wenn Sie Ihr Layout auf feste Breiten aufgebaut haben, haben Sie in jeder Sprache, die Sie hinzufügen, eine defekte Benutzeroberfläche.

Dies sind die typischen Expansionsraten, mit denen Sie arbeiten:

Einzelne Wörter können sich weit über diese Durchschnittswerte hinaus ausdehnen. „FAQ“ wird im Spanischen zu „Preguntas frecuentes“ – das ist eine Steigerung von 567 %.

Die Lösung besteht darin, flexible Layouts anstelle von festen zu entwickeln. Anstatt eine feste Breite für eine Schaltfläche festzulegen, lassen Sie sie mit ihrem Inhalt wachsen:

button { width: 120px; }

button { width: 120px; }

button { 
  min-width: 120px;
  width: auto;
  padding: 8px 16px;
}

button { 
  min-width: 120px;
  width: auto;
  padding: 8px 16px;
}

Denken Sie in der Designphase darüber nach. Wenn Sie zuerst für Englisch entwerfen und später übersetzen, verbringen Sie mehr Zeit mit dem Debuggen von Layoutproblemen in jeder Sprache, als Sie damit verbracht hätten, von Anfang an Flexibilität einzubauen.

Die Art und Weise, wie Sie Ihren Quelltext schreiben, beeinflusst die Übersetzungsqualität. Vage Formulierungen, Redewendungen und clevere Wortspiele führen oft zu verwirrenden oder falschen Übersetzungen.

Die häufigsten zu vermeidenden Probleme:

Unvollständige Sätze

Ein String wie „No items“ könnte mehrere Bedeutungen haben. Befinden sich keine Artikel im Warenkorb? Hat eine Suche keine Ergebnisse geliefert? Ihr Übersetzer muss raten, und eine falsche Vermutung bedeutet eine falsche Übersetzung.

Schreiben Sie vollständige Sätze mit einem klaren Subjekt und Verb.

"No items"

"No items"

"You have no items in your cart."

"You have no items in your cart."

Redewendungen

„This is a piece of cake“ ergibt für einen englischen Muttersprachler Sinn. Wörtlich ins Deutsche übersetzt, werden sich Ihre Nutzer fragen, warum Ihre App über Nachtisch spricht. Die meisten Redewendungen funktionieren nur in der jeweiligen Sprache, daher ist es am besten, sie ganz zu vermeiden.

Komplexes Vokabular

Einfache Wörter lassen sich zuverlässiger übersetzen. Schreiben Sie „entfernen“ statt „eliminieren“ und „verwenden“ statt „utilisieren“. Wählen Sie im Zweifelsfall das kürzere, gebräuchlichere Wort.

Datums- und Zahlenformate variieren erheblich zwischen Locales. Das Fest-Codieren dieser Formate verursacht dasselbe Problem wie das Fest-Codieren von Text: Es funktioniert in einem Markt und bricht in anderen zusammen.

Verwenden Sie die integrierten Lokalisierungsfunktionen Ihres Frameworks, um diese automatisch basierend auf dem Locale des Benutzers zu formatieren.

JavaScript:

const price = '$' + amount.toFixed(2);

const price = '$' + amount.toFixed(2);

const price = new Intl.NumberFormat(userLocale, {
  style: 'currency',
  currency: currencyCode
}).format(amount);

const price = new Intl.NumberFormat(userLocale, {
  style: 'currency',
  currency: currencyCode
}).format(amount);

Ruby on Rails:

"$#{price}"

"$#{price}"

number_to_currency(price, locale: I18n.locale)

number_to_currency(price, locale: I18n.locale)

Auf diese Weise behandelt derselbe Code die Formatierung für jedes von Ihnen unterstützte Locale korrekt.

Sprache und Locale sind nicht dasselbe. Spanisch ist eine Sprache. Mexikanisches Spanisch (es-MX), Spanisch aus Spanien (es-ES) und argentinisches Spanisch (es-AR) sind Locales. Die Unterschiede zwischen ihnen gehen über das Vokabular hinaus. Datumsformate, Währung, kulturelle Bezüge und Tonfall können alle variieren.

Wenn Sie nur einen Sprachcode ohne Locale angeben, riskieren Sie, Benutzern in bestimmten Regionen die falschen Inhalte anzuzeigen.

Nehmen Sie Französisch als Beispiel:

Wenn Sie Ihre Sprachdateien einrichten, verwenden Sie vollständige Locale-Codes anstelle von Sprachcodes allein. Dies gibt Ihnen die Flexibilität, verschiedenen Regionen unterschiedliche Inhalte bereitzustellen, ohne Ihr Setup später umstrukturieren zu müssen.

Wenn Sie sich entscheiden, mit menschlichen Übersetzern zu arbeiten, bedenken Sie, dass diese direkt aus Ihren Ressourcendateien arbeiten. Ohne zusätzliche Informationen sehen sie nur den String selbst. Sie haben keine Möglichkeit zu wissen, wo er in der Benutzeroberfläche erscheint, worauf er sich bezieht oder wie viel Platz die Übersetzung haben muss.

Ein String wie „Abbrechen“ könnte sich auf das Abbrechen einer Bestellung, eines Abonnements oder einer Formularübermittlung beziehen. Jeder dieser Fälle könnte je nach Sprache unterschiedlich übersetzt werden.

Fügen Sie Ihren Ressourcendateien Kommentare hinzu, um zu erklären, was jeder String tut und wo er erscheint:

{
  // Button in the checkout flow. Cancels the current order. Keep short.
  "checkout.cancel_button": "Cancel",

  // Error message shown when login fails. Followed by a link to reset password.
  "auth.login_error": "Incorrect email or password."
}

{
  // Button in the checkout flow. Cancels the current order. Keep short.
  "checkout.cancel_button": "Cancel",

  // Error message shown when login fails. Followed by a link to reset password.
  "auth.login_error": "Incorrect email or password."
}

Wenn Sie ein Übersetzungstool verwenden, ermöglichen die meisten Plattformen das Anhängen von Screenshots, die zeigen, wo diese Strings erscheinen. Dies ermöglicht es Übersetzungstools, deutlich genauere Übersetzungen zu erstellen, als wenn sie nur mit Text arbeiten.

Sobald Ihre Strings in Ressourcendateien sind und Ihre Benutzeroberfläche flexibel ist, müssen Sie jedem Benutzer automatisch die richtige Sprache anzeigen. Die meisten Frameworks handhaben dies mit integrierten i18n-Bibliotheken.

React mit react-i18next:

i18n
  .use(LanguageDetector)
  .use(initReactI18next)
  .init({
    resources,
    fallbackLng: 'en',
    detection: {
      order: ['navigator', 'localStorage']
    }
  });

i18n
  .use(LanguageDetector)
  .use(initReactI18next)
  .init({
    resources,
    fallbackLng: 'en',
    detection: {
      order: ['navigator', 'localStorage']
    }
  });

Ruby on Rails:

before_action :set_locale

def set_locale
  I18n.locale = extract_locale_from_accept_language_header || I18n.default_locale
end

before_action :set_locale

def set_locale
  I18n.locale = extract_locale_from_accept_language_header || I18n.default_locale
end

Legen Sie immer eine Fallback-Sprache fest. Wenn eine Übersetzungsdatei fehlt oder ein String noch nicht übersetzt wurde, zeigt Ihre App den Fallback anstelle eines defekten Schlüssels wie auth.login_error an.

Für Web-Apps können Sie Benutzern auch erlauben, die erkannte Sprache manuell zu überschreiben. Speichern Sie ihre Wahl, damit sie über Sitzungen hinweg bestehen bleibt:

// Save the user's choice
localStorage.setItem('userLanguage', selectedLanguage);

// Check for a saved choice first, then fall back to the browser language
const userLanguage = localStorage.getItem('userLanguage') || navigator.language;

// Save the user's choice
localStorage.setItem('userLanguage', selectedLanguage);

// Check for a saved choice first, then fall back to the browser language
const userLanguage = localStorage.getItem('userLanguage') || navigator.language;

Mobile Apps benötigen in der Regel keinen Sprachumschalter. Benutzer erwarten, dass mobile Apps ihren Geräteeinstellungen folgen.

Ein manueller Lokalisierungs-Workflow sieht ungefähr so aus: Strings in eine Tabelle exportieren, an einen Übersetzer senden, mehrere Tage warten, sie zurückbekommen, Übersetzungen in Ihre Dateien kopieren, feststellen, dass Sie 12 Strings verpasst haben, und von vorne beginnen. Das skaliert nicht.

Ein Software-Lokalisierungstool verwaltet den gesamten Workflow für Sie. Ein gutes Tool wird:

• Sich mit Ihrem Repository verbinden, neue und geänderte Strings erkennen und Übersetzungen kontinuierlich auf dem neuesten Stand halten
• Ihrem Team einen zentralen Ort bieten, um alle Übersetzungen zu verwalten
• Integrierte CAT-Funktionen wie Translation Memory, Längenlimit-Erkennung und Terminologieverwaltung enthalten

PTC erledigt all dies. Außerdem können Sie die ersten 20.000 Wörter kostenlos in 2 Sprachen übersetzen, und der Einstieg dauert weniger als 5 Minuten.

Die Übersetzung ist nicht der letzte Schritt. Bevor Sie eine lokalisierte Version ausliefern, testen Sie diese genauso, wie Sie jedes andere Release testen würden.

Integrieren Sie Lokalisierungstests von Anfang an in Ihren QA-Prozess. Einen fehlerhaften Checkout-Prozess im Deutschen erst durch Nutzerbewertungen zu finden, ist deutlich teurer, als ihn vor dem Start zu entdecken.

Wie viel kostet Software-Lokalisierung?

Gute Software-Lokalisierung muss nicht teuer sein. Der größte Faktor für Ihr Budget ist nicht die Anzahl der unterstützten Sprachen. Es ist die Art und Weise, wie Sie übersetzen.

Professionelle menschliche Übersetzungen für Software liegen in der Regel zwischen 0,10 $ und 0,30 $ pro Wort. Für eine mittelgroße App mit 15.000 Wörtern sind das 1.500 $ bis 4.500 $ pro Sprache, noch bevor Sie Tests, Projektmanagement oder zukünftige Updates bei jeder Produktänderung einplanen.

KI-Übersetzung mit einem Tool wie PTC kostet nur einen Bruchteil davon:

Nach dem kostenlosen Testzeitraum arbeitet PTC nach dem Modell der Zahlung nach Bedarf. Ihre ersten 500 Wörter pro Monat sind kostenlos. Je mehr Sie übersetzen, desto niedriger wird Ihr Wortpreis, und sobald Sie einen niedrigeren Tarif erreichen, behalten Sie diesen für drei Monate bei, selbst wenn Ihr Volumen sinkt.

Um eine genaue Zahl für Ihr Projekt zu erhalten, nutzen Sie den Preisrechner von PTC oder laden Sie Ihre Ressourcendatei direkt hoch, um die Kosten zu sehen, bevor Sie sich festlegen.

Richten Sie Ihren Software-Lokalisierungsprozess in 3 Schritten ein

Die oben genannten Best Practices für die Software-Lokalisierung decken viel ab. Einiges davon, wie das Schreiben übersetzbarer Texte oder die Planung für Locales, erfordert bewusste Entscheidungen Ihres Teams. Aber ein großer Teil der technischen Arbeit, wie das Erkennen von String-Änderungen, das Verwalten von Übersetzungsdateien, das Markieren von Längenproblemen und das Synchronhalten von Übersetzungen, kann mit dem richtigen Tool automatisiert werden.

So richten Sie mit PTC einen funktionierenden Lokalisierungsprozess ein.

01

Für PTC anmelden

Erstellen Sie ein Projekt in PTC, laden Sie Ihre Ressourcendateien hoch und wählen Sie Ihre Übersetzungssprachen aus. Während des kostenlosen Testzeitraums können Sie 2 Sprachen wählen.

Fügen Sie dann Kontext zu Ihrer App hinzu: was sie tut und für wen sie gedacht ist. Dies macht die Übersetzungen von PTC präzise statt generisch. Sie können auch ein Glossar mit Begriffen hinzufügen, die immer auf eine bestimmte Weise übersetzt werden sollen, wie Produktnamen oder technische Terminologie.

PTC übersetzt diese automatisch und wendet Ihren Kontext und Ihr Glossar auf jeden String an. Die gesamte Einrichtung dauert weniger als 5 Minuten.

02

Übersetzungen anzeigen und verfeinern

Sobald die Übersetzungen fertig sind, können Sie diese in Ihrem Dashboard überprüfen. Sie können einzelne Strings manuell bearbeiten oder Teammitglieder hinzufügen, um die Überprüfungen für bestimmte Sprachen zu übernehmen.

Wenn Ihnen eine Übersetzung auffällt, die besser sein könnte, markieren Sie diese und teilen Sie PTC das Problem mit. PTC übersetzt sie kostenlos neu und wendet das Gelernte auf zukünftige Übersetzungen in Ihrem Projekt an.

PTC prüft zudem automatisch die Übersetzungslänge. Strings, die für Ihre Benutzeroberfläche zu lang sein könnten, werden gelb hervorgehoben. Sie können PTC bitten, sie passend neu zu übersetzen, oder die Längenbeschränkungen an die Gegebenheiten Ihrer UI anpassen.

Beispiel für Software-Lokalisierung: WPML mit PTC übersetzen

WPML ist eines der am weitesten verbreiteten Mehrsprachigkeits-Plugins für WordPress. Es in 23 Sprachen übersetzt zu halten, ist keine Option, sondern Teil jeder Veröffentlichung.

Jahrelang ging das Team den traditionellen Weg: Beauftragung professioneller menschlicher Übersetzer, Verwaltung von Glossardateien und Koordinierung von Updates in allen Sprachen für jedes Release. Jedes Mal mussten das Produkt, die Terminologie und die Erwartungen von Grund auf neu erklärt werden. Die Kosten lagen zwischen 1.000 $ und 8.000 $ pro Release.

Sie versuchten Alternativen: Crowdsourcing, automatisierte Workflows und Hybridmodelle. Nichts löste das Problem.

Seit dem Wechsel zu PTC gehen die Releases pünktlich raus. Die Übersetzungen sind vollständig, genau und konsistent in allen 23 Sprachen – ohne String-Freeze, ohne Koordinationsaufwand und ohne Verzögerungen.

Vor PTC

Nach PTC

Starten Sie noch heute mit der Lokalisierung Ihrer Software

PTC ist für Ihre ersten 20.000 Wörter in 2 Sprachen kostenlos. Der Einstieg dauert weniger als 5 Minuten.

Kostenlose Testversion starten