WorkMore Site Translator

Open Pages, find the page and click the “+” in its Languages column. A draft copy opens in your editor; translate it and publish. The two pages are linked from then on.

As many as you need. Settings → Site Translator lists them; each one gets its own URL prefix, its own menu locations, its own site title and tagline, and a place in the language switcher.

Yes. The Content card under Settings → Site Translator lists every post type and taxonomy that has an admin screen; tick the ones that should carry a language. Unticked content is shown in every language as it is.

Yes. A translation is a copy of the page including the builder’s data, so it opens in Elementor, Flatsome’s UX Builder or any other builder exactly like the original — you translate the texts in place.

Everything that exists when you activate the plugin is in your default language and keeps its URL. Nothing is copied or changed until you create a translation.

The language most of your content is written in. Visitors get that language at your plain URLs and every other language under its prefix ( /th/ , /en/ , …). The default language also decides which core, theme and plugin translations the visitor side loads — independently of Settings → General → Site Language, which keeps governing the dashboard. If you already have content in several languages, pick the biggest one as the default and mark the rest in the Language box or with Tools → Assign.

Three ways, all set up under Settings → Site Translator, where you pick the style (inline links, list, pills or a dropdown), the label (native name, English name or code) and an optional accent color, and see a live preview: as a menu item (Appearance → Menus → “Language switcher”), as a widget, or with the [wmst_switcher] shortcode / wmst_language_switcher() template tag anywhere in your content, builder or theme. No JavaScript is loaded; the switcher takes the color of the text around it, so it fits light and dark headers alike, and color="…" / bg="…" on the shortcode (or a few CSS variables, listed in the settings) recolor it.

Yes. Build a menu in another language and assign it to that language’s twin of a location under Appearance → Menus → Manage Locations. A language switcher can be added to any menu as well.

Your posts, pages and other content translate as usual on a WooCommerce site. Products themselves are not offered for translation: copying a product takes more than copying a post (variations, SKU, stock). That is what the separately sold Pro add-on does — translated products, variations, categories and attributes, synced price and stock, shop/cart/checkout/account pages per language, cart and order language, customer emails.

No. A language is an ordinary term on each post; lists are filtered by one indexed clause, translations are read from the object cache, and the only frontend output besides the hreflang tags is the switcher’s small inline CSS on pages that show a switcher.

No. The plugin makes no network requests of its own. The optional “Install language pack” button on the settings screen uses WordPress’ own language-pack installer, which downloads from WordPress.org exactly as Settings → General does. The only outbound link is the “Upgrade to Pro” button, which opens our website when you click it.

Deactivating never deletes anything. Uninstalling removes language assignments, translation links and settings only if you opted in to “Delete language data and settings when the plugin is uninstalled”. Translated posts and pages are ordinary content and are never deleted.