WordPress-Internationalisierung: So übersetzen Sie Themes und Plugins

Machen Sie Ihr WordPress-Theme oder -Plugin bereit für die Übersetzung. Dieser Leitfaden behandelt Text-Domains, gettext-Funktionen, die POT-Generierung und den Lademechanismus, der den Benutzern Übersetzungen anzeigt. Die PTC (Private Translation Cloud) übersetzt dann die Ressourcendateien und führt eine visuelle Übersetzungsprüfung des gerenderten Themes oder Plugins in jeder Sprache durch.

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 PO-Dateien-Seite für den 3-Schritte-Workflow.

Am Ende dieses Leitfadens wird Ihr Theme oder Plugin:

gemäß den WordPress-Programmierstandards korrekt internationalisiert sein.
durch die PTC in 40+ Sprachen übersetzbar sein.
über WordPress.org-Sprachpakete verteilbar sein.
bei jedem Release mit der visuellen Übersetzungsprüfung der PTC verifizierbar sein.

Was ist WordPress-Internationalisierung?

Internationalisierung (i18n) ist die Vorbereitung Ihres Codes, damit er übersetzt werden kann. Lokalisierung (l10n) ist der nächste Schritt. Sie erzeugt die tatsächlichen übersetzten Strings für bestimmte Sprachen.

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

Jeden benutzerseitigen String in gettext-Funktionen wrappen, damit WordPress ihn zur Laufzeit austauschen kann.
Eine Text-Domain definieren, die Ihre Übersetzungen mit Ihrem Projekt verknüpft.
Eine POT-Datei generieren, 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 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 Rolle:

POT (Portable Object Template). Die aus Ihrem Code generierte Quelldatei. Sie listet jeden übersetzbaren String ohne angehängte Übersetzungen auf. Diese übergeben Sie der PTC.
PO (Portable Object). Eine Kopie der POT-Datei mit hinzugefügten Übersetzungen für eine bestimmte Sprache. Reiner Text, menschenlesbar. Die PTC gibt eine PO-Datei pro Zielsprache zurück.
MO (Machine Object). Die kompilierte binäre Version einer PO-Datei. WordPress liest MO-Dateien zur Laufzeit, da sie schneller laden als PO-Text.
JSON. Das JavaScript-Äquivalent zu MO. WordPress kann MO-Dateien nicht aus JavaScript lesen, daher produziert die Build-Pipeline JSON-Dateien für browserseitige Strings.
.l10n.php. Eine neuere Alternative zu 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 auf den unterstützten WordPress-Versionen durchweg besser als MO.

Warum Community-Übersetzungen nicht ausreichen

WordPress.org bietet Community-Übersetzungen über GlotPress an. In der Praxis deckt dies 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 über 40 Sprachen hinweg abdecken.

Zwei strukturelle Probleme erklären diese Lücke:

Freiwillige sind in den meisten Locales knapp. Eine Handvoll Plugins mit massiven Nutzerbasen ziehen Übersetzer an. Die meisten tun das nicht.
Es kann Monate oder Jahre dauern, bis Übersetzungen erscheinen, falls sie überhaupt erscheinen. 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 in einem Release-Zeitplan wünschen, den Sie kontrollieren. Genau das liefert die PTC.

Vorbereiten Ihres WordPress-Themes oder -Plugins für die Übersetzung

Eine nicht übereinstimmende Text-Domain oder ein nicht gewrappter String führt dazu, dass dieser Text niemals in Ihrer übersetzten Ausgabe erscheint. Die Details sind wichtig.

Schritt 1: Definieren Sie Ihre Text-Domain und den Domain-Pfad

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 sie 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-Pfad teilt WordPress mit, wo sich Ihre Übersetzungsdateien relativ zum Stammverzeichnis des Plugins oder Themes befinden. /languages ist der Standard.

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

Jeder String, den Sie übersetzbar machen möchten, muss in eine der gettext-Funktionen von WordPress gewrappt werden. Zur Laufzeit suchen diese Funktionen nach der korrekten Übersetzung. Wird keine gefunden, nutzen sie den ursprünglichen String als Fallback.

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

// 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 in Strings. Übersetzer sehen nur Fragmente und können Wörter für Sprachen mit unterschiedlicher Syntax nicht umstellen. Verwenden Sie printf() oder sprintf() mit einem Platzhalter. Fügen Sie einen Übersetzerkontext hinzu, damit Ü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 (ein Kommentar, zwei Kommentare). Andere Sprachen sind das nicht. Verwenden Sie _n(), um jede Pluralregel zu handhaben, die WordPress kennt:

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

