PO-bestanden vertalen zonder je app te breken

TABLE OF CONTENTS

PO-bestanden lijken op eenvoudige tekstbestanden, totdat een vertaald %s, een ontbrekende meervoudsvorm of een aangepaste msgid je app doet crashen. Gebruik deze workflow om de gebruikersgerichte teksten te vertalen, terwijl je de gettext-structuur intact laat.

Plak het hele bestand niet in een gewone tekstvertaler. Een PO-bestand staat dicht bij broncode: de woorden zijn vertaalbaar, maar de bestandsstructuur, placeholders, opmerkingen en meervoudsindexen moeten ongewijzigd blijven.

Methode 1: Gebruik een PO-bestand vertaler

Kies deze methode als je snel een veilige eerste versie wilt en niet handmatig msgid / msgstr paren wilt bewerken.

Maak een back-up van het originele .po-bestand. Bewaar een schone kopie in je repository voordat je iets naar een vertaler stuurt. Als het vertaalde bestand niet werkt, heb je een betrouwbare versie nodig om mee te vergelijken.
Open een PO-bewuste vertaler. Gebruik een tool die gemaakt is voor gettext-bestanden, zoals OpenL PO Translator, een documentvertaler op basis van betalen per gebruik. Een PO-bewuste tool vertaalt de doelteksten, terwijl bronstrings, opmerkingen, placeholders en bestandsstructuur intact blijven. Als je nog een tool kiest, vergelijk dan opties in onze beste PO vertaler gids.
Upload het .po-bestand. Gebruik het taalbestand dat msgid en msgstr entries bevat. Als je alleen een .pot-template hebt, maak dan eerst een .po-bestand voor de doeltaal en upload vervolgens het .po-bestand.
Kies de bron- en doeltaal. Stem de brontaal af op de tekst binnen msgid, niet op de taal van je beheerdersinterface. Bijvoorbeeld: als het bestand Engelse msgid-strings bevat en je Spaanse output nodig hebt, kies dan Engels naar Spaans.
Download het vertaalde bestand. Sla het op volgens de locale naamgevingsconventie die je framework verwacht. WordPress-plugins gebruiken vaak een text-domain plus locale patroon, terwijl Django bestanden meestal opslaat onder locale/<taal>/LC_MESSAGES/.
Controleer eerst de risicovolle strings. Zoek in het vertaalde bestand naar %, {, }, <, >, msgid_plural, msgctxt en #, fuzzy. Dit zijn de items die het meest waarschijnlijk invloed hebben op het gedrag tijdens runtime.
Test het vertaalde bestand in je app. Laad de taal lokaal en klik door de schermen die de vertaalde strings gebruiken. Een PO-bestand is niet klaar zodra het vertaald is; het is pas klaar wanneer de app nog steeds correct wordt weergegeven.

Methode 2: PO-bestanden vertalen in Poedit

Kies deze methode wanneer je menselijke controle, WordPress-compatibiliteit of een zorgvuldige, item-voor-item workflow nodig hebt.

