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 gestartet. Die Anmeldungen rollen ein, und dann wird Ihr Posteingang von Support-Tickets überflutet. Benutzer können nicht auf die Schaltfläche „Jetzt kaufen“ klicken, weil sie abgeschnitten wurde. Navigationsmenüs brechen über zwei Zeilen um. Ihre sorgfältig entworfene UI sieht völlig kaputt aus.

Das passiert, wenn Sie direkt zur Übersetzung springen, ohne Ihre Software richtig zu lokalisieren. Der Text wird übersetzt, aber die App wurde nicht darauf ausgelegt, damit umzugehen.

Dieser Leitfaden deckt alles ab, was Sie brauchen, um Software-Lokalisierung richtig zu machen. Sie werden lernen:

• Was Software-Lokalisierung ist
• Der Unterschied zwischen Lokalisierung, Übersetzung und Internationalisierung
• Wie Sie sich auf den Software-Lokalisierungsprozess vorbereiten
• Best Practices für dynamische Inhalte, Textexpansion, lokalespezifische Formatierung und Tests
• Die Kosten der Software-Lokalisierung
• Wie man einen Lokalisierungs-Workflow einrichtet, der nicht bei jedem Release abbricht

Was ist Software-Lokalisierung?

Software-Lokalisierung ist der Prozess der Anpassung Ihrer Software an einen bestimmten Markt. Dies geht über das Übersetzen 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 je nach Standort Ihres Benutzers zwei verschiedene Dinge bedeuten kann:

Das ist nur ein kleines Beispiel für die Aspekte, die bei der Software-Lokalisierung berücksichtigt werden. Multiplizieren Sie das mit Daten, Währungen, Formaten und kulturellen Referenzen, und Sie beginnen den Umfang der Arbeit zu sehen.

Software-Lokalisierung vs. Übersetzung vs. Internationalisierung

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

Der Software-Lokalisierungsprozess

Software-Lokalisierung ist kein einzelner Schritt, den Sie vor dem Start abschließen. Es ist ein fortlaufender Prozess, der parallel zur Entwicklung läuft. Hier ist eine Übersicht, wie er sich normalerweise gliedert:

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

1. Waterfall Die Lokalisierung beginnt nach Abschluss der Entwicklung. Sie beenden die Entwicklung und übergeben dann alles in einem Batch zur Übersetzung. Es ist einfach zu verwalten, verzögert aber Ihr Release in anderen Sprachen und macht die Fehlerbehebung in dieser Phase teuer.
2. Agile Lokalisierung Die Lokalisierung läuft parallel zur Entwicklung. Statt eines großen Batches am Ende senden Sie während des gesamten Entwicklungszyklus Strings 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 verbindet sich direkt mit Ihrem Übersetzungstool. Wenn sich also ein String ändert, wird er automatisch zur Übersetzung gesendet. Wenn die Übersetzung fertig ist, wird sie automatisch wieder zusammengeführt.

Software-Lokalisierung Best Practices

Jedes Projekt ist anders, und Ihre Lokalisierungsbedürfnisse 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 all Ihren übersetzbaren Text in separaten Dateien

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

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 refactoren müssen.

Deshalb ist es am besten, den gesamten benutzerorientierten Text von Anfang an in dedizierte Ressourcendateien zu verschieben. Dies umfasst alles, was Ihre Benutzer sehen können:

• UI-Labels, Schaltflächen und Menüpunkte
• Fehlermeldungen und Validierungstexte
• E-Mail-Vorlagen und Benachrichtigungen
• Hilfetexte, Tooltips und Platzhalter
• Erfolgs- und Bestätigungsmeldungen

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

Hier ist ein Vorher und Nachher für jedes größere Framework.

React:

Vorher

<button>Submit</button>

Nachher, unter Verwendung von 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, unter Verwendung von Rails I18n:

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

Es ist auch wichtig, Ihren Strings klare, beschreibende Keys zu geben. Ein Key namens checkout.submit_button sagt einem Übersetzer genau, wo dieser String erscheint und was er tut. Auf der anderen Seite sagt string_147 ihnen gar nichts, was zu Fehlübersetzungen führt. Beschreibende Keys machen es auch für Ihr eigenes Team einfacher zu verfolgen, welche Strings externalisiert wurden, und alles zu entdecken, was fehlt.

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 aufzubauen, 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 Wortreihenfolge. Aber in Sprachen wie Japanisch steht der Name an einer anderen Position im Satz. Ihre Übersetzer können Fragmente nicht umordnen, sodass der Satz am Ende grammatikalisch falsch ist.

