I18n di temi e plugin WordPress: rendi il codice traducibile

Rendi traducibile un tema o un plugin WordPress: text domain, __() e _n(), un file POT con WP-CLI, per poi caricare i file .mo, .json e .l10n.php.

Localizza questa app in tedesco e spagnolo con PTC.

Prepara il tuo tema o plugin WordPress per la traduzione. Questa guida illustra i text domain, le funzioni gettext, la generazione dei POT e il meccanismo di caricamento che mostra le traduzioni agli utenti. PTC (Private Translation Cloud) traduce poi i file di risorse ed esegue la revisione visiva del tema o plugin renderizzato in ogni lingua.

Vuoi tradurre un sito WordPress che gestisci, non il codice che hai scritto? Usa WPML.

Questa guida è rivolta agli sviluppatori che scrivono il codice. Se hai già un file POT o PO e devi solo tradurlo, vai alla pagina dei file PO per il workflow in 3 passaggi.

Al termine di questa guida, il tuo tema o plugin sarà:

• Internazionalizzato correttamente secondo gli standard di codifica di WordPress.
• Traducibile da PTC in oltre 40 lingue.
• Distribuibile tramite i Language Pack di WordPress.org.
• Verificabile a ogni release con la revisione visiva della traduzione di PTC.

Cos'è l'internazionalizzazione di WordPress?

L'internazionalizzazione (i18n) è il lavoro di preparazione del tuo codice affinché possa essere tradotto. La localizzazione (l10n) è il passaggio successivo. Produce le stringhe tradotte effettive per lingue specifiche.

Per i temi e i plugin WordPress, i18n significa tre cose:

• Racchiudere ogni stringa rivolta all'utente nelle funzioni gettext, in modo che WordPress possa sostituirle a runtime.
• Definire un text domain che lega le tue traduzioni al tuo progetto.
• Generare un file POT da cui partono i traduttori (o PTC).

Una volta completato questo lavoro, avrai tutto il necessario per produrre i file PO, MO, JSON e .l10n.php tradotti per qualsiasi lingua.

PTC traduce i file POT in MO, JSON e .l10n.php per WordPress

Cinque estensioni di file compaiono in qualsiasi workflow di traduzione di WordPress. PTC traduce da .pot (la tua origine) in .po, .mo, .json e .l10n.php per ogni lingua di destinazione. Ogni formato ha un ruolo specifico:

• POT (Portable Object Template). Il file di origine generato dal tuo codice. Elenca ogni stringa traducibile senza traduzioni allegate. È quello che consegni a PTC.
• PO (Portable Object). Una copia del POT con le traduzioni aggiunte per una lingua specifica. Testo normale, leggibile da esseri umani. PTC restituisce un PO per ogni lingua di destinazione.
• MO (Machine Object). La versione binaria compilata di un PO. WordPress legge i file MO a runtime perché si caricano più velocemente rispetto al testo dei PO.
• JSON. L'equivalente JavaScript del MO. WordPress non può leggere i file MO da JavaScript, quindi la pipeline di build produce file JSON per le stringhe lato browser.
• .l10n.php. Un'alternativa più recente ai MO, introdotta in WordPress 6.5. Si carica più velocemente e usa meno memoria. WordPress lo sceglie automaticamente quando ne esiste uno accanto al file MO.

Attiva .l10n.php per i nuovi progetti. È decisamente migliore rispetto al MO sulle versioni supportate di WordPress.

Perché la traduzione della community non è sufficiente

WordPress.org offre traduzioni della community tramite GlotPress. In pratica, copre una piccola frazione di ciò di cui la maggior parte dei plugin e temi ha bisogno. Un'analisi su oltre 60.000 plugin e temi WordPress ha rilevato che la traduzione della community copre meno del 5% delle esigenze di traduzione in 40 lingue.

Due problemi strutturali spiegano questo divario:

• I volontari scarseggiano nella maggior parte dei locale. Una manciata di plugin con un'enorme base di utenti attrae traduttori. La maggior parte no.
• Le traduzioni possono impiegare mesi o anni per apparire, se mai appaiono. Se vuoi che gli utenti vedano il tuo plugin o tema nella loro lingua fin dal primo giorno, non puoi affidarti alla community.

Questa guida presuppone che tu voglia una copertura di traduzione completa e coerente con una cadenza delle release sotto il tuo controllo. Questo è ciò che offre PTC.

Preparare il tuo tema o plugin WordPress per la traduzione

Un text domain non corrispondente o una stringa non racchiusa in un wrapper significa che quel testo non apparirà mai nel tuo output tradotto. I dettagli contano.

Passaggio 1: Definisci il text domain e il percorso del dominio

Ogni tema o plugin ha bisogno di un text domain. Il text domain è un identificatore univoco che dice a WordPress quali file di traduzione appartengono al tuo progetto. Deve corrispondere esattamente allo slug del tuo plugin o tema.

Dichiaralo nell'intestazione del file principale del tuo plugin:

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

Oppure nel style.css del tuo tema:

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

Il percorso del dominio dice a WordPress dove si trovano i tuoi file di traduzione rispetto alla root del plugin o del tema. /languages è lo standard.

Passaggio 2: Racchiudi le tue stringhe PHP nelle funzioni gettext

Qualsiasi stringa che vuoi rendere traducibile deve essere racchiusa in una delle funzioni gettext di WordPress. A runtime, quelle funzioni cercano la traduzione corretta. Se non ne viene trovata nessuna, usano come fallback la stringa originale.

Stringhe di base. Usa __() quando devi restituire una stringa. Per l'output HTML, usa le varianti escaped. Gli standard di codifica di WordPress raccomandano echo esc_html__() rispetto a _e(). La forma escaped rende esplicito l'escaping dell'output e previene gli attacchi XSS nel punto di output:

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

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

Stringhe con variabili. Non concatenare le variabili nelle stringhe. I traduttori vedono solo frammenti e non possono riordinare le parole per lingue con una sintassi diversa. Usa printf() o sprintf() con un segnaposto. Aggiungi un commento per il traduttore in modo che i traduttori sappiano cosa rappresenta %s:

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

Forme plurali. I plurali inglesi sono semplici (un commento, due commenti). Le altre lingue non lo sono. Usa _n() per gestire ogni regola per i plurali conosciuta da WordPress:

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

Stringhe che richiedono un contesto. Alcune parole hanno significati diversi a seconda di dove appaiono. Usa _x() per fornire ai traduttori il contesto di cui hanno bisogno:

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

Passaggio 3: Internazionalizza le tue stringhe JavaScript

WordPress fornisce il pacchetto wp-i18n, così puoi usare in JavaScript le stesse funzioni gettext che usi in PHP. Quando registri il tuo script, dichiara wp-i18n come dipendenza:

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

Poi nel tuo file JavaScript:

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

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

Se usi un bundler come Webpack, installa @wordpress/babel-plugin-makepot. Estrae le stringhe traducibili dal tuo bundle come parte della tua build.

Passaggio 4: Genera il tuo file POT

Una volta che le tue stringhe sono racchiuse nelle funzioni, genera un file POT. Il POT è il file di origine su cui lavora PTC (o qualsiasi traduttore). Contiene ogni stringa traducibile ma nessuna traduzione.

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

WP-CLI scansiona i tuoi file PHP, JavaScript e block.json alla ricerca di chiamate gettext. Li compila in un singolo POT. Se il tuo team usa Composer, aggiungi questo comando come script Composer. Questo mantiene l'uso di WP-CLI coerente in tutto il team senza un'installazione globale.

L'intera suite di comandi wp i18n copre il resto della pipeline:

Non hai bisogno di Poedit. Tutto in questo workflow passa tramite WP-CLI e PTC. WP-CLI gestisce la generazione dei POT e la compilazione di MO/JSON. PTC gestisce la traduzione e restituisce ogni formato di file di cui WordPress ha bisogno. Poedit è un utile editor desktop per la traduzione manuale, ma non fa parte di questo workflow.