Strings, die Kontext benötigen. Manche Wörter haben je nach Verwendungsort unterschiedliche Bedeutungen. Verwenden Sie _x(), um Ü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 wp-i18n-Paket zur Verfügung, damit Sie in JavaScript dieselben gettext-Funktionen nutzen können wie in PHP. Deklarieren Sie bei der Registrierung Ihres Skripts wp-i18n als Abhängigkeit:

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

Dann 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. Es extrahiert als Teil Ihres Builds übersetzbare Strings aus Ihrem Bundle.

Schritt 4: Generieren Sie Ihre POT-Datei

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

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

WP-CLI scannt Ihre PHP-, JavaScript- und block.json-Dateien nach gettext-Aufrufen. Es kompiliert sie in eine einzige POT-Datei. Wenn Ihr Team Composer verwendet, fügen Sie diesen Befehl als Composer-Skript hinzu. Das hält die Nutzung von WP-CLI im gesamten Team ohne eine globale Installation konsistent.

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

Befehl	Was er tut
`wp i18n make-pot`	Eine POT-Datei aus der Quelle generieren.
`wp i18n update-po`	Vorhandene PO-Dateien synchronisieren, wenn sich Ihre POT-Datei ändert.
`wp i18n make-mo`	PO-Dateien in binäre MO-Dateien kompilieren.
`wp i18n make-json`	JS-Strings aus PO- in JSON-Dateien extrahieren.
`wp i18n make-php`	`.l10n.php`-Dateien generieren (WordPress 6.5+).

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

Übersetzen von POT-Dateien mit der PTC

Die PTC wurde 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, welche Ausgabeformate Sie benötigen. Die PTC gibt eine beliebige Kombination aus Folgendem zurück:

.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 in WordPress 6.5+.

Der Einrichtungsassistent bittet Sie, Ihr Theme oder Plugin zu beschreiben. Die PTC nutzt die 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, Feature-Labels und jegliche andere Terminologie über alle Sprachen hinweg konsistent.

Die PTC parst die gettext-Struktur beim Upload. Sie erkennt Platzhalter (%s, %1$s, %d), Pluralformen (mit _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 laden Sie Dateien nicht mehr manuell hoch:

# .github/workflows/translate.yml
name: Regenerate POT for PTC
on:
  push:
    branches: [main]
    paths:
      - 'languages/my-plugin.pot'
jobs:
  translate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Generate POT
        run: |
          wp i18n make-pot . languages/my-plugin.pot --domain=my-plugin
      - name: Translate with PTC
        run: |
          cat > .ptc-config.yml <<'EOF'
          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
          EOF
          curl -fsSL https://raw.githubusercontent.com/OnTheGoSystems/ptc-cli/main/ptc-cli.sh -o ptc-cli.sh
          chmod +x ptc-cli.sh
          ./ptc-cli.sh --config-file .ptc-config.yml --api-token="${{ secrets.PTC_API_TOKEN }}"

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-Templates für GitHub Actions, GitLab CI und Bitbucket Pipelines finden Sie im Leitfaden 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. Siehe die PTC-API-Referenz für den vollständigen Webhook und die REST-API.

Ob Sie .mo-Dateien in Ihr Repository einchecken, hängt von den Richtlinien Ihres Teams ab. Viele Plugins generieren diese stattdessen beim Release. Die CI-Integration der PTC erzeugt sie bei jedem Übersetzungsdurchlauf. Checken Sie sie nur ein, wenn Sie übersetzte Dateien in der Versionshistorie haben möchten.

Laden von Übersetzungen in WordPress

Wenn Sie die übersetzten Dateien zur Hand haben, platzieren Sie sie korrekt und teilen Sie WordPress mit, wo sie zu finden sind. Der Dateiname steht 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 language_COUNTRY-Format. de_DE ist Deutsch (Deutschland). fr_FR ist Französisch (Frankreich). pt_BR ist Portugiesisch (Brasilien). zh_CN ist Chinesisch (vereinfacht). Das WordPress-Übersetzungsportal listet jedes unterstützte Locale auf.

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

Speicherort	Muster	Beispiel
`/languages/`-Ordner des Plugins	`{text-domain}-{locale}.mo`	`my-plugin-de_DE.mo`
`/languages/`-Ordner 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 innerhalb des Themes gebündelt sind. Im globalen Sprachverzeichnis verwenden sowohl Plugins als auch Themes das {text-domain}-{locale}-Muster.

Laden von Übersetzungen für Plugins (PHP)

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

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

Laden von Übersetzungen für Themes (PHP)

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

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

Laden von JavaScript-Übersetzungen

Rufen Sie nach der Registrierung Ihres Skripts (Schritt 3 oben) 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'
    );
} );

