Cool Plugins AutoPoly - WordPress Plugin

A Guide to Configuring and Using Cool Plugins AutoPoly for Polylang

Cool Plugins AutoPoly becomes useful when a site is already built on Polylang, but creating translations manually starts taking more time than publishing the content itself. This guide focuses not on a promotional overview of the plugin, but on a practical workflow: what to check before installation, how to choose an automatic translation method, how to prepare pages, taxonomies, fields, and editors, how to verify the result, and where to look when part of the text remains untranslated.

AutoPoly does not replace the architecture of a multilingual site. It works on top of Polylang and speeds up the steps you would normally do by hand: create a language copy of a post, select the target language, send the content to a translator, return the text to the editor, and then review the page. So the real question is not whether to "click one button" or not, but what content can safely be handed off to automation, where editorial review is still needed, and which elements should be prepared in advance.

This guide is written for site owners, editors, WordPress administrators, and developers responsible for the quality of a multilingual site. You will see exact interface labels such as Languages, AutoPoly, Settings, Translate Now, Bulk Translate, and Update Content. They are intentionally left in English because those are the labels used in the product documentation and interface examples.

One important caveat: automatic translation is useful for quickly producing a draft of a localized page, but it does not guarantee perfect terminology, legal accuracy, preservation of meaning in complex wording, or correct handling of every dynamic block. The best results come when AutoPoly is used as a workflow accelerator, not as a replacement for final editing.

What Problem AutoPoly Solves Alongside Polylang

Polylang handles the language structure of WordPress: languages, links between originals and translations, language-specific URLs, the language switcher, and the mapping of each post to its locale. But Polylang alone does not turn all content into a finished translation in one click. In most cases, an editor still has to open the post, create a language version, copy the structure, paste in the translation, check the blocks, assign categories, and save the result.

AutoPoly adds an automatic translation layer to that workflow. According to the official product page and documentation, the plugin can duplicate and translate titles, content, images, galleries, and some meta fields, and it can work with Gutenberg, Elementor, Classic Editor, and Divi depending on the editor and the capabilities of the version you use. This becomes especially valuable on sites with many similar pages, listings, categories, landing pages, Elementor templates, or posts with repetitive structure.

The practical value of the product is easiest to see in this sequence:

1. The site already has a primary language and Polylang is enabled.
2. The administrator adds the target language and checks the URL settings.
3. The editor opens a page or selects multiple pages from the list.
4. AutoPoly creates the translation through the selected engine.
5. The editor saves the result, reviews the public page, and manually fixes any places where the automatic translation got it wrong.

AutoPoly's main strength is reducing repetitive manual work. Instead of copying page structure and moving blocks by hand every time, the editor gets a usable translated version much faster. But the quality of the result still depends on the source markup, block support, the selected translation provider, your terminology rules, and how disciplined the review process is.

Where the Plugin Fits Best

AutoPoly is a good fit for sites that have already committed to using Polylang and mainly need to speed up content translation. That can include corporate websites with dozens of service pages, blogs with regular publishing schedules, educational projects, Elementor landing pages, catalogs with custom post types, and stores where product descriptions need to be produced quickly in multiple languages. In projects like these, translating each page manually often becomes the bottleneck.

Another strong use case is launching a new language version for the first time. When a site already contains a large volume of content, the editor's goal is not to craft one perfectly translated article, but to quickly build the basic multilingual structure, spot the gaps, and distribute the manual review work. In that scenario, bulk translation and taxonomy translation save far more time than translating one page at a time.

Where You Should Not Expect Miracles

The plugin should not be treated as a universal localization platform for every complex setup. If the site relies heavily on custom shortcodes, custom blocks, advanced fields, dynamic widgets, content from external APIs, or legally sensitive copy, you should test everything on a site copy before doing a broad rollout. The documentation clearly shows that custom blocks and fields require separate configuration, and the WordPress.org FAQ warns that some content outside supported blocks or widgets may not be included in automatic translation.

AutoPoly is also not the right choice for anyone trying to move away from Polylang. It is specifically an add-on for Polylang, not a standalone multilingual system. If the site has not yet settled on a translation architecture, compare the available approaches first: Polylang with AutoPoly, visual translation with TranslatePress, cloud-based Weglot, the broader WPML ecosystem, or manual localization handled by editors.

