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

Dieser Leitfaden führt Sie von Anfang bis Ende durch den Prozess der Software-Lokalisierung, mit Best Practices und echten Code-Beispielen.

Ihre App ist gerade in Frankreich auf den Markt gekommen. Die Anmeldungen laufen, und dann wird Ihr Posteingang mit Support-Tickets überflutet. Benutzer können nicht auf den Button „Buy now“ (Jetzt kaufen) klicken, weil er abgeschnitten ist. Navigationsmenüs brechen über zwei Zeilen um. Ihr sorgfältig entworfenes UI ist völlig zerschossen.

Das passiert, wenn Sie direkt zur Übersetzung übergehen, ohne Ihre Software richtig zu lokalisieren. Der Text wird übersetzt, aber die App wurde nicht dafür entwickelt, ihn zu verarbeiten.

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

• Was Software-Lokalisierung ist
• Den Unterschied zwischen Lokalisierung, Übersetzung und Internationalisierung
• Wie Sie sich auf den Prozess der Software-Lokalisierung vorbereiten
• Best Practices für dynamische Inhalte, Textexpansion, locale-spezifische Formatierung und Tests
• Die Kosten der Software-Lokalisierung
• Wie Sie einen Lokalisierungs-Workflow einrichten, der nicht bei jedem Release fehlschlägt

Was ist Software-Lokalisierung?

Software-Lokalisierung ist der Prozess der Anpassung Ihrer Software an einen bestimmten Markt. 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 Referenzen.

Das Ziel ist es, dass sich Ihre Software so anfühlt, als wäre sie von Anfang an für diesen Markt entwickelt worden.

Hier ist ein Beispiel, das zeigt, wie dasselbe Datum zwei verschiedene Dinge bedeuten kann, je nachdem, wo sich Ihr Benutzer befindet:

Das ist ein kleines Beispiel dafür, was Software-Lokalisierung leistet. Multiplizieren Sie das mit Daten, Währungen, Formaten und kulturellen Referenzen, 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 Prozess der Software-Lokalisierung

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

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

1. Wasserfall Die Lokalisierung beginnt nach Abschluss der Entwicklung. Sie schließen den Build ab und übergeben dann alles in einem Durchgang zur Übersetzung. Es ist einfach zu verwalten, verzögert jedoch Ihr Release in anderen Sprachen und macht die Behebung von Fehlern in dieser Phase teuer.
2. Agile Lokalisierung Die Lokalisierung läuft parallel zur Entwicklung. Anstatt eines großen Batches 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. Wenn sich also ein String ändert, wird er automatisch zur Übersetzung gesendet. Wenn die Übersetzung fertig ist, wird sie automatisch wieder zusammengeführt.

Best Practices für die Software-Lokalisierung

Jedes Projekt ist anders, und Ihre Lokalisierungsanforderungen hängen von Ihrem Stack, Ihren Zielmärkten und Ihrem Team ab. Diese Liste deckt den Kern dessen ab, was Software-Lokalisierung erfolgreich macht.

Speichern Sie Ihren gesamten übersetzbaren Text in separaten Dateien

Wenn Sie Text direkt in Ihren Quellcode hardcodieren, können Übersetzungstools ihn nicht finden. Diese Tools scannen Ressourcendateien wie JSON, PO oder YAML nach zu übersetzenden Strings. Wenn Ihr Text in Ihren JavaScript-, PHP- oder Ruby-Dateien vergraben ist, liefert der Scan kein Ergebnis.

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 benutzerseitigen Texte von Anfang an in spezielle Ressourcendateien auszulagern. Dies umfasst alles, was Ihre Benutzer sehen können:

• UI-Labels, Buttons und Menüpunkte
• Fehlermeldungen und Validierungstexte
• E-Mail-Vorlagen und Benachrichtigungen
• Hilfetexte, Tooltips und Platzhaltertexte
• 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:

Vorher

