WordPress-Internationalisierung: Themes und Plugins übersetzen

Bereiten Sie Ihr WordPress-Theme oder -Plugin für die Übersetzung vor. Dieser Leitfaden behandelt Text-Domains, gettext-Funktionen, die POT-Generierung und den Lademechanismus, der den Benutzern die Übersetzungen präsentiert. Die PTC (Private Translation Cloud) übersetzt anschließend die Ressourcendateien und prüft das dargestellte Theme oder Plugin in jeder Sprache visuell.

Dieser Leitfaden richtet sich an Entwickler, die den Code schreiben. Wenn Sie bereits eine POT- oder PO-Datei haben und diese nur übersetzen müssen, gehen Sie zur Seite für PO-Dateien für den 3-Schritte-Workflow.

Am Ende dieses Leitfadens ist Ihr Theme oder Plugin:

Korrekt gemäß den WordPress-Programmierstandards internationalisiert.
Durch die PTC in über 40 Sprachen übersetzbar.
Über WordPress.org-Sprachpakete verteilbar.
Bei jedem Release mit der visuellen Übersetzungsprüfung der PTC verifizierbar.

Was ist WordPress-Internationalisierung?

Internationalisierung (i18n) ist die Vorbereitung Ihres Codes, damit dieser übersetzt werden kann. Lokalisierung (l10n) ist der nächste Schritt. Dabei werden die eigentlichen übersetzten Strings für bestimmte Sprachen erstellt.

Für WordPress-Themes und -Plugins bedeutet i18n drei Dinge:

Umschließen Sie jeden benutzerseitigen String mit gettext-Funktionen, damit WordPress diese zur Laufzeit austauschen kann.
Definieren Sie eine text domain, die Ihre Übersetzungen an Ihr Projekt bindet.
Generieren Sie eine POT-Datei, mit der Übersetzer (oder die PTC) arbeiten.

Sobald diese Arbeit erledigt ist, haben Sie alles, was Sie brauchen, um übersetzte PO-, MO-, JSON- und .l10n.php-Dateien für jede beliebige Sprache zu erstellen.

Die PTC übersetzt POT-Dateien in MO, JSON und .l10n.php für WordPress

Fünf Dateiendungen tauchen in jedem WordPress-Übersetzungs-Workflow auf. Die PTC übersetzt von .pot (Ihrer Quelle) in .po, .mo, .json und .l10n.php für jede Zielsprache. Jedes Format hat eine bestimmte Aufgabe:

POT (Portable Object Template). Die aus Ihrem Code generierte Quelldatei. Sie listet jeden übersetzbaren String auf, ohne dass Übersetzungen angehängt sind. Diese übergeben Sie an die PTC.
PO (Portable Object). Eine Kopie der POT-Datei, der Übersetzungen für eine bestimmte Sprache hinzugefügt wurden. Reiner Text, menschenlesbar. Die PTC liefert ein PO pro Zielsprache zurück.
MO (Machine Object). Die kompilierte Binärversion eines PO. WordPress liest MO-Dateien zur Laufzeit, da sie schneller laden als PO-Text.
JSON. Das JavaScript-Äquivalent zum MO. WordPress kann MO nicht aus JavaScript lesen, daher erzeugt die Build-Pipeline JSON-Dateien für browserseitige Strings.
.l10n.php. Eine neuere Alternative zum MO, eingeführt in WordPress 6.5. Sie lädt schneller und verbraucht weniger Speicher. WordPress wählt sie automatisch aus, wenn sie neben der MO-Datei existiert.

Aktivieren Sie .l10n.php für neue Projekte. Es ist MO auf den unterstützten WordPress-Versionen strikt überlegen.

Warum Community-Übersetzungen nicht ausreichen

WordPress.org bietet Community-Übersetzungen über GlotPress an. In der Praxis decken diese nur einen kleinen Bruchteil dessen ab, was die meisten Plugins und Themes benötigen. Eine Analyse von mehr als 60.000 WordPress-Plugins und -Themes ergab, dass Community-Übersetzungen weniger als 5 % des Übersetzungsbedarfs in 40 Sprachen abdecken.

Zwei strukturelle Probleme erklären diese Lücke:

Freiwillige sind in den meisten Locales rar. Eine Handvoll Plugins mit riesiger Nutzerbasis ziehen Übersetzer an. Die meisten jedoch nicht.
Es kann Monate oder Jahre dauern, bis Übersetzungen erscheinen, wenn überhaupt. Wenn Sie möchten, dass Benutzer Ihr Plugin oder Theme vom ersten Tag an in ihrer Sprache sehen, können Sie sich nicht auf die Community verlassen.

