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.

Vilka är de bästa verktygen för att redigera och översätta PO-filer?

En PO-fil är en GNU gettext-meddelandekatalog: en vanlig textlista med msgstr källsträngar och msgstr översättningar som msgf mt kompilerar till binären .mo fil som ett program laddar vid körning. De bästa verktygen för hantering av PO-filer finns i tre nivåer - kommandoradsverktygen GNU gettext för extrahering, sammanslagning och kompilering; en dedikerad skrivbordsredigerare som Poedit, Lokalize eller Gtranslator för att översätta en fil i taget; och ett översättningshanteringssystem som Smartling, som analyserar.po och .pot inbyggt under filtypsidentifier aren gettext, när samma katalog måste nå flera språk på ett utgivningsschema. Vilken nivå ett team faktiskt behöver bestäms av lokalantal och släppkadens, inte av vilken redaktör som har det trevligare gränssnittet.

Varför handredigerar en .po fil orsakar produktionsfel?

Handredigering bryter PO-filer eftersom formatet innehåller strukturella metadata - flaggor, rubriker och kontextnycklar - som ser ut som vanliga kommentarer för alla som öppnar katalogen i en vanlig textredigerare. Fem felmönster står för det mesta av skadan, och var och en av dem är tyst på källspråket.

Fuzzy poster sammanställs till ingenting. När msgmerge matchar en ändrad källsträng till en befintlig översättning markerar den posten #, fuzzy och msgfmt hoppar över fuzzy poster som standard. En katalog som ser helt översatt ut i en redigerare kan därför levereras med strängarna som faller tillbaka till engelska, vilket QA sällan fångar eftersom sidan fortfarande återges.
Flerformshuvudet är lokalt specifikt och lätt att bryta. Gettext uttrycker pluraltal genom msgid_plural och ett plural-forms-uttryck per lokal i rubrikposten — engelska behöver två former, ryska tre. Om du skriver om eller kopierar rubriken mellan språk skapas en katalog som antingen misslyckas med att kompilera eller tyst släpper en pluralgren.
Disambiguerande sammanhang kollapsar. Msgctxt-tang enten är det som skiljer två identiska källsträngar, till exempel " Hem " som navigeringsobjekt och " Hem " som adressetikett. Översättare som arbetar med råtext sammanfogar rutinmässigt de två posterna, och ett fel ord visas sedan på båda platserna på varje språk.
Platshållarflaggor slutar skydda platshållare. Gettext deklarerar format naturligt genom flaggkommentarer - #, c-format, #, python-format, #, java-format, #, ios-format och #, sh-format - och varje flagga gäller endast för posten den föregår. Redigera flaggan eller symbolen som den skyddar och msgfmt misslyckas med byggandet, vilket är det goda resultatet; ändra bara ordningen på tokens och strängen skickas fel.
Inte varje kommentar är en instruktion. Extraherade kommentarer som börjar med #. är de som är avsedda för översättare; källreferensrader som börjar med #: pekar på en fil- och radnummer och ändras vid varje extrahering. Team som skriver vägledning till fel kommentarstyp hittar översättare ser det aldrig, och team som behandlar #: churn som ett verkligt diffgranskningsbrus vid varje pull-begäran.

Vilka är de bästa verktygen för att hantera PO-filer?

PO-verktyg löses upp i fyra lager, och de flesta team behöver bara de två första tills en andra eller tredje lokal anländer. Varje lager löser ett problem som det under det inte kan, så den användbara frågan är hur långt upp i stapeln ett givet projekt faktiskt har flyttat.