<button>Submit</button>

Nachher, mit react-i18next

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

WordPress:

Vorher

echo 'Submit';

Nachher, WordPress i18n

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

Ruby on Rails:

Vorher

flash[:notice] = "Profile updated successfully"

Nachher, mit Rails I18n:

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

Es ist auch wichtig, Ihren Strings klare, aussagekräftige Keys zu geben. Ein Key namens checkout.submit_button sagt einem Übersetzer genau, wo dieser String erscheint und was er bewirkt. Andererseits sagt string_147 ihm nichts, was zu Fehlübersetzungen führt. Aussagekräftige Keys machen es auch für Ihr eigenes Team einfacher zu verfolgen, welche Strings externalisiert wurden, und Fehlendes zu erkennen.

Verwenden Sie Platzhalter für Namen, Zahlen und Daten

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

Hier ist der Grund:

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

Dieses Beispiel teilt den Satz in drei Fragmente auf. Im Englischen funktioniert die Wortstellung. Aber in Sprachen wie Japanisch steht der Name an einer anderen Stelle im Satz. Ihre Übersetzer können Fragmente nicht umordnen, sodass der Satz am Ende grammatikalisch falsch ist.

Platzhalter lösen dieses Problem, indem sie den Satz als Ganzes erhalten. Ihre Übersetzer oder Ihr Übersetzungstool erhalten den vollständigen Satz zur Bearbeitung, einschließlich einer Markierung, die zeigt, wohin die Variable gehört. Sie können diese Markierung dort platzieren, wo es die Grammatik ihrer Sprache erfordert.

So sehen Platzhalter in verschiedenen Dateiformaten aus:

JSON:

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

YAML:

greeting: "Hello, %{name}!"

PO:

msgid "Hello, %s!"

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

Bauen Sie Ihr UI so auf, dass es längeren Text verarbeiten kann

Die meisten Sprachen sind länger als Englisch. Ein Button, der perfekt in Ihr englisches UI passt, wird im Deutschen, Französischen oder Spanischen oft abgeschnitten. Wenn Sie Ihr Layout auf festen Breiten aufgebaut haben, erhalten Sie in jeder hinzugefügten Sprache ein zerschossenes UI.

Dies sind die typischen Expansionsraten, mit denen Sie arbeiten:

Einzelne Wörter können weit mehr expandieren als diese Durchschnittswerte. „FAQ“ wird im Spanischen zu „Preguntas frecuentes“ – das ist ein Zuwachs von 567 %.

Die Lösung besteht darin, flexible Layouts zu erstellen anstelle von festen. Anstatt einem Button eine feste Breite zuzuweisen, lassen Sie ihn mit seinem Inhalt wachsen:

Vorher – feste Breite führt bei längeren Sprachen zu Layoutfehlern

button { width: 120px; }

Nachher – wächst mit dem übersetzten Text

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

Denken Sie bereits in der Designphase daran. Wenn Sie zuerst für Englisch designen und später übersetzen, werden Sie mehr Zeit mit dem Debuggen von Layoutfehlern in jeder Sprache verbringen, als Sie gebraucht hätten, um von Anfang an Flexibilität einzubauen.

Schreiben Sie Text, der leicht zu übersetzen ist

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

Die häufigsten Probleme, die Sie vermeiden sollten:

Unvollständige Sätze

Ein String wie „No items“ (Keine Artikel/Elemente) könnte mehrere Dinge bedeuten. Befinden sich keine Artikel im Warenkorb? Hat eine Suche keine Ergebnisse geliefert? Ihr Übersetzer muss raten, und falsch geraten bedeutet eine falsche Übersetzung.

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

Vorher – mehrdeutig

"No items"

Nachher – klare Bedeutung

"You have no items in your cart."

Redewendungen