Open het bestand in Poedit. Poedit is een speciale vertaaleditor voor PO en andere lokalisatieformaten; de basiseditor is gratis, met betaalde Pro-functies voor intensievere workflows. Voor WordPress legt het officiële Polyglots-handboek uit dat Poedit .po en .mo bestanden kan maken vanuit een POT-bestand en ondersteuning biedt voor meervoudsvormen en UTF-8.
Werk bij vanaf de POT-template als de bron is gewijzigd. Als ontwikkelaars de app-tekst hebben aangepast, werk het .po bestand bij vanaf de nieuwste .pot voordat je gaat vertalen. Zo blijven nieuwe, verwijderde en fuzzy strings zichtbaar in plaats van dat verouderde UI-tekst ongemerkt wordt meegeleverd.
Vertaal alleen het msgstr veld. De msgid is de bronstring die je app gebruikt om de vertaling op te zoeken. In normale gettext-workflows moeten vertalers msgstr bewerken, niet msgid.
Laat placeholders exact intact. Vertaal of wijzig variabelen zoals %s, %d, %1$s, {name}, %(count)s, :name of HTML-tags niet. Als de woordvolgorde moet veranderen, verplaats de placeholder als geheel.
Behandel meervoudsvormen als aparte vertalingen. Een meervoudsitem kan msgid, msgid_plural en meerdere msgstr[n] waarden bevatten. Vul elk meervoudsvak in dat vereist is door de doeltaal, in plaats van overal dezelfde zin te kopiëren.
Sla het .mo-bestand op en compileer het indien je app dit nodig heeft. Sommige ontwikkelomgevingen lezen .po-bestanden direct tijdens de ontwikkeling, maar WordPress en veel gettext-configuraties gebruiken gecompileerde .mo-bestanden tijdens runtime. Poedit kan automatisch een .mo-bestand compileren bij het opslaan; Django kan berichten compileren met django-admin compilemessages.
Los waarschuwingen op voordat je uploadt. In Poedit wijzen waarschuwingsiconen vaak op kapotte placeholders, ontbrekende variabelen of fouten in meervoudsvormen. Corrigeer deze voordat je de vertaling importeert in WordPress, Django, Drupal of je release branch.

Methode 3: Gebruik een lokalisatieplatform

Kies hiervoor wanneer meerdere vertalers, reviewers of release managers aan dezelfde PO-bestanden moeten werken.

Importeer het PO-bestand in een platform dat gettext ondersteunt. Weblate en vergelijkbare lokalisatieplatformen ondersteunen PO-workflows. Team-lokalisatieplatformen zijn vaak betaalde producten, hoewel Weblate ook een open-source self-hosted optie biedt. De manier waarop ze omgaan met opmerkingen, headers, fuzzy strings en placeholders verschilt, dus controleer de formaatinstellingen voordat je productie-bestanden uploadt.
Stel controles voor placeholders en tags in. Zet QA-regels aan voor printf-stijl placeholders, benoemde variabelen, HTML/XML-tags en meervoudsvormen. Deze controles vangen fouten die normale spellcheckers niet kunnen detecteren.
Houd ontwikkelaarsopmerkingen zichtbaar. PO-opmerkingen kunnen context bevatten zoals bronverwijzingen, uitgeschreven ontwikkelaarsnotities, vlaggen en eerdere bronstrings. Vertalers hebben deze notities nodig wanneer een korte UI-label zoals “Open” een werkwoord, bijvoeglijk naamwoord of menucommando kan zijn.
Gebruik translation memory met review. Translation memory is handig voor herhaalde UI-strings, maar kan een oude vertaling in een nieuwe context kopiëren. Controleer hergebruikte strings wanneer msgctxt, bronverwijzingen of omliggende UI zijn gewijzigd.
Exporteer PO-bestanden en voer lokale controles uit. Vertrouw niet blindelings op de export. Plaats het vertaalde bestand terug in de app, compileer indien nodig, en test de schermen voordat je samenvoegt.

Regels voor PO-bestanden die je nooit mag breken

PO-item	Vertalen?	Veilig voorbeeld	Waarom het belangrijk is
`msgid`	Nee	`msgid "Save changes"`	De app gebruikt deze bronstring als zoeksleutel in veel gettext-workflows.
`msgstr`	Ja	`msgstr "Guardar cambios"`	Dit is de tekst in de doeltaal die gebruikers zien.
`msgctxt`	Nee	`msgctxt "button"`	Context maakt onderscheid tussen identieke bronstrings.
`%s`, `%d`, `%1$s`	Nee	`Hello, %s` -> `Hola, %s`	De runtime-code vervangt deze placeholders door actuele waarden.
`{name}`, `%(count)s`, `:name`	Nee	`Welcome, {name}`	Genaamd variabelen moeten nog steeds overeenkomen met de app-code.
HTML-tags	Meestal niet	`<strong>Warning</strong>`	Vertaal de tekst, niet de tag-syntax.
`msgid_plural`	Nee	`msgid_plural "%d files"`	Het bron-meervoud hoort bij het originele codepad.
`msgstr[0]`, `msgstr[1]`	Ja, zorgvuldig	`msgstr[0] "%d file"`	Elke doeltaal heeft eigen meervoudregels.
`#, fuzzy`	Eerst controleren	`#, fuzzy`	Fuzzy betekent dat de vertaling mogelijk verouderd of niet bevestigd is.
`#.` ontwikkelaarscommentaar	Meestal niet	`#. Button label`	Deze notities helpen vertalers de context te begrijpen.

