qTranslate X stores all language variants inline in the same wp_posts.post_content field, separated by markers like [:en], [:de], [:fr], and a terminating [:]. That schema means a single row holds every language, which is elegant on the front end but opaque in the admin: the default post list cannot show per-language coverage because all languages share the same row.

SleekView parses the language markers at query time and pivots the inline content into per-language columns. Each post becomes one row with a status badge per configured language, based on whether the corresponding marker section is empty or populated.

The plugin itself is no longer actively maintained, but many sites still run it. SleekView treats the inline-marker schema as a read-mostly source of truth, with optional write-back for inline status flags via wp_postmeta rather than direct edits to post_content.

qTranslate X is no longer maintained, but it still runs on many production sites because migration to a successor plugin is a real project. The inline-marker schema is elegant in its way: one post row holds every language variant, separated by tags. That elegance becomes a problem in the admin, where the default post list cannot show per-language coverage because all variants share the same content field.

Sites running qTranslate X for years often have no clean answer to the question of which posts are missing a French translation, or which German translations are placeholder text from a hasty rollout. Parsing the [:lang] markers and pivoting them into per-language columns gives that answer in seconds. The grid is read-mostly to protect post_content from accidental edits, but the coverage matrix it produces is exactly what a migration script to Polylang or WPML needs as input.

Site owners who plan to stay on qTranslate X for now get an audit surface they have never had. Site owners who plan to migrate get a concrete starting point with no surprises.