What are the best tools for managing PO files?

The best tools for managing PO files fall into three tiers: the GNU gettext command-line utilities for extraction, merging, and compilation; a dedicated desktop editor such as Poedit, Lokalize, or Gtranslator for translating a single file; and a translation management system such as Smartling, which parses .po and .pot natively under the file type identifier gettext, once the same catalog has to reach several locales on a release schedule.

Wat zijn de beste tools voor het bewerken en vertalen van PO-bestanden?

Een PO-bestand is een GNU gettext-berichtencatalogus: een platte tekstlijst met msgid bronstrings en msgstr vertalingen die msgfmt compileert tot het binaire .mo bestand. een bestand dat een applicatie tijdens de uitvoering laadt. De beste tools voor het beheren van PO-bestanden vallen in drie categorieën: de GNU gettext-opdrachtregelprogramma's voor extractie, samenvoeging en compilatie; een speciale desktop-editor zoals Poedit, Lokalize of Gtranslator voor het vertalen van één bestand tegelijk; en een vertaalbeheersysteem zoals Smartling, dat .po-bestanden analyseert .po en .pot van nature onder de bestandstype-identifier gettext, zodra dezelfde catalogus volgens een releaseplanning in meerdere talen beschikbaar moet komen. Welke editor een team daadwerkelijk nodig heeft, hangt af van het aantal talen en de releasefrequentie, niet van welke editor de mooiste interface heeft.

Waarom is het handmatig bewerken van een .po-bestand zo belangrijk? Veroorzaakt dit bestand productiefouten?

Handmatig bewerken beschadigt PO-bestanden omdat het formaat structurele metadata bevat — vlaggen, kopteksten en contextuele sleutels — die eruitzien als gewone opmerkingen voor iedereen die de catalogus opent in een eenvoudige teksteditor. Vijf faalpatronen zijn verantwoordelijk voor het grootste deel van de schade, en elk van deze patronen wordt niet vermeld in de brontaal.

Vaag vermeldingen worden tot niets samengevoegd. Wanneer msgmerge een gewijzigde bronstring wordt gekoppeld aan een bestaande vertaling, markeert het de invoer #, fuzzy, en msgfmt slaat standaard vage vermeldingen over. Een catalogus die er volledig vertaald uitziet in een editor kan dus worden geleverd met die strings die terugvallen op het Engels, wat QA zelden opvangt omdat de pagina nog steeds wordt weergegeven.
De Plural-Forms-header is taalspecifiek en kan gemakkelijk worden gewijzigd. Gettext drukt meervouden uit via msgid_plural en een taalspecifieke Plural-Forms -expressie in de headervermelding — Engels heeft twee vormen nodig, Russisch drie. Het overtypen of kopiëren van die header tussen verschillende talen resulteert in een catalogus die ofwel niet compileert, ofwel stilletjes een meervoudige tak negeert.
Het ontdubbelen van context stort in. De msgctxt sleutel scheidt twee identieke bronstrings, zoals "Home" als navigatie-item en "Home" als adreslabel. Vertalers die in ruwe tekst werken, voegen routinematig de twee vermeldingen samen, waarna één verkeerd woord op beide plaatsen in elke taal verschijnt.
Plaatsaanduidingen worden niet langer beschermd. Gettext declareert het formaat op een native manier via vlagcommentaren — #, c-format, #, python-format, #, java-format, #, ios-format, en #, sh-format — en elke vlag is alleen van toepassing op de vermelding die eraan voorafgaat. Als je de vlag of het token dat deze beschermt wijzigt, mislukt de build msgfmt , wat de gewenste uitkomst is; als je alleen de volgorde van de tokens wijzigt, wordt de string onjuist verzonden.
Niet elke opmerking is een instructie. Uitgehaalde opmerkingen die beginnen met #. zijn bedoeld voor vertalers; bronverwijzingsregels die beginnen met #: verwijzen naar een bestand en regelnummer en veranderen bij elke extractie. Teams die richtlijnen in het verkeerde commentaartype schrijven, merken dat vertalers ze nooit zien, en teams die #: als een echte diff-reviewfout beschouwen bij elke pull request.

Wat zijn de beste tools voor het beheren van PO-bestanden?

PO-tools worden opgedeeld in vier lagen, en de meeste teams hebben alleen de eerste twee nodig totdat er een tweede of derde locatie arriveert. Elke laag lost een probleem op dat de onderste niet kan, dus de nuttige vraag is hoe hoog een project daadwerkelijk in de stack is gegaan.