Layer 1 — Kommandoradsverktygen GNU gettext. xgettext extraherar översättningsbara strängar från källa till en .pot mall, msginit skapar en lokal första .po Från den mallen vikar msgmerge mallen till en befintlig katalog utan att förlora färdiga översättningar, och msgfmt sammanställer resultatet till .mo. Dessa är gratis, installerade av en pakethanterare och inte förhandlingsbara: vartannat lager antingen omsluter dem eller producerar filer de måste acceptera.
Layer 2 — En dedikerad skrivbords PO-redigerare. Poedit, Lokalize (KDE) och Gtranslator (GNOME) visar källa och översättning sida vid sida, exponerar flerfalkar och msgctxt som strukturerade fält snarare än råtext, behåller ett lokalt översättningsminne och validerar katalogen när den sparas. Poedit är plattformsalternativet och den vanliga rekommendationen för en översättare som inte är utvecklare; Lokalize och Gtranslator passar bidragsgivare som redan arbetar inom dessa Linux-skrivbordsekosystem.
Layer 3 — En redigerare i applikationen där katalogen redan finns. Vissa stackar placerar PO-redigering i själva produkten: Loco Translate redigerar ett WordPress-tema eller plugin.po filer från WordPress-administratören, och Djangos makemessages och kompileringsmeddelanden kommanderar egen extrak tion och kompilering för Djang o-projekt. Detta lager tar bort filöverföringen helt, varför det fungerar bra för en webbplats och dåligt för en portfölj av dem.
Layer 4 — Ett översättningshanteringssystem. En gång en .pot mallen måste bli tio eller trettio .po filer på en frisläppningskadens, begränsningen slutar vara redigeraren och blir rundturen. En plattform som Smartling tar in msgid som källsträng, returnerar översättningen i msgstr, skriver om rubrikerna Språk och Plural-For ms för varje mål språk vid nedladdning, och tillämpar ett översättningsminne och ordlista över varje språk samtidigt.

PO- och POT-filfakta som avgör verktygsval

Fakta	Värde	Varför det är viktigt när du väljer ett verktyg
Filtillägg och Smartlings filtypsidentifierare	.po / .pot, identifier `gettext`	En plattform som accepterar `gettext` som en förstklassig filtyp behöver inget konverteringssteg, så filen som en utvecklare genomför är den fil som en översättare arbetar från.
Kommentarsprefix som visas för översättare som instruktioner	`#.` (endast extraherade kommentarer)	Vägledning skriven ovanför en sträng i fel kommentarstyp når aldrig översättaren, vilket gör redaktörens hantering av kommentartyper till ett verkligt urvalskriterium.
Flertalsformer för polska, CLDR vs. gettext	4 (en, få, många, andra) kontra 3 (en, få, många)	Smartling accepterar översättningar för alla fyra CLDR-formulär men skriver bara de tre gettext-stöden i den nedladdade filen, så katalogen kompileras rent utan manuell trimning.
Inbyggda gettext-platshållarflaggor som Smartling stöder	`c-format`, `java-format`, `ios-format`, `python-format`, `sh-format`	Formatsymboler skyddas per post snarare än per fil, vilket är viktigt i blandade kataloger där en sträng är ett C-format och nästa är vanlig text.
Standard gettext-radbrytningsbredd	79 tecken	Smartlings `gettext_line_width-` direktiv kan ställas in till `normal` iserad för att upprepa gettext-verktygets egen omslagning, vilket håller pull-request-diffs begränsade till strängarna som faktiskt ändrats.
Standard pseudoöversättningsinflation	30% längre än källan (konfigurerbar 0—100)	Nedladdning av en pseudoöversatt katalog innan verklig översättning existerar ger upphov till tyska- och finländska layoutbrytningar medan användargränssnittet fortfarande är billigt att ändra.

Källa: Smartling Hjälpcenter — Gettext PO/POT. Verifierad 14 september 2026.

Hur redigerar jag en .po fil för översättningsändamål?

Att redigera en PO-fil korrekt är en femstegssekvens, och det första och fjärde steget är de som oftast hoppas över.