What to Check Before Installation and First Launch

Before installing the plugin, it is not enough to confirm that WordPress loads and plugins can be installed. For AutoPoly, three layers matter: Polylang readiness, content structure, and the selected translation engine. If any one of those is not prepared, the issue often looks like "the plugin did not translate the page," when the real cause may be an unsupported block, a taxonomy that was never enabled, a missing translation key, or a target language that was set up incorrectly.

Check the Basic Language Setup

First, make sure Polylang is already configured: the primary language is assigned, target languages are added, the language switcher appears where visitors need it, and the site's URL structure makes sense. If language pages are being created chaotically, AutoPoly will only accelerate the chaos. Good preparation is simple: the editor knows which language is the source, which languages are targets, and how to verify the link between the original and the translation in the editor's right-hand panel.

For Gutenberg and Classic Editor, the key reference point is still the language block on the right side of the screen. In AutoPoly's documentation, the translation workflow starts precisely with selecting the language version and clicking the add translation icon. If that block is missing or the language is not configured, it is too early to start with AutoPoly.

Check the Content Type and Editor

Official sources confirm support for Gutenberg, Elementor, Classic Editor, and Divi, but the available feature set differs between the free and paid versions. WordPress.org notes that the free version focuses on Chrome Built-in AI, Yandex, Gutenberg, and inline translation, while features such as bulk translation, Classic Editor, Divi, Google Translate, OpenAI, Gemini, DeepL, taxonomies, and retranslation belong to Premium. So before configuring anything, match your use case against the version you actually have.

If the site is built with Elementor, it is worth checking both page translation and template translation separately. Elementor documentation warns that categories, tags, and custom taxonomies should ideally be translated before translating the pages themselves, otherwise the translated page may need to be manually linked to the appropriate translated terms. The logic is similar for Divi and Classic Editor: prepare the languages and terms first, then translate the content.

Check Content That Does Not Live in Standard Blocks

Problems usually do not appear in ordinary paragraph text, but in content hidden deeper in the structure: ACF fields, term meta, custom Gutenberg blocks, shortcodes, widgets from third-party plugins, SEO fields, image captions, buttons, and repeaters. AutoPoly documentation specifically describes the Supported Blocks, Custom Fields, and Terms Meta Fields settings. That is a clear signal: if your site uses a nonstandard content structure, you need to expose it to the plugin in advance.

For ACF, keep in mind the limitation noted on WordPress.org: not every field type is supported, only certain ones such as text, textarea, and wysiwyg in Gutenberg pages. If the site uses repeaters, flexible content, complex relationship fields, or data from external integrations, do not confidently promise automatic translation without testing. It is safer to choose one representative page, translate it, compare every field, and only then move on to bulk processing.

A practical pre-launch test: pick one page of each important type: a standard post, an Elementor page, an ACF-based post, a page with custom blocks, a product, or a service page. Translate them one by one and review the front end. Only after that should you move on to bulk translation.

Installation and Initial Validation Without Unnecessary Risk

Installing AutoPoly is broadly similar to installing any other WordPress plugin, but there is one key nuance: AutoPoly is meant to work alongside Polylang. If Polylang is not installed or not configured, there is nothing for it to translate. In the official instructions, installation of the free version starts with finding and activating Polylang, then installing AutoPoly - AI Translation For Polylang from the plugin directory.

Basic Installation of the Free Version

1. Open the WordPress admin panel and go to Plugins - Add New.
2. Search for Polylang, then install and activate it if it is not already installed.
3. Add the required languages in Polylang settings and confirm that they appear in the post editor.
4. Search for AutoPoly - AI Translation For Polylang, then install and activate the plugin.
5. Open a page or post that includes the Polylang language panel and confirm that the AutoPoly translation workflow is available.

After activation, do not start translating the entire site right away. Your first step should be a control translation of a single simple page. That quickly shows whether the plugin recognizes the source language, whether the Translate Now button appears, whether the translation engine selection window opens, and whether the result can be saved with Update Content.

If You Are Using the Pro Version