Tradurre i file POT con PTC

PTC è pensato per gli sviluppatori WordPress. Inizia con un file POT e ottieni file di traduzione pronti per la produzione. La prova di 30 giorni copre fino a 20.000 parole in due lingue.

Configura il tuo primo progetto di traduzione

Carica il tuo file POT. Scegli di quali formati di output hai bisogno. PTC restituisce qualsiasi combinazione di:

• File .po per ogni lingua di destinazione.
• File .mo, compilati e pronti per essere rilasciati.
• File .json per le tue stringhe JavaScript.
• File .l10n.php per un caricamento più rapido su WordPress 6.5+.

La configurazione guidata ti chiede di descrivere il tuo tema o plugin. PTC usa la descrizione per generare traduzioni con il tono e il contesto giusti. Aggiungi i termini specifici del brand al glossario in questa fase. Il glossario mantiene nomi, etichette delle funzionalità e qualsiasi altra terminologia coerenti in tutte le lingue.

PTC analizza la struttura gettext al momento del caricamento. Riconosce i segnaposto (%s, %1$s, %d), le forme plurali (voci estratte con _n() e la relativa intestazione Plural-Forms) e i contesti (voci _x() con msgctxt). Quindi genera le categorie plurali corrette per ogni lingua. Il polacco ottiene one / few / many / other. Il giapponese ottiene solo other. L'arabo ottiene sei forme.

Passa alla localizzazione continua

Una volta tradotti i tuoi primi file, fai l'upgrade a Pay-As-You-Go. Collega PTC al tuo repository GitHub, GitLab o Bitbucket. Da quel momento non caricherai più i file manualmente.

Esegui il commit di un .ptc-config.yml indicando il tuo file di origine e dove devono essere collocate le traduzioni:

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

Poi aggiungi la PTC Translate action al tuo workflow. Contiene al suo interno una versione fissata della CLI di PTC, quindi la tua build non scarica nulla a runtime:

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

Hai due modi per automatizzare questo processo. Con l'integrazione Git, PTC monitora il tuo repository e apre una merge request con le traduzioni aggiornate ogni volta che il file di origine cambia. Per eseguire la traduzione all'interno del tuo job CI, usa invece la CLI di PTC: carica il file modificato, attende il completamento della traduzione e scarica i file tradotti. I modelli di workflow pronti all'uso per GitHub Actions, GitLab CI e Bitbucket Pipelines si trovano nella guida alla configurazione della pipeline CI/CD.

Entrambi i flussi forniscono una merge request o un download con i file .po, .mo, .json e .l10n.php aggiornati. Consulta il riferimento dell'API PTC per i webhook e l'API REST completi.

La scelta di eseguire o meno il commit dei file .mo nel tuo repository dipende dalle policy del team. Molti plugin li generano invece al momento della release. L'integrazione CI di PTC li produce a ogni esecuzione della traduzione. Registrali nel version control solo se desideri avere i file tradotti nella cronologia delle versioni.

Caricare le traduzioni in WordPress

Con i file tradotti a disposizione, posizionali correttamente e di' a WordPress dove trovarli. Il nome del file viene prima di tutto. WordPress cerca i file di traduzione usando un modello di denominazione specifico. Un nome file che non corrisponde significa che il file non verrà caricato.

Scegliere i nomi file corretti

I codici dei locale seguono il formato language_COUNTRY. de_DE è il tedesco (Germania). fr_FR è il francese (Francia). pt_BR è il portoghese (Brasile). zh_CN è il cinese semplificato. Il portale di traduzione di WordPress elenca tutti i locale supportati.

Il nome file previsto dipende da dove posizioni il file:

I temi usano una convenzione di denominazione più breve quando i file sono inclusi nel bundle del tema. Nella directory globale delle lingue, sia i plugin che i temi usano il modello {text-domain}-{locale}.

Caricare le traduzioni per i plugin (PHP)

Registra le traduzioni in WordPress sull'hook init. Non usare plugins_loaded. Attiva un avviso di deprecazione nelle versioni attuali di WordPress:

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