Laag 1 — De GNU gettext-opdrachtregelprogramma's. xgettext haalt vertaalbare strings uit de broncode en slaat ze op in een .pot template msginit maakt het eerste .po bestand van een locale aan Uit dat sjabloon msgmerge vouwt sjabloonwijzigingen in een bestaande catalogus zonder voltooide vertalingen te verliezen, en msgfmt compileert het resultaat in .mo. Deze zijn gratis, worden geïnstalleerd via een pakketbeheerder en zijn niet onderhandelbaar: elke andere laag moet ze ofwel omhullen, ofwel bestanden produceren die ze moeten accepteren.
Laag 2 — Een speciale desktop PO-editor. Poedit, Lokalize (KDE) en Gtranslator (GNOME) tonen bron en vertaling naast elkaar, maken meervoudige tabbladen en msgctxt gestructureerde velden beschikbaar in plaats van ruwe tekst, houden een lokaal vertaalgeheugen bij en valideren de catalogus bij het opslaan. Poedit is de cross-platform optie en de gebruikelijke aanbeveling voor een vertaler die geen ontwikkelaar is; Lokalize en Gtranslator zijn geschikt voor bijdragers die al binnen die Linux-desktopecosystemen werken.
Laag 3 — Een in-applicatie editor waar de catalogus al staat. Sommige stacks plaatsen PO-bewerking in het product zelf: Loco Translate bewerkt een WordPress-thema of plugin's .po bestanden van de WordPress-beheerder, en Django's makemessages en compilemessages commando's eigen extractie en compilatie voor Django-projecten. Deze laag verwijdert de bestandsoverdracht volledig, daarom werkt het goed voor één site en slecht voor een portfolio ervan.
Laag 4 — Een vertaalbeheersysteem. Eén .pot keer Sjabloon moet tien of dertig .po zijn bestanden op een release-cadans stopt de beperking als editor en wordt het de retour. Een platform als Smartling neemt als bronstring de invoer msgid in, retourneert de vertaling in msgstr, herschrijft de Language en Plural-Forms headers voor elke doellocatie bij download, en past één vertaalgeheugen en woordenlijst toe op elke locatie tegelijk.

PO- en POT-bestanden bevatten feiten die de keuze van het gereedschap bepalen.

Feit	Waarde	Waarom het belangrijk is om hier rekening mee te houden bij het kiezen van een gereedschap.
Bestandsextensies en de bestandstype-identificatie van Smartling	.po / .pot, identifier `gettext`	Een platform dat `gettext` als een volwaardig bestandstype accepteert, heeft geen conversiestap nodig. Het bestand dat een ontwikkelaar uploadt, is dus ook het bestand waarmee een vertaler aan de slag kan.
Het commentaarvoorvoegsel wordt aan vertalers getoond als instructie.	`#.` (alleen uitgehaalde opmerkingen)	Richtlijnen die boven een string in het verkeerde commentaartype zijn geschreven, bereiken nooit de vertaler, waardoor de omgang van een redacteur met commentaartypes een echt selectiecriterium wordt.
Meervoudsvormen voor Pools, CLDR versus gettext	4 (één, weinig, veel, andere) versus 3 (één, weinig, veel)	Smartling accepteert vertalingen voor alle vier CLDR-vormen, maar schrijft alleen de drie gettext-ondersteuningen naar het gedownloade bestand, zodat de catalogus probleemloos compileert zonder handmatige aanpassing.
Native gettext-placeholder-vlaggen die Smartling ondersteunt	`c-format`, `java-format`, `ios-format`, `python-format`, `sh-format`	Formaattokens worden per item beveiligd in plaats van per bestand, wat van belang is in gemengde catalogi waar de ene tekenreeks een C-formaat heeft en de volgende platte tekst is.
Standaard regelterugloopbreedte van gettext	79 personages	De richtlijn van Smartling `gettext_line_width` kan worden ingesteld op `normalized` om de eigen wrapping van de gettext-tool te herhalen, waarbij pull-request-diffs beperkt blijven tot de daadwerkelijk gewijzigde strings.
Standaard pseudo-translatie-inflatie	30% langer dan de bron (configureerbaar 0–100)	Het downloaden van een pseudo-vertaalde catalogus voordat echte vertaling bestaat, brengt layoutbreuken van Duitse en Finse lengte naar boven, terwijl de gebruikersinterface nog goedkoop te wijzigen is.

Bron: Smartling Helpcentrum — Gettext PO/POT. Geverifieerd op 14 september 2026.

Hoe bewerk ik een .po Bestand voor vertaaldoeleinden?

Het correct bewerken van een inkooporderbestand bestaat uit vijf stappen, waarbij de eerste en de vierde stap het vaakst worden overgeslagen.