The documentation describes Pro installation as uploading a ZIP file through Plugins - Add New - Upload Plugin. It also includes an important warning: when upgrading from the free version to Pro, you should not keep both versions active at the same time because that can trigger a conflict. In practice, that means you should create a backup, deactivate the free version, and then install the Pro package using the standard WordPress method.

This guide does not cover purchasing, billing, or license management. For the actual workflow, something else matters more: after installing Pro, you get access to additional providers and modes, but each one still needs to be tested separately. If the translator requires an API key, keep it only in the plugin settings and do not include it in support tickets, articles, contractor tasks, or public logs.

Minimum Test After Installation

Create a short test page with a title, two paragraphs, an image with a caption, a button, and one category. Add the target language through Polylang, click the add translation icon, and select an available translation provider. Once the process finishes, click Update Content, open the public page, and check five things: the title, the text, the button, the image, and the language relationship through the switcher.

If the test page works, that does not yet mean the whole site is ready for bulk translation. But it does confirm the basic WordPress - Polylang - AutoPoly - translator chain. From there, you can move on to the settings that affect quality and coverage.

Post-Install Configuration: Providers, Visibility, and a Safe Starting Point

This settings section should be the most practical part of the workflow, because this is where AutoPoly either becomes a usable tool or a source of unpredictable drafts. The core settings revolve around choosing a translator, controlling button visibility, handling keys, testing Chrome Built-in AI, and preparing the fields that should be included in translation.

Choosing a Translator and Understanding Provider Logic

The official AutoPoly page lists several options: Chrome Built-in AI, Yandex, Google Translate, OpenAI, Gemini, and DeepL. It is important not to collapse them all into one abstract concept of "AI translation." Each method comes with its own requirements and tradeoffs. Chrome Built-in AI is positioned as an option that does not require a separate API key, but it depends on proper browser setup and available language packs. Google Translate Widget and Yandex are better understood as fast machine-translation options. OpenAI, Gemini, and DeepL are usually chosen when text quality and context matter more.

In the plugin settings, it is a good idea to keep visible only the providers your team actually uses. The WordPress.org changelog mentions the addition of an option to hide unused providers in the dashboard. That is not just cosmetic: fewer choices in the modal window mean fewer editor mistakes. If your team uses DeepL for marketing pages and Chrome Built-in AI for blog drafts, that should be documented in your internal workflow.

How to Choose a Provider for a Typical Site

• For a first-pass draft of a large archive, a fast and accessible option can work, but only with selective page reviews after processing.
• For commercial landing pages, it is better to use a higher-quality provider and a prepared glossary.
• For technical documentation, you need a terminology list and manual review of any wording where an error would change the meaning of the instruction.
• For WooCommerce descriptions, review product names, attributes, categories, and SEO snippets carefully, because terminology errors affect both search visibility and conversions.

Do not choose an engine based on speed alone. WordPress.org reviews show that different providers produce different quality levels and may come with their own limits or added costs. That is not a flaw in AutoPoly, but a property of the automatic translation chain as a whole.

Chrome Built-in AI and Language Packs

The Chrome AI documentation for AutoPoly specifically outlines the prerequisites: a secure connection, Translation API enabled in Chrome, installed language packs, and validation of language pairs through Chrome's internal settings pages. For administrators, that means this: if the translation button is available but Chrome AI does not work, the problem may not be in WordPress at all, but in the browser, HTTPS, or the language packs.

If your team plans to use Chrome Built-in AI as the main free option, set it up first in a controlled environment rather than on the live site. Check the source and target language, restart the browser after changing flags, then go to Languages - AutoPoly - Settings and run the built-in test if it is available in the interface. After that, translate one page and compare the result to the original.

API Keys and Security

For providers like OpenAI, Gemini, and DeepL, AutoPoly documentation shows the general pattern: the key is added in AutoPoly settings, and the corresponding translation button becomes active. This guide intentionally does not include instructions for creating keys or managing provider accounts, because that is a separate area involving both security and cost. The main rule is simple: the key should be stored only where the plugin needs it to work.

Do not paste keys into translator tasks, support emails unless absolutely necessary, public screenshots, tutorial articles, or issue comments. If you need to show a problem to a developer, redact the key and show only the button state, selected provider, and error message. If you suspect a leak, revoke the key in the provider dashboard and create a new one.