Dieser Leitfaden geht davon aus, dass Sie eine konsistente, vollständige Abdeckung der Übersetzungen nach einem von Ihnen kontrollierten Release-Zeitplan wünschen. Genau das liefert die PTC.

Ihr WordPress-Theme oder -Plugin für die Übersetzung vorbereiten

Eine falsch zugewiesene text domain oder ein nicht gekapselter String führt dazu, dass dieser Text niemals in Ihrer übersetzten Ausgabe erscheint. Auf die Details kommt es an.

Text Domain und den Domain Path

Jedes Theme oder Plugin benötigt eine Text-Domain. Die Text-Domain ist eine eindeutige Kennung, die WordPress mitteilt, welche Übersetzungsdateien zu Ihrem Projekt gehören. Sie muss exakt mit dem Slug Ihres Plugins oder Themes übereinstimmen.

Deklarieren Sie diese im Header der Hauptdatei Ihres Plugins:

<?php
/**
 * Plugin Name: My Plugin
 * Description: An example plugin.
 * Version: 1.0.0
 * Text Domain: my-plugin
 * Domain Path: /languages
 */

Oder in der style.css Ihres Themes:

/*
Theme Name: My Theme
Text Domain: my-theme
Domain Path: /languages
*/

Der domain path teilt WordPress mit, wo sich Ihre Übersetzungsdateien relativ zum Stammverzeichnis des Plugins oder Themes befinden. /languages ist der Standard.

Schritt 2: Kapseln Sie Ihre PHP-Strings in gettext-Funktionen

Jeder String, den Sie übersetzbar machen möchten, muss in eine der gettext-Funktionen von WordPress gekapselt werden. Zur Laufzeit suchen diese Funktionen die richtige Übersetzung heraus. Wird keine gefunden, greifen sie auf den ursprünglichen String als Fallback zurück.

Einfache Strings. Verwenden Sie __(), wenn Sie einen String zurückgeben müssen. Für die HTML-Ausgabe verwenden Sie die Escaping-Varianten. Die WordPress-Programmierrichtlinien empfehlen echo esc_html__() anstelle von _e(). Die Escaping-Form macht das Maskieren der Ausgabe explizit und verhindert XSS-Angriffe bei der Ausgabe:

// Return a translated string
$label = __( 'Settings', 'my-plugin' );

// Echo a translated string, escaped for HTML
echo esc_html__( 'Settings saved.', 'my-plugin' );

Strings mit Variablen. Verketten Sie keine Variablen innerhalb von Strings. Übersetzer sehen dann nur Fragmente und können die Wörter für Sprachen mit einer anderen Syntax nicht umstellen. Verwenden Sie printf() oder sprintf() mit einem Platzhalter. Fügen Sie einen Übersetzerkommentar hinzu, damit die Übersetzer wissen, wofür %s steht:

printf(
    /* translators: %s: the user's display name */
    esc_html__( 'Welcome back, %s.', 'my-plugin' ),
    esc_html( $display_name )
);

Pluralformen. Englische Pluralformen sind einfach (one comment, two comments). In anderen Sprachen ist das nicht der Fall. Verwenden Sie _n(), um jede Pluralregel abzudecken, die WordPress kennt:

printf(
    esc_html( _n( '%s comment', '%s comments', $count, 'my-plugin' ) ),
    number_format_i18n( $count )
);

Strings, die Kontext benötigen. Einige Wörter haben je nach Verwendungsort unterschiedliche Bedeutungen. Verwenden Sie _x(), um den Übersetzern den benötigten Kontext zu geben:

// "Export" as a noun (the file) vs. a verb (the action)
echo esc_html_x( 'Export', 'button label', 'my-plugin' );

Schritt 3: Internationalisieren Sie Ihre JavaScript-Strings

WordPress stellt das Paket wp-i18n bereit, damit Sie in JavaScript dieselben gettext-Funktionen verwenden können, die Sie in PHP nutzen. Wenn Sie Ihr Skript registrieren, deklarieren Sie wp-i18n als Abhängigkeit:

wp_register_script(
    'my-plugin-script',
    plugins_url( 'js/app.js', __FILE__ ),
    array( 'wp-i18n' ),
    '1.0.0',
    true
);

Anschließend in Ihrer JavaScript-Datei:

const { __, _n, sprintf } = wp.i18n;