Kort voorbeeld: Veilige vs. kapotte PO-vertaling

Hier is een normale gettext-entry:

#. %s is de weergavenaam van de gebruiker.
#, c-format
msgid "Welcome back, %s"
msgstr ""

Een veilige Spaanse vertaling laat %s onveranderd:

#. %s is de weergavenaam van de gebruiker.
#, c-format
msgid "Welcome back, %s"
msgstr "Bienvenido de nuevo, %s"

Een kapotte vertaling verandert de placeholder:

msgid "Welcome back, %s"
msgstr "Bienvenido de nuevo, % s"

Dat kleine spatie kan uitmaken. GNU msgfmt --check-format is ontworpen om mismatches in format-strings te detecteren, zoals verkeerde %-placeholders, en Poedit waarschuwt ook voor veelvoorkomende placeholderproblemen. Voor een bredere lijst van strings die onaangetast moeten blijven, gebruik onze gids wat niet te vertalen.

Hoe een vertaald PO-bestand te controleren

Voer gettext-validatie uit als je gettext hebt geïnstalleerd.

msgfmt --check --check-format -o /tmp/messages.mo path/to/messages.po

Dit controleert de syntax, headers en formatstrings, en schrijft vervolgens een tijdelijk gecompileerd catalogusbestand als het bestand geldig is.

Compileer het bestand zoals jouw framework verwacht.

django-admin compilemessages

Voor Django-projecten compileert compilemessages de .po-bestanden die zijn aangemaakt met makemessages naar .mo-bestanden voor gettext-ondersteuning.

Zoek naar lege vertalingen.

grep -n 'msgstr ""' path/to/messages.po

Lege msgstr-velden kunnen bewust zijn voor niet-vertaalde items, maar ze mogen je niet verrassen bij een release.

Zoek naar fuzzy strings.

grep -n '#, fuzzy' path/to/messages.po

Fuzzy strings moeten door een persoon worden gecontroleerd vóór de release. Standaard gebruikt msgfmt geen fuzzy vertalingen, tenzij je compileert met --use-fuzzy, dus een fuzzy item kan zich gedragen als een niet-vertaalde string in de uiteindelijke catalogus.

Test de echte gebruikersinterface. Open de schermen met formulieren, meervoudsvormen, foutmeldingen, accountmenu’s en betalingsprocessen. PO-validatie vangt bestandsproblemen; alleen UI-testen detecteren ongemakkelijke formuleringen, overloop en ontbrekende context.

Welke methode moet je gebruiken?

Situatie	Beste methode	Waarom
Je hebt snel een eerste versie nodig voor één PO-bestand	PO-bestand vertaler	Snelste manier met behoud van structuur
Je onderhoudt een WordPress-plugin of thema	Poedit	Bekende WordPress-werkwijze met `.mo`-compilatie
Je onderhoudt een Django-app	PO vertaler of Poedit, daarna `compilemessages`	Vertalen kan snel, maar framework-compilatie blijft vereist
Je hebt veel talen en reviewers	Lokalisatieplatform	Betere toewijzing, geschiedenis, kwaliteitscontrole en reviewbeheer
Je vertaalt strings voor ontwikkelaars	Menselijke review na machinevertaling	Code-termen, placeholders en context zijn belangrijker
Je lokaliseert ook JSON of frontend i18n-bestanden	Gebruik een workflow specifiek voor het formaat	PO-regels gelden niet altijd voor JSON, YAML of ICU-berichten

Als je project gettext PO-bestanden combineert met JSON locale-bestanden, vertaal elk formaat met een tool die de structuur begrijpt. PO-bestanden draaien om msgid en msgstr; JSON-lokalisatie draait om sleutels en waarden. Voor die workflow, zie onze gids over de beste JSON-vertalers in 2026.

