WPML Translation Management creates a row in icl_translate_job for every translation job, with the actual field-level translations stored in icl_translate and the post-language relationship tracked in icl_translations. The default queue dashboard shows jobs grouped by translator and status, but filtering by deadline or word count means clicking through multiple screens and losing the view between visits.

SleekView joins icl_translate_job to icl_translations and surfaces one row per job with translator, source language, target language, deadline, word count, and status as first-class columns. Saved views remember which combinations matter, so the Monday review of overdue Spanish jobs is one click instead of three filters.

Edits route through the WPML Translation Management save path so reassigning a translator or changing a deadline fires the same hooks as the default dashboard. Bulk reassignment of stalled jobs becomes practical because the filter selects exactly the jobs that need to move.

Translation Management is where WPML graduates from a translation utility to actual project software, but the dashboard that ships with it stops scaling somewhere around fifty active jobs. Project managers then maintain a parallel spreadsheet of who is working on what, which deadline is at risk, and how many words are in flight per translator. That spreadsheet diverges from the database within a week.

Reading icl_translate_job directly closes the gap because the saved view is always the live state of the queue, not a snapshot. Overdue jobs surface as a one-click filter rather than a Monday-morning audit by hand, and translator reassignment becomes a bulk operation against a precisely scoped set. The plugin still owns the editor, the service integrations, and the assignment hooks.

SleekView just gives the people running the program the table that they were trying to recreate in a spreadsheet anyway, with concrete numbers tied to the source rows.