FunzionalitàPluginPrezziRisorse
Cambia lingua
RisorseUn File In Entrata, Cinque Formati In Uscita: Come Proteggere le Tue Traduzioni WordPress per il Futuro

Un File In Entrata, Cinque Formati In Uscita: Come Proteggere le Tue Traduzioni WordPress per il Futuro

SimplePoTranslate Team21 marzo 2026
Un File In Entrata, Cinque Formati In Uscita: Come Proteggere le Tue Traduzioni WordPress per il Futuro

Hai passato tre settimane a tradurre il tuo tema WordPress in spagnolo. Il file .po è perfetto: ogni stringa rivista, ogni variabile intatta, ogni forma plurale corretta. Poi il tuo cliente decide di migrare da un tema PHP classico a una configurazione headless con React sul frontend.

Improvvisamente il tuo file .po è inutile. L'app React ha bisogno di .json. I widget PHP legacy hanno ancora bisogno di .mo. Il freelance che si occupa dell'app mobile vuole .xliff. E nessuno ha tempo per ritradurre 4.000 stringhe in tre formati diversi.

Questo non è un caso limite. È la realtà dello sviluppo WordPress moderno, dove i temi vengono forniti con componenti PHP e JavaScript, i plugin utilizzano un mix di Gettext e i18next e i clienti cambiano idea sull'architettura più spesso di quanto cambino le loro password.

Perché i Formati dei File di Traduzione Contano Più Che Mai

Cinque anni fa, la traduzione di WordPress era semplice. Avevi un file .po (sorgente leggibile) e un file .mo (binario compilato). Questo era tutto. Ogni tema, ogni plugin, ogni strumento di traduzione parlava la stessa lingua.

Oggi, l'ecosistema WordPress utilizza almeno cinque formati di file di traduzione in produzione:

I Cinque Formati Che Devi Conoscere

.po (Portable Object) — Il formato sorgente leggibile utilizzato da GNU Gettext. Contiene le stringhe originali (msgid) e le loro traduzioni (msgstr). Questo è ciò che i traduttori modificano.

msgid "Add to Cart"
msgstr "Anadir al carrito"

msgid "Your order has been shipped to %s"
msgstr "Su pedido ha sido enviado a %s"

.mo (Machine Object) — La versione binaria compilata di un file .po. WordPress legge i file .mo in fase di esecuzione usando load_textdomain(). Più veloce dell'analisi di .po in fase di esecuzione, ma non modificabile manualmente.

.json (JavaScript Object Notation) — Utilizzato da wp_set_script_translations() per le traduzioni basate su JavaScript nei blocchi Gutenberg, nei componenti React e nei temi moderni. WordPress si aspetta una specifica struttura JSON con chiavi locale_data.

{
  "locale_data": {
    "flavor-starter": {
      "Add to Cart": ["Anadir al carrito"],
      "Your order has been shipped to %s": ["Su pedido ha sido enviado a %s"]
    }
  }
}

.php (PHP Array) — Un formato sempre più popolare per i temi e i plugin che utilizzano il caricamento delle traduzioni in stile Laravel. Alcuni temi WordPress moderni bypassano completamente Gettext e caricano le traduzioni da array PHP per migliorare le prestazioni.

<?php
return [
    'Add to Cart' => 'Anadir al carrito',
    'Your order has been shipped to %s' => 'Su pedido ha sido enviado a %s',
];

.xliff (XML Localization Interchange File Format) — Lo standard industriale per lo scambio di traduzioni tra diversi strumenti e piattaforme. Utilizzato da strumenti CAT (Computer-Assisted Translation) come memoQ, Trados e Memsource. Essenziale quando si lavora con traduttori umani professionisti.

<trans-unit id="1">
  <source>Add to Cart</source>
  <target>Anadir al carrito</target>
</trans-unit>

Il Problema: Blocco del Formato