How to Roll Back a Questionable Setting

Test every AutoPoly setting through a small, reversible change. For example, if you enable support for a new custom block, first create a copy of a page, add the block, translate only that page, and save the result. If the translation breaks the structure, disable block support in Supported Blocks, delete the test language copy, or restore the page from backup. Do not start bulk translation immediately after changing several parameters at once.

Translating a Single Page: The Right Order of Operations

A single-page translation is the best way to understand how AutoPoly behaves. It shows the full path from the source page to the published result and helps you identify weak spots before bulk processing. According to the documentation, the general workflow is similar across Gutenberg, Classic Editor, Elementor, and Divi: open the page, select the target language, create the translation, choose a provider, run the translation, click Update Content, and review the page.

Workflow for Gutenberg or a Standard Page

1. Open the source page or post in the primary language.
2. In the Polylang language panel, find the target language and click the add translation icon.
3. When prompted, choose to create a copy of the source content if you want to preserve the page structure.
4. Click Translate Now and wait for the Select Translation Engine window.
5. Select the provider approved for this type of content.
6. Run the translation and wait for the result to appear.
7. Click Update Content, then save or update the page.
8. Open the public version, switch languages, and review the structure, links, buttons, and headings.

Do not skip the last step. In the editor, everything may look translated, but the front end shows the real picture: whether blocks are broken, styles are intact, source-language phrases are still present in buttons, or the layout has shifted because the translation is longer.

What to Check in the Editor After Translation

Start with the title and permalink. Automatic translation of the text does not necessarily mean that the URL, SEO title, description, and breadcrumbs are ready for publishing. Then check the page hero area, buttons, forms, image captions, alt text, tables, FAQ, links to related pages, and any condition-based blocks. If the page is built from repeated sections, make sure all of them were translated, not just the first one.

If the source page contains blocks from third-party plugins, compare the source and translation visually. AutoPoly aims to preserve structure and styling, but the documentation and user reviews show that unsupported blocks or commercial libraries can result in incomplete coverage. When in doubt, add the block to Supported Blocks or translate the problematic fragment using inline translation.

Inline Translation for Targeted Edits

Inline translation is useful when you do not need to retranslate the entire page. The Classic Editor documentation describes a simple workflow: highlight a specific fragment, wait for the translation button to appear, choose a language, and then either replace the source text or copy the translation manually. This is useful for short edits, isolated blocks, phrases in widgets, and situations where translating the whole page again would be unnecessary.

Use inline translation after the main pass. For example, the page may already be translated, but one phrase inside a shortcode or custom widget remains in the original language. Instead of retranslating the whole page, select that fragment and process it separately. That reduces the risk of accidentally overwriting a translation that has already been edited by hand.

Bulk Translation: When It Saves Time and When It Creates Debt

Bulk translation is one of the most visible features in AutoPoly Pro. According to the documentation, it lets you select multiple pages, posts, or custom post types, click Bulk Translate, choose a language and provider, and then wait for the automated process to finish. That is helpful when you need to create a language version of a large volume of content quickly. But bulk mode is also the area that requires the most disciplined preparation.

Translate Taxonomies Before Bulk Processing

AutoPoly documentation repeats an important rule several times for Elementor, Classic Editor, and Divi: if the source page is assigned to a category, tag, or custom taxonomy, the related terms should ideally be translated in advance. Otherwise, the translated page may appear without the correct connection to the translated category, and the editor will have to fix those relationships manually.

For standard categories and tags, this can be done through the terms list and the Bulk Translate button. For custom taxonomies, first check Languages - Settings, then the Custom Post Types and Taxonomies section. If the taxonomy is not enabled for translation there, AutoPoly will not be able to build language relationships correctly for it.

Split Translation Into Batches

Do not translate the entire site in a single operation, even if the interface allows you to select a large number of posts. It is safer to work in batches by content type: first 5 standard pages, then 5 Elementor pages, then one custom post type, then categories and tags. After each batch, review a sample on the front end. That makes it easier to identify which group caused the issue, and it keeps you from having to roll back hundreds of posts.