const message = __( 'Settings saved.', 'my-plugin' );

Wenn Sie einen Bundler wie Webpack verwenden, installieren Sie @wordpress/babel-plugin-makepot. Dieses Tool extrahiert als Teil Ihres Builds übersetzbare Strings aus Ihrem Bundle.

Schritt 4: Generieren Sie Ihre POT-Datei

Sobald Ihre Strings gekapselt sind, generieren Sie eine POT-Datei. Die POT-Datei ist die Quelldatei, mit der die PTC (oder jeder Übersetzer) arbeitet. Sie enthält jeden übersetzbaren String, aber keine Übersetzungen.

wp i18n make-pot . languages/my-plugin.pot

Das WP-CLI durchsucht Ihre PHP-, JavaScript- und block.json-Dateien nach gettext-Aufrufen. Es kompiliert sie zu einer einzigen POT-Datei. Wenn Ihr Team Composer verwendet, fügen Sie diesen Befehl als Composer-Skript hinzu. Dadurch bleibt die Nutzung des WP-CLI im gesamten Team konsistent, ohne dass eine globale Installation erforderlich ist.

Die vollständige Befehlssuite wp i18n deckt den Rest der Pipeline ab:

Befehl	Funktion
`wp i18n make-pot`	Generiert eine POT-Datei aus der Quelle.
`wp i18n update-po`	Synchronisiert vorhandene PO-Dateien, wenn sich Ihre POT-Datei ändert.
`wp i18n make-mo`	Kompiliert PO-Dateien in binäre MO-Dateien.
`wp i18n make-json`	Extrahiert JS-Strings aus PO-Dateien in JSON-Dateien.
`wp i18n make-php`	Generiert `.l10n.php`-Dateien (WordPress 6.5+).

Sie benötigen kein Poedit. Alles in diesem Workflow läuft über das WP-CLI und die PTC. Das WP-CLI übernimmt die POT-Generierung und die MO/JSON-Kompilierung. Die PTC übernimmt die Übersetzung und liefert jedes Dateiformat zurück, das WordPress benötigt. Poedit ist ein nützlicher Desktop-Editor für die manuelle Übersetzung, aber es ist kein Teil dieses Workflows.

POT-Dateien mit der PTC übersetzen

Die PTC wurde speziell für WordPress-Entwickler entwickelt. Starten Sie mit einer POT-Datei und erhalten Sie produktionsreife Übersetzungsdateien zurück. Die 30-Tage-Testphase deckt bis zu 20.000 Wörter in zwei Sprachen ab.

Richten Sie Ihr erstes Übersetzungsprojekt ein

Laden Sie Ihre POT-Datei hoch. Wählen Sie aus, welche Ausgabeformate Sie benötigen. Die PTC liefert jede beliebige Kombination aus:

.po-Dateien für jede Zielsprache.
.mo-Dateien, kompiliert und bereit zur Veröffentlichung.
.json-Dateien für Ihre JavaScript-Strings.
.l10n.php-Dateien für schnelleres Laden unter WordPress 6.5+.

Der Einrichtungsassistent bittet Sie, Ihr Theme oder Plugin zu beschreiben. Die PTC nutzt diese Beschreibung, um Übersetzungen mit der richtigen Tonalität und dem passenden Kontext zu generieren. Fügen Sie in dieser Phase markenspezifische Begriffe zum Glossar hinzu. Das Glossar hält Namen, Funktionsbezeichnungen und jede andere Terminologie über alle Sprachen hinweg konsistent.

Die PTC parst die gettext-Struktur beim Upload. Sie erkennt Platzhalter (%s, %1$s, %d), Pluralformen (aus _n() extrahierte Einträge mit ihrem Plural-Forms-Header) und Kontexte (_x()-Einträge mit msgctxt). Anschließend generiert sie die korrekten Pluralkategorien pro Sprache. Polnisch erhält one / few / many / other. Japanisch erhält nur other. Arabisch erhält sechs Formen.

Wechseln Sie zur kontinuierlichen Lokalisierung

Sobald Ihre ersten Dateien übersetzt sind, führen Sie ein Upgrade auf Pay-As-You-Go durch. Verbinden Sie die PTC mit Ihrem GitHub-, GitLab- oder Bitbucket-Repository. Ab diesem Zeitpunkt müssen Sie keine Dateien mehr manuell hochladen.

Committen Sie eine .ptc-config.yml, in der Sie Ihre Quelldatei benennen und angeben, wohin die Übersetzungen gehören:

# .ptc-config.yml
source_locale: en
files:
  - file: languages/my-plugin.pot
    output: languages/my-plugin-{{lang}}.po
    additional_translation_files:
      - type: mo
        path: languages/my-plugin-{{lang}}.mo

Fügen Sie dann die PTC Translate Action zu Ihrem Workflow hinzu. Sie enthält eine gepinnte Version der PTC CLI, sodass Ihr Build zur Laufzeit nichts herunterlädt:

# .github/workflows/translate.yml
name: Regenerate POT for PTC
on:
  push:
    branches: [main]
    paths:
      - 'languages/my-plugin.pot'
  workflow_dispatch: {}

jobs:
  translate:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
      - name: Generate POT
        run: |
          wp i18n make-pot . languages/my-plugin.pot --domain=my-plugin
      - uses: OnTheGoSystems/ptc-action@v1
        with:
          api-token: ${{ secrets.PTC_API_TOKEN }}
          create-pr: true

Sie haben zwei Möglichkeiten, dies zu automatisieren. Mit der Git-Integration überwacht die PTC Ihr Repository und öffnet einen Merge Request mit aktualisierten Übersetzungen, sobald sich die Quelldatei ändert. Um die Übersetzung stattdessen innerhalb Ihres eigenen CI-Jobs auszuführen, verwenden Sie die PTC CLI – sie lädt die geänderte Datei hoch, wartet auf den Abschluss der Übersetzung und lädt die übersetzten Dateien herunter. Vorgefertigte Workflow-Vorlagen für GitHub Actions, GitLab CI und Bitbucket Pipelines finden Sie in der Anleitung zur Einrichtung der CI/CD-Pipeline.

Beide Workflows liefern einen Merge Request oder einen Download mit den aktualisierten .po-, .mo-, .json- und .l10n.php-Dateien. In der PTC-API-Referenz finden Sie die vollständige Webhook- und REST-API.

Ob Sie .mo-Dateien in Ihr Repository committen, hängt von den Richtlinien Ihres Teams ab. Viele Plugins generieren sie stattdessen zum Zeitpunkt des Releases. Die CI-Integration der PTC erstellt sie bei jedem Übersetzungsdurchlauf. Checken Sie sie nur ein, wenn Sie übersetzte Dateien im Versionsverlauf haben möchten.

Übersetzungen in WordPress laden

Sobald Ihnen die übersetzten Dateien vorliegen, platzieren Sie diese richtig und teilen Sie WordPress mit, wo sie zu finden sind. Der Dateiname steht dabei an erster Stelle. WordPress sucht nach Übersetzungsdateien anhand eines bestimmten Benennungsmusters. Ein nicht übereinstimmender Dateiname führt dazu, dass die Datei nicht geladen wird.

Die richtigen Dateinamen wählen

Locale-Codes folgen dem Format language_COUNTRY. de_DE steht für Deutsch (Deutschland). fr_FR steht für Französisch (Frankreich). pt_BR steht für Portugiesisch (Brasilien). zh_CN steht für Chinesisch (vereinfacht). Das WordPress-Übersetzungsportal listet jedes unterstützte Locale auf.

Der erwartete Dateiname hängt davon ab, wo Sie die Datei ablegen:

Speicherort	Muster	Beispiel
Ordner `/languages/` des Plugins	`{text-domain}-{locale}.mo`	`my-plugin-de_DE.mo`
Ordner `/languages/` des Themes	`{locale}.mo`	`de_DE.mo`
Globales WordPress-Sprachverzeichnis (`/wp-content/languages/`)	`{text-domain}-{locale}.mo`	`my-plugin-de_DE.mo`

Themes verwenden eine kürzere Benennungskonvention, wenn Dateien im Theme gebündelt sind. Im globalen Sprachverzeichnis verwenden sowohl Plugins als auch Themes das Muster {text-domain}-{locale}.

Übersetzungen für Plugins laden (PHP)

Registrieren Sie Übersetzungen in WordPress über den Hook init. Verwenden Sie nicht plugins_loaded. Dies löst in aktuellen WordPress-Versionen eine Deprecation-Warnung aus:

add_action( 'init', function () {
    load_plugin_textdomain(
        'my-plugin',
        false,
        dirname( plugin_basename( __FILE__ ) ) . '/languages/'
    );
} );

Übersetzungen für Themes laden (PHP)

Verwenden Sie load_theme_textdomain(), eingehängt in den Hook after_setup_theme:

add_action( 'after_setup_theme', function () {
    load_theme_textdomain( 'my-theme', get_template_directory() . '/languages' );
} );

JavaScript-Übersetzungen laden

Nachdem Sie Ihr Skript registriert haben (Schritt 3 oben), rufen Sie wp_set_script_translations() auf. WordPress lädt dann die JSON-Übersetzungen für dieses Skript-Handle:

add_action( 'init', function () {
    wp_set_script_translations(
        'my-plugin-script',
        'my-plugin',
        plugin_dir_path( __FILE__ ) . 'languages'
    );
} );

Das Laden überprüfen

Stellen Sie die Sprache Ihrer WordPress-Website auf ein Ziel-Locale ein. Die Einstellung finden Sie unter Einstellungen > Allgemein > Sprache der Website.
Laden Sie das Frontend und die Admin-Seiten neu, die Ihr Plugin oder Theme darstellt.
Strings, die in __() oder esc_html__() eingeschlossen sind, sollten in der neuen Sprache erscheinen.

Wenn etwas fehlt, finden Sie unter WordPress-Plugin-Übersetzungen werden nicht angezeigt? Fehlende Übersetzungen beheben die häufigsten Ursachen.

Rechts-nach-links-Sprachen und bidirektionale Layouts

Der Übersetzungs-Workflow ist für Rechts-nach-links-Sprachen (RTL) identisch. Arabisch, Hebräisch, Persisch und Urdu verwenden dieselbe POT/PO/MO-Pipeline.

Der zusätzliche Schritt besteht darin, sicherzustellen, dass Ihr Theme RTL-Stile unterstützt. WordPress lädt automatisch eine rtl.css-Datei, falls eine solche in Ihrem Theme-Verzeichnis existiert. Verwenden Sie die Funktion is_rtl(), um RTL-spezifische Stile oder Skripte bedingt anzuwenden.

Daten, Zahlen und Währungen lokalisieren

Ein übersetzter String ist nicht alles. Daten, Zahlen und Währungen müssen ebenfalls dem Locale des Benutzers entsprechen. Verwenden Sie die integrierten Formatierungsfunktionen von WordPress anstelle der nativen PHP-Funktionen:

date_i18n() formatiert Daten entsprechend dem aktiven Locale.
number_format_i18n() formatiert Zahlen mit Locale-abhängigen Dezimal- und Tausendertrennzeichen.

Diese Funktionen sind nicht Teil des Workflows für Übersetzungsdateien. Sie sind jedoch wichtig für ein vollständig lokalisiertes Erlebnis.

Blöcke des Block-Editors (Gutenberg) internationalisieren

Blöcke fügen der Standard-Pipeline zwei zusätzliche Schritte hinzu:

JavaScript-Übersetzungen benötigen eine .json-Datei pro Locale. Generieren Sie diese aus der .po mit wp i18n make-json.
Das Editor-Skript des Blocks benötigt wp_set_script_translations() in PHP. Das weist WordPress an, das JSON an den Block auszuliefern.

Die vom Block gerenderte Ausgabe im Frontend verwendet dieselben __()-Aufrufe wie Ihr restliches PHP. Hier ist kein zusätzlicher Aufwand nötig.

Ihre README und den WordPress.org-Eintrag übersetzen

Ihre readme.txt ist keine Ressourcendatei. Das WP-CLI erfasst sie nicht automatisch, wenn ein POT generiert wird. Um sie zu übersetzen, verwenden Sie die Funktion Paste to Translate der PTC. Fügen Sie den Inhalt ein, wählen Sie Ihre Zielsprachen und laden Sie das Ergebnis herunter. An Kunden gerichtete E-Mails, die vom Plugin gesendet werden, und die Beschreibung der WordPress.org-Plugin-Seite werden auf die gleiche Weise übersetzt – alles im selben Projekt, damit die Terminologie konsistent bleibt.

Wenn Ihr Plugin oder Theme auf WordPress.org gelistet ist, erscheint die übersetzte Beschreibung auf dem Tab „Details“ des Plugins in der Sprache des Benutzers. Damit die Übersetzungen dort live gehen, folgen Sie dem WordPress.org-Importprozess.

Benutzerinhalte von Plugins mit der PTC-API übersetzen

