TranslatePress Business adds the translator role and tracks which user edited each dictionary row in wp_users and the per-language dictionary tables. The default admin shows dictionary entries in a flat list and translator activity only inside the WordPress users screen, so a project manager auditing translator throughput pivots between two screens.

SleekView joins the per-language dictionary tables to wp_users on the editor column and surfaces one row per dictionary entry with translator, last-edit time, status, and target language as first-class columns. Saved views remember combinations like edited-by-alex-this-week or pending-review-from-ria.

Inline edits route through TranslatePress Business's dictionary save path so the audit columns update correctly and the translator role's capabilities are respected. Bulk approval of a translator's filtered output works the same way: each save calls the plugin's CRUD layer so the editor column and timestamps remain accurate.

The Business edition of TranslatePress adds the only feature that turns a translation plugin into project software: actual translator accounts with audit data. That audit data lives in dictionary tables and in wp_users, but the default admin presents it on two separate screens. Project managers end up keeping a spreadsheet of who is working on what, with throughput estimates that diverge from the live database within a sprint.

Reading the dictionary tables joined to wp_users directly closes that gap because the saved view always reflects the live audit columns. Per-translator backlog, per-language throughput, and approval queues all surface as one-click filters. Translators see their own personal queue scoped per role and managers see the cross-team picture.

The plugin still owns the writes, the role capabilities, and the dictionary logic. SleekView just makes the data legible enough that the spreadsheet is no longer necessary.