Integrations

LocaleReady translates final rendered HTML, so most plugins need nothing written for them specifically — if a plugin prints ordinary markup, that markup translates. Three situations do not fit that model, and got dedicated support. This page is the technical reference; see integrations on the main site for the plain-language version.

WooCommerce

• Cart and checkout. These run on WooCommerce’s Store API, fetched by the browser after the page has already loaded — not something the page-render pipeline ever sees. LocaleReady translates Store API responses field by field: product names and labels already in memory are filled in immediately, and one unfamiliar string never blanks out the rest of the response.
• Prices and counts. Amounts, currency symbols, and the mini-cart item counter are excluded from every provider by default, layered on top of LocaleReady’s own currency-pattern protection.
• Order email. LocaleReady remembers the language a customer checked out in and sends every later order email — a shipping notice, a refund notice — in that language, regardless of which admin screen triggered it. The shop’s own copy of the same email is untouched.
• The mini-cart’s REST base. WooCommerce’s own script only sets state.woocommerce.restUrl on the cart and checkout pages; LocaleReady fills it in everywhere else the mini-cart can appear, so it does not fail on a translated URL.

Gravity Forms

Gravity Forms queues its notifications and sends them from a background task with no request, no referrer, and no visitor cookie behind it — sometimes minutes later, sometimes from “Resend Notifications” months after the fact. LocaleReady writes the submitting visitor’s language onto the entry the moment it is submitted, and reads it back whenever the notification actually sends. The form itself, its labels, and its validation messages need nothing special — they translate through the ordinary page pipeline.

Page builders

Elementor, Divi, Beaver Builder, and Oxygen all render their output as plain HTML on the front end, which LocaleReady translates without any builder-specific code. The one thing every builder needs is to have its live-editing canvas excluded — that canvas also renders through the front end, and translating it would risk saving translated text back into your source content on the next save. LocaleReady recognizes each builder’s editing request by its query argument and leaves it alone. This check runs unconditionally and is inert on a site without the builder installed, which is also why a builder not listed here by name is not necessarily unsupported — the check is about the shape of a request, not a list of known plugin slugs.

SEO plugins (Yoast SEO, RankMath)

Both plugins print a schema.org graph as a <script type="application/ld+json"> tag, which HTML parsers (including LocaleReady’s own segmenter) treat as raw text and skip. LocaleReady reads that graph directly, translates its prose fields, and rewrites the URLs inside it to the translated page’s own address — so the graph never contradicts the translated canonical link a few lines above it. This runs whether or not the rest of the page’s text is being machine translated, because the URLs are the part a search engine actually acts on.

Writing your own integration

Everything above is built from the same public filters documented in hooks and filters — nothing here reaches into a private API. If a plugin you run has its own AJAX action, its own JSON shape, or its own notification queue, the filters that make WooCommerce and Gravity Forms work are the ones to reach for.