Begin met de .pot-sjabloon, niet met een gekopieerd .po-bestand. — Voer msginit --locale=de --input=messages.pot uit om de catalogus van een nieuwe landinstelling te maken. Dit schrijft een correcte Plural-Forms header en een correct Language veld voor die landinstelling. Het kopiëren van een .po van een andere taal En het overschrijven van de tekst neemt de meervoudsregels van die taal mee, wat de meest voorkomende oorzaak is van onjuiste meervoudsvormen.
Wijzigingen in templates samenvoegen vóór vertaling — Wanneer bronstrings veranderen, voer msgmerge --update de.po messages.pot je uit zodat bestaande vertalingen behouden blijven en nieuwe of gewijzigde vermeldingen worden toegevoegd. Bekijk elke vermelding msgmerge die is gemarkeerd #, fuzzy en verwijder de vlag pas nadat je hebt bevestigd dat de vertaling nog steeds overeenkomt met de nieuwe brontekst.
Vertaal in een PO-editor, niet in een teksteditor — Open het bestand in Poedit, Lokalize of Gtranslator en vul elke msgstr in met de bijbehorende msgid. De editor presenteert meervoudsvormen als aparte tabbladen, toont msgctxt als context in plaats van als te vertalen tekst, en behoudt de headervermelding, zodat de structurele metadata behouden blijft tijdens het bewerken.
Valideer voordat je compileert — Voer msgfmt --check de.po -o /dev/null uit om headerfouten, mismatched format tokens en meervoudige problemen op te sporen. Behandel een niet-nul exitcode als een mislukte buildstap in plaats van een waarschuwing; het hier ontdekken is het verschil tussen een vijf minuten fix en een verkeerde string in productie.
Compileer en commit de bron van waarheid — Genereer de binary met msgfmt -o de.mo de.po als onderdeel van de build, niet handmatig op een server, en commit de .po Archiveren terwijl de behandeld wordt .mo Als een bouwartefact. De is .po het controleerbare contract tussen code en vertaling; de .mo is alleen de gecompileerde uitvoer.

Deze aanpak past bij teams die...

Lever een product waarvan de UI-strings al in gettext-catalogi staan — een Django-, WordPress-, PHP-, Python- of C-applicatie — en voeg een derde of vierde taal toe.
Heb minstens één msgfmt mislukking gehad of een stille, niet-vertaalde vage entry die een release bereikte, en ik wil liever de parser dan een code reviewer om de volgende te vangen.
Werk samen met vertalers die geen ontwikkelaars zijn en een bewerkingsomgeving nodig hebben waarin beide programma's naast elkaar kunnen worden gebruikt, in plaats van een tekstverwerker en een stijlgids.
Wekelijks of sneller publiceren, dus vertaalde catalogi moeten als pull requests binnenkomen in plaats van als een batch die na afloop van de sprint wordt geleverd.
Dezelfde terminologie is nodig in een .po een catalogus, een JSON-resourcebestand en een helpcentrum, dat gebruikmaakt van één gedeeld vertaalgeheugen en een gedeelde woordenlijst in plaats van drie lokale.

Wanneer een specifieke toolchain voor inkooporders niet de juiste prioriteit is

Producten voor één taal, waarbij de gettext-roundtrip een buildstap en een bestandsformaat toevoegt zonder een taal toe te voegen.
Applicaties waarvan de vertaalbare inhoud voornamelijk door gebruikers gegenereerde databaserijen bestaat in plaats van UI-strings; die hebben een content-niveau workflow nodig, geen berichtencatalogus.
Codebases die nog steeds weergavestrings hardcoderen, omdat extractie met xgettext moet plaatsvinden voordat een editor of platform er waarde aan toevoegt.
Projecten die al gebruikmaken van XLIFF- of JSON-resourcebestanden en geen gettext-catalogi meer hoeven te beheren.

Kun je een gebruiksvriendelijke PO-editor aanbevelen voor beginners?

Poedit is meestal de eerste aanbeveling voor iemand die voor het eerst een PO-bestand opent: het werkt op Windows, macOS en Linux en opent .po bestanden. en .pot Het programma leest bestanden direct in, toont de brontekst en de vertaling naast elkaar, behandelt meervoudsvormen en msgctxt als gestructureerde velden en valideert de catalogus bij het opslaan. Gebruik deze vragen om te bevestigen dat dit het juiste uitgangspunt is en geen standaardinstelling.

Moet je naast de editor nog iets anders installeren?
Een desktop PO-editor compileert het .mo bestand. Het bestand wordt automatisch voor u opgeslagen, zodat een vertaler die alleen werkt verder niets anders nodig heeft. Een ontwikkelaar die xgettext of msgmerge gebruikt, moet nog steeds de GNU gettext-hulpprogramma's apart installeren. Op Windows en minimale Docker-images is het ontbreken hiervan de meest voorkomende oorzaak van problemen op de eerste dag.

