Automatic Translate Addon for WPML extends WPML's translation management with machine-translation providers like Google, DeepL, and Microsoft. Jobs go through WPML's standard icl_translate_job pipeline and write back to icl_translations, with addon-specific status flags stored alongside. The WPML Translation Management screen shows this through a heavy interface that does not aggregate well across thousands of jobs.

SleekView reads icl_translate_job, icl_translations, and the addon's batch metadata directly, then renders results server-paginated. Each row is a job with source post, target language, provider, machine-translation status, and review status as first-class columns. Saved views remember which providers, languages, and review states a localization team filters on every week.

Edits route through the WPML and addon APIs where supported, so changing a job's review state from a SleekView row triggers the same hooks the addon's UI does. There is no direct schema write that would bypass the plugin's expected flow.

Auto-translation at scale is a queue management problem more than a translation problem. A site running the addon for six months across four target languages and two providers easily accumulates tens of thousands of icl_translate_job rows. The default WPML Translation Management interface was built for human translation workflows and stalls under that volume, hiding pending-review and failed jobs behind paginated lists that reset on every navigation.

Reading the job tables directly closes that gap. A reviewer can load a saved view of pending-review-in-French sorted by job age and clear two hundred entries in an afternoon. A localization manager can compare provider quality across languages with concrete numbers instead of estimates.

An engineer can filter to failed jobs and triage provider errors before they pile up. The plugin keeps doing the translation work, and the audit layer is what makes the queue manageable.