The free Translate WordPress plugin (the GTranslate widget) keeps almost all of its WordPress-side state in wp_options under the GTranslate key, plus a handful of widget option rows. The default settings page is fine for an initial setup, but once a site runs several languages with custom URL rules and selector exclusions, the linear settings UI stops being a useful audit surface.

SleekView reads the GTranslate option row, normalizes its nested values into a flat table, and exposes each setting as a row with type, current value, and last-edited columns. Excluded selectors, language flags, URL formats, and analytics rules each become filterable facets in the grid.

The widget itself still proxies translations through GTranslate's service; nothing about that front-end behaviour changes. SleekView is purely an audit layer on the WordPress side that makes the option values legible.

The free Translate WordPress widget is built for one operator setting up one site in one sitting. Within those constraints, the settings page is perfectly adequate: pick languages, configure the switcher, save. The pain shows up six months later when an agency inherits a portfolio of forty client sites that all use this widget, each with slightly different exclusion selectors, custom CSS, and analytics rules.

At that point the agency does not need a fancier editor. It needs to compare configuration across sites, find which ones have alt-attribute translation disabled, and confirm that exclusion selectors still match elements on the redesigned templates. Treating the GTranslate option row as a table makes those audits possible.

A developer sees one row per setting, can filter by status, and can export CSV to compare against other sites in the portfolio. None of this changes how the widget translates content. It just turns a long settings page into a working audit surface for teams that manage many sites at once.