Parly — Simple Multi Language

Yes. Duplication copies all post meta, which is where page builders store their layouts, so each translation is edited with the same builder as the original. For AI bulk translation, note that builders like WPBakery and Divi keep visible text inside shortcodes (e.g. [nectar_split_heading text="..."]); Parly's export and prompt tell the AI to translate that text while preserving the shortcode structure. After importing a page-builder page, review it and, if a heading did not translate, open it in the builder and adjust — editing text where it actually lives is always the most reliable.

Yes. Create one menu per language in Appearance → Menus, then map them in the Menus tab (per theme location, per language). Parly swaps the menu automatically based on the language of the page being viewed.

Removing a language shows a confirmation screen listing every affected page. By default pages are moved to the trash (recoverable); you can optionally delete them permanently, which requires typing the language code to confirm.

Export generates a JSON file with your content and embedded instructions for the AI, plus a ready-to-paste prompt shown on screen. You attach the file to any AI chat, paste the prompt, and upload the returned JSON. Parly validates the file, repairs common formatting mistakes, and creates translations as drafts (or published, your choice). No API keys, no external calls — the plugin never contacts any server.

No. Parly makes no external requests. The AI translation step happens entirely outside the plugin, in whatever tool you choose. The site scanner only fetches pages of your own site.

One functional cookie (parly_lang, 30 days) may be set in two situations: when automatic browser detection is enabled (to make sure detection happens only once) and when a visitor manually picks a language in the switcher (to remember the choice). It contains only a language code and is never sent to third parties.

Two options. First, the Theme texts tab: scan a page, register the texts it finds, and Parly replaces them in the rendered HTML on translated pages — no theme changes needed. Second, for text a developer controls, the parly_t( array( 'en' => 'About us', 'pt' => 'Sobre nós' ) ) helper returns the string matching the language of the page being viewed. If a theme cannot be edited and the scanner does not reach the text, a plugin with a different (automatic, external-service) approach such as Weglot may fit better — different trade-offs, usually a paid subscription.

If your theme builds a page's content inside a custom template (for example front-page.php, or a page-home.php matched by the home slug), WordPress only uses that template for the original page. A duplicated translation has a different slug (e.g. home-2) and is not the configured front page, so it falls back to the generic page.php and, if the content field is empty, renders nothing. Point the theme at the original page with parly_get_original_id(). In page.php (or wherever the branch lives): $parly_id = function_exists( 'parly_get_original_id' ) ? parly_get_original_id() : get_queried_object_id(); if ( (int) get_option( 'page_on_front' ) === $parly_id ) { get_template_part( 'template-parts/home' ); return; } Now every language variant reuses the same custom markup. Use parly_t() / parly_get_current_lang() inside that markup (or register the visible strings under Theme texts) so the reused template shows text in the current language. parly_is_translation() is also available if you only want to branch on translated views.

The switcher link for that language falls back to the site homepage. Unpublished (draft) translations are never linked.

No. Running two multilingual systems at once causes conflicts. Parly shows a notice if it detects one active, and you should use only one at a time.