FAQ

Kan ik PO-bestanden vertalen met Google Translate?

Je kunt individuele msgstr-waarden kopiëren naar een algemene vertaler, maar het uploaden of plakken van het hele PO-bestand in een gewone tekstvertaler is riskant. Algemene vertalers kunnen msgid, opmerkingen, aanhalingstekens, meervoudsindexen of placeholders wijzigen. Gebruik liever een PO-bewuste vertaler, Poedit of een lokalisatieplatform.

Wat is het verschil tussen `.po`, `.pot` en `.mo`?

.pot is het sjabloon dat uit de broncode wordt gehaald. Dit bevat meestal originele strings, maar geen voltooide vertalingen. .po is het bewerkbare vertalingsbestand voor één doeltaal. .mo is de gecompileerde binaire catalogus die veel op gettext gebaseerde apps tijdens runtime laden.

Moet ik `msgid` vertalen?

Nee, niet in de normale workflow. Vertaal msgstr. De GNU gettext-handleiding beschrijft msgid als de originele, niet-vertaalde string en msgstr als de vertaling; msgid-strings worden geproduceerd en beheerd door gettext-tools.

Hoe controleer ik of een PO-bestand geldig is?

Voer msgfmt --check --check-format uit als gettext beschikbaar is, open het bestand in Poedit, of gebruik de QA-controles van je localisatieplatform. Compileer en test daarna het bestand binnen de app. Validatie is noodzakelijk, maar het vervangt geen UI-testen.

Wat gebeurt er als ik een placeholder breek?

In het beste geval toont de app een vreemde string. In het slechtste geval geeft de runtime formatter een foutmelding omdat de vertaalde string niet meer overeenkomt met de variabelen die de code doorgeeft. Placeholders mogen alleen als complete tokens worden verplaatst, nooit vertaald of gedeeltelijk aangepast.

Kan OpenL PO-bestanden vertalen?

Ja. OpenL PO Translator is speciaal ontwikkeld voor gettext .po-bestanden en geeft aan dat placeholders en variabelen onaangeroerd blijven tijdens het vertalen naar meer dan 100 talen. Het gebruikt een pay-per-use documentvertalingsworkflow, dus gebruik het voor een snelle eerste versie wanneer het behouden van de PO-structuur belangrijker is dan alles handmatig doen. Als je alleen een .pot-template hebt, maak dan eerst een .po-bestand in de doeltaal voordat je OpenL gebruikt.

Bronnen

GNU gettext-handleiding: PO-bestanden — Officiële uitleg van het PO-bestandsformaat door gettext.
GNU gettext-handleiding: PO-bestandsvermeldingen — Bron voor msgid, msgstr, opmerkingen, vlaggen en de structuur van vermeldingen.
GNU gettext-handleiding: Vermeldingen met meervoudsvormen — Bron voor de structuur van vermeldingen met meervoudsvormen.
GNU gettext-handleiding: msgfmt-aanroep — Bron voor msgfmt --check en validatie van opmaakstrings.
OpenL PO Translator — OpenL productpagina voor het vertalen van .po-bestanden met behoud van placeholders en variabelen.
Poedit — Officiële Poedit-site voor de PO-vertaaleditor en Pro-aanbod.
WordPress Polyglots Handbook: Poedit — WordPress-gids voor het gebruik van Poedit, POT-bestanden, PO-bestanden, MO-compilatie en waarschuwingen voor placeholders.
Django-documentatie: Vertaling — Django-workflow voor berichtbestanden en vertaling.
Django-documentatie: compilemessages — Django-commandoverwijzing voor het compileren van .po-bestanden naar .mo-bestanden.
Drupal-documentatie: PO- en POT-bestanden — Drupal-uitleg over .po, .pot, context, meervoudsvormen, opmerkingen en variabelen.
Weblate-documentatie: GNU gettext PO — Notities van het lokalisatieplatform over PO-headers, eerdere bronstrings, verouderde strings en gegenereerde MO-bestanden.