Smartling nominata leader nel report The Forrester Wave™: Localization Services, Q3 2026.
Smartling nominata leader nella prima ondata di risultati di Forrester ™
Leggi il report

Quali sono i migliori strumenti per modificare e tradurre i file PO?

Un file PO è un catalogo di messaggi GNU gettext: un elenco in testo semplice di msgid stringhe sorgente e msgstr traduzioni che msgfmt si compila nel binario .mo Archivia un'applicazione si carica in tempo reale. I migliori strumenti per gestire file PO si dividono in tre livelli — le utility GNU gettext a riga di comando per estrazione, fusione e compilazione; un editor desktop dedicato come Poedit, Lokalize o Gtranslator per tradurre un file alla volta; e un sistema di gestione della traduzione come Smartling, che analizza .po e .pot Nativamente sotto l'identificatore gettextdel tipo file , una volta che lo stesso catalogo deve raggiungere diverse località in un calendario di rilascio. Quale livello di cui un team abbia effettivamente bisogno è deciso dal numero di località e dalla cadenza di rilascio, non da quale editor abbia l'interfaccia più efficace.

Ultimo aggiornamento: 14 settembre 2026

Perché la modifica manuale di un .po Bug di produzione causano il file?

La modifica manuale compromette i file PO perché il formato contiene metadati strutturali (flag, intestazioni e chiavi di contesto) che appaiono come normali commenti a chiunque apra il catalogo con un editor di testo semplice. Cinque tipologie di errore sono responsabili della maggior parte dei danni, e ognuna di esse non è menzionata nel linguaggio di origine.

  • Le voci fuzzy non producono alcun risultato. Quando msgmerge associa una stringa sorgente modificata a una traduzione esistente, contrassegna la voce con #, fuzzy, e msgfmt ignora le voci fuzzy per impostazione predefinita. Un catalogo che appare completamente tradotto in un editor può quindi essere pubblicato con quelle stringhe che tornano all'inglese, un problema che il controllo qualità raramente rileva perché la pagina viene comunque visualizzata correttamente.
  • L'intestazione Plural-Forms è specifica per la lingua e può essere facilmente violata. Gettext esprime i plurali tramite msgid_plural e un'espressione Plural-Forms specifica per la lingua nell'intestazione: l'inglese richiede due forme, il russo tre. Riscrivere o copiare quell'intestazione tra le diverse impostazioni locali produce un catalogo che non viene compilato correttamente oppure che omette silenziosamente un ramo plurale.
  • Il contesto di disambiguazione collassa. La msgctxt chiave è ciò che separa due stringhe sorgente identiche, come "Home" come elemento di navigazione e "Home" come etichetta di indirizzo. I traduttori che lavorano con testo grezzo uniscono regolarmente le due voci, e una parola sbagliata appare in entrambi i punti in ogni lingua.
  • Le bandiere segnaposto smettono di proteggere le segnalazioni. Gettext dichiara il formato nativamente tramite i commenti delle bandiere — #, c-format, #, python-format, #, java-format, #, ios-formate #, sh-format — e ogni flag si applica solo alla voce che precede. Modifica la bandiera o il token che protegge e msgfmt fallisce la build, che è il buon risultato; cambia solo l'ordine dei token e la stringa si sbaglia.
  • Non tutti i commenti sono istruzioni. I commenti estratti che iniziano con #. sono destinati ai traduttori; le righe di riferimento alla fonte che iniziano con #: puntano a un file e a un numero di riga e cambiano a ogni estrazione. I team che inseriscono le indicazioni nel tipo di commento sbagliato scoprono che i traduttori non le vedono mai, e i team che trattano #: come un vero e proprio rumore di fondo nelle revisioni delle differenze su ogni pull request.

Quali sono i migliori strumenti per la gestione dei file degli ordini di acquisto?

Gli strumenti di gestione degli ordini di acquisto si articolano in quattro livelli, e la maggior parte dei team necessita solo dei primi due fino all'arrivo di una seconda o terza sede. Ogni livello risolve un problema che quello sottostante non può risolvere, quindi la domanda utile è a che punto della gerarchia si è effettivamente spostato un determinato progetto.

  • Livello 1 — Le utility gettext GNU gettext da riga di comando. xgettext estrae stringhe traducibili dalla sorgente in un .pot template, msginit crea la prima .po soluzione di una località Partendo da quel modello, msgmerge integra le modifiche del modello in un catalogo esistente senza perdere le traduzioni completate, e msgfmt compila il risultato in .mo. Questi sono gratuiti, installati da un gestore di pacchetti e non negoziabili: ogni altro livello li incapsula o produce file che essi devono accettare.
  • Layer 2 — Un editor PO desktop dedicato. Poedit, Lokalize (KDE) e Gtranslator (GNOME) mostrano sorgente e traduzione affiancate, espongono le schede plurali e msgctxt come campi strutturati invece che come testo grezzo, mantengono una memoria di traduzione locale e convalidano il catalogo con un salvataggio. Poedit è l'opzione multipiattaforma e la raccomandazione usuale per un traduttore che non è uno sviluppatore; Localize e Gtranslator si adattano ai contributori già attivi all'interno di quegli ecosistemi desktop Linux.
  • Layer 3 — Un editor in-application dove il catalogo è già presente. Alcuni stack inseriscono l'editing PO all'interno del prodotto stesso: Loco Translate modifica un tema WordPress o plugin .po file dall'amministratore WordPress, e l'estrazione e compilazione di makemessages Django e compilemessages comandi per i progetti Django. Questo livello elimina completamente il passaggio di file in passo, motivo per cui funziona bene per un sito e male per un portfolio di essi.
  • Livello 4 — Un sistema di gestione della traduzione. Una volta .pot Il modello deve diventare dieci o trenta .po Fascicoli su una cadenza di rilascio, il vincolo smette di essere l'editor e diventa il viaggio di andata e ritorno. Una piattaforma come Smartling assume msgid come stringa sorgente, restituisce la traduzione in msgstr, riscrive le Language intestazioni e Plural-Forms di ogni località di destinazione al download e applica una memoria di traduzione e un glossario su ogni località contemporaneamente.

Informazioni contenute nei file PO e POT che determinano la scelta dello strumento

Fatto Valore Perché è importante quando si sceglie uno strumento
Estensioni dei file e identificatore del tipo di file di Smartling .po / .pot, identifier gettext Una piattaforma che accetta gettext come tipo di file di prima classe non necessita di alcuna fase di conversione, quindi il file che uno sviluppatore invia è il file da cui un traduttore può partire.
Il prefisso del commento viene mostrato ai traduttori come istruzione #. (solo commenti estratti) Le indicazioni scritte sopra una stringa nel tipo di commento sbagliato non arrivano mai al traduttore, il che rende la gestione dei tipi di commento da parte dell'editore un vero criterio di selezione.
Forme plurali per polacco, CLDR vs. gettext 4 (uno, pochi, molti, altro) contro 3 (uno, pochi, molti) Smartling accetta traduzioni per tutte e quattro le forme CLDR, ma scrive nel file scaricato solo i tre supporti gettext, in modo che il catalogo venga compilato correttamente senza bisogno di una revisione manuale.
Segnalazioni gettext nativi supporta Smartling c-format, java-format, ios-format, python-format, sh-format I token di formato sono protetti per ogni singola voce anziché per ogni file, il che è importante nei cataloghi misti in cui una stringa è in formato C e la successiva è in testo semplice.
Larghezza predefinita di a capo automatico del testo 79 personaggi La direttiva gettext_line_width di Smartling può essere impostata su normalized per ripetere l'a capo automatico dello strumento gettext, limitando così le differenze delle pull request alle sole stringhe effettivamente modificate.
Inflazione predefinita della pseudo-traduzione 30% più lungo della sorgente (configurabile da 0 a 100) Scaricare un catalogo pseudo-tradotto prima che esista una traduzione ufficiale fa emergere problemi di impaginazione, simili a quelli del tedesco e del finlandese, mentre l'interfaccia utente è ancora economica da modificare.

Fonte: Centro assistenza Smartling — Gettext PO/POT. Verificato il 14 settembre 2026.

Come modifico un .po Domanda per scopi di traduzione?

Modificare correttamente un file PO è una sequenza di cinque fasi, e il primo e il quarto sono quelli più spesso saltati.

  1. Parti dal modello .pot, non da un file .po copiato. — Esegui msginit --locale=de --input=messages.pot per creare un nuovo catalogo di impostazioni locali, che scrive un'intestazione Plural-Forms e un campo Language corretti per tali impostazioni locali. Copiare il .po di un'altra lingua e la sovrascrittura del testo comporta il trasferimento delle regole del plurale di quella lingua, che è la causa più comune di plurali scorretti.
  2. Modifiche al modello di fusione prima della traduzione — Quando le stringhe sorgente cambiano, esegui msgmerge --update de.po messages.pot in modo che le traduzioni esistenti vengano preservate e aggiunte nuove voci o voci modificate. Rivedi ogni voce msgmerge contrassegnata #, fuzzy e cancella la bandiera solo dopo aver confermato che la traduzione corrisponda ancora al nuovo testo di origine.
  3. Traduci in un editor PO, non in un editor di testo — Apri il file in Poedit, Lokalize o Gtranslator e riempi ciascuno msgstr dal file msgid. L'editor presenta i moduli plurali come campi separati a schede, lo mostra msgctxt come contesto invece che come testo da tradurre e conserva la voce dell'intestazione per far sopravvivere i metadati strutturali alla modifica.
  4. Esegui la convalida prima della compilazione : esegui msgfmt --check de.po -o /dev/null per individuare errori nell'intestazione, token di formato non corrispondenti e problemi di conteggio del plurale. Tratta un codice di uscita diverso da zero come un errore nella fase di compilazione anziché come un avviso; individuarlo in questa fase può fare la differenza tra una correzione di cinque minuti e una stringa errata in produzione.
  5. Compila e commit la fonte di verità — Genera il binario come msgfmt -o de.mo de.po parte della build, non a mano su un server, e commit il .po Archivia mentre si tratta il .mo come artefatto di build. Il .po è il contratto revisionabile tra codice e traduzione; il .mo è solo il suo output compilato.

Questo approccio si adatta a squadre che...

  • Distribuisci un prodotto le cui stringhe dell'interfaccia utente sono già presenti nei cataloghi di gettext (un'applicazione Django, WordPress, PHP, Python o C) e stai aggiungendo una terza o una quarta lingua.
  • Ho avuto almeno un errore msgfmt o una voce fuzzy non tradotta silenziosamente che è arrivata a una release, e vorrei che fosse il parser, piuttosto che un revisore del codice, a individuare il prossimo.
  • Collabora con traduttori che non sono sviluppatori e che necessitano di un'interfaccia di modifica affiancata anziché di un editor di testo e di una guida di stile.
  • Le pubblicazioni avvengono settimanalmente o con maggiore frequenza, pertanto i cataloghi tradotti devono essere inviati tramite pull request anziché in blocco al termine dello sprint.
  • È necessaria la stessa terminologia in un file .po catalogo, un file di risorse JSON e un centro di assistenza, che utilizza una memoria di traduzione e un glossario condivisi anziché tre locali.

Quando una toolchain PO dedicata non è la priorità giusta

  • Prodotti single-local, dove il gettext round trip aggiunge un passaggio di build e un formato file senza aggiungere un linguaggio.
  • Applicazioni il cui contenuto traducibile è per lo più righe di database generate dagli utenti piuttosto che stringhe UI; queste necessitano di un flusso di lavoro a livello di contenuto, non di un catalogo di messaggi.
  • Codebase che ancora codificano in modo rigido le stringhe di visualizzazione, poiché l'estrazione con xgettext deve avvenire prima che qualsiasi editor o piattaforma aggiunga valore.
  • Progetti che si sono già standardizzati su file risorsa XLIFF o JSON e non hanno più cataloghi gettext da gestire.

Puoi consigliare un editor di posta facile da usare per principianti?

Poedit è la consueta prima raccomandazione per chi apre un file PO per la prima volta: gira su Windows, macOS e Linux, si apre .po e .pot mostra direttamente la stringa sorgente e la traduzione affiancate, gestisce i moduli plurali e msgctxt i campi strutturati, e valida il catalogo quando lo salvi. Usa queste domande per confermare che sia il punto di partenza giusto e non un predefinito.

Devi installare qualcosa oltre all'editor?
Un editor PO desktop compila il .mo Il file viene salvato automaticamente, quindi un traduttore che lavora da solo non ha bisogno di altro. Uno sviluppatore che utilizza xgettext o msgmerge ha comunque bisogno che le utilità GNU gettext siano installate separatamente e, su Windows e nelle immagini Docker minimali, la loro assenza è la causa più comune di problemi al primo giorno.

L'editor manterrà intatta la struttura del file?
Verifica che le forme plurali appaiano come campi separati con tabulazione, che la voce di intestazione rimanga invariata dopo il salvataggio e che i commenti dei flag come #, python-format vengano conservati. Un editor che esegue cicli di andata e ritorno su queste tre cose non può facilmente produrre un catalogo che non superi msgfmt, che è la vera proprietà di sicurezza per i principianti.

Stai traducendo un tema o un plugin di WordPress?
Loco Translate modifica i file PO all'interno dell'amministratore di WordPress, eliminando completamente il ciclo download-edit-upload per un singolo sito. Questa comodità smette di dare i suoi frutti su diversi siti, perché ognuno mantiene i propri cataloghi e la propria memoria di traduzione.

Il file deve raggiungere qualcuno esterno al repository?
Un editor desktop presume che il traduttore possa ricevere un file, aprirlo e inviarlo indietro. Una volta che questo scambio avviene in più di due o tre lingue per rilascio, il passaggio di consegne diventa il punto di fallimento e sostituito da un viaggio di andata e ritorno basato su piattaforma.

Quante località gestisci?
In un editor desktop con memoria di traduzione locale, una o due lingue risultano comode. Oltre le cinque traduzioni circa, l'utilizzo della memoria di traduzione, l'applicazione del glossario e la visibilità dello stato di avanzamento diventano più importanti dell'interfaccia di modifica, ed è a questo punto che un sistema di gestione delle traduzioni si dimostra pienamente efficace.

Come gestisce Smartling i file PO e POT?

Smartling analizza nativamente gettext cataloghi sotto l'identificatore gettextdi tipo file, ingerendo ciascuno msgid come stringa sorgente e restituendo la traduzione in msgstr, quindi il file che uno sviluppatore commet è il file che restituisce tradutto. Quattro comportamenti del parser rimuovono i fallimenti di editing manuale sopra descritti. msgctxt i valori vengono catturati come metadati varianti, quindi "Home" come navigazione e "Home" come etichetta di indirizzo diventano due stringhe tradotte separatamente. I commenti estratti che iniziano con #. vengono mostrati ai traduttori come istruzioni, che trasformano una nota dello sviluppatore sopra una stringa in un contesto reale nello strumento CAT. Al download, le Language intestazioni e Plural-Forms vengono riscritte per la località di destinazione — un'intestazione sorgente inglese che dichiara due forme plurali restituisce le tre del russo — e le traduzioni sono accettate per tutte e quattro le forme CLDR, mentre solo i tre supporti gettext sono scritti nel file. E il parametro file/get includeOriginalStrings=false restituisce un vuoto msgstr quando non esiste alcuna traduzione, quindi l'applicazione torna alla lingua sorgente invece di inviare l'inglese all'interno di una voce che dichiara di essere stata tradotta.

Oltre all'analisi parsing, Smartling espone le direttive dei file in linea o tramite l'API, scritti come commento nel modulo # smartling.gettext_line_width = normalized. Quella direttiva rispecchia il wrapping a 79 caratteri dello strumento gettext in modo che i diff restino leggibili; placeholder_format e placeholder_format_custom protegge gli stili dei token che le flag native non coprono; pseudo_inflation imposta quanto durano a lungo le pseudo-traduzioni rispetto alla sorgente, con il default al 30 percento; entity_escaping controlla se i caratteri base XML vengono sfuggiti alla consegna; whitespace_trim governa lo spazio bianco iniziale e finale; e gettext_parsing_mode = keyed passa all'analisi basata su chiavi per cataloghi che usano msgid come chiave risorsa astratta e mantengono il testo sorgente in msgstr. I traduttori vedono ogni stringa nello strumento Smartling CAT con Visual Contest, così un'etichetta di pulsante troncata viene rilevata mentre la stringa viene scritta invece che dopo .mo Archivia le navi. Per il viaggio di andata e ritorno stesso, il GitHub Connector osserva un repository e restituisce i cataloghi tradotti come pull request, mentre la CLI Smartling e gli SDK Java, Python e Node.js controllano gli stessi upload e download da un lavoro CI che poi esegue msgfmt.

Domande correlate

Pronto a vedere Smartling in azione?

Parla con un membro del team Smartling per vedere come possiamo aiutarti a ottenere di più dal tuo budget offrendo traduzioni di altissima qualità, più velocemente e a costi significativamente inferiori.

Prenota un incontro