For large sites, it helps to keep a simple tracking table: content type, source language, target language, provider, number of processed pages, who reviewed the result, and what issues were found. AutoPoly speeds up translation creation, but it does not replace your quality control process. Without that control, bulk translation quickly turns into accumulated editorial debt.

Validation After a Batch Finishes

After bulk translation, open the list of pages in the target language and check the post statuses. Then select a few pages from the beginning, middle, and end of the batch. On the front end, review the language switcher, title, first paragraphs, buttons, menus, images, SEO block, and related categories. If the site uses caching, clear the cache before reviewing or open the page in a private browsing window.

If a batch produces many errors, do not launch the next one. Look for the common factor: one block, one provider, one language, one post type, or one taxonomy. Bulk translation is only useful when each new batch behaves predictably.

Glossary and Terminology: How Not to Damage Brand Meaning

Automatic translation handles text quickly, but it struggles most with terminology, product names, brands, abbreviations, and words with multiple meanings. For cases like that, AutoPoly offers a glossary. The documentation describes two entry types, names and general terms, as well as glossary creation, CSV import, and CSV export.

What to Add to the Glossary

The glossary should not contain everything. Add only the terms where a translation mistake would clearly damage meaning. That includes brand names, product names, plan names, specific features, legal wording, button labels, WooCommerce terminology, technical abbreviations, and recurring phrases. If you add too many random words, the glossary becomes noisy and starts working against natural translation.

The official documentation recommends avoiding duplicates and adding terms clearly. That is good practical advice: if the same term appears in multiple forms in the glossary, the translator may behave unpredictably. For teams, it is best to adopt a simple rule: one term, one preferred spelling, one short explanation of context.

How to Use the Glossary in a Real Workflow

Before running bulk translation, collect 20 to 50 critical terms and add them in the AutoPoly Dashboard under the Glossary tab. After the first translation batch, look for the words that still came out poorly. Do not fix them page by page only by hand. It is better to add the term to the glossary, then use retranslation where it is safe, or apply a targeted correction to pages that have already been edited.

The documentation points out an important nuance: the glossary is applied automatically during bulk translations, but for single-page translations through specific providers, terms may require manual handling. So you should not expect identical behavior across every mode. If terminology matters, test the exact workflow your editors will actually use.

Importing and Exporting the Glossary

CSV import and export are useful when multiple people work on the site or when you need to move a glossary between projects. Export the glossary before major editing, keep a copy with your editorial rules, and avoid mixing terms from different brands in a single file. If the site is being translated for multiple markets, it is better to maintain separate term lists for each language pair.

Custom Blocks, ACF Fields, and Term Meta Fields

Regular editor text is the simplest case. Complexity begins where content is stored in nonstandard blocks, ACF fields, term meta, or widgets. AutoPoly provides dedicated tools for that, but they require deliberate configuration. If the right fields are not enabled, the translation may look incomplete: the title is translated, the main text is translated, but an important card, caption, feature spec, or benefits block stays in the source language.

Supported Blocks for Gutenberg

The documentation for custom Gutenberg blocks explains that AutoPoly translates supported post types, pages, and Gutenberg blocks by default, but custom blocks from third-party plugins, themes, or tools such as ACF may not be translated automatically. For those blocks, go to Languages - AutoPoly - Supported Blocks, locate the block, add it, and insert the special text in the block section where the translatable content lives.

That may look unusual, but the logic is straightforward: the plugin needs to understand exactly where the text is located inside the custom block. If the block is built as a set of decorative containers and nested fields, automatic translation may not find the right layer without help. That is why you should always run a test on a copied page after adding the block.

Custom Fields and Conflict With Polylang Synchronization

For custom fields, AutoPoly offers a Custom Fields section where you can mark fields for translation and click Save Fields. But the documentation adds an important warning: if Polylang custom field synchronization is enabled, AutoPoly may not translate the values even if the field is marked in AutoPoly. In that case, the values will be copied from the original instead of being translated.

The practical order is this: first identify which fields actually contain translatable text, then check Languages - Settings - Synchronization, disable synchronization for those fields, save the settings, and only then test the translation. For fields where the same value should remain across all languages, such as an ID, color, number, technical flag, or integration URL, translation does not need to be enabled.