Caricare le traduzioni per i temi (PHP)

Usa load_theme_textdomain() agganciato a after_setup_theme:

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

Caricare le traduzioni JavaScript

Dopo aver registrato il tuo script (Passaggio 3 qui sopra), chiama wp_set_script_translations(). WordPress carica quindi le traduzioni JSON per quell'handle dello script:

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

Verifica il caricamento

1. Imposta la lingua del tuo sito WordPress su un locale di destinazione. L'impostazione si trova in Impostazioni > Generali > Lingua del sito.
2. Ricarica il front end e le pagine di amministrazione renderizzate dal tuo plugin o tema.
3. Le stringhe racchiuse in __() o esc_html__() dovrebbero apparire nella nuova lingua.

Se manca qualcosa, consulta Le traduzioni del plugin WordPress non vengono visualizzate? Risolvi le traduzioni mancanti per le cause più comuni.

Portare le traduzioni agli utenti: due percorsi

Una volta che PTC ha tradotto i tuoi file, puoi rilasciarli in uno di questi due modi.

Percorso 1: Pubblicare le traduzioni tramite i Language Pack di WordPress.org (CLPTE)

Tempo totale: 4-6 giorni.

Passaggio 1: Crea un account CLPTE

Il ruolo CLPTE (Cross-Locale Project Translation Editor) ti permette di inviare traduzioni per conto del tuo tema o plugin in ogni lingua di destinazione da un unico account. Un normale account Editor di traduzione è per singola lingua; il CLPTE no.

Se hai già un account su WordPress.org, potresti riscontrare un problema in cui il tuo nuovo account CLPTE viene disabilitato. WordPress non consente account multipli. Per risolvere, invia un'email a forum-password-resets@wordpress.org spiegando che stai cercando di creare un account CLPTE. Condividere la documentazione pertinente dei Polyglots con il moderatore e menzionare il team Polyglots su Slack sono entrambe azioni utili.

Tempo stimato: ~3-5 giorni (incluso il tempo di attesa se il tuo nuovo account è disabilitato).

Passaggio 2: Richiedi l'accesso CLPTE sul blog dei Polyglots

Con il tuo account abilitato, pubblica una richiesta sul blog dei Polyglots di WordPress.org. Segui il loro modello:

PTE/CLPTE Request

Plugin URL: https://wordpress.org/plugins/my-plugin/
Authors / Editors: @your-wp-username
Type of request: CLPTE

Riceverai una notifica quando la tua richiesta verrà approvata.

Tempo stimato: ~1 giorno (il Polyglots Global Team esamina le richieste in batch).

Passaggio 3: Importa i file .po tradotti

1. Accedi a https://translate.wordpress.org/ usando il tuo account CLPTE.
2. Vai alla pagina del progetto di traduzione del tuo plugin o tema (ad esempio, translate.wordpress.org/projects/wp-plugins/{your-plugin-slug}/).
3. Apri il progetto locale per ogni lingua che hai tradotto.
4. Scorri verso il basso e fai clic su Importa traduzioni.
5. Carica il tuo file .po (o .mo).
6. Contrassegna le stringhe importate come “current” nell'editor di traduzione. Le stringhe approvate si uniscono alla generazione successiva dei Language Pack (in genere ogni giorno).
7. Ripeti l'operazione per ogni lingua di destinazione. Ogni locale ha la propria pagina di traduzione.

Tempo stimato: ~10-30 minuti per lingua.

Dopo una finestra di 24-48 ore per i Language Pack, i siti che eseguono il tuo plugin iniziano a ricevere le nuove traduzioni tramite gli aggiornamenti automatici dei Language Pack di WordPress. Gli utenti non vedono alcun avviso di aggiornamento. Le traduzioni appaiono e basta.

Cosa farà e non farà il CLPTE per te