Plugins, die benutzergenerierte Daten speichern (Foren-Plugins, Bewertungs-Plugins, Kommentar-Plugins), können diese Inhalte übersetzen, sobald sie eintreffen. Die PTC-REST-API übersetzt Benutzerbeiträge, Kommentare und Bewertungen bei Bedarf mit Bearer-Token-Authentifizierung und verwendet dabei dasselbe Glossar und dieselbe Markenstimme wie Ihre .po-Dateien.

Visuelle Übersetzungsprüfung Ihres dargestellten Themes oder Plugins – veröffentlichen Sie ohne manuelle QA pro Sprache

Eine übersetzte .po-Datei ist notwendig, aber nicht ausreichend. Das übersetzte Theme oder Plugin muss weiterhin überprüft werden:

Ein übersetztes Label kann im Deutschen zu einem Überlauf bei einem Button auf der Einstellungsseite führen.
„Submit“ wird im Französischen möglicherweise als Substantiv übersetzt, obwohl die Admin-Aktion ein Verb benötigt.
Ein hartcodierter englischer String außerhalb von __() wird unübersetzt dargestellt, unabhängig davon, wie viele Sprachen Sie veröffentlichen.

Die visuelle Übersetzungsprüfung der PTC ersetzt den Durchlauf der manuellen QA. WordPress-Themes und -Plugins werden im Browser dargestellt (sowohl wp-admin als auch das Frontend). Die richtige Variante ist die Browser-Erweiterung.

Installieren Sie sie einmal. Zeichnen Sie einen Rundgang durch Ihr Theme oder Plugin auf einer Test-Website auf. Decken Sie Einstellungsseiten, Admin-Aktionen und die Frontend-Ausgabe ab. Die PTC spielt die Aufzeichnung nach jedem Übersetzungsupdate in jeder Zielsprache erneut ab. Sie erfasst jeden Bildschirm und meldet zwei Arten von Korrekturen zurück:

Korrekturen in den .po-Dateien, wenn die PTC diese kontrolliert. Die PTC übersetzt eine falsche Bedeutung neu, wählt ein kürzeres Synonym, das auf einen Button passt, oder generiert eine Pluralform neu.
Prompts für Cursor oder Claude Code, wenn der Fehler in Ihrem PHP- oder JavaScript-Code liegt. Beispiele hierfür sind ein fehlender __()-Wrapper, ein hartcodierter englischer String oder ein durch Verkettung gebildeter Satz, der sprintf( __( ... ) ) verwenden sollte.

Sie veröffentlichen pro Release ein verifiziertes, mehrsprachiges Plugin. Der Restaufwand der manuellen QA entfällt.

Preise: 30-Tage-Testphase, danach Pay-As-You-Go

Die Testphase umfasst 20.000 Wörter in 2 Sprachen ohne Kreditkarte. Wenn die Testphase endet, bietet die PTC Pay-As-You-Go. Kein Abonnement. Keine Mindestlaufzeit. Die ersten 500 Wörter jeden Monat sind kostenlos. Sie zahlen nur für den Rest. Die Preisseite enthält einen Kostenrechner. Melden Sie sich mit einer Firmen-E-Mail-Adresse für eine erweiterte Business-Testphase an.

Bereit, ein verifiziertes Plugin oder Theme zu veröffentlichen?

Die PTC generiert die Übersetzungen und prüft das dargestellte Plugin. Sie bestätigen das Ergebnis und veröffentlichen es. Der gesamte Zyklus läuft ohne manuelle QA ab:

Generieren Sie Ihre .pot-Datei mit wp i18n make-pot.
Laden Sie diese in die PTC hoch und erhalten Sie innerhalb von Minuten .po-, .mo-, .l10n.php- und .json-Dateien zurück.
Installieren Sie die Browser-Erweiterung, um das ausgeführte Plugin in jeder Zielsprache zu überprüfen.

Starten Sie Ihre 30-Tage-Testphase – 20.000 Wörter übernehmen wir, keine Kreditkarte erforderlich.

Verwandte Themen:

PO-Dateien online mit KI übersetzen – die kanonische Seite zur PO/POT-Übersetzung.
GlotPress vs. PTC für die Übersetzung von WordPress-Plugins/-Themes – wann Sie sich für Community-Übersetzungen oder die PTC entscheiden sollten.
WordPress-Plugin-Übersetzungen werden nicht angezeigt? Fehlende Übersetzungen beheben – Leitfaden zur Fehlerbehebung.
So importieren Sie Theme- und Plugin-Übersetzungen in WordPress.org – der CLPTE-Prozess und eine schnellere Alternative.
PTC-API-Referenz – REST-Endpunkte für die CI-Integration.