Zal de editor de bestandsstructuur intact laten?
Controleer of meervoudsvormen als aparte tabvelden worden weergegeven, of de koptekst na het opslaan ongewijzigd blijft en of vlagcommentaren zoals #, python-format behouden blijven. Een editor die deze drie zaken heen en weer verwerkt, kan niet zomaar een catalogus produceren die niet voldoet aan msgfmt, en dat is nu juist de eigenschap die beginners echt veilig maakt.

Ben je bezig met het vertalen van een WordPress-thema of -plugin?
Loco Translate bewerkt PO-bestanden binnen de WordPress-beheerder, waardoor de download-bewerken-uploadcyclus voor één site volledig wordt weggenomen. Dat gemak betaalt zich niet meer uit op meerdere sites, omdat elke site zijn eigen catalogi en vertaalgeheugen heeft.

Moet het bestand iemand buiten de repository bereiken?
Een desktopeditor gaat ervan uit dat de vertaler een bestand kan ontvangen, openen en terugsturen. Zodra die uitwisseling in meer dan twee of drie talen per release plaatsvindt, wordt de overdracht zelf het breekpunt, en vervangt een platformgebaseerde retour dit.

Hoeveel locaties beheert u?
Een of twee talen kunnen probleemloos worden verwerkt in een desktopeditor met een lokaal vertaalgeheugen. Naast de ongeveer vijf belangrijkste aspecten zijn het benutten van het vertaalgeheugen, het afdwingen van de woordenlijst en de zichtbaarheid van de status belangrijker dan de bewerkingsinterface. Dat is het punt waarop een vertaalbeheersysteem zijn waarde bewijst.

Hoe gaat Smartling om met PO- en POT-bestanden?

Smartling parseert gettext-catalogi op een native manier onder de bestandstype-identifier gettext, waarbij elke msgid als bronstring wordt geïnjecteerd en de vertaling in msgstr wordt geretourneerd. Het bestand dat een ontwikkelaar commit, is dus het bestand dat vertaald wordt teruggestuurd. Vier parser-gedragingen verwijderen de hierboven genoemde fouten bij handbewerking. msgctxt waarden worden vastgelegd als variantmetadata, dus "Home" als navigatie en "Home" als adreslabel worden twee afzonderlijk vertaalde strings. Geëxtraheerde opmerkingen die beginnen met #. worden aan vertalers getoond als instructies, waardoor een ontwikkelaarsnoot boven een string in echte context wordt in de CAT-tool. Bij download worden de Language and-headers Plural-Forms herschreven voor de doellocatie — een Engelse bronheader die twee meervoudsvormen retouren als de drie van het Russische — en worden vertalingen geaccepteerd voor alle vier CLDR-formulieren terwijl alleen de drie gettext-supports in het bestand worden geschreven. En de parameter file/get includeOriginalStrings=false retourneert een lege msgstr wanneer er geen vertaling bestaat, waardoor de applicatie terugvalt op de brontaal in plaats van Engels te verzenden in een item dat beweert vertaald te zijn.

Naast het parsen, biedt Smartling de mogelijkheid om bestandsrichtlijnen inline of via de API te definiëren als een commentaar in de vorm # smartling.gettext_line_width = normalized. Die richtlijn weerspiegelt de eigen 79-tekens-afbreking van de gettext-tool, zodat verschillen leesbaar blijven; placeholder_format en placeholder_format_custom beschermen tokenstijlen die niet door de native vlaggen worden gedekt; pseudo_inflation bepaalt hoeveel langer pseudo-vertalingen duren dan de brontekst, met een standaardwaarde van 30 procent; entity_escaping bepaalt of de basis-XML-tekens worden ontsnapt bij levering; whitespace_trim regelt de voorloop- en afloopspaties; en gettext_parsing_mode = keyed schakelt over naar sleutelgebaseerde parsing voor catalogi die msgid als abstracte resourcesleutel gebruiken en de brontekst in msgstr bewaren. In de Smartling CAT-tool zien vertalers elke tekenreeks met visuele context, waardoor een afgekorte knoptekst al tijdens het schrijven van de tekenreeks wordt opgemerkt, in plaats van na de extensie .mo bestanden schepen. Voor de heen- en terugreis zelf bewaakt de GitHub Connector een repository en retourneert vertaalde catalogi als een pull request. De Smartling CLI en de Java-, Python- en Node.js-SDK's sturen vervolgens dezelfde uploads en downloads aan vanuit een CI-taak die msgfmt uitvoert.