Linguise Translate handles translation through its own service and stores the WordPress-side configuration that makes a multilingual site possible: the active-language list, the original URL set, the per-page translation references, and the rules around which post types and paths are translated. The Linguise side dashboard answers marketing questions like traffic and word counts; what it does not give back is a per-post coverage view inside WP admin.

SleekView reads the same active-language option and the per-page meta Linguise writes and renders every translatable post as a real table. Title, post type, language, translation status, source URL, and last-modified become first-class columns with sort, filter, and inline edit on WordPress-side fields. A localization manager can scope to one language and one post type or pull every missing row in a single click.

The hosted service still handles the actual translation and the URL swap on the front end. The table view owns the audit surface, so untranslated pages and stale references stop hiding behind a hosted-side traffic graph.

Linguise Translate succeeds by hiding the translation step behind a hosted service, which is also why the WordPress side stays thin. Traffic graphs and word totals on the Linguise dashboard answer marketing questions, but they never tell a localization manager which German pages shipped untranslated last week or which French references have gone stale since the source was rewritten. Reading the active-language option and the per-page references already in WordPress turns those questions into a real table.

Language, status, and source URL become first-class columns. Filters compose, so an editor can pull every missing row for one language in a click. Saved views split the audit by role so localization managers, editors, and stakeholders each get their own slice.

Linguise keeps doing the translation, the table view keeps the WordPress-side state honest.