Data format

PO converter

A .po file is a GNU gettext Portable Object: a plain-text translation catalog in which each entry pairs a msgid — the original string, which doubles as its own key — with a msgstr holding the translation. It is the format most open-source software is translated in, and it is designed to be readable and diffable in a normal editor.

Private for supported formats — processed in your browser

Convert supported files

Runs on your device

Drop PO files here

Batch files can each use a different output. Nothing uploads for local conversions.

Working inputs include camera RAW, browser-local audio/video, PDF, CBZ/CBR comics, office documents, ebooks, markup, 3D models, structured text, images, and archives.

Where PO comes from

Gettext began at Sun Microsystems in the 1990s and became GNU gettext, which standardised the .po/.pot/.mo trio still in use today. Its defining decision was to key entries on the English source text rather than on invented identifiers, so that untranslated software still displays something sensible. That choice shaped a generation of tooling — Poedit, Weblate, Transifex, Launchpad — and PHP, Python, C and countless others still ship gettext catalogs.

How PO works

  • Entries are blank-line-separated blocks of msgid and msgstr, each a sequence of C-style quoted strings that concatenate across lines.
  • The catalog opens with an entry whose msgid is empty; its msgstr carries the header fields, including Plural-Forms and the content charset.
  • msgctxt disambiguates identical source strings used in different places, and becomes the real key when present.
  • Plurals use msgid_plural with indexed msgstr[0], msgstr[1] … selected by the Plural-Forms expression in the header.
  • Comments are typed by their leading character: # translator, #. extracted, #: source reference, #, flags such as fuzzy.
  • A .po is compiled to a binary .mo for runtime lookup; the .po itself is the editable source.

When to use PO

  • Translating open-source software, where gettext is effectively the default
  • Reviewing translation changes in version control, since the format diffs cleanly
  • Moving a catalog into a platform that expects XLIFF, JSON or a mobile resource format
  • Extracting source strings for a translation memory or terminology check

Strengths and limitations

Strengths

  • Human-readable and diff-friendly, unlike every XML alternative
  • Untranslated entries degrade to the English source instead of showing a raw key
  • Mature plural handling that covers languages with more than two forms
  • Enormous tooling ecosystem

Limitations

  • Keying on source text means an English typo fix invalidates every translation of that string
  • Comments and flags are conventions layered on a simple grammar rather than typed fields
  • Needs compiling to .mo before an application can use it efficiently

Compatibility

Gettext runtimes exist for essentially every language, and desktop editors (Poedit, Lokalize, Gtranslator) plus every major translation platform read .po directly. Novus Convert parses the catalog locally, keys entries on msgctxt where present and on msgid otherwise, and converts between it and the other nine localization formats without uploading strings that may not be public yet.

Identifiers, source strings, translations and context are preserved. Header fields, translator comments, source references and flags such as fuzzy are not carried into formats that have nowhere to put them — converting a reviewed catalog to a mobile resource file loses the review state, not the translations.