Google Translate WP Pro stores cached translation pairs in wp_options under a plugin-specific prefix and tags translatable posts with metadata like translation status, target language, and source hash in wp_postmeta. The plugin's settings screen handles API keys and language picker config, but does not consolidate cache contents or per-post status.

SleekView reads the relevant wp_options rows and joins them against wp_posts and wp_postmeta. Each row is a translatable post with target language, status, cached flag, last-translated date, and source author as columns. Saved views remember the slice each team works through, like pending-on-launch-day or stale-after-content-refresh.

Edits route through the plugin's API for status changes where supported, and fall back to update_post_meta otherwise. The Google Translate API itself stays inside the plugin so quota and billing remain its responsibility.

Cache-based translation plugins are designed to make machine translation invisible. The settings screen handles API keys and the front end gets the translated result, and most days that is enough. The audit question lands when launches stack up.

Which posts are still pending in Spanish before the campaign goes live? Which cache entries went stale after the homepage rewrite? How much cache volume drove last month's bill? Reading wp_options and the relevant wp_postmeta rows directly closes those gaps. A localization manager can see at a glance which posts need a re-translate, finance can forecast cache cost by language, and editors can confirm coverage before pushing publish. The plugin keeps making the API calls; the audit layer answers the operational questions the settings screen never tried to.