• Non puoi sostituire le traduzioni della community esistenti. Vengono importate solo le stringhe non tradotte. L'aggiornamento di una traduzione della community esistente richiede il processo standard e l'attesa della revisione del team del locale.
• Gli aggiornamenti richiedono caricamenti manuali per ogni release. Ogni nuova release significa un nuovo ciclo di caricamenti.
• La creazione e l'approvazione dell'account richiedono in genere 4-6 giorni in totale.

Percorso 2: Includere i file .mo nel bundle del tuo plugin o tema

Se hai bisogno che le traduzioni vadano online più velocemente di quanto consenta il CLPTE, o se preferisci non dipendere dalla pipeline di distribuzione di WordPress.org, includi i file .mo direttamente nel bundle della release del tuo plugin o tema. Tempo totale: 15-30 minuti.

Passaggio 1: Aggiungi i file .mo alla directory /languages/

Posiziona i tuoi file .mo compilati all'interno della directory /languages/ del tuo plugin o tema, in modo che WordPress li trovi durante il caricamento del tuo text domain:

my-plugin/
├─ my-plugin.php
├─ readme.txt
├─ languages/
│  ├─ my-plugin-es_ES.mo
│  ├─ my-plugin-es_ES.po
│  ├─ my-plugin-fr_FR.mo
│  ├─ my-plugin-fr_FR.po
│  ├─ my-plugin-de_DE.mo
│  └─ my-plugin-de_DE.po

Usa lo stesso text domain nei nomi dei tuoi file di traduzione e nelle tue chiamate load_plugin_textdomain() o load_theme_textdomain().

Passaggio 2: Privilegia i tuoi file in bundle rispetto alle traduzioni della community

Per impostazione predefinita, WordPress dà priorità alle traduzioni della community di WordPress.org rispetto a quelle in bundle. Per assicurarti che il tuo plugin o tema usi invece i file .mo in bundle, aggiungi il filtro load_textdomain_mofile.

Per i plugin, aggiungi al file principale del tuo plugin (ad es. my-plugin.php):

function my_plugin_load_embedded_translation_file( $mofile, $domain ) {
    if ( 'my-domain' === $domain && false !== strpos( $mofile, WP_LANG_DIR . '/plugins/' ) ) {
        $locale = apply_filters( 'plugin_locale', determine_locale(), $domain );
        $local_mofile = WP_PLUGIN_DIR . '/' . dirname( plugin_basename( __FILE__ ) ) .
                        '/languages/' . $domain . '-' . $locale . '.mo';

        if ( file_exists( $local_mofile ) ) {
            return $local_mofile;
        }
    }
    return $mofile;
}
add_filter( 'load_textdomain_mofile', 'my_plugin_load_embedded_translation_file', 10, 2 );

Per i temi, aggiungi al functions.php del tuo tema:

function my_theme_load_embedded_translation_file( $mofile, $domain ) {
    if ( 'my-domain' === $domain && false !== strpos( $mofile, WP_LANG_DIR . '/themes/' ) ) {
        $locale = apply_filters( 'theme_locale', determine_locale(), $domain );
        $local_mofile = get_template_directory() . '/languages/' . $locale . '.mo';

        if ( file_exists( $local_mofile ) ) {
            return $local_mofile;
        }
    }
    return $mofile;
}
add_filter( 'load_textdomain_mofile', 'my_theme_load_embedded_translation_file', 10, 2 );

Conferma inoltre che il tuo plugin o tema carichi il text domain sull'hook corretto:

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

Passaggio 3: Verifica che le traduzioni in bundle si carichino su un sito di test

Installa il tuo plugin o tema su un sito di test e cambia la lingua di WordPress in una di quelle che hai fornito:

1. Vai su Impostazioni > Generali > Lingua del sito e seleziona una lingua il cui file .mo è presente nella tua cartella /languages/.
2. Carica una pagina o una schermata che contiene stringhe che sai essere state tradotte.
3. Conferma che le stringhe appaiano nella lingua corretta e corrispondano alle traduzioni che hai aggiunto.

Se vedi ancora vecchie traduzioni della community, rivedi lo snippet nel Passaggio 2. Deve indirizzare correttamente WordPress ai tuoi file .mo in bundle.