Überprüfen Sie das Laden

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

Wenn etwas fehlt, lesen Sie WordPress-Plugin-Übersetzungen werden nicht angezeigt? Fehlende Übersetzungen beheben für die häufigsten Ursachen.

Rechts-nach-links-Sprachen und bidirektionale Layouts

Der Übersetzungs-Workflow ist für Rechts-nach-links-Sprachen (RTL) derselbe. 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, wenn eine in Ihrem Theme-Verzeichnis existiert. Verwenden Sie die Funktion is_rtl(), um RTL-spezifische Stile oder Skripte bedingt anzuwenden.

Lokalisieren von Daten, Zahlen und Währungen

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

date_i18n() formatiert Daten gemäß dem aktiven Locale.
number_format_i18n() formatiert Zahlen mit Locale-spezifischen Dezimal- und Tausendertrennzeichen.

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

Internationalisierung von Block-Editor-Blöcken (Gutenberg)

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 teilt WordPress mit, dem Block das JSON bereitzustellen.

Die vom Block gerenderte Ausgabe im Frontend verwendet dieselben __()-Aufrufe wie Ihr restliches PHP. Hier ist keine zusätzliche Arbeit erforderlich.

Übersetzen Ihrer README-Datei und Ihres WordPress.org-Eintrags

Ihre readme.txt ist keine Ressourcendatei. WP-CLI erfasst sie nicht bei der Generierung einer POT-Datei. 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. Kundenorientierte E-Mails, die vom Plugin gesendet werden, und die Beschreibung der WordPress.org-Plugin-Seite werden auf dieselbe 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 Details-Tab des Plugins in der Sprache des Benutzers. Um Übersetzungen dort live zu schalten, folgen Sie dem WordPress.org-Importprozess.

Übersetzen von Plugin-Benutzerinhalten mit der PTC-API

Plugins, die benutzergenerierte Daten speichern (Forum-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 gerenderten 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 verifiziert werden:

Ein übersetztes Label kann auf Deutsch über einen Button auf der Einstellungsseite hinausragen.
„Submit“ wird auf Französisch möglicherweise als Substantiv übersetzt, wenn die Admin-Aktion ein Verb benötigte.
Ein hardcodierter englischer String außerhalb von __() wird unübersetzt dargestellt, unabhängig davon, in wie vielen Sprachen Sie veröffentlichen.

Die visuelle Übersetzungsprüfung der PTC ersetzt den Durchlauf der manuellen QA. WordPress-Themes und -Plugins werden im Browser gerendert (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 in jeder Zielsprache nach jedem Übersetzungs-Update 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.
Cursor- oder Claude Code-Prompts, wenn der Fehler in Ihrem PHP- oder JavaScript-Code liegt. Beispiele sind ein fehlender __()-Wrapper, ein hardcodierter 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 deckt 20.000 Wörter in 2 Sprachen ohne Kreditkarte ab. Wenn die Testphase endet, bietet die PTC Pay-As-You-Go. Kein Abonnement. Keine Mindestabnahme. Die ersten 500 Wörter jeden Monat sind kostenlos. Sie zahlen nur für den Rest. Die Preisseite bietet 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 gerenderte Plugin. Sie bestätigen das Ergebnis und veröffentlichen es. Der gesamte Kreislauf läuft ohne manuelle QA:

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

Starten Sie Ihre 30-Tage-Testphase – 20.000 Wörter auf unsere Kosten, keine Kreditkarte erforderlich.

Verwandt:

PO-Dateien online mit KI übersetzen – die zentrale Seite zur PO/POT-Übersetzung.
GlotPress im Vergleich zur PTC für die Übersetzung von WordPress-Plugins/-Themes – wann Sie sich für Community-Übersetzungen und wann für 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 – CLPTE-Prozess und eine schnellere Alternative.
PTC-API-Referenz – REST-Endpunkte für die CI-Integration.