„This is a piece of cake“ (Das ist ein Kinderspiel) ergibt für englische Muttersprachler Sinn. Wörtlich ins Deutsche übersetzt, werden sich Ihre Benutzer fragen, warum Ihre App über Dessert spricht. Die meisten Ausdrücke 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 „remove“ (entfernen) statt „eliminate“ (eliminieren) und „use“ (verwenden) statt „utilize“ (nutzbar machen). Im Zweifelsfall wählen Sie das kürzere, gebräuchlichere Wort.

Behandeln Sie Daten, Zahlen und Währungen korrekt

Datums- und Zahlenformate variieren erheblich zwischen Locales. Das Hardcodieren dieser Formate verursacht dasselbe Problem wie das Hardcodieren von Text: Es funktioniert in einem Markt und schlägt in anderen fehl.

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

JavaScript:

Vorher

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

Nachher

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

Ruby on Rails:

Vorher

"$#{price}"

Nachher

number_to_currency(price, locale: I18n.locale)

Auf diese Weise verarbeitet derselbe Code die Formatierung für jedes Locale, das Sie unterstützen, korrekt.

Planen Sie für das Locale, nicht nur für die Sprache

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 Referenzen und der Ton können 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 Ressourcendateien einrichten, verwenden Sie vollständige Locale-Codes anstelle von reinen Sprachcodes. Dies gibt Ihnen die Flexibilität, verschiedenen Regionen unterschiedliche Inhalte bereitzustellen, ohne Ihr Setup später umstrukturieren zu müssen.

Geben Sie Übersetzern den nötigen Kontext

Wenn Sie sich entscheiden, mit menschlichen Übersetzern zu arbeiten, denken Sie daran, dass diese direkt mit Ihren Ressourcendateien arbeiten. Ohne zusätzliche Informationen sehen sie nur den String selbst. Sie haben keine Möglichkeit zu wissen, wo er im UI erscheint, worauf er sich bezieht oder wie viel Platz für die Übersetzung zur Verfügung steht.

Ein String wie „Cancel“ (Abbrechen/Stornieren) könnte sich auf das Stornieren einer Bestellung, eines Abonnements oder das Abbrechen einer Formularübermittlung beziehen. Jedes davon könnte je nach Sprache unterschiedlich übersetzt werden.

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

JSON mit Kontext-Kommentaren

{
  // 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, können Sie auf den meisten Plattformen Screenshots anhängen, die zeigen, wo diese Strings erscheinen. Dadurch können Übersetzungstools deutlich genauere Übersetzungen erstellen als bei der reinen Arbeit mit Text.

Richten Sie die Spracherkennung ein

Sobald sich Ihre Strings in Ressourcendateien befinden und Ihr UI 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']
    }
  });

Ruby on Rails:

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 fehlerhaften Keys wie auth.login_error an.

Bei Web-Apps können Sie Benutzern auch ermöglichen, die erkannte Sprache manuell zu überschreiben. Speichern Sie ihre Auswahl, damit sie sitzungsübergreifend erhalten 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;

Mobile Apps benötigen im Allgemeinen keinen Sprachumschalter. Benutzer erwarten, dass mobile Apps den Geräteeinstellungen folgen.

Wählen Sie ein Lokalisierungstool

Ein manueller Lokalisierungs-Workflow sieht in etwa so aus: Exportieren Sie Strings in eine Tabelle, senden Sie sie an einen Übersetzer, warten Sie mehrere Tage, erhalten Sie sie zurück, kopieren Sie die Übersetzungen in Ihre Dateien, stellen Sie fest, dass Sie 12 Strings übersehen haben, und fangen Sie von vorne an. Das ist nicht skalierbar.

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, Erkennung der Längenbegrenzung und Terminologiemanagement umfassen

Die PTC bietet all das. Außerdem deckt die Testphase Ihre ersten 20.000 Wörter in 2 Sprachen ab, und der Einstieg dauert weniger als 5 Minuten.

Erfahren Sie, wie die PTC Software-Lokalisierung handhabt