Esegui il commit dei file .mo, tagga una release ed esegui il push su wordpress.org tramite SVN come fai di solito.

Il compromesso tra velocità e distribuzione canonica

• Pro: istantaneo. Le nuove traduzioni sono online nel momento in cui gli utenti aggiornano il tuo plugin (o lo installano per la prima volta). Nessuna attesa di più giorni per il CLPTE. Nessun ciclo di approvazione del team Polyglots.
• Pro: controlli il workflow. La cadenza delle traduzioni corrisponde esattamente alla cadenza delle release.
• Pro: nessuna dipendenza dal badge del plugin. Le traduzioni funzionano a prescindere dal fatto che il tuo plugin abbia o meno i permessi CLPTE.
• Contro: la dimensione del file del plugin cresce. Ogni .mo è piccolo (in genere 5-50 KB), ma 20 lingue aggiungono ~500 KB al download.
• Contro: nessun aggiornamento automatico delle traduzioni tra le release del plugin. Con il CLPTE, le traduzioni aggiornate su wordpress.org si propagano agli utenti entro 48 ore, anche se non rilasci una nuova release. Con il bundle, le traduzioni si aggiornano solo quando rilasci una nuova release.
• Contro: nessun badge “tradotto”. WordPress.org mostra un badge di completamento della traduzione nelle schede dello store dei plugin basato sulla copertura dei Language Pack, non sui file .mo in bundle. Il solo bundle non fa ottenere il badge.

Quale percorso corrisponde alla tua cadenza delle release?

L'approccio doppio è comune: includi i file MO nel bundle per una disponibilità immediata e inviali al CLPTE per la distribuzione canonica. Gli utenti ottengono le traduzioni in bundle con l'aggiornamento; l'overlay del Language Pack le aggiorna tra una release e l'altra.

Lingue da destra a sinistra (RTL) e layout bidirezionali

Il flusso di lavoro di traduzione è lo stesso per le lingue da destra a sinistra (RTL). Arabo, ebraico, persiano e urdu usano la stessa pipeline POT/PO/MO.

Il passaggio aggiuntivo è assicurarsi che il tuo tema supporti gli stili RTL. WordPress carica automaticamente un file rtl.css se ne esiste uno nella directory del tuo tema. Usa la funzione is_rtl() per applicare in modo condizionale stili o script specifici per RTL.

Localizzare date, numeri e valute

Una stringa tradotta non è tutto. Anche date, numeri e valute devono seguire il locale dell'utente. Usa le funzioni di formattazione integrate di WordPress invece di quelle native di PHP:

• date_i18n() formatta le date in base al locale attivo.
• number_format_i18n() formatta i numeri con separatori delle migliaia e decimali sensibili al locale.

Queste funzioni non fanno parte del flusso di lavoro dei file di traduzione. Sono importanti per un'esperienza completamente localizzata.

Internazionalizzare i blocchi dell'editor a blocchi (Gutenberg)

I blocchi aggiungono due passaggi extra alla pipeline standard:

• Le traduzioni JavaScript richiedono un file .json per locale. Generalo dal .po con wp i18n make-json.
• Lo script dell'editor del blocco richiede wp_set_script_translations() in PHP. Questo dice a WordPress di servire il JSON al blocco.

L'output renderizzato dal blocco sul front end usa le stesse chiamate __() del tuo altro PHP. Nessun lavoro extra in questo caso.

Tradurre il tuo README e la scheda dello store di WordPress.org

Il tuo readme.txt non è un file di risorse. WP-CLI non lo rileverà durante la generazione di un POT. Per tradurlo, usa la funzionalità Paste to Translate di PTC. Incolla il contenuto, scegli le lingue di destinazione e scarica il risultato. Le email rivolte ai clienti inviate dal plugin e la descrizione della pagina del plugin su WordPress.org si traducono allo stesso modo, tutte nello stesso progetto affinché la terminologia rimanga coerente.

Se il tuo plugin o tema è presente su WordPress.org, la descrizione tradotta appare nella scheda Dettagli del plugin nella lingua dell'utente. Per far sì che le traduzioni vadano online in quella sezione, segui il processo di importazione di WordPress.org.

Tradurre i contenuti utente del plugin con l'API PTC

I plugin che memorizzano dati generati dagli utenti (plugin per forum, recensioni o commenti) possono tradurre quei contenuti man mano che arrivano. L'API REST PTC traduce post, commenti e recensioni degli utenti su richiesta con autenticazione Bearer, usando lo stesso glossario e la stessa voce del brand dei tuoi file .po.

Revisione visiva della traduzione del tuo tema o plugin renderizzato: rilascia senza QA manuale per lingua

Un file .po tradotto è necessario, ma non è sufficiente. Il tema o plugin tradotto richiede ancora una verifica:

• Un'etichetta tradotta potrebbe andare in overflow nel pulsante di una pagina delle impostazioni in tedesco.
• “Submit” potrebbe essere tradotto come sostantivo in francese quando l'azione di amministrazione richiedeva un verbo.
• Una stringa inglese hardcoded al di fuori di __() verrà visualizzata non tradotta, indipendentemente da quante lingue rilasci.

La revisione visiva della traduzione di PTC sostituisce il ciclo di QA manuale. I temi e plugin WordPress vengono renderizzati nel browser (sia wp-admin che il front end). La variante giusta è l'estensione del browser.

Installala una volta. Registra un percorso guidato del tuo tema o plugin su un sito di test. Copri le pagine delle impostazioni, le azioni di amministrazione e l'output del front end. PTC riproduce la registrazione in ogni lingua di destinazione dopo ogni aggiornamento della traduzione. Cattura ogni schermata e segnala due tipi di correzioni:

• Correzioni nei file .po quando PTC ha il controllo su di essi. PTC ritraduce un'accezione errata, sceglie un sinonimo più corto che si adatta a un pulsante o rigenera una forma plurale.
• Prompt per Cursor o Claude Code quando il problema risiede nel tuo codice PHP o JavaScript. Gli esempi includono un wrapper __() mancante, una stringa inglese hardcoded o una frase costruita per concatenazione che dovrebbe usare sprintf( __( ... ) ).

Rilasci un plugin multilingue verificato a ogni release. Il lavoro residuo di QA manuale scompare.

Prezzi: prova di 30 giorni, poi Pay-As-You-Go

La prova copre 20.000 parole in 2 lingue senza carta di credito. Al termine della prova, PTC offre il Pay-As-You-Go. Nessun abbonamento. Nessun impegno minimo. Le prime 500 parole ogni mese sono gratuite. Paghi solo per il resto. La pagina dei prezzi ha un calcolatore dei costi. Iscriviti con un'email aziendale per una prova aziendale estesa.

Pronto a rilasciare un plugin o tema verificato?

PTC genera le traduzioni ed esegue la revisione del plugin renderizzato. Tu confermi il risultato e lo rilasci. L'intero ciclo viene eseguito senza QA manuale:

1. Genera il tuo file .pot con wp i18n make-pot.
2. Caricalo su PTC e ottieni indietro i file .po, .mo, .l10n.php e .json in pochi minuti.
3. Installa l'estensione del browser per verificare il plugin in esecuzione in ogni lingua di destinazione.

Inizia la tua prova di 30 giorni: 20.000 parole offerte da noi, nessuna carta di credito richiesta.

Articoli correlati:

• Traduci file PO online con l'IA: la pagina canonica per la traduzione di PO/POT.
• GlotPress vs PTC per la traduzione di plugin/temi WordPress: quando scegliere la traduzione della community rispetto a PTC.
• Le traduzioni del plugin WordPress non vengono visualizzate? Risolvi le traduzioni mancanti: guida alla risoluzione dei problemi.
• Come importare le traduzioni di temi e plugin su WordPress.org: processo CLPTE e un'alternativa più veloce.
• Riferimento dell'API PTC: endpoint REST per l'integrazione CI.

Ultimo aggiornamento: 11 novembre 2026