Quality checks

Machine translation is good, but not perfect. Some mistakes are cosmetic; others break a page: a missing closing tag, a changed link, a lost {name} placeholder that makes a template fail. Ponyglot checks every translation before it reaches your site.

Errors block, warnings travel

Findings have one of two severities.

Errors are problems that could break the page or violate a rule you set: broken HTML, changed links or placeholders, an empty translation, a text too long for its field, a changed brand name, a forbidden word. What happens next depends on who fixes errors on your site (see Who fixes errors below): either editors get the translation with the error marked, or it is held back until someone decides about it in the review queue.

Warnings are things an editor should look at, but that may be fine: a translation much longer than the source, a meta description longer than search engines show, a glossary term that doesn’t appear literally (perhaps because it’s inflected). The draft is delivered, and the warning travels with it, so the connector can show it next to the draft.

The split keeps two promises at once: nothing broken is published unnoticed, and editors aren’t bothered with matters of taste as if they were errors.

Who fixes errors

Each site has a QA mode (site settings, QA errors); your plan decides which modes you can choose:

Editors fix QA errors (all plans; the default on Pro, Growth and Scale)

For small teams where the editor is also the reviewer. The translation arrives complete, with the error marked next to the text, in the draft or suggestion. The editor fixes it like any other edit; publishing with an open error asks for confirmation. Connectors that can’t show errors yet get such translations held back instead.

Separate QA review before delivery (Agency, where it’s the default, and Scale)

For agencies and teams with a translator or reviewer. Translations with errors wait in the review queue; nothing with an error reaches the CMS. Editors see which segments are waiting and why, and pages arrive in one piece once everything is resolved. Reviewers get emails (right away or as a daily summary, on the Members page).

Either way, text you publish is checked again. If an error made it into published text, the review queue lists it under Published with QA issues.

Why held-back translations aren’t retranslated automatically

A delta job doesn’t retranslate segments held back by QA. The same source often produces the same problem again, and you would pay again for it. Instead, someone decides in the review queue: fix the text, deliver it anyway, discard it, or discard and retranslate.

The checks are simple on purpose

The checks compare strings and counts: which tags, which URLs, which placeholders, which terms. They don’t understand grammar. That makes them fast, predictable and explainable: every finding says what’s wrong in one sentence. It also means they can miss things, such as a tag moved to a different place or an inflected forbidden word. Editors remain in charge; QA helps them find the obvious problems first.

See QA checks for the complete list.