Testen Sie jede lokalisierte Version vor dem Launch

Die Übersetzung ist nicht der letzte Schritt. Bevor Sie eine lokalisierte Version veröffentlichen, testen Sie sie auf dieselbe Weise, wie Sie jedes andere Release testen würden.

Layout: Passt der Text, ohne abgeschnitten zu werden? Funktioniert die Navigation noch, oder sehen Sie einen Überlauf?

Funktionalität: Werden Formulare korrekt übermittelt? Erscheinen Fehlermeldungen in der richtigen Sprache? Verarbeitet die Suche Zeichen mit Akzenten oder Umlauten wie é, ñ und ü?

Formatierung: Haben Daten das richtige Format für das Locale? Sind Zahlen und Währungen korrekt formatiert? Steht das Währungssymbol an der richtigen Stelle?

Rechts-nach-links-Sprachen: Wenn Sie Arabisch oder Hebräisch unterstützen, testen Sie das gesamte RTL-Layout separat. Die RTL-Unterstützung wirkt sich auf mehr als nur die Textrichtung aus. Sie betrifft Ihr gesamtes UI-Layout.

Integrieren Sie Lokalisierungstests von Anfang an in Ihren QA-Prozess. Einen fehlerhaften Checkout-Prozess auf Deutsch durch Benutzerbewertungen zu entdecken, ist deutlich teurer, als ihn vor dem Launch abzufangen.

Wie viel kostet Software-Lokalisierung?

Gute Software-Lokalisierung muss nicht teuer sein. Der größte Faktor in Ihrem Budget ist nicht, wie viele Sprachen Sie unterstützen. Es ist die Art und Weise, wie Sie übersetzen.

Professionelle menschliche Übersetzung für Software kostet typischerweise 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, bevor Sie Tests, Projektmanagement oder zukünftige Updates bei jeder Produktänderung einkalkulieren.

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

Nach der Testphase arbeitet die PTC mit einem Pay-As-You-Go-Modell. Ihre ersten 500 Wörter jeden Monat sind kostenlos. Je mehr Sie übersetzen, desto niedriger ist Ihr Preis pro Wort, und sobald Sie einen niedrigeren Preis erreichen, behalten Sie diesen für drei Monate, selbst wenn Ihr Volumen sinkt.

Um einen genauen Betrag für Ihr Projekt zu erhalten, verwenden Sie den Kostenrechner der PTC oder laden Sie Ihre Ressourcendatei direkt hoch, um die Kosten zu sehen, bevor Sie sich verpflichten.

Berechnen Sie Ihre Übersetzungskosten

Richten Sie Ihren Software-Lokalisierungsprozess in 3 Schritten ein

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

So richten Sie mit der PTC einen funktionierenden Lokalisierungsprozess ein.

Melden Sie sich bei der PTC an

Erstellen Sie ein Projekt in der PTC, laden Sie Ihre Ressourcendateien hoch und wählen Sie Ihre Zielsprachen aus. Während der Testphase können Sie 2 Sprachen auswählen.

Die PTC generiert basierend auf der hochgeladenen Datei automatisch eine Produktbeschreibung Ihrer App. Überprüfen Sie die Beschreibung und behalten Sie sie bei oder bearbeiten Sie sie. Sie können auch bereits vorhandene Übersetzungen hochladen und ein Glossar mit Begriffen hinzufügen, die immer auf eine bestimmte Weise übersetzt werden sollen, wie Produktnamen oder technische Terminologie.

Die gesamte Einrichtung dauert weniger als 5 Minuten.

Übersetzungen anzeigen und verfeinern

Sobald die Übersetzungen fertig sind, können Sie mit der PTC eine KI-Übersetzungsprüfung durchführen, anstatt einzelne Strings manuell zu bearbeiten oder Teammitglieder hinzuzufügen, um Prüfungen für bestimmte Sprachen durchzuführen.

