What the POM Translate architecture optimizes

POM Translate is designed to avoid duplicate WordPress objects, repeated translation lookups, and write work during a visitor request. Those choices reduce specific costs, but they do not guarantee that every translated page will be faster than its source route.

Save-time work protects read-time work

The more expensive structural work happens when eligible source content is saved:

  • parse the source body;
  • discover supported values and attributes;
  • freeze inline markup;
  • build the content skeleton;
  • update source associations;
  • remove obsolete rows;
  • prepare localized slug entries.

A target visitor does not ask the parser to rediscover this structure. The renderer reads the prepared representation and existing translations.

This moves predictable editorial work away from high-volume public traffic.

One object avoids duplicate query models

WordPress queries return canonical posts and terms. POM Translate localizes their supported values after object selection instead of joining or synchronizing a second set of language-specific content records.

This benefits integrations that already work by canonical ID and reduces duplicated relationship management. It does not eliminate the normal WordPress query, theme rendering, shortcode execution, or integration work needed on an uncached request.

The runtime primes source rows and translation maps for related subjects instead of performing an isolated lookup for every displayed string. Dedicated bulk preparation exists for post localization, terms, menus, and translation sets.

Within a request, repeated subject, exclusion, slug, registered-string, and translation lookups can be reused. This is especially important on archives or menus where many localized objects appear together.

Cache groups serve different lifetimes

POM Translate uses WordPress’s object-cache API for separate purposes:

  • request-only values that must not survive into another request;
  • supported data that can be reused across requests when the site has a persistent object-cache backend;
  • short-lived completed-body entries separated by post, locale, rendering options, and renderer version.

Without Redis, Memcached, or another persistent object-cache backend, WordPress’s cache API still avoids repeated work during the current request, but most entries do not survive into the next request.

Fallback prevents expensive repair work

An empty target value returns its source unit. An invalid placeholder translation also falls back. An incompatible or unresolved skeleton abandons the reconstructed result.

The renderer does not:

  • write a repaired translation;
  • queue machine translation;
  • call POM AI;
  • regenerate the source skeleton;
  • scan all content to find a substitute.

This keeps the public path read-oriented and bounded.

Dedicated maps avoid blanket filters

Localized slugs, registered strings, software catalogs, menus, supported metadata, REST payloads, and WooCommerce contexts use focused handlers. POM Translate does not apply one unconditional “translate every string” filter to all WordPress output.

Focused surfaces reduce unnecessary work and prevent technical or private values from entering a generic translation lookup.

Internal caching is not full-page caching

Even a warm POM Translate object cache still allows PHP, WordPress, the theme, and active plugins to run. A full-page cache or CDN can skip more of that stack for eligible anonymous traffic.

Use these layers together with clear ownership:

CDN or static page cache
        ↓ on a miss
WordPress request
        ↓
POM Translate prepared data and object caches
        ↓
Localized output

Do not attribute a CDN hit, page-cache hit, or optimized database query solely to the translation architecture.

Where performance can still vary

Target routes may do additional work for:

  • skeleton reconstruction;
  • translation maps and metadata;
  • localized menus and terms;
  • link and slug localization;
  • canonical and alternate-language metadata;
  • WooCommerce or REST context handling.

Theme templates, page builders, shortcodes, remote calls, object-cache persistence, PHP opcode caching, and full-page caches often have a larger effect than the translation lookup itself.

Measure the actual deployment instead of relying on architecture alone. Measure multilingual performance responsibly provides a controlled procedure.

One post, many languages
Previous
Translate public settings values
Next