La maggior parte degli strumenti di traduzione produce un solo formato di output. Poedit ti dà .po e .mo. WPML memorizza le traduzioni nel database (non in file). Weglot mantiene le traduzioni sui propri server in un formato proprietario. Anche le piattaforme TMS come Crowdin e Lokalise richiedono di configurare manualmente i formati di esportazione per ogni progetto.

Questo crea il blocco del formato: le tue traduzioni sono intrappolate nel formato prodotto dal tuo strumento attuale. Quando i tuoi requisiti cambiano, hai due opzioni:

  1. Ritradurre tutto nel nuovo formato (costoso, dispendioso in termini di tempo e si perdono eventuali correzioni manuali)
  2. Scrivere script di conversione personalizzati (soggetti a errori, specialmente per forme plurali complesse e variabili)

Nessuna delle due opzioni è buona. Entrambe sprecano tempo e denaro. Entrambe introducono rischi.

Scenari Reali in Cui il Blocco del Formato Fa Male

Scenario 1: Modernizzazione del tema. Il tema del tuo cliente viene ricostruito con blocchi Gutenberg. I vecchi template PHP usavano file .mo. I nuovi blocchi hanno bisogno di .json per wp_set_script_translations(). Le tue 3.000 stringhe tradotte devono esistere in entrambi i formati durante la transizione.

Scenario 2: Workflow dell'agenzia. Gestisci 20 siti di clienti. Alcuni utilizzano temi classici (.mo). Alcuni utilizzano configurazioni headless (.json). Uno utilizza un framework personalizzato che legge array PHP. Hai bisogno delle stesse traduzioni in formati diversi per clienti diversi.

Scenario 3: Revisione professionale. Le tue traduzioni AI sono accurate al 95%, ma vuoi che un madrelingua riveda il restante 5%. I traduttori professionisti utilizzano strumenti CAT che importano .xliff. Devi esportare le tue traduzioni in .xliff, inviarle per la revisione e unire le correzioni.

Scenario 4: Migrazione della piattaforma. Il tuo cliente sta passando da WordPress a un'applicazione Node.js personalizzata. La nuova app utilizza i18next e ha bisogno di file .json. Le tue 5.000 stringhe tradotte in formato .po devono essere convertite, senza perdere una singola variabile o forma plurale.

La Soluzione: Traduci Una Volta, Ottieni Ogni Formato

SimplePoTranslate adotta un approccio diverso. Quando carichi un file .po, .pot, .json o .xliff ed esegui una traduzione, ottieni un ZIP contenente tutti e cinque i formati:

translations-es_ES.zip
├── flavor-starter-es_ES.po
├── flavor-starter-es_ES.mo
├── flavor-starter-es_ES.json
├── flavor-starter-es_ES.php
└── flavor-starter-es_ES.xliff

Questa non è una "funzionalità premium" bloccata dietro un livello enterprise. Ogni piano a pagamento, Pro (19 $/mese) e Lifetime (399 $ una tantum), include tutti e cinque i formati di output in ogni lavoro di traduzione.

Perché Questo È Importante per la Protezione Futura

Quando hai tutti e cinque i formati fin dall'inizio, non hai mai bisogno di ritradurre. Le tue traduzioni sono una risorsa che si adatta a qualsiasi requisito tecnico:

  • Il cliente migra da classico a Gutenberg? Distribuisci il file .json.
  • Il nuovo sviluppatore preferisce gli array PHP? Consegnagli il file .php.
  • Il traduttore professionista vuole rivedere? Invia il file .xliff.
  • Passaggio a un CMS diverso? I file .json e .xliff sono indipendenti dalla piattaforma.

Traduci una volta. I formati sono pronti quando ne hai bisogno.

Come Funziona Ogni Formato in WordPress

Sapere quale file va dove è essenziale per una distribuzione pulita.

Distribuzione di File .mo (Temi e Plugin PHP Classici)

wp-content/languages/plugins/woocommerce-es_ES.mo
wp-content/languages/themes/flavor-starter-es_ES.mo

WordPress li carica automaticamente quando la lingua del sito corrisponde. Nessun plugin richiesto. Zero overhead del database. Questo è l'approccio che offre le migliori prestazioni.

Distribuzione di File .json (Blocchi Gutenberg e Componenti JS)

wp-content/languages/plugins/woocommerce-es_ES-{handle}-{md5}.json

Il nome del file include l'handle dello script e un hash MD5. WordPress li associa quando chiami wp_set_script_translations() nel tuo plugin o tema. Se stai costruendo blocchi Gutenberg, questo è il file che fa apparire correttamente le etichette e le descrizioni dei tuoi blocchi tradotti.

Utilizzo di File .xliff (Workflow di Revisione Professionale)

I file .xliff non vengono distribuiti a WordPress. Vengono utilizzati come un formato di scambio quando è necessario inviare le traduzioni a un revisore professionista o importarle in uno strumento CAT. Il flusso di lavoro è simile a questo:

  1. Carica .po su SimplePoTranslate e ottieni .xliff nello ZIP
  2. Invia .xliff al tuo traduttore o revisore
  3. Ricevi .xliff corretto indietro
  4. Carica .xliff corretto su SimplePoTranslate e ottieni .mo e .json aggiornati

Questo flusso di lavoro di andata e ritorno preserva ogni variabile e forma plurale perché il Blocco della Sintassi di SimplePoTranslate li protegge in ogni fase.

Il Test del Vendor Lock-In

Ecco un semplice test per determinare se il tuo attuale flusso di lavoro di traduzione ha un problema di lock-in:

  1. Puoi esportare le tue traduzioni come file .po standard in questo momento?
  2. Se annulli oggi l'abbonamento al tuo strumento di traduzione, conservi ogni stringa tradotta?
  3. Puoi importare le tue traduzioni in uno strumento o piattaforma completamente diversa senza ritradurre?

Se la risposta a una qualsiasi di queste domande è "no", sei bloccato. Servizi come Weglot e GTranslate falliscono tutte e tre le domande: annulla l'abbonamento e le tue traduzioni svaniscono. WPML memorizza le traduzioni nel database, rendendo possibile l'esportazione ma dolorosa. Anche gli strumenti desktop come Poedit superano il test sulla carta, ma ti limitano solo a .po e .mo.

Con SimplePoTranslate, la risposta a tutte e tre le domande è "sì". Scarichi file standard in cinque formati. Sono tuoi. Elimina il tuo account domani e ogni traduzione che tu abbia mai fatto funzionerà ancora.

Costruire una Libreria di Traduzioni Agnostica dal Formato

Per le agenzie e gli sviluppatori che gestiscono più progetti, l'approccio più intelligente è quello di costruire una libreria di traduzioni: un repository Git o una cartella condivisa dove memorizzi i file tradotti per ogni progetto cliente.

translations/
├── client-acme/
│   ├── es_ES/
│   │   ├── flavor-starter-es_ES.po
│   │   ├── flavor-starter-es_ES.mo
│   │   ├── flavor-starter-es_ES.json
│   │   ├── flavor-starter-es_ES.php
│   │   └── flavor-starter-es_ES.xliff
│   └── de_DE/
│       └── ...
├── client-globex/
│   └── ...

Quando un cliente ha bisogno di un nuovo formato, lo hai già. Quando un cliente cambia piattaforma, le tue traduzioni migrano senza alcuno sforzo. Quando un nuovo sviluppatore si unisce al team, può vedere esattamente cosa è stato tradotto e in quali formati.

Questo è ciò che significa realmente "a prova di futuro": non prevedere quale tecnologia utilizzeranno i tuoi clienti il prossimo anno, ma assicurarti che le tue traduzioni funzionino con qualsiasi cosa scelgano.

Pronto a smettere di preoccuparti dei formati di file? Prova SimplePoTranslate gratuitamente: carica un file, ottieni cinque formati indietro. Nessuno script di conversione, nessuna ritraduzione, nessun lock-in.