Bogo stays close to core WordPress on purpose. Each translation is a duplicated post in wp_posts with a _locale postmeta value and a _original_post reference to its source. The default admin shows a small locale switcher in the post list, but no combined view across locales and no way to spot which originals are missing a Japanese or French copy at a glance.

SleekView reads wp_posts joined against wp_postmeta on _locale and _original_post, then surfaces every original with one column per active Bogo locale. Each cell shows the linked post status, the last-modified date, or a missing badge if no translation exists for that locale yet. Saved views remember which post type, which locales, and which gap pattern a team cares about.

Edits route through the same WordPress post API that Bogo uses, so updating a translation's status or slug in a SleekView row triggers the same hooks any other admin action would. There is no shadow schema and no risk of drifting from core post behaviour.

Bogo's design choice to stay on wp_posts instead of adding custom tables is what makes it so easy to install and so portable across hosts. The same choice is what hides translation coverage in the default admin, because the post list can only show one locale at a time. A site running Bogo for a year often has thousands of originals and a long tail of locale duplicates, and the only way to find which originals still need a French version is to filter the post list by _locale manually and cross-reference.

That works for a handful of pages and breaks for a real localization programme. Reading wp_postmeta for _locale and _original_post directly closes that gap. A localization manager can see at a glance that 312 posts are missing Japanese and 47 pages need a French update, and route work to the right translator with a scoped CSV.

The plugin keeps doing what it does well; the audit layer is what the default admin never tried to be.