Platzhalter lösen dies, indem sie den Satz ganz lassen. Ihre Übersetzer oder Ihr Übersetzungstool erhalten den vollständigen Satz zum Arbeiten, einschließlich einer Markierung, die zeigt, wohin die Variable gehört. Sie können diese Markierung dorthin setzen, wo die Grammatik ihrer Sprache es 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 Ihre UI so, dass sie längere Texte bewältigen kann

Die meisten Sprachen sind länger als Englisch. Eine Schaltfläche, die perfekt in Ihre englische UI passt, wird im Deutschen, Französischen oder Spanischen oft abgeschnitten. Wenn Sie Ihr Layout um feste Breiten herum aufgebaut haben, haben Sie in jeder Sprache, die Sie hinzufügen, eine kaputte UI.

Dies sind die typischen Expansionsraten, mit denen Sie arbeiten:

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

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

Vorher – feste Breite bricht in längeren Sprachen

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 entwerfen und später übersetzen, werden Sie mehr Zeit mit dem Debuggen von Layout-Problemen in jeder Sprache verbringen, als Sie für den Aufbau von Flexibilität von Anfang an benötigt hätten.

Schreiben Sie Texte, die einfach zu übersetzen sind

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 es zu vermeiden gilt:

Unvollständige Sätze

Ein String wie „No items“ könnte mehrere Dinge bedeuten. 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.

Vorher – mehrdeutig

"No items"

Nachher – klare Bedeutung

"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 Benutzer fragen, warum Ihre App über Nachtisch 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“ statt „eliminate“ und „use“ statt „utilize“. Wählen Sie im Zweifelsfall das kürzere, gebräuchlichere Wort.

Handhaben Sie Daten, Zahlen und Währungen korrekt

Datums- und Zahlenformate variieren erheblich zwischen den Regionen. Das Hartcodieren dieser Formate verursacht das gleiche Problem wie das Hartcodieren von Text: Es funktioniert in einem Markt und bricht in anderen.

Verwenden Sie die integrierten Lokalisierungs-Utilities Ihres Frameworks, um diese automatisch basierend auf dem Gebietsschema des Benutzers 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 handhabt derselbe Code die Formatierung korrekt für jedes von Ihnen unterstützte Gebietsschema.

Berücksichtigen Sie das Gebietsschema, nicht nur die Sprache

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

Wenn Sie nur einen Sprachcode ohne Gebietsschema angeben, riskieren Sie, Benutzern in bestimmten Regionen den falschen Inhalt anzuzeigen.

Nehmen wir Französisch als Beispiel:

Wenn Sie Ihre Ressourcendateien einrichten, verwenden Sie vollständige Locale-Codes anstatt nur 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 Kontext, den sie benötigen

Wenn Sie sich entscheiden, mit menschlichen Übersetzern zusammenzuarbeiten, 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 in der UI erscheint, worauf er sich bezieht oder wie viel Platz die Übersetzung hat.

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

Fügen Sie Kommentare zu Ihren Ressourcendateien hinzu, um zu erklären, was jeder String macht 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, ermöglichen es die meisten Plattformen, Screenshots anzuhängen, die zeigen, wo diese Strings erscheinen. Dies ermöglicht es Übersetzungstools, deutlich genauere Übersetzungen zu erstellen, als wenn sie nur mit Text arbeiten.

Spracherkennung einrichten

Sobald Ihre Strings in Ressourcendateien vorliegen und Ihre 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 stattdessen den Fallback anstelle eines unübersetzten Keys wie auth.login_error an.

Bei Web-Apps können Sie Benutzern auch erlauben, die erkannte Sprache manuell zu überschreiben. Speichern Sie deren Auswahl, damit sie über Sitzungen hinweg 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 Einstellungen ihres Geräts folgen.

Wählen Sie ein Lokalisierungstool

Ein manueller Lokalisierungs-Workflow sieht etwa so aus: Strings in eine Tabellenkalkulation exportieren, an einen Übersetzer senden, mehrere Tage warten, zurückerhalten, Übersetzungen in Ihre Dateien kopieren, feststellen, dass Sie 12 Strings vergessen haben, und von vorne beginnen. 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 zur Verwaltung aller Übersetzungen bieten
• Integrierte CAT-Funktionen wie Translation Memory, Längenbegrenzungserkennung und Terminologieverwaltung enthalten

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

