CSA Research asked 8,709 people in 29 countries. They found that 76% want products with information in their language. Also 40% will not buy from websites that're not in their language. For a Magento 2 store that sells in more than one language market, having a catalog that is not translated limits revenue. This happens even before any ad is bought.
AI has made translating thousands of SKUs cheap, and Google has not banned it. Its scaled content abuse policy targets pages produced at volume mainly to manipulate rankings, whether by automation, humans, or both. Google has also told publishers that automated translation falls under that warning when it gives users little value. The risk is not the model. The risk is publishing machine output that nobody checked.
This guide gives a six-step workflow for translating a Magento 2 catalog with AI: store view setup, prompt templates, batch translation, human review, hreflang, and pre-launch quality checks. These examples show how MageDelight’s AI Content Translator works because its approval queue fits perfectly into the workflow. You can use any tool in the same way.
Prerequisites
• Magento Open Source or Adobe Commerce 2.4.x. MageDelight’s extension supports versions from 2.4.0 to 2.4.9.
• One store view per target language, created under Stores > Settings > All Stores.
• An API key for OpenAI, Google Gemini, or Anthropic Claude. The extension supports all three.
• Clean source content. Translation copies every typo and thin description into each new language, so fix the English first. MageDelight’s AI Content Generator can draft missing product copy.
• A named reviewer for each language, whether in-house or freelance.
• A staging site and a full database backup before installing, as the user manual advises.
• Google Search Console access for every language version.
Step 1: Set Up One Store View per Language
Changing a store view’s locale swaps interface text only. Per Adobe’s store localization documentation, product names, descriptions, categories, CMS pages, and blocks must still be translated separately for each store view, while SKU, price, and inventory stay shared. The store view is therefore the unit of work for everything that follows.
1. Create the store view under Stores > Settings > All Stores > Create Store View, and set its status to Enabled.
2. At store view scope, open Stores > Configuration > General > Locale Options, clear Use Website, and select the language locale.
3. Choose the URL structure now: store code in the path, a subdomain, or a country domain. This choice sets your hreflang URLs in Step 5, and changing it later means redirects.
4. Keep the Default Store View as the base language. The extension shows its Translate actions only on non-default store views and never overwrites base content.
Success looks like this: when you switch the scope to the view, the fields inherit the base text. The storefront displays interface labels, with English product copy. It is ready to be replaced.
Step 2: Build Prompt Templates and a Glossary
A generic prompt gives generic output. Brand names get translated, units drift, and HTML breaks. Prompt templates fix this once instead of correcting it product by product. In the extension, they live under MageDelight > AI Content Translator > Prompt Templates. Each template is tied to an entity type (product, category, CMS page) and a content type (name, description, meta title), and only one default is allowed per combination. The master prompt accepts the placeholders {{source_text}}, {{source_language}} and {{target_language}}.
Write these rules into the master prompt:
• Leave SKUs, model numbers, and brand names untranslated.
• Preserve every HTML tag and Page Builder structure exactly.
• Use a fixed register, such as formal address in German (Sie) and French (vous).
• Add no claims, materials, or certifications that the source text does not contain.
• For meta fields, keep within the length limit and never stuff keywords.
Create separate templates for product names, long descriptions, meta fields, category copy, and legal CMS pages. The product page also lists glossary control, so load your approved terms there. Test each template with the Translate button in the template editor before saving it.
Model and temperature settings matter too. The user manual suggests a default temperature setting of 0.7. At 0, the output is very literal. It's best to use this low setting for technical details and legal text. Higher values are meant for marketing content. The manual places its models like GPT-4.5, Gemini 2.5 Pro, and Claude Opus 4 on tasks that need SEO performance and brand sensitivity. Lighter models are reserved for scale, less sensitive work. Instead of relying on model labels, run the same 20 SKUs through two models. Show the outputs to your reviewer without revealing which model produced which. If the model's output works just as well, go with that one.
Step 3: Translate in Controlled Batches
Start with a pilot of 20 to 50 SKUs. In the pilot, include every product type, the very short and the long descriptions, items that use HTML tables, and names that contain special characters. A pilot costs little. Reveals prompt problems before the inventory grows to 5,000 products.
5. Open MageDelight > AI Content Translator > Bulk Content Translation (Single Attribute).
6. Pick the prompt template, the attribute (for example, Short Description), the source store view, and the target store view.
7. Upload a CSV with SKUs in the first column (maximum 5 MB).
8. Enable Skip Empty Attributes. Leave Existing Translations off so reviewer edits survive
9. Set a small batch size, between 1 and 50. The manual notes that smaller batches improve stability and error handling.
10. Start the job. Results land in the Translation Queue as Pending, and nothing publishes automatically.
After the pilot is approved, move to Bulk Content Translation (Multi Attribute) for the launch. The cost increases depending on the number of attributes, products, and models, so determine the price before starting the project. Handle the work in the order of revenue: start with bestsellers and top categories and finish with tail items. Individual changes do not require a job because the Translate button is located next to each attribute on the product, category, and CMS editing pages.
Step 4: Run a Human Review Queue
Translation Queue is the control point. For each record, the reviewer sees the source text and translated text. The reviewer can edit the translation. The reviewer then chooses one of three actions: Approve & Publish, Reject (admin notes required), or Re-. Rejected records stay in Translation Queue for audit. Content goes live after Approval.
Good reviews depend on a brief: a glossary, tone rules, a do-not-translate list, and examples of past rejections. Good reviews deserve a log of every rejection reason. If the same rejection reason repeats, such as the word for a product type, I should fix the prompt template and re-translate the entire batch instead of editing each record separately. Good reviews are best when a workable rule says that if one in ten sampled records needs a substantive fix, I should stop and revise the prompt template before running the next batch.
What to review, by content type
|
Content type |
Risk |
Reviewer |
What to check |
Auto-publish? |
|
Product name |
High |
Native speaker |
Brand and model terms intact; natural wording; matches how locals search |
No |
|
Short description |
Medium |
Native speaker |
Meaning, tone, no added claims; HTML preserved |
No |
|
Long description |
Medium |
Native speaker (sample for long tail) |
Tables, lists and specs; units; consistency with name |
Sample-checked |
|
Meta title and description |
High |
SEO + native speaker |
Length, keyword intent, natural phrasing |
No |
|
Category copy |
High |
Native speaker |
Page Builder structure; internal links; search intent |
No |
|
Legal CMS pages |
Critical |
Legal reviewer |
Literal accuracy; jurisdiction wording |
Never |
|
URL keys |
High |
SEO |
Uniqueness per store view; redirect plan |
Handled manually |
Step 5: Add hreflang Correctly
Translated pages exist after Step 4, but Google still has to learn that they are equivalents. Google's hreflang guidance sets out the rules. Each language version must list itself and every other version. Alternate URLs must be fully qualified, with https included. Localized versions are considered duplicates when the main content remains untranslated. Therefore, the translation itself is what keeps these pages apart. Google also says it does not use hreflang or the HTML lang attribute to detect a page’s language, because its own algorithms do that. Hreflang maps pages to each other. It does not declare a language.
Google treats three methods as equivalent: link elements in the head, HTTP headers, and XML sitemap entries. In Magento, the first and third methods are the choices. The extension manages content, and its user manual does not describe hreflang output; therefore, hreflang must be handled as a task. Adobe Commerce Marketplace lists dedicated hreflang extensions that inject tags for each product, category, and CMS page; custom layout code is the alternative.
A product page available in English, German, and Arabic would carry the block on all three URLs:
<link rel="alternate" hreflang="en" href="https://www.example.com/fusion-backpack.html" />
<link rel="alternate" hreflang="de" href="https://www.example.com/de/fusion-rucksack.html" />
<link rel="alternate" hreflang="ar" href="https://www.example.com/ar/fusion-backpack.html" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/fusion-backpack.html" />
• Map page to page. A product tag points to the translated product, never to a language home page.
• Include only translated pages. If a store view has no approved translation for a URL, leave it out of the set.
• Keep it reciprocal. Every alternate must link back, and every page lists itself.
• Set x-default for visitors who match no listed language, usually the English or language-selector page.
• Canonicalize each translated page to itself, not to the English original.
URL keys need a policy. The user manual says category and CMS URL keys are scoped to the store view but are not auto-translated. This is to prevent links and unwanted redirects. Choose one rule for each market: either keep the key in all store views (this is the simplest approach and hreflang takes care of the mapping) or translate the keys after a review, making sure they stay unique per store view and setting up 301 redirects for any old URLs. Before publishing, decide whether to use native script for Arabic or Hindi stores and use that choice consistently across all content.
Step 6: Run Quality Checks Before Indexing
Please perform the checks listed below on the staging environment using between five and ten pages, for each template type. If a page fails the check, keep it unpublished. Set it to noindex until the issue is resolved.
|
Check |
How to verify |
Pass rule |
|
Markup intact |
Compare rendered source of original and translation; look at tables, lists, Page Builder blocks |
No broken tags or stray HTML |
|
Protected terms |
Search target text for brand names, SKUs, model numbers |
Unchanged, glossary spelling |
|
Numbers and units |
Compare sizes, weights, quantities, dates against source |
Match, or converted on purpose |
|
Untranslated leftovers |
Scan the target view for source-language text in tabs, swatches, attributes |
None in visible content |
|
Meta fields |
Check length and keyword intent; the extension targets 150 to 160 characters for descriptions |
Reads naturally, fits the limit |
|
Script and layout |
View Arabic in RTL; check long German words in buttons and menus; check encoding |
No overflow, correct direction |
|
Locale mapping |
Confirm locale, currency and hreflang code for each store view |
Code matches language and region |
|
hreflang set |
Crawl a sample; confirm self-reference, return tags, full URLs |
Every variant lists all variants |
|
Indexability |
Confirm no noindex, self-canonical, URL present in the sitemap |
Indexable and self-canonical |
|
Native sign-off |
Reviewer reads top pages on staging and records approval |
Sign-off logged in the queue |
After launch, request indexing for the pages through Search Console. Continue indexing the pages and watch each language version separately for coverage errors, and check coverage errors again so a problem in one market does not hide inside the global totals.
Common Mistakes and Troubleshooting
• Overwrite switched on by accident. It replaces reviewed text with fresh AI output. Keep it off after the pilot and export the target store view before any deliberate overwrite.
• hreflang published before translation. Tags pointing at pages that still contain English invite duplicate-content problems. Add tags only for approved pages.
• One-way tags. If the German page lists the English page but not the reverse, the pair is incomplete.
• Every page pointing to the home page. Mapping must be page to page.
• Rubber-stamping the queue. Approving 200 records in a row means nobody is reading. Cap batch size per reviewer per day.
• Changing results between batches. The manual lists Latest aliases that always point to the newest model. For a rollout, pick a fixed model version so batch 40 reads like batch 1.
• Experimental or preview models in production. The manual flags these as unsuitable for production use.
• Truncated long pages. Default Max Tokens is 3900. Long CMS pages and descriptions may need a higher value, at a higher cost.
Which Setup Fits Your Store
• Under 500 SKUs, one or two languages: run one pilot. Then translate everything. Use one reviewer per language to check all fields and every bestseller description. The AI Content Translator license starts at $199 for Magento Open Source. The AI Content Translator price for Adobe Commerce is $399. The AI Content Translator price for Adobe Commerce Cloud is $499.
• Thousands of SKUs, languages. Use a stronger model for names, meta fields, and category copy. Use a model for long-tail descriptions. This way, the important parts get the attention they need while still keeping things for the rest. Sample: review the tail and apply the one-in-ten stop rule.
• Legal and safety content: low temperature, mandatory legal review, no auto-approval. For terms, privacy, and warranty pages, consider a professional translator for the final pass.
• Same language, regions (en-US, en-GB, en-AU): translation is not the problem. Localize spelling, currency, and offers. Use region codes in hreflang.
• Translations already live and never reviewed: audit before adding more. MageDelight’s Magento Technical SEO Audit covers indexing and international setup, and the MageDelight guide to AI content and search visibility shows where translated copy fits in a wider content plan.
For most stores, the first move is the same: a 30-SKU pilot in one language, a reviewer with a written brief, and hreflang only on approved pages. AI Content Translator covers the translation and approval side. If setup or ongoing hreflang work needs hands, MageDelight’s Magento support service can take it on.
FAQ
Does Google penalize AI-translated pages?
Not automatically. Google’s spam policies focus on content that is generated in volumes to trick search rankings. Google has made it clear that automated translation can fall under this warning if it doesn’t provide value to users. Translations that sound natural and help real shoppers are treated differently. So only publish translations that a reviewer has approved.
Do I need hreflang if each language already has its own store view?
Yes. Store views create the pages. Hreflang tells Google they are equivalents. Google notes it may find versions on its own, but it is usually best to indicate them explicitly.
Should I translate URL keys?
Either approach works as long as you apply it consistently. The extension does not auto-translate category and CMS URL keys. This is to prevent broken links and redirects. If you choose to translate them, make sure to review each one. Keep the URL keys for each store view. Also set up a 301 redirect for any URLs to avoid losing traffic.
Which AI model should I use?
Match the model to the content. The manual shows the models for SEO‑critical copy and for brand‑sensitive copy. It also shows models for bulk work. Test two models on the twenty SKUs with a blind review, then lock a fixed version for the rollout.
How many products should I pilot first?
Select between twenty and fifty SKUs that cover every product type, the shortest and longest descriptions, and any item with tables or special characters. If more than one in ten sampled records requires a substantive fix, then move on to the full batch of SKUs.



