How It Works

Understand local translation storage, delivery and automation flow.

The core architecture

Administrator
    ↓
WordPress scanner
    ↓
Translation segments / global strings
    ↓
Translation queue
    ↓
DeepL / Google / custom provider
    ↓
Stored WordPress translations
    ↓
Frontend renderer + language switcher
    ↓
Visitor switches instantly

The external provider is an authoring tool, not the frontend delivery system.

Source content versus translations

The plugin keeps the original WordPress page/post as the source of truth. It does not create a duplicate WordPress page for every language.

Instead it stores translation records keyed to stable translation segments. A segment may represent:

• page title
• paragraph
• heading
• Elementor field
• Gutenberg block text
• post excerpt
• shortcode-rendered text
• visually discovered rendered text

Source hashes

Each source segment has a hash. If the source text changes, an existing public translation can be marked Needs Review rather than silently presenting an outdated translation as current.

Server-side and client-side rendering

The plugin uses both approaches because modern WordPress sites are heterogeneous:

• Server renderer applies translations while WordPress generates HTML.
• Frontend binder handles content that is easier to identify after rendering, including delayed/dynamic builder output.
• Rendered-site discovery crawls published content to find human-visible text missed by source scanning.

This layered approach is why the plugin can support WordPress core content, Elementor, shortcodes and third-party plugin output without requiring each plugin to provide a dedicated integration.