Hvad er de bedste værktøjer til redigering og oversættelse af PO-filer?

Sidst gennemgået: 14. september 2026

Hvad er de bedste værktøjer til at håndtere PO-filer?

PO-værktøjer opdeles i fire lag, og de fleste teams har kun brug for de to første, indtil en anden eller tredje lokalitet ankommer. Hvert lag løser et problem, som det nedenunder ikke kan, så det nyttige spørgsmål er, hvor langt op i stakken et givet projekt rent faktisk har bevæget sig.

• Lag 1 — GNU gettext kommandolinjeværktøjerne. xgettext udtrækker oversættelige strenge fra kildekoden til en .pot skabelon, msginit opretter en lokalitets første .po Fra den skabelon folder msgmerge skabelonændringer ind i et eksisterende katalog uden at miste færdige oversættelser, og msgfmt kompilerer resultatet til .mo. Disse er gratis, installeret af en pakkehåndtering og ikke til forhandling: hvert andet lag enten omslutter dem eller producerer filer, de skal acceptere.
• Lag 2 — En dedikeret desktop PO-editor. Poedit, Lokalize (KDE) og Gtranslator (GNOME) viser kildekode og oversættelse side om side, eksponerer plural tabs og msgctxt som strukturerede felter i stedet for rå tekst, beholder en lokal oversættelseshukommelse og validerer kataloget ved lagring. Poedit er den platformsuafhængige løsning og den sædvanlige anbefaling til en oversætter, der ikke er udvikler; Lokalize og Gtranslator passer til bidragydere, der allerede arbejder i disse Linux-desktopøkosystemer.
• Lag 3 — En editor i programmet, hvor kataloget allerede findes. Nogle stacks placerer PO-redigering inde i selve produktet: Loco Translate redigerer et WordPress-tema eller plugins .po filer fra WordPress-administratoren, og Djangos kommandoer makemessages og compilemessages udfører deres egen udtrækning og kompilering til Django-projekter. Dette lag fjerner filoverdragelsen helt, hvilket er grunden til, at det fungerer godt for ét websted og dårligt for en portefølje af dem.
• Lag 4 — Et oversættelsesstyringssystem. En gang én .pot skabelonen skal blive ti eller tredive .po filer på en udgivelseskadence, holder begrænsningen op med at være editoren og bliver til rundgangen. En platform som Smartling indtager msgid som kildestreng, returnerer oversættelsen msgstr, omskriver Language og Plural-Forms headerne for hver destinationslokalitet ved download og anvender én oversættelseshukommelse og ordliste på tværs af hver lokalitet på én gang.

Fakta om PO- og POT-filer, der afgør valg af værktøj

Kilde: Smartling Hjælpecenter — Gettext PO/POT. Bekræftet 14. september 2026.

Hvordan redigerer jeg en .po fil til oversættelsesformål?

Korrekt redigering af en PO-fil er en sekvens i fem trin, og det første og fjerde trin er dem, der oftest springes over.

1. Start fra .pot-skabelonen, ikke en kopieret .po — Kør msginit --locale=de --input=messages.pot for at oprette et nyt katalog til den lokale sprogindstilling, som skriver en korrekt Plural-Forms og Language for den pågældende lokalitet. Kopiering af et andet sprogs .po og overskrivning af teksten medfører, at sprogets flertalsregler medfølger, hvilket er den mest almindelige kilde til ødelagte flertalsformer.
2. Flet skabelonændringer før oversættelse — Når kildestrenge ændres, skal du køre msgmerge --update de.po messages.pot så eksisterende oversættelser bevares, og nye eller ændrede poster tilføjes. Gennemgå alle poster markeret med msgmerge #, fuzzy , og fjern kun flaget efter at have bekræftet, at oversættelsen stadig matcher den nye kildetekst.
3. Oversæt i en PO-editor, ikke en teksteditor — Åbn filen i Poedit, Lokalize eller Gtranslator msgid msgstr Editoren præsenterer flertalsformer som separate faneblade, viser msgctxt som kontekst i stedet for tekst, der skal oversættes, og bevarer headerindgangen, så de strukturelle metadata overlever redigeringen.
4. Valider før du kompilerer — Kør msgfmt --check de.po -o /dev/null for at opdage headerfejl, tokens med uoverensstemmelser i formatet og problemer med flertalsantal. Behandl en exit-kode, der ikke er nul, som et mislykket byggetrin snarere end en advarsel; at opdage det her er forskellen mellem en fem minutters rettelse og en forkert streng i produktion.
5. Kompilér og commit source of truth — Generer den binære fil med msgfmt -o de.mo de.po som en del af builden, ikke manuelt på en server, og commit .po filen under behandling af .mo som et byggeartefakt. .po er den gennemgåelige kontrakt mellem kode og oversættelse; .mo er kun dens kompilerede output.

Denne tilgang passer til teams, der...

• Send et produkt, hvis UI-strenge allerede findes i gettext-kataloger – et Django-, WordPress-, PHP-, Python- eller C-program – og tilføjer en tredje eller fjerde lokalitet.
• Har haft mindst én msgfmt fejl eller en lydløst uoversat fuzzy-post, der når en udgivelse, og ønsker, at parseren i stedet for en kodegransker fanger den næste.
• Arbejd med oversættere, der ikke er udviklere og har brug for en side om side redigeringsflade i stedet for en teksteditor og en stilguide.
• Udgives ugentligt eller hurtigere, så oversatte kataloger skal ankomme som pull requests i stedet for som en batch leveret efter sprinten er afsluttet.
• Brug for den samme terminologi i en .po katalog, en JSON-ressourcefil og et hjælpecenter, som bruger én delt oversættelseshukommelse og ordliste i stedet for tre lokale.

Når en dedikeret PO-værktøjskæde ikke er den rette prioritet

• Produkter med én lokalitet, hvor gettext-runden tilføjer et byggetrin og et filformat uden at tilføje et sprog.
• Applikationer, hvis oversættelige indhold primært er brugergenererede databaserækker i stedet for brugergrænsefladestrenge; disse kræver en arbejdsgang på indholdsniveau, ikke et meddelelseskatalog.
• Kodebaser, der stadig hardcoderer, viser strenge, da udtrækning med xgettext skal ske, før nogen editor eller platform tilføjer værdi.
• Projekter, der allerede er standardiseret på XLIFF- eller JSON-ressourcefiler og ikke har nogen gettext-kataloger tilbage at administrere.

Kan du anbefale en brugervenlig PO-editor til begyndere?

Poedit er den sædvanlige første anbefaling til nogen, der åbner en PO-fil for første gang: den kører på Windows, macOS og Linux, åbner .po og .pot filer direkte, viser kildestrengen og oversættelsen side om side, håndterer flertalsformer og msgctxt som strukturerede felter og validerer kataloget, når du gemmer det. Brug disse spørgsmål til at bekræfte, at det er det rigtige udgangspunkt snarere end en standard.

Skal du installere noget andet end editoren?
En desktop PO-editor kompilerer .mo filen filen for dig ved lagring, så en oversætter, der arbejder alene, ikke behøver andet. En udvikler, der kører xgettext eller msgmerge skal stadig have GNU gettext-værktøjerne installeret separat, og på Windows og minimale Docker-aftryk er deres fravær den mest almindelige fejl på den første dag.

Vil editoren bevare filens struktur intakt?
Kontroller, at flertalsformer vises som separate fanebladsfelter, at headerposten overlever en gemning uændret, og at flagkommentarer såsom #, python-format bevares. En editor, der går i gang med disse tre ting, kan ikke nemt producere et katalog, der fejler msgfmt, som er den virkelige sikkerhedsegenskab for begyndere.

Oversætter du et WordPress-tema eller plugin?
Loco Translate redigerer PO-filer i WordPress-administratorpanelet, hvilket fjerner download-rediger-upload-cyklussen helt for et enkelt websted. Den bekvemmelighed holder ikke længere rent på tværs af flere websteder, fordi hvert websted har sine egne kataloger og sin egen oversættelseshukommelse.

Skal filen nå ud til en person uden for arkivet?
En desktop-editor antager, at oversætteren kan modtage en fil, åbne den og sende den tilbage. Når denne udveksling sker på mere end to eller tre sprog pr. udgivelse, bliver selve overdragelsen fejlpunktet, og en platformbaseret rundtur erstatter den.

Hvor mange lokaliteter vedligeholder du?
En eller to sprogindstillinger fungerer fint i en desktop-editor med en lokal oversættelseshukommelse. Ud over cirka fem er udnyttelsen af oversættelseshukommelse, håndhævelse af ordlister og statussynlighed vigtigere end redigeringsgrænsefladen, hvilket er det punkt, hvor et oversættelsesstyringssystem fortjener sin plads.

Hvordan håndterer Smartling PO- og POT-filer?

Smartling analyserer gettext-kataloger nativt under filtype-id'en gettext, indtager hver msgid som kildestreng og returnerer oversættelsen msgstr, så den fil, en udvikler committer, er den fil, der kommer tilbage oversat. Fire parser-adfærd fjerner ovenstående fejl i forbindelse med manuel redigering. msgctxt værdier registreres som variantmetadata, så "Hjem" som navigation og "Hjem" som adresseetiket bliver til to separat oversatte strenge. Udtrukne kommentarer, der starter med #. vises til oversættere som instruktioner, hvilket sætter en udviklernote over en streng i reel kontekst i CAT-værktøjet. Ved download omskrives headerne for Language og Plural-Forms for mållokaliteten — en engelsk kildeheader, der erklærer to flertalsformer, returneres som russisk tre — og oversættelser accepteres for alle fire CLDR-former, mens kun de tre gettext-understøttelser skrives ind i filen. Og parameteren file/get includeOriginalStrings=false returnerer en tom msgstr når der ikke findes nogen oversættelse, så applikationen vender tilbage til kildesproget i stedet for at sende engelsk til en post, der hævder at være oversat.

Ud over parsing eksponerer Smartling fildirektiver inline eller gennem API'en, skrevet som en kommentar i formen # smartling.gettext_line_width = normalized. Denne direktiv afspejler gettext-værktøjets egen 79-tegns ombrydning, så diffs forbliver læsbare; placeholder_format og placeholder_format_custom beskytter token-stile, som de native flag ikke dækker; pseudo_inflation angiver, hvor meget længere pseudo-oversættelser kører end kildeteksten, med en standardværdi på 30 procent; entity_escaping styrer, om XML-basistegnene escapes ved levering; whitespace_trim styrer indledende og efterfølgende mellemrum; og gettext_parsing_mode = keyed skifter til nøglebaseret parsing for kataloger, der bruger msgid som en abstrakt ressourcenøgle og beholder msgstr i . Oversættere ser hver streng i Smartling CAT-værktøjet med visuel kontekst, så en afkortet knapetiket fanges, mens strengen skrives, i stedet for efter .mo -filen. filskibe. På selve rundturen overvåger GitHub Connector et repository og returnerer oversatte kataloger som en pull-anmodning, og Smartling CLI og Java-, Python- og Node.js SDK'erne driver de samme uploads og downloads fra et CI-job, der derefter kører msgfmt.

Relaterede spørgsmål

• Hvordan implementerer man oversættelse i et Django-projekt?
• Hvad er de bedste værktøjer til redigering af ResX-filer?
• Hvad er de bedste GitHub-lokaliseringsværktøjer til oversættelse af kodelagre?
• Hvad er de bedste værktøjer til at konvertere CSV-filer til lokalisering?