Using Gloty
WooCommerce & page builders
A store is the hardest thing to translate well: the content is spread across products, attributes, templates, JavaScript-rendered blocks, AJAX fragments, and transactional email. Gloty handles each of those differently — here is what to expect.
WooCommerce
The WooCommerce integration activates automatically when WooCommerce is active. No configuration required.
What gets translated
| Area | Covers |
|---|---|
| Catalogue | Product titles, descriptions, short descriptions, and excerpts; product categories and tags. |
| Attributes & variations | Attribute labels and variation option names — so a variable product's selectors read in the visitor's language. |
| Cart | Cart item names and the interface strings around them. |
| Checkout | Checkout field labels and placeholders. |
| Emails | Order email subjects and headings. |
| Breadcrumbs | The WooCommerce breadcrumb trail. |
The mini-cart, free-shipping bar, and order review
Since 1.15.0 WooCommerce re-renders the mini-cart drawer, the free-shipping progress bar, and the checkout order review as HTML fragments over its own AJAX endpoint, then swaps them into the page. Gloty translates those fragments — so strings like Subtotal, View cart, Checkout, and your free-shipping message no longer snap back to the source language after adding an item.
If a cached or third-party script calls the cart endpoint without a language prefix, Gloty recovers the visitor's language from the page they are on, so the fragment still renders translated.
Cart and Checkout blocks
Block-based Cart and Checkout need language packs. Those blocks render in the browser with JavaScript, so their text never appears in the HTML Gloty can read. The fix is WordPress's own translation files.
Since 1.6.0 Gloty installs the matching WordPress language packs — core, your active theme, and your plugins including WooCommerce — automatically in the background whenever you add or activate a language. With the WooCommerce pack installed for, say, German, WordPress feeds those blocks translated strings and they render in German.
To check or re-run the install:
- The setup wizard's Install language packs step reports how many packs were added.
- Adding or activating a language later triggers the install again for that language.
- Language packs only exist for strings the plugin authors have had translated. A string with no community translation stays in English — that is a limit of the pack, not of Gloty.
Store URLs
Shop, product, category, and cart URLs all keep the active language
prefix, including the AJAX endpoints the cart uses. A customer
browsing in /de/ stays in /de/ from
catalogue through checkout.
Prices, currency, and tax
Gloty translates text. It does not convert currency, change prices, or alter tax and shipping rules — those stay under WooCommerce's control, where they belong. Pair Gloty with a multi-currency plugin if you need per-market pricing.
Put your product names in the glossary. Product and brand names are exactly what machine translation mangles, and exactly what customers search for. Add them to the glossary before your first large translation run: they stay verbatim, and they stop consuming quota.
Store performance
Product pages contain far more translatable strings than a typical page. Gloty loads all translations a page needs in a single query and holds them in memory for the request, which removes the bulk of the per-string lookup cost on sites without a persistent object cache. 1.13.0 / 1.14.0
If you run a large catalogue, a persistent object cache (Redis or Memcached) plus a page cache is still the biggest single improvement you can make — for WooCommerce generally, not just for Gloty.
See also our guide on translating a WooCommerce store.
Page builders
Because Gloty reads the rendered page rather than a specific builder's data format, builders work without per-builder configuration. Elementor, Beaver Builder, Divi, and similar tools translate on the front end like any other markup.
Elementor
Elementor gets explicit handling: Gloty stays out of the way inside the Elementor editor and its preview frame, so you always edit your real source content and never a translated copy. On the front end, Elementor-rendered content is translated normally.
Working with builders
- Always edit in the source language. Translations are stored separately and generated from the source; editing a translated view is not how Gloty works.
- Expect a delay after a layout change. New text is discovered when the page renders, then queued and translated — it is not instant.
-
Exclude what should not be touched. Add a CSS
class or selector for code samples, credits, or embedded widgets
to Exclusion selectors in
Settings. The defaults
.notranslateand.skip-translationwork out of the box — add either class to any element.
Other integrations
| Plugin | What Gloty does |
|---|---|
| Yoast SEO | Translates its meta titles, descriptions, social tags, breadcrumbs, and canonicals instead of emitting duplicates. |
| Rank Math | Same treatment as Yoast. |
| LiteSpeed Cache, WP Rocket, W3 Total Cache, WP Super Cache, Cache Enabler, WP Fastest Cache, SiteGround | Purges each language-prefixed URL when its translations change. |