qTranslate XT continues the qTranslate X schema: every configured language lives inline in the same wp_posts.post_content row, separated by markers like [:en], [:de], [:fr] and a terminating [:]. The fork actively patches edge cases, but the underlying admin still cannot pivot per-language coverage because all variants share the same content field.

SleekView parses those markers at query time and produces one row per post with a status badge per configured language. Filters like missing-in-Spanish, short-in-German, or filled-in-all-languages become saved views that load with one click, even on sites with tens of thousands of qTranslate XT posts.

Edits are read-mostly by default. Optional status flags are saved as wp_postmeta instead of direct edits to post_content, so the rich inline-marker structure remains intact and survives upgrades of the qTranslate XT plugin.

qTranslate XT keeps the qTranslate family alive on modern WordPress, which is genuinely useful for the long tail of multilingual sites that cannot migrate easily. The community has done careful work on Gutenberg compatibility and on patching the inline-marker schema for current core releases. What the fork has not changed is the fundamental admin limitation: per-language coverage cannot be pivoted out of a single content field by the standard post list.

Anyone running qTranslate XT at scale ends up maintaining a spreadsheet of which posts are translated where, which works until it does not. Treating [:lang] markers as a parseable schema and pivoting them into per-language columns is the missing audit layer. Site owners gain real coverage numbers, editors see exactly which posts need a French version, and migration planners get a concrete CSV to feed into Polylang or WPML import scripts.

The plugin keeps its current schema and the fork's careful compatibility work; only the admin gains a queryable surface that the original qTranslate plugins never built.