Terms Meta Fields

Term meta is often used in catalogs, filters, category cards, brand pages, and custom taxonomies. If term meta fields contain headings, descriptions, captions, SEO phrases, or text badges, they also need to be reviewed. AutoPoly includes a separate Terms Meta Fields section where you can mark the fields and save the selection.

Do not enable translation for every meta field blindly. It is better to leave technical fields untranslated. Only fields that contain human-readable text should be translated. After configuration, open the term archive page in the target language and confirm that the translated term displays the correct text rather than a copy of the source.

Elementor, Divi, and Classic Editor: Editor-Specific Nuances

One reason AutoPoly is interesting is that it does not stop at standard blocks. But different editors store content differently, so they also need to be checked differently. On an Elementor page, text lives in widgets and templates; in Divi, it lives in modules and sections; in Classic Editor, it lives in the main post content, but it may still be surrounded by shortcodes and meta fields.

Elementor: Pages, Templates, and the Language Switcher

The documentation shows Elementor page translation through the Translate button inside the Elementor interface and translation engine selection. It also mentions Elementor templates and the Connect Polylang for Elementor integration, where you can add a language switcher and configure its layout, alignment, flags, language names, language codes, hiding the current language, and hiding languages that do not yet have translations.

In practice, there are three layers to check in Elementor. First, whether the text inside widgets was translated. Second, whether the section structure and responsiveness were preserved. Third, whether the language switcher displays correctly in the header template or floating switcher. If the translated text becomes longer, buttons may wrap to two lines, cards may become taller, and the hero section may lose balance. That is not necessarily an AutoPoly bug, but it is absolutely part of result validation.

Divi: Translating Modules While Preserving Design

The official documentation describes a similar process for Divi: install Polylang and AutoPoly, choose the target translation language, create the translation, select the engine, click Translate, then Update Content, and review the page. The FAQ says that AutoPoly translates the content while keeping the Divi layout and styling from the original. Even so, the editor should still review the public page, because a longer translation can change the visual rhythm.

Pay special attention to buttons, tab blocks, sliders, testimonial modules, and forms. If a module contains text not in a regular field but in a setting or dynamic source, it may require separate review.

Classic Editor: When Simplicity Helps

Classic Editor is often easier for AutoPoly because the content usually lives in one field. But older sites built with Classic Editor also tend to contain many shortcodes, tables, HTML inserts, and custom fragments. The documentation shows both the regular translation workflow and inline translation for selected text. If the page contains a gallery shortcode or form shortcode, do not expect the shortcode itself to automatically turn into a translated interface. AutoPoly may translate the surrounding text, but the shortcode output depends on the plugin that renders it.

Practical Example: Translating a Services Section Into a Second Language

Imagine an agency website where the primary language is already configured in Polylang, and the team now needs to prepare an English version of the services section quickly. The section includes a page called "Website Development," a category called "Services," several Gutenberg blocks, a CTA button, an image, SEO fields, and two ACF text fields: a short subtitle and a caption for a content card.

Goal

The goal is to create a usable English version of the page linked to the original through Polylang, with the block structure preserved, the category translated, and the public output working correctly. This is not the final editorial polish, but a solid draft that can be reviewed and refined quickly.

Preparation

1. Make sure the language has been added in Polylang and appears in the editor.
2. Open Languages - Settings and confirm that the required taxonomy is enabled for translation.
3. Translate the "Services" category through the category list or by using bulk translation for terms.
4. Open Languages - AutoPoly - Custom Fields and mark only the ACF fields that contain text.
5. Check Synchronization in Polylang and disable synchronization for the fields that should be translated rather than copied.
6. Add the company name, product names, and fixed terms that should remain consistent to the glossary.

Translation Steps

Open the source page, find the Polylang language block, and create a translation for the target language. If the interface asks whether the original content should be duplicated, choose to copy the structure. Then click Translate Now, choose a translator, wait for the result, and click Update Content. After saving, open the translated page in the editor and check the ACF fields, title, CTA button, image caption, and the link to the translated category.

If the page contains a block that was not translated, do not rerun the whole operation immediately. First determine the source of the problem: is it an unsupported block, a custom field, a shortcode, or dynamic content? For an unsupported block, configure Supported Blocks; for a field, use Custom Fields; for a small fragment, use inline translation.

