WPML Media Translation creates a translation row in icl_translations for each attachment in wp_posts with post_type=attachment, then stores per-language alt text and captions back in wp_postmeta. The default Media library handles language switching well but doesn't show coverage as a pivot, so an editor reviewing 6,000 images for French alt-text coverage clicks through page after page of the grid view.

SleekView joins icl_translations to wp_posts for attachments and renders one row per file with a column per language showing whether the translation exists and whether alt text is set. Saved views remember filters like missing-alt-in-French or attachments-uploaded-this-quarter, so accessibility audits load with one click.

Edits route through the WPML Media Translation save path so alt-text and caption changes hit the same hooks the plugin uses internally. Bulk updates work the same way: set alt text on fifty rows at once and each save still goes through the plugin's CRUD layer for proper cache invalidation.

Attachments are where multilingual sites quietly fail audits. The plugin makes per-language alt text trivially possible but the Media library was designed for browsing by upload date, not for auditing coverage across six languages and 6,000 files. Accessibility audits then run on spreadsheets that capture a snapshot of wp_postmeta at one moment in time.

By the next sprint the spreadsheet is stale because uploads, alt-text edits, and translation jobs have moved on. Reading icl_translations joined to attachment postmeta closes that loop because the saved view always reflects what's in the database now. Editorial teams see which campaign images are blocked on French alt text before the campaign launches, accessibility auditors run their remediation list against live data, and localization managers can budget translation work in concrete file counts.

The plugin still owns the attachment storage, the language relationship, and the alt-text save logic. SleekView just makes the coverage visible enough to act on.