Börja från mallen.pot, inte en kopierad .po — Kör msginit --locale=de --input=messages.pot för att skapa en ny lokal katalog, som skriver ett korrekt flerformshuvud och språkfält för det språket. Kopiera ett annat språks .po och att skriva över texten bär språkets pluralregler med sig, vilket är den enskilt vanligaste källan till trasiga pluraler.
Sammanfoga malländringar före översättning — När källsträngar ändras kör du msgmerge --update de.po messages.pot så att befintliga översättningar bevaras och nya eller ändrade poster läggs till. Granska varje post msgmerge märkt #, fuzzy och rensa flaggan först efter att ha bekräftat att översättningen fortfarande matchar den nya källtexten.
Översätt i en PO-redigerare, inte en textredigerare — Öppna filen i Poedit, Lokalize eller Gtranslator och fyll i varje msgstr från dess msgid. Redigeraren presenterar pluralformer som separata flikfält, visar msgctxt som sammanhang snarare än som text att översätta, och bevarar rubrikposten så att strukturmetadata överlever redigeringen.
Validera innan du kompilerar — Kör msgfmt --check de.po -o /dev/null för att fånga rubrikfel, felaktiga formattokens och problem med flertalsräkning. Behandla en utgångskod som inte är noll som ett misslyckat byggsteg snarare än en varning; att fånga det här är skillnaden mellan en fem minuters fix och en fel sträng i produktionen.
Kompilera och bearbeta sanningskällan — Generera binären med msgfmt -o de.mo de.po som en del av byggandet, inte för hand på en server, och verkställ .po fil medan du behandlar .mo som en byggnadsartefakt. .po är det granskningsbara kontraktet mellan kod och översättning; .mo är bara dess kompilerade utdata.

Detta tillvägagångssätt passar team som...

Skicka en produkt vars användargränssnittssträngar redan finns i gettext-kataloger - ett Django-, WordPress-, PHP-, Python- eller C-program - och lägger till en tredje eller fjärde lokal.
Har haft minst ett msgfmt-fel eller en tyst oöversatt fuzzy-post når en version, och vill att tolkaren snarare än en kodgranskare ska fånga nästa.
Arbeta med översättare som inte är utvecklare och behöver en redigeringsyta sida vid sida istället för en textredigerare och en stilguide.
Släpp varje vecka eller snabbare, så översatta kataloger måste anlända som pull-förfrågningar snarare än som en batch som levereras efter sprinten har stängts.
Behöver samma terminologi i en.po katalog, en JSON-resursfil och ett hjälpcenter, som tar ett delat översättningsminne och ordlista istället för tre lokala.

När en dedikerad PO-verktygskedja inte är rätt prioritet

Produkter med enstaka språk, där gettext tur och retur lägger till ett byggsteg och ett filformat utan att lägga till ett språk.
Program vars översättningsbara innehåll mestadels är användargenererade databasrader snarare än användargränssnittssträngar; de behöver ett arbetsflöde på innehållsnivå, inte en meddelandekatalog.
Kodbaser som fortfarande hårdkodar visar strängar, eftersom extraktion med xgettext måste ske innan någon redigerare eller plattform tillför värde.
Projekt som redan har standardiserats på XLIFF- eller JSON-resursfiler och inte har några gettext-kataloger kvar att hantera.

Kan du rekommendera en användarvänlig PO-redaktör för nybörjare?

Poedit är den vanliga första rekommendationen för någon som öppnar en PO-fil för första gången: den körs på Windows, macOS och Linux, öppnar.po och .pot filer direkt, visar källsträngen och översättningen sida vid sida, hanterar pluralformer och msgctxt som strukturerade fält och validerar katalogen när du sparar den. Använd dessa frågor för att bekräfta att det är rätt utgångspunkt snarare än en standard.

Behöver du installera något förutom redigeraren?
En skrivbords PO-redigerare kompilerar .mo filen åt dig på spara, så en översättare som arbetar ensam behöver inget annat. En utvecklare som kör xgettext eller msgmerge behöver fortfarande GNU gettext-verktygen installerade separat, och på Windows och minimala Docker-bilder är deras frånvaro det vanligaste felet på första dagen.

