DeepL WP integrations typically write translation cache into wp_options under a plugin-specific prefix and tag posts with DeepL-specific postmeta keys such as _deepl_target_lang, _deepl_last_translated, and _deepl_source_hash. That is enough for the plugin to detect changes and reuse cache, but the default admin offers no consolidated view of what is in the cache or which posts are still pending.

SleekView reads the relevant wp_options rows and joins them against wp_posts and wp_postmeta so every translatable post surfaces with target language, last-translated date, source hash, and pending-update flag as columns. Saved views remember the slice an editor cares about, like pending-since-launch or stale-because-source-edited.

Edits route through the plugin's API for inline changes where supported, and direct meta updates fall back to standard update_post_meta calls. The DeepL API itself is not called from SleekView; the plugin retains full control of when and how it talks to DeepL.

DeepL integrations are designed to make translation cheap and invisible. The plugin writes cache entries to wp_options and tags posts with _deepl_* meta, then quietly serves cached pairs whenever it can. That is exactly what most sites want until the audit question shows up.

Which posts are still pending? Which got stale after a content refresh? How much cache volume drove last month's DeepL bill? Reading the cache options and the per-post meta directly closes those gaps. A localization manager can see at a glance that 312 posts are missing French and 47 went stale after the homepage rewrite. Finance can chart cache volume by language to forecast next month's API spend.

The plugin keeps doing the translation work and the API calls, while the audit layer answers the operational questions the settings screen never tried to.