Erfahren Sie, wie PTC Software-Lokalisierung handhabt

Testen Sie jede lokalisierte Version vor dem Start

Die Übersetzung ist nicht der letzte Schritt. Bevor Sie eine lokalisierte Version veröffentlichen, testen Sie sie genauso, 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 Akzentzeichen wie é, ñ und ü?

Formatierung: Sind Daten im richtigen Format für das Gebietsschema? Sind Zahlen und Währungen korrekt formatiert? Befindet sich das Währungssymbol an der richtigen Position?

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

Integrieren Sie Lokalisierungstests von Anfang an in Ihren QA-Prozess. Einen kaputten Checkout-Prozess im Deutschen durch Benutzerbewertungen zu finden, ist deutlich teurer, als ihn vor dem Start 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 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, bevor Sie Tests, Projektmanagement oder zukünftige Updates bei jeder Produktänderung einrechnen.

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

Nach der kostenlosen Testphase arbeitet PTC nach einem Pay-As-You-Go-Modell. Ihre ersten 500 Wörter pro Monat sind kostenlos. Je mehr Sie übersetzen, desto niedriger wird Ihr Wortpreis, und sobald Sie einen niedrigeren Preis erreicht haben, 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.

Berechnen Sie Ihre Übersetzungskosten

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 das Gebietsschema, 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 Synchronisieren von Übersetzungen, kann mit dem richtigen Tool automatisiert werden.

Hier erfahren Sie, wie Sie mit PTC einen funktionierenden Lokalisierungsprozess einrichten.

Melden Sie sich bei PTC an

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

PTC generiert automatisch eine Beschreibung Ihrer App basierend auf der hochgeladenen Datei. Überprüfen Sie die Beschreibung und behalten oder bearbeiten Sie diese. Sie können auch bestehende Ü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 eine KI-Übersetzungsprüfung mit PTC durchführen, anstatt einzelne Strings manuell zu bearbeiten oder Teammitglieder für die Überprüfung bestimmter Sprachen hinzuzufügen.

AI Visual QA geht über den standardmäßigen Prozess der String-Prüfung hinaus, indem es Ihre tatsächliche UI in jeder Zielsprache untersucht.

Was Sie nicht mehr tun müssen:

• Ihr Produkt manuell in jeder Zielsprache öffnen, um nach Anzeigeproblemen zu suchen
• QA-Prüfer koordinieren, die die Zielsprachen sprechen
• Kaputte Layouts oder fehlende Strings erst nach einem Release entdecken

Was Sie stattdessen erhalten:

• PTC prüft Ihre übersetzte UI visuell und findet Fehler, die eine String-Inspektion nicht erfassen kann
• Fehler in von PTC generierten Übersetzungen werden automatisch behoben
• Jede Sprache wird vor dem Release geprüft, in Minuten statt Stunden

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

PTC scannt nach Fehlern, die erst auftreten, wenn Ihre App läuft. Es behebt automatisch Probleme auf Übersetzungsebene, wie ungeschickte Formulierungen, falsche Tonalität oder Text, der nicht zum Kontext passt. Fehler auf Code-Ebene, wie fehlende Keys, hartcodierte Strings und Formatierungsfehler, werden markiert, damit Ihr Team sie in der Quelle beheben kann.

Verbinden Sie Ihren Entwicklungs-Workflow

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

Wenn Sie noch weiter gehen möchten, ermöglicht es die PTC API, die Übersetzung direkt in Ihre CI/CD-Pipeline zu integrieren, sodass lokalisierte Versionen immer zeitgleich mit Ihrer Ausgangssprache versandbereit sind.

Nutzen Sie PTC 30 Tage lang kostenlos

Beispiel für Software-Lokalisierung: Übersetzung von WPML mit PTC

WPML ist eines der am weitesten verbreiteten mehrsprachigen Plugins für WordPress. Es in 23 Sprachen übersetzt zu halten, ist nicht optional. Es ist Teil jedes Releases.

Jahrelang machte das Team dies 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 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 über alle 23 Sprachen hinweg, ohne String-Freeze, ohne Koordinationsaufwand und ohne Verzögerungen.

Vor PTC

Nach PTC

Beginnen 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.

Starten Sie Ihre kostenlose Testphase