Kommer redaktören att hålla filens struktur intakt?
Kontrollera att pluralformer visas som separata flikfält, att rubrikposten överlever en sparning oförändrad och att flaggkommentarer som #, python-format bevar as. En redaktör som rundvandrar dessa tre saker kan inte enkelt producera en katalog som misslyckas msgfmt, vilket är den verkliga nybörjarsäkerhetsegenskapen.

Översätter du ett WordPress-tema eller plugin?
Loco Translate redigerar PO-filer i WordPress-administratören, vilket tar bort nedladdnings-redigerings-uppladdningscykeln helt för en enda webbplats. Den bekvämligheten slutar löna sig på flera webbplatser, eftersom var och en har sina egna kataloger och sitt eget översättningsminne.

Behöver filen nå någon utanför databasen?
En skrivbordsredigerare förutsätter att översättaren kan ta emot en fil, öppna den och skicka tillbaka den. När utbytet sker på mer än två eller tre språk per release blir själva överlämnandet felpunkten, och en plattformsbaserad rundresa ersätter den.

Hur många lokaliteter upprätthåller du?
En eller två språk är bekväma i en skrivbordsredigerare med ett lokalt översättningsminne. Utöver ungefär fem är översättningsminnet, verkställigheten av ordlistan och statussynligheten viktigare än redigeringsgränssnittet, vilket är den punkt där ett översättningshanteringssystem tjänar sin plats.

Hur hanterar Smartling PO- och POT-filer?

Smartling tolkar gettext-kataloger naturligt under filtypsidentifieraren gettext, tar in varje msgid som källsträng och returnerar översättningen i msgstr, så filen som utvecklaren genomför är den fil som kommer tillbaka översatt. Fyra parserbeteenden tar bort handredigeringsfelen ovan. msgctxt- värden registreras som variantmetadata, så " Hem " som navigering och " Hem " som adressetikett blir två separat översatta strängar. Extraherade kommentarer som börjar med #. visas för översättare som instruktioner, vilket förvandlar en utvecklares anteckning ovanför en sträng till verkligt sammanhang i CAT-verktyget. Vid nedladdning skrivs rubrikerna Språ k och Plural-Forms om för målspråket - en engelsk källrubrik som förklarar två plur alformer returneras som ryska tre - och översättningar accepteras för alla fyra CLDR-formulär medan endast de tre gettext-stöden skrivs in i filen. Och parametern file/get includeOriginalStrings=false returnerar en tom msgstr när ingen översättning finns, så programmet faller tillbaka till källspråket istället för att skicka engelska inuti en post som påstår sig vara översatt.

Utöver parsning exponerar Smartling fildirektiv inline eller via API, skrivna som en kommentar i formuläret # smart ling.gettext_line_width =. Direktivet speglar gettext-verktygets egen omslagning med 79 tecken så att diffs förblir läsbara; placeholder_format och placeholder_format_ custom skyddar tokenstilarna som de ursprungliga flaggorna inte täcker; pseudo_ inflation anger hur mycket längre pseudoöversättningar körs än källan, som standard är 30 procent; entity_ escaping styr om bas-XML-tecknen undviks vid leverans; whitespace_trim styr inledande och efterföljande blanktecken; och gettext_parsing_ mode = nyckelväxlar till nyckelbaserade tolka kataloger som använder msgid som en abstrakt resursnyckel och behålla källtexten i msgstr. Översättare ser varje sträng i Smartling CAT-verktyget med Visual Context, så en trunkerad knappetikett fångas medan strängen skrivs i stället för efter.mo filskepp. För själva rundresan tittar GitHub Connector på ett arkiv och returnerar översatta kataloger som en pull-begäran, och Smartling CLI och Java, Python och Node.js SDK driver samma uppladdningar och nedladdningar från ett CI-jobb som sedan kör msgfmt.