Result Review

Open the public page in the target language. Confirm that the URL matches the Polylang language structure, that the language switcher leads back to the original, that the category opens the correct archive, that the CTA button still has the right link, that the image displays properly, and that the text does not break the layout. Then open the page at mobile width and check whether any translated phrases have become too long for buttons or cards.

A Detail People Often Forget

If the source page is changed later, the translation may not update automatically. AutoPoly documentation describes retranslation: on the translated page, a Retranslate Page button appears, you can choose whether to translate the title, the content, or both, and then click Update Content. But if the translation has already been edited manually, retranslation may overwrite part of those edits. Before retranslating, save a copy or use it only on pages where it is safe.

How to Check Translation Quality and SEO Results

After automatic translation, do not review only the grammar. On a multilingual site, Polylang relationships, URLs, the language switcher, indexability, metadata, internal links, images, and caching all matter. AutoPoly speeds up the creation of translated content, but it does not perform the editor's full quality-control job.

Editorial Review

Start by comparing the source and translated pages for meaning. Automatic translation may render the words correctly but still alter the tone, mistranslate a term, or make a sentence feel unnecessarily heavy. Look especially closely at the page hero section, commercial claims, legal wording, limitations, instructions, plan headings, and button labels.

Then review the glossary. If a term that should have stayed as a brand was translated, add it to the glossary and fix the page. If the same term was translated differently in different places, decide which version your team will treat as standard and document it.

Technical Review

• Confirm that the translation is linked to the original in the Polylang panel.
• Open the language switcher and make sure it leads to the corresponding page, not the home page.
• Check breadcrumbs, menus, categories, tags, and archives.
• Check images, captions, alt text, and galleries.
• Check the SEO title, description, and localized snippets if they are stored in supported fields.
• Clear the cache if the public site still shows the old language.

When Retranslation Is Needed

Retranslation is useful when the source page has changed and you need to carry those updates into an existing translation. The documentation shows dedicated workflows for Classic Editor, Gutenberg, and Elementor, as well as bulk retranslation. But retranslation should be used carefully. If the translation has already gone through editorial review, automatic reprocessing may replace precise wording with a rougher machine-generated version.

A good rule is to first understand what actually changed in the original. If one paragraph was added, inline translation may be the better option. If the page was fully rewritten, retranslation is justified. If only the images changed or the section order was rearranged, automatic translation may not be necessary at all.

Common AutoPoly Issues and How to Diagnose Them

Problems in AutoPoly rarely have one universal cause. The same symptom can be tied to Polylang settings, the selected provider, the browser, block support, an external service limit, or a conflict between two plugin versions. For that reason, diagnosis works best as a chain: symptom, likely cause, check, fix, rollback.

The Translation Button Is Inactive

Symptom: the editor sees the page and the Polylang language, but the translation button is unavailable or does not start the process. The official FAQ lists missing valid API credentials or an unselected provider among the causes. For Chrome Built-in AI, the issue may also be an unprepared browser, disabled Translation API, or missing language packs.

What to check: whether a provider is selected, whether the key is saved in Settings, whether the target language is available, whether the needed feature is included in the plugin version, and whether Free and Pro are both active at the same time. For Chrome AI, check HTTPS, Chrome flags, and language packs.

How to fix it: save the provider settings, refresh the editor page, and run a test operation on a short page. If the problem started after switching providers, go back to the previously working option and test the new one separately.

Only Part of the Page Was Translated

Symptom: the title and regular paragraphs are translated, but certain blocks, ACF fields, shortcodes, buttons, or cards remain in the source language. This is a typical issue on complex pages. The WordPress.org FAQ explicitly warns that content coming from shortcode-based text, custom fields, or other plugins may not be picked up by bulk translation.

What to check: whether the text lives in a supported block, whether the custom field is marked for translation, whether Polylang synchronization is enabled for that field, and whether the problematic text is actually output by a third-party plugin. If it is a Gutenberg custom block, check Supported Blocks. If it is ACF, check Custom Fields. If it is term meta, check Terms Meta Fields.