Die AI Visual QA führt den Standardprozess der Prüfung auf String-Ebene weiter, indem sie Ihr tatsächliches UI in jeder Zielsprache untersucht.

Womit Sie aufhören:

• Ihr Produkt manuell in jeder Zielsprache zu öffnen, um es auf Darstellungsprobleme zu prüfen
• QA-Prüfer zu koordinieren, die die Zielsprachen sprechen
• Zerschossene Layouts oder fehlende Strings nach einem Release zu entdecken

Was Sie stattdessen erhalten:

• Die PTC prüft Ihr übersetztes UI visuell und findet Fehler, die bei der String-Inspektion nicht auffallen
• Fehler, die in von der PTC generierten Übersetzungen gefunden werden, werden automatisch behoben
• Jede Sprache wird vor dem Release geprüft, in Minuten statt in Stunden

Um zu beginnen, gehen Sie in Ihrem Dashboard zum Tab AI Visual QA. Je nach Art der Software, die Sie übersetzen, können Sie entweder Screenshots Ihres UI hochladen oder die PTC Visual QA Browser-Erweiterung verwenden, um die Bildschirme für die Prüfung aufzuzeichnen.

Die PTC sucht nach Fehlern, die erst auftreten, wenn Ihre App ausgeführt wird. Sie behebt automatisch Fehler auf Übersetzungsebene, wie ungeschickte Formulierungen, einen falschen Ton oder Text, der nicht in den Kontext passt. Fehler auf Codeebene, wie fehlende Keys, hardcodierte Strings und Formatierungsfehler, werden für Ihr Team gekennzeichnet, damit es sie im Quellcode beheben kann.

Verbinden Sie Ihren Entwicklungs-Workflow

Wenn Sie sich mit der Funktionsweise der PTC vertraut gemacht haben, führen Sie ein Upgrade auf Pay-As-You-Go durch, um auf Pro-Funktionen zuzugreifen, wie die Verbindung der PTC mit Ihrem GitHub-, GitLab- oder Bitbucket-Repository. Mit dieser Integration erkennt die PTC neue und geänderte Strings automatisch und hält Ihre Übersetzungen ohne manuelle Datei-Uploads auf dem neuesten Stand.

Wenn Sie noch weiter gehen möchten, ermöglicht Ihnen die PTC-API, die Übersetzung direkt in Ihre CI/CD-Pipeline zu integrieren, sodass lokalisierte Versionen immer bereit sind, zusammen mit Ihrer Ausgangssprache veröffentlicht zu werden.

Nutzen Sie die PTC 30 Tage lang

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

Das WPML ist eines der am häufigsten verwendeten mehrsprachigen Plugins für WordPress. Es in 23 Sprachen übersetzt zu halten, ist nicht optional. Es ist Teil jedes Releases.

Jahrelang machte das Team es auf die traditionelle Weise: professionelle menschliche Übersetzer einstellen, Glossardateien verwalten und Updates über alle Sprachen hinweg für jedes Release koordinieren. Jedes Mal mussten sie das Produkt, die Terminologie und die Erwartungen von Grund auf neu erklären. Die Kosten lagen zwischen 1.000 $ und 8.000 $ pro Release.

Sie probierten Alternativen aus: Crowdsourcing, automatisierte Workflows und hybride Modelle. Nichts löste das Problem.

Seit dem Wechsel zur PTC werden Releases pünktlich veröffentlicht. Die Übersetzungen sind vollständig, präzise und über alle 23 Sprachen hinweg konsistent, ohne String Freeze, ohne Koordinationsaufwand und ohne Verzögerungen.

Vor der PTC

Nach der PTC

Beginnen Sie noch heute mit der Lokalisierung Ihrer Software

Die Testphase der PTC deckt Ihre ersten 20.000 Wörter in 2 Sprachen ab. Der Einstieg dauert weniger als 5 Minuten.

Starten Sie Ihre Testphase