the problem
WordPress translation is dominated by two heavy plugins (WPML, Polylang) that bolt onto the existing post/term schema and bring decades of edge-case scaffolding. For new sites that want clean multilingual content and AI-assisted drafts, the plugin tax is steep — performance penalty, schema sprawl, and migration risk.
the approach
Flavor stores all translations in a single custom table keyed by (object_type, object_id, field_name, language, string_key) — one indexed lookup instead of a JOIN tree across
per-language post copies. No post duplication, no taxonomy multiplication.
Key capabilities:
- Single-table architecture —
{prefix}_flavor_translations, no per-language post copies - AI translation, opt-in — OpenAI Chat Completions API, administrator-triggered, no telemetry; nothing sent until an admin configures a key and clicks “Translate”
- WPML public-API compatible —
icl_object_id,wpml_translate_single_string,wpml_*filter shims; existing code keeps working after migration - Addon extension points —
flv/pre_translate,flv/pre_translate_batch,flv/translation_providerfilters let addons short-circuit or swap the provider - WP-CLI ready —
wp flavor translate,wp flavor migrate-wpml, batch processing - REST API —
/wp-json/flavor/v1/...with per-route capability checks - ACF aware — text, textarea, wysiwyg, and repeater group strings are translatable
- URL-prefixed locales —
/fr/about/,/de/about/, automatic hreflang and sitemap entries - Block-aware translator — Gutenberg block content translated with byte preservation
stack
- WordPress 6.0+, PHP 8.0+
- Custom DB table with composite index
- OpenAI Chat Completions API (opt-in)
- WP-CLI commands
- REST API
- React-based admin UI (
@wordpress/components)