How to fix it: enable support for the required block or field, test on a copy of the page, and then translate the fragment again. For one-off cases, use inline translation so you do not overwrite a translation that has already been manually edited.

Bulk Translation Produces Errors or 0 Percent Results

Symptom: bulk translation starts, but some pages are not translated or the result shows a failure. WordPress.org reviews include a practical example where a user linked the issue to unsupported blocks from a commercial library. That does not prove a universal cause, but it points in a useful diagnostic direction.

What to check: whether different page types are mixed in the same batch, whether unsupported blocks are present, whether the provider limit has been reached, whether taxonomies have been translated, and whether the selected provider is available in the current version. Open one problematic page and try translating it manually. If manual translation also fails, the issue is not specific to bulk mode.

How to fix it: reduce the batch size, separate pages by editor, translate taxonomies in advance, configure supported blocks, and test again on a small group. If the result becomes predictable after the fix, continue in batches.

Chrome Built-in AI Does Not Translate Even Though the Plugin Is Installed

Symptom: AutoPoly is installed, but Chrome AI does not start or reports that translation is unavailable. The documentation requires a secure connection, Translation API, language packs, and verification of supported language pairs. If the site is opened over an insecure address or the browser is not ready, WordPress settings will not fix it.

What to check: HTTPS, the state of Chrome flags, the presence of source and target language packs, whether the browser is up to date, whether it was restarted after flag changes, and the built-in check under Languages - AutoPoly - Settings.

How to fix it: first get Chrome AI working successfully on one language pair, then run translation in AutoPoly. If the project needs stable quality without depending on a local browser setup, consider another provider.

The Translation Reads Fine Grammatically, but the Terminology Is Wrong

Symptom: the page is readable, but a brand name, service name, WooCommerce term, or technical word is translated in a way that does not match company usage. This is not an interface problem, but a terminology-control problem.

What to check: whether the term exists in the glossary, whether there are duplicates, whether the glossary is applied in the chosen translation mode, and whether the source language matches what the system expects. For already translated pages, check whether manual edits were overwritten by retranslation.

How to fix it: add the term to the glossary, then correct the page manually or through retranslation if the page has not yet been edited. For critical pages, require a final manual review by an editor.

Tips for Safe Work on a Live Site

Automatic translation changes post content, so it should be handled with the same care as a data import or bulk edit. AutoPoly is not a harmless preview button. Once you click Update Content, the result is saved in WordPress and may become visible on the public site.

Create a Backup Before a Large Batch

Before running bulk translation, save a backup of the database and files. This is especially important if the translation includes images, galleries, fields, and custom post types. If something goes wrong, restoring from backup is much easier than manually deleting dozens of partially translated pages.

Do Not Translate Everything on Publication Day

First prepare a technical batch, then complete editorial review, and only then publish. For a commercial site, it is better to leave some time between automatic processing and opening the language version to visitors. That gives you time to check menus, indexability, forms, links, currencies, legal copy, and important CTAs.

Agree on Roles

AutoPoly speeds up the work, but it does not decide who owns the final text. The administrator configures Polylang, providers, fields, and the glossary. The editor reviews meaning and terminology. The developer helps with custom blocks, ACF, and conflicts. Even if one person handles everything, it is still useful to move through those roles in sequence instead of mixing configuration and editing together.

When Cool Plugins AutoPoly Is the Right Choice

Cool Plugins AutoPoly is worth using when a site already runs on Polylang, the team wants to speed up the creation of language copies, and the content is structured enough to be handled automatically. The plugin is especially useful for sites with a large number of pages, Elementor or Gutenberg content, repeated templates, categories, tags, and a real need for bulk translation.

Before a full rollout, validate Polylang, the language setup, the provider, the glossary, supported blocks, custom fields, and one representative page. Then translate in batches, review the results, log the errors, and only after that expand the process across the whole site. If that workflow matches your needs, you can get the Cool Plugins AutoPoly file and test it on a site copy or a small set of pages.

The main criterion is simple: AutoPoly is valuable not when it promises to "translate everything," but when it helps an editor reach a reviewable result faster. If you are prepared to set up the foundation, control quality, and avoid launching bulk translation blindly, the plugin can significantly reduce the time required to build a multilingual WordPress site.