# General Translation Knowledge Base: General Translation vs. GNU gettext: servono entrambi? URL: https://generaltranslation.com/it/kb/general-translation-vs-gettext.mdx Docs index: https://generaltranslation.com/llms.txt Description: Mantieni GNU gettext per l'estrazione e il rendering e aggiungi General Translation per generare e mantenere aggiornati i file PO. General Translation tiene conto delle note per i traduttori e del contesto dei messaggi in fase di generazione, applica una terminologia condivisa e mette a disposizione dei revisori un editor nella Dashboard. Le chiamate gettext esistenti e i cataloghi compilati restano al loro posto. Category: Internazionalizzazione Last updated: 2026-10-16 Authors: Kevin Wu, Jackie Chen Published: 2026-10-16 GNU gettext è la toolchain su cui si regge ancora gran parte della traduzione del software. Racchiudi le stringhe visibili all'utente in `_()` o `gettext()`, `xgettext` le estrae in un template POT, `msginit` crea un file PO per ogni lingua, `msgmerge` aggiorna questi file quando la sorgente cambia e `msgfmt` li compila nei file `.mo` che il programma carica a runtime. I programmi C, l'estensione gettext di PHP, il modulo `gettext` di Python, WordPress, Django e Babel usano tutti questo formato. Quello che gettext lascia a te è quasi tutto il lavoro di traduzione: dalla versione 1.0 può abbozzare le voci con un LLM locale, ma ogni `msgstr` di ogni file PO va completato da te, dai tuoi traduttori o da un servizio esterno. General Translation non sostituisce nessuna parte della toolchain: la sua CLI genera quei file PO a partire dal tuo template, così il resto della configurazione di gettext rimane invariato. ## I punti di forza di gettext * **Il testo di origine è la chiave.** Nel codice si scrive `_("Inbox")`, non il nome di una chiave, e una stringa senza traduzione [ripiega sul testo di origine](https://www.gnu.org/software/gettext/manual/html_node/Interface-to-gettext.html) anziché generare un errore. * **Regole del plurale per ogni lingua.** Ogni file PO contiene un'[intestazione `Plural-Forms` con la regola della lingua](https://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html), che `msginit` compila automaticamente. Il polacco, ad esempio, ha una regola a tre forme e tre slot `msgstr[n]` per ogni voce plurale. * **Il contesto viaggia con la stringa.** `msgctxt` (da `pgettext`) [distingue "Archive" verbo da "Archive" sostantivo](https://www.gnu.org/software/gettext/manual/html_node/Contexts.html), i commenti `#.` trasmettono note ai traduttori (`xgettext --add-comments`), le righe `#:` rimandano alla sorgente e flag come `python-format` permettono a `msgfmt --check` di rifiutare una traduzione che corrompe un segnaposto. * **Aggiornamenti sicuri.** `msgmerge` [conserva le traduzioni esistenti quando il template cambia](https://www.gnu.org/software/gettext/manual/html_node/msgmerge-Invocation.html) e contrassegna come fuzzy le voci la cui sorgente è stata modificata, mantenendo la sorgente precedente per il confronto (`--previous`). * **Bozze con LLM locali.** Dalla versione 1.0, [`msgpre` e `spit` pretraducono i file PO](https://www.gnu.org/software/gettext/manual/html_node/Pretranslating.html) con un LLM installato in locale tramite ollama, fornendo un punto di partenza che un traduttore può poi revisionare. * **Supporto ovunque.** PO è il formato letto e scritto dagli editor PO come Poedit e dalla maggior parte dei sistemi di gestione delle traduzioni (TMS), e gli strumenti sono [software libero](https://www.gnu.org/software/gettext/manual/html_node/Licenses.html) (GPL, con la libreria di runtime sotto LGPL). ## Cosa gettext lascia a carico tuo Ecco un piccolo script Python che usa il modulo `gettext` della libreria standard: ```python title="inbox.py" import gettext, sys lang = sys.argv[1] count = int(sys.argv[2]) t = gettext.translation("inbox", localedir="locale", languages=[lang], fallback=True) _ = t.gettext # TRANSLATORS: intestazione della pagina della posta in arrivo print(_("Inbox")) print(t.ngettext("You have %d unread message.", "You have %d unread messages.", count) % count) print(t.pgettext("email verb", "Archive")) ``` Il flusso di lavoro di gettext con [GNU gettext 1.0](https://lists.gnu.org/archive/html/info-gnu/2026-01/msg00007.html): ```bash xgettext --language=Python --keyword=pgettext:1c,2 --add-comments=TRANSLATORS -o po/inbox.pot inbox.py msginit --no-translator --locale=pl_PL.UTF-8 -i po/inbox.pot -o po/pl.po # qualcuno compila tutti i msgstr in po/pl.po msgfmt --check -o locale/pl/LC_MESSAGES/inbox.mo po/pl.po ``` Una volta compilato il file polacco, `python3 inbox.py pl 5` stampa "Masz 5 nieprzeczytanych wiadomości.". Poi qualcuno, nel codice, cambia "unread message" in "new message". `xgettext` e `msgmerge --update --previous` mantengono la vecchia traduzione polacca e la contrassegnano come fuzzy, perché ora traduce un testo diverso: ```text title="po/pl.po" #: inbox.py:10 #, fuzzy, python-format #| msgid "You have %d unread message." #| msgid_plural "You have %d unread messages." msgid "You have %d new message." msgid_plural "You have %d new messages." msgstr[0] "Masz %d nieprzeczytaną wiadomość." msgstr[1] "Masz %d nieprzeczytane wiadomości." msgstr[2] "Masz %d nieprzeczytanych wiadomości." ``` `msgfmt` [esclude le voci fuzzy](https://www.gnu.org/software/gettext/manual/html_node/msgfmt-Invocation.html) (segnala "2 translated messages, 1 fuzzy translation"), quindi ora lo stesso comando stampa "You have 5 new messages." in inglese, in mezzo a una schermata in polacco. La vecchia traduzione polacca dice ancora "non letti", quindi va aggiornata. General Translation può generare l'aggiornamento a partire dal nuovo template durante la build. ## Tradurre i cataloghi gettext con General Translation La CLI di General Translation legge il template POT, traduce ogni voce e genera un file PO per ciascuna lingua di destinazione. Configura `gt.config.json` in modo che punti al template e specifica dove salvare il file di ciascuna lingua. Questa config è stata verificata con `gt` 2.26.5: ```json title="gt.config.json" { "defaultLocale": "en", "locales": ["de", "pl", "pt_BR"], "customMapping": { "pt_BR": { "code": "pt-BR" } }, "files": { "pot": { "include": ["po/inbox.pot"], "transform": { "match": "^po/inbox\\.pot$", "replace": "po/{locale}.po" }, "transformationFormat": "PO" } } } ``` * **`pot` legge i file PO e POT** e, con `"transformationFormat": "PO"`, l'output è costituito da file `.po` tradotti. (Vedi il [riferimento al formato PO / POT](/docs/cli/reference/formats/po-pot-files).) * **`transform` definisce il nome dell'output.** `{locale}` corrisponde all'impostazione regionale esattamente come scritta in `locales`, quindi otterrai `po/pl.po` e `po/pt_BR.po`. (Vedi [`transform`](/docs/cli/reference/config#files).) * **Mantieni i nomi delle impostazioni regionali di gettext.** [`customMapping`](/docs/cli/reference/config#custom-mapping) associa `pt_BR` al codice locale standard `pt-BR`. Lo stesso pattern si applica ad altre strutture, come `languages/my-plugin.pot` e `languages/my-plugin-de_DE.po` di un plugin WordPress. Una volta configurata la CLI (vedi l'[Avvio rapido della CLI](/docs/cli/quickstart)), il flusso di lavoro diventa: ```bash xgettext --language=Python --keyword=pgettext:1c,2 --add-comments=TRANSLATORS -o po/inbox.pot inbox.py msgconv --to-code=UTF-8 -o po/inbox.pot po/inbox.pot npx gt translate msgfmt --check -o locale/pl/LC_MESSAGES/inbox.mo po/pl.po ``` `xgettext` lascia `charset=CHARSET` come segnaposto nell'intestazione del template e `msgconv` lo imposta su UTF-8, come farebbe `msginit` per un file di lingua. [`npx gt translate`](/docs/cli/reference/commands/translate) invia ogni voce accompagnata, come contesto, da tutto ciò che il file PO sa su di essa: il `msgctxt`, i commenti per i traduttori `#.`, i riferimenti `#:` e i flag di formato. Per una voce plurale, General Translation scrive l'intestazione `Plural-Forms` della lingua di destinazione, compila tutti gli slot `msgstr[n]` previsti dall'intestazione (tre per il polacco, sei per l'arabo) e verifica che i segnaposto come `%d` restino intatti. Quando un `msgid` cambia, General Translation genera una traduzione del nuovo testo all'esecuzione successiva, mentre le voci invariate riutilizzano le traduzioni precedenti. Importa le traduzioni PO esistenti con [`npx gt upload`](/docs/cli/reference/commands/upload) prima della prima esecuzione di generazione. Le modifiche apportate in seguito in un editor PO locale possono essere salvate sulla piattaforma con [`npx gt save-local`](/docs/cli/reference/commands/save-local) prima di generare di nuovo. Oltre alla compilazione di `msgstr`, General Translation offre tutto il resto dello stack. Un Glossario e i Prompt personalizzati in un [Gruppo di contesto](/docs/platform/dashboard/guides/defining-context-for-translations) mantengono coerenti terminologia e tono nei file PO e in ogni altra area del prodotto che traduci; i revisori possono [controllare e modificare](/docs/platform/dashboard/guides/reviewing-translations) ogni voce PO nella Dashboard, con le forme plurali della lingua di destinazione; infine, la CLI viene eseguita in CI, così ogni rilascio viene distribuito con cataloghi aggiornati. Esegui la CLI Node.js durante la build, poi compila l'output PO con `msgfmt`. La tua applicazione continuerà a caricare localmente le traduzioni compilate. ## GNU gettext e General Translation a confronto | Funzionalità | GNU gettext | General Translation | | ------------------------------------------ | ---------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | Estrae le stringhe dal codice | Sì, `xgettext` | Legge il template POT esistente | | Crea un file per ogni lingua | Sì, `msginit` | Sì, dal template, per ogni impostazione regionale configurata | | Scrive le traduzioni | Dalla versione 1.0 genera bozze con un LLM locale, che un traduttore deve poi completare | Sì, con [`npx gt translate`](/docs/cli/reference/commands/translate) | | Quando cambia una stringa di origine | `msgmerge` la contrassegna come fuzzy finché qualcuno non la revisiona | Viene ritradotta all'esecuzione successiva; le voci invariate vengono riutilizzate | | Forme plurali | `msginit` scrive l'intestazione; sei tu a compilare ogni slot | Scrive l'intestazione e compila tutti gli slot | | Contesto per la traduzione | `msgctxt`, commenti per i traduttori, riferimenti, flag | Gli stessi, più Glossario e prompt personalizzati | | Compila e recupera le traduzioni a runtime | Sì, `msgfmt` e il runtime di gettext | Mantiene il compilatore e il runtime di gettext che già usi | | Costo | Software libero | [Traduzione a consumo](https://generaltranslation.com/pricing) | ## Quando usare l'uno o l'altro Usa gettext da solo se i tuoi file PO vengono già compilati da traduttori o da un TMS, se ogni traduzione deve essere scritta da una persona prima del rilascio, oppure se la tua build non può eseguire Node.js. Aggiungi General Translation se vuoi che ogni file PO venga tradotto in tutte le lingue non appena il template cambia, con tutte le forme plurali compilate e una terminologia coerente ovunque, senza dover attendere un ciclo di traduzione. Non c'è nulla da migrare: General Translation mantiene le tue chiamate `_()`, il tuo template, i tuoi file PO e il tuo runtime. Sostituisce semplicemente il passaggio manuale tra `msgmerge` e `msgfmt`. (Per configurazioni specifiche di un framework, consulta [General Translation vs. Django's translation framework](/kb/general-translation-vs-django-i18n) e [General Translation vs. Babel and Flask-Babel](/kb/general-translation-vs-flask-babel).) ## Punti chiave * GNU gettext estrae, unisce, compila e recupera le traduzioni e, dalla versione 1.0, può generarne una bozza con un LLM locale, ma non le porta a termine. Le stringhe nuove e modificate compaiono nella lingua di origine finché qualcuno non le traduce o non le revisiona. * La CLI di General Translation traduce un template POT in un file PO per ciascuna lingua, tramite la chiave `pot`, `"transformationFormat": "PO"`, un `transform` per il percorso di output e `customMapping` per nomi come `pt_BR`. * Per ogni voce plurale, General Translation scrive l'intestazione `Plural-Forms` della lingua di destinazione e tutti gli slot `msgstr[n]`, usando `msgctxt` e i commenti per i traduttori come contesto. `msgfmt` e il runtime gettext restano al loro posto. ## Related questions - [General Translation e il framework di traduzione di Django: servono entrambi?](https://generaltranslation.com/it/kb/general-translation-vs-django-i18n.mdx): Usa insieme il framework di traduzione di Django e General Translation. Django si occupa dell'estrazione dei messaggi, della selezione della lingua e del rendering. General Translation compila i suoi file PO, forme plurali comprese, con la terminologia del tuo prodotto e la revisione nella Dashboard. I tuoi template e i modelli di URL restano invariati, mentre le traduzioni si aggiornano di pari passo con il codice. - [General Translation, Babel e Flask-Babel a confronto: quale scegliere?](https://generaltranslation.com/it/kb/general-translation-vs-flask-babel.mdx): Babel formatta date, numeri e valute per qualsiasi impostazione regionale e gestisce i cataloghi gettext, mentre Flask-Babel lo integra con Flask, ma nessuno dei due traduce le tue stringhe. La CLI di General Translation popola i file PO di Babel per ogni lingua, forme plurali incluse, così puoi continuare a usare Flask-Babel e smettere di tradurre i cataloghi a mano. - [Perché usare General Translation invece di un TMS (Smartling, Lokalise, Phrase, Crowdin o Transifex)?](https://generaltranslation.com/it/kb/general-translation-vs-tms.mdx): Un sistema di gestione delle traduzioni (TMS) come Smartling, Lokalise, Phrase, Crowdin o Transifex coordina i traduttori, ma gli sviluppatori devono comunque estrarre le stringhe, inviarle, attendere le traduzioni e reintegrarle nel prodotto. General Translation traduce i contenuti direttamente nel tuo codice insieme al loro contesto, distribuisce tutte le lingue a ogni rilascio e si basa su librerie open source, senza vendor lock-in. - [General Translation vs. Weblate: quale scegliere?](https://generaltranslation.com/it/kb/general-translation-vs-weblate.mdx): Weblate è una piattaforma di localizzazione self-hostable basata su Git, pensata per tradurre i file di un repository insieme a una community o a un team. General Translation integra la generazione delle traduzioni nello sviluppo e nei rilasci, sfruttando JSX contrassegnato e un contesto di prodotto condiviso. Puoi mantenere i tuoi file gettext oppure adottare la scrittura inline per eliminare anche la manutenzione del catalogo di origine. - [Qual è il miglior software di localizzazione per gli sviluppatori?](https://generaltranslation.com/it/kb/best-localization-software.mdx): Cerca un unico sistema che copra l'intera pipeline, dalla libreria i18n nel tuo codice fino alla traduzione e alla consegna, invece di mettere insieme una libreria, un sistema di gestione delle traduzioni e un fornitore di traduzioni separati. ## Previous and next questions - Previous question: [General Translation o Symfony Translation: quale scegliere?](https://generaltranslation.com/it/kb/general-translation-vs-symfony-translation.mdx) - Next question: [General Translation vs. i18n-tasks: quale scegliere?](https://generaltranslation.com/it/kb/general-translation-vs-i18n-tasks.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/it/kb/sitemap.md) for every article.