Babble Multilingual takes a different approach from custom-table plugins: it creates a shadow post type per active language and stores translations as posts in wp_posts with that shadow type, linked back to the original through _babble_* postmeta. The architecture stays close to core WordPress, but coverage is invisible because every shadow type lives in its own admin list.

SleekView reads wp_posts joined against wp_postmeta on Babble's linking keys, then surfaces every original with one column per active language. Each cell resolves to published, draft, stale, or missing based on the matching shadow post's status. Saved views remember which post types and language subsets a team is responsible for.

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

Babble's shadow-post architecture is elegant on paper and operationally awkward in practice. Every translated post is a real WordPress post in its own shadow type, which keeps queries fast and the schema portable. The cost is that every language gets its own admin list, and there is no single screen that says how many originals still need French.

A site that has run Babble for a year often has thousands of originals and a long tail of shadow posts in three or four languages, and the only way to find coverage gaps is to open each shadow-type admin list one at a time. Reading wp_postmeta for _babble_* links directly closes that gap. A localization manager can see at a glance that 312 originals are missing French and 47 pages need a German update.

A translator can pull a CSV of exactly the work they own. The plugin keeps doing what it does well; the audit layer is what the default admin never tried to be.