How do you translate an Adobe Commerce or Magento storefront without confusing a store view’s locale, installed language pack, catalog text, theme phrases and customer communications? Adobe Commerce has a powerful hierarchy of websites, stores and store views, but a locale switch does not automatically translate the merchant’s product descriptions or policies. This guide explains each layer and shows how to verify a multilingual shopping experience from product listing through checkout and post-purchase communication.
Readers searching for Magento 2 translation, Adobe Commerce store views, language pack setup, i18n CSV translations, localized product attributes, translated category URLs, inline translation and multilingual SEO often find instructions that solve only one part of the problem. Official Adobe documentation distinguishes interface translation tables from merchant-authored content and explains how to translate products and categories at store-view scope. Developer tools and packages require a controlled workflow, not casual edits on a live production site.
The reliable approach begins with the store hierarchy and a sample shopper task. Choose the target locale and store view; confirm the language package; translate catalog and CMS content in the correct scope; verify attribute labels, SEO and URLs; and test currency, tax, checkout and email templates. This practical longform guide explains the trade-offs, common mistakes and a review process suitable for teams serving international buyers.
Quick answer: a complete multilingual visitor journey
Use a separate store view for the chosen language when appropriate, set its locale and install a compatible language pack if needed. Remember that interface words and merchant-authored descriptions are different: translate product and category fields for the selected store view, inspect attribute labels, CMS pages and blocks, and verify search, links, checkout and emails. Never assume that a switch of locale alone rewrites your product catalog.
What professional translation means here
A multilingual Adobe Commerce and Magento project has three simultaneous obligations: the words must preserve meaning; the platform must serve the correct locale and resource; and the underlying business must be able to deliver what the language version promises. A translation can pass a language review and still fail a customer when a product option, form, search result, password email or checkout message points elsewhere. The practical standard is a verified task, not a translated-word percentage.
Separate four categories before work begins: source-controlled facts that must not change; human-facing terms that require accurate translation; technical keys or identifiers that must stay stable; and region-specific offers that require business approval. An editor should be able to explain which category a string belongs to. When a statement crosses categories, stop and ask who owns the decision instead of improvising.
The complete step-by-step guide
1. Understand websites, stores and store views
Adobe Commerce has a hierarchy of websites, stores and store views. Views commonly distinguish language presentations while websites and stores may also carry other commercial structure. Configuration inheritance helps reuse data but complicates ownership when a translation must differ. Draw the hierarchy for the actual installation before translating.
Start by treating the Adobe Commerce and Magento language edition as a service commitment rather than a decoration. Readers do not care how many strings were processed; they care whether the page answers their question and leads to the correct next step. Describe one visitor, the decision that visitor is trying to make, and the evidence needed to make it. A person choosing a course, buying a product or asking for a return may interpret an attractive but incomplete page as a complete offer. That is why translation starts with promises, not buttons.
A practical test for this stage is straightforward: Which store view owns the words and settings seen by a shopper? Write down the source setting, the target locale, the expected result and the observed result. If the two differ, identify whether the content, routing, permissions or commerce behavior is responsible. That record is more useful than an unsupported claim that the translation is complete.
2. Decide whether a store view fits the project
A language edition often uses another store view. That does not mean every business requirement, domain or currency variation should be implemented as a new language view. Architecture choices have SEO and operational effects. Separate translation requirements from tax, inventory and market requirements.
A language code and a country are different pieces of information. French in France and French in Canada share a language but may require different shipping terms, spelling, regulatory notices or customer support arrangements. A URL subdirectory is also not the same thing as a locale code; one can change while the other continues to describe language and region. Before editing content, write down the exact audience, target language, optional region and URL policy. This small exercise prevents later confusion about where the visitor should land.
A practical test for this stage is straightforward: Can two languages share the same actual product stock and pricing facts? Write down the source setting, the target locale, the expected result and the observed result. If the two differ, identify whether the content, routing, permissions or commerce behavior is responsible. That record is more useful than an unsupported claim that the translation is complete.
3. Create a store view with a stable code
Adobe’s Admin documentation describes creating store views under Stores > Settings > All Stores and setting a name, code, status and sort order. Codes become useful stable references in configuration and some integrations. Choose a code that team members can recognize and preserve.
Product capabilities are always conditional on plans, site configuration, integrations and the storefront version. A feature shown in one tutorial may be hidden or unavailable on another installation. Instead of treating a screenshot as permission to make a promise, check the product’s current documentation, feature entitlement and the interface actually in use. Keep a record of any unsupported route. You can still serve readers well by naming the limitation and providing a reliable alternative, but not by implying that an unavailable feature works.
A practical test for this stage is straightforward: Can every public language version be traced to a specific view code? Write down the source setting, the target locale, the expected result and the observed result. If the two differ, identify whether the content, routing, permissions or commerce behavior is responsible. That record is more useful than an unsupported claim that the translation is complete.
4. Set locale at the correct configuration scope
The Store View selector in Stores > Settings > Configuration controls which scope is being edited. The locale choice is in General locale options. A change intended for one store view should not accidentally overwrite a website-wide default. Check the displayed configuration scope before saving.
Source content is not merely text waiting to be translated. It contains decisions about names, prices, eligibility, timings, ownership and exclusions. The first task is to separate stable facts from prose that can be adapted. The second is to identify where the facts come from and who may authorize corrections. A translator can improve clarity without changing a contract. Where a source statement is ambiguous, ask the content owner to resolve the meaning before creating a confident target-language sentence.
A practical test for this stage is straightforward: Does only the intended store view show the requested locale behavior? Write down the source setting, the target locale, the expected result and the observed result. If the two differ, identify whether the content, routing, permissions or commerce behavior is responsible. That record is more useful than an unsupported claim that the translation is complete.
5. Know what a locale switch actually does
Adobe explains that changing locale points interface text to a different translation table. It does not automatically rewrite merchant-created product names, categories or CMS pages. This difference is central to every multilingual Commerce project. List interface phrases separately from authored catalog text.
An editable field often has a hidden relationship to other fields. A product name may appear in search, a navigation menu, a confirmation email and a social preview. A CMS reference may drive a collection list, whereas a separate static page may require individual editing. Document these dependencies as a short content map, using real examples from the project. Then change a safe test record and observe every surface it touches. That is more reliable than assuming one successful save proves that the whole system has updated.
A practical test for this stage is straightforward: Can a translated Add to Cart button appear beside an English product description? Write down the source setting, the target locale, the expected result and the observed result. If the two differ, identify whether the content, routing, permissions or commerce behavior is responsible. That record is more useful than an unsupported claim that the translation is complete.
6. Install and review language packages
Language packages supply localized interface phrases, sometimes installed as extensions or Composer-managed components. Package compatibility, provenance and update policy matter because a theme or extension can add strings outside the package’s coverage. Treat packages as maintained software dependencies.
Interface strings are short but consequential. Words such as Continue, Subscribe, Available, Free, Cancel and Confirm can mean different things at different moments in a transaction. A translation that reads naturally in isolation can mislead if the button submits a payment rather than opening information. Open the screen, record what the control actually does and choose language that tells the truth. Test focus order, input errors and the mobile layout, because the same short label may need a more explicit version in constrained contexts.
A practical test for this stage is straightforward: Does the installed pack match the Commerce version and active locale? Write down the source setting, the target locale, the expected result and the observed result. If the two differ, identify whether the content, routing, permissions or commerce behavior is responsible. That record is more useful than an unsupported claim that the translation is complete.
7. Understand phrase dictionaries and CSV files
Magento’s i18n infrastructure includes source-to-target phrase dictionaries stored in CSV files. Developer documentation describes phrase collection and package creation tools; the locale filename and case matter. Editing keys or placeholders can break rendered interface text. Test a handful of formatted phrases in a staging environment.
Navigation should preserve the reader’s place in the task. A language switcher that takes every visitor back to a homepage is not equivalent to one that opens the same article in another language. Similarly, a menu item can be grammatically correct while pointing to a source-language page. Sketch the journeys from entry page to destination before testing. Include the browser back button, copied URLs and direct visits from search engines. These ordinary routes reveal broken assumptions that a translation editor will not show.
A practical test for this stage is straightforward: Do prices, variables and interpolation survive translation without corruption? Write down the source setting, the target locale, the expected result and the observed result. If the two differ, identify whether the content, routing, permissions or commerce behavior is responsible. That record is more useful than an unsupported claim that the translation is complete.
8. Use developer tooling safely
Adobe documents CLI tools for collecting translation phrases and packaging language resources. These are implementation tools normally handled by a qualified developer with backups and deployment controls, not a requirement for a content translator to edit production code. Separate content approval from software deployment rights.
Dynamic content is best tested as data, not as a screenshot. A field can inherit a source value until a specific locale has an override. A list can omit records that are unpublished in one language. A tag or option may look like a sentence but actually function as a stable identifier. Protect identifiers and relationships while translating their human-visible labels. Create an inventory of record types and field types, then test one representative example of each before processing the full catalogue.
A practical test for this stage is straightforward: Can a package be built and rolled back without a live-site outage? Write down the source setting, the target locale, the expected result and the observed result. If the two differ, identify whether the content, routing, permissions or commerce behavior is responsible. That record is more useful than an unsupported claim that the translation is complete.
9. Translate product text per store view
Adobe documents choosing a specific Store View in Catalog > Products, clearing Use Default Value for translatable fields and entering the language-specific text. Product names, descriptions, SEO metadata and alt text can need separate review. Preserve shared SKUs, price and inventory information.
Visual adaptation is part of meaning. Translated text can be longer, require different line breaks or use a script that needs suitable fonts and right-to-left support. An image can contain embedded source-language words; an icon may communicate differently in another culture. Do not solve these problems by shrinking every font or deleting essential information. Instead inspect the design at mobile and desktop widths, check accessible names and provide a locale-specific visual only where it improves understanding without changing the underlying claim.
A practical test for this stage is straightforward: Does the translated view display the right human-facing fields for the same item? Write down the source setting, the target locale, the expected result and the observed result. If the two differ, identify whether the content, routing, permissions or commerce behavior is responsible. That record is more useful than an unsupported claim that the translation is complete.
10. Translate configurable product attributes
Attribute labels such as colour or size may be managed separately from a product’s main description, with labels for each store view. An unreviewed attribute can misstate an option or create mixed-language filter controls. Inventory the visible attributes and their labels.
Search visibility begins with a useful, available page. An attractive translated title cannot compensate for a broken route, an empty body or a page that automatically redirects people away from their chosen language. Write headings that answer real questions, use language-appropriate terms, and confirm that the canonical URL, indexing configuration and alternate-language signals describe the pages that actually exist. Search engines do not complete checkout or support tickets for people; you still need a visitor-level functional test.
A practical test for this stage is straightforward: Can a shopper select a variant without confusing label and underlying value? Write down the source setting, the target locale, the expected result and the observed result. If the two differ, identify whether the content, routing, permissions or commerce behavior is responsible. That record is more useful than an unsupported claim that the translation is complete.
11. Translate categories and navigation
Adobe’s store-localization guide describes translating category names, descriptions, SEO fields and URL keys at the selected store-view scope. Navigation depends on category structure and visibility as well as the words in a menu. Check the full path from a translated menu to its products.
Catalog and service information mixes descriptive text with structured facts. A colour, dimension, qualification, warranty, appointment duration or stock position may be stored in an attribute rather than in the main description. Translate the human-visible words but do not silently modify identifiers, option relationships or factual measures. A fluent product story that promises a different bundle is inaccurate. Build a sample product with variants and check every option selection before you approve a large set of localized records.
A practical test for this stage is straightforward: Does each localized category contain the correct related items? Write down the source setting, the target locale, the expected result and the observed result. If the two differ, identify whether the content, routing, permissions or commerce behavior is responsible. That record is more useful than an unsupported claim that the translation is complete.
12. Plan category URL keys and redirects
A translated category URL key may improve readability, but changing it carelessly can break bookmarks and search results. Adobe’s guidance describes permanent redirect options for previous URLs in category editing. Prepare a migration map before changing live routes.
SEO metadata has at least three audiences: the person searching, the person sharing a link and the software interpreting the page. A description should faithfully summarize the localized page, not a page that has not been translated yet. Social images may carry text that needs another edition, and structured data must not claim prices, availability or ratings unsupported by the page. Keep a separate check for titles, descriptions, preview cards, language alternates and any custom metadata that inherits from the source.
A practical test for this stage is straightforward: Does an old category URL reach the intended new-language destination? Write down the source setting, the target locale, the expected result and the observed result. If the two differ, identify whether the content, routing, permissions or commerce behavior is responsible. That record is more useful than an unsupported claim that the translation is complete.
13. Audit CMS pages and content blocks
Storefront information pages, promotion blocks, footers and policy messages can be created separately from interface packages. Store-view associations and content inheritance can determine which version appears on a given route. Inventory all CMS pages and blocks with legal or commercial claims.
The final action is where errors become expensive. A shopper may read the correct localized product description but enter an unexpected currency, shipping region or checkout language. A student may find a translated course timetable and then submit a registration form with English-only consent text. Walk through the transaction using safe test accounts and non-production payments where available. Read every intermediate message, not only the first and last screens. Separate the problem of translation from the problem of what the system can actually deliver.
A practical test for this stage is straightforward: Does a translated catalog link to an approved policy in that language? Write down the source setting, the target locale, the expected result and the observed result. If the two differ, identify whether the content, routing, permissions or commerce behavior is responsible. That record is more useful than an unsupported claim that the translation is complete.
14. Check theme and extension phrases
A language pack may translate core labels yet leave custom theme, payment, search or extension text in English. Developer phrase dictionaries can address appropriate components, but unsupported customizations require coordinated maintenance. List the extensions a shopper actually sees.
Transactional messages deserve their own inventory. Order confirmations, password resets, invoices, booking reminders and failed-payment notices can be controlled by different services or apps. A published storefront language does not automatically guarantee that every notification is translated or sent to the right recipient. Test language preferences, fallback, dynamic placeholders and the links inside messages. The aim is to preserve the transaction’s identity and next action; accidental substitution of order numbers, amounts or dates is a serious error.
A practical test for this stage is straightforward: Which team owns the untranslated phrase after the theme updates? Write down the source setting, the target locale, the expected result and the observed result. If the two differ, identify whether the content, routing, permissions or commerce behavior is responsible. That record is more useful than an unsupported claim that the translation is complete.
15. Use inline translation only in a controlled context
Adobe documents inline translation as a developer tool with configuration and cache implications. It can help identify or edit interface strings but should not be enabled casually on a live store, especially with caching and operational effects. Prefer staging and a tested release path.
Third-party tools introduce boundaries. A support widget may load in English, a consent manager may set a different language, or an external form may ignore the site’s locale entirely. The correct response is not to assume that Adobe Commerce and Magento’s translation feature has authority over every integration. Create a list of tools visible to readers and identify which service owns each string. Where a tool cannot be localized, make the limitation visible in planning and consider a supported workflow rather than fabricating compatibility.
A practical test for this stage is straightforward: Can the tool be switched off cleanly after a controlled change? Write down the source setting, the target locale, the expected result and the observed result. If the two differ, identify whether the content, routing, permissions or commerce behavior is responsible. That record is more useful than an unsupported claim that the translation is complete.
16. Keep currency, tax and shipping factual
A store view’s language does not itself promise a new currency, tax rule, destination or shipping method. These settings belong to commerce configuration. A translator should not insert language that implies operations the merchant cannot provide. Validate displayed prices and delivery conditions with the merchant.
Accessibility is not an optional finishing touch. Screen-reader language, reading order, form labels, alt text, keyboard navigation, error explanations and directionality all affect whether information is understood. Translate alternative text according to the function of the image in that context; it should not simply duplicate a filename. Ask a reviewer to navigate without a mouse and, where feasible, use assistive technology. A language edition fails if it is only understandable to sighted desktop users.
A practical test for this stage is straightforward: Is the charge shown at checkout consistent with the translated offer? Write down the source setting, the target locale, the expected result and the observed result. If the two differ, identify whether the content, routing, permissions or commerce behavior is responsible. That record is more useful than an unsupported claim that the translation is complete.
17. Test storefront search and product discoverability
A localized catalog should allow buyers to find products using natural target-language terms. Search behavior can depend on indexed fields, attributes and custom search modules, which need testing at store-view scope. Use known product queries and record expected results.
A quality review should cover meaning, function and evidence separately. A bilingual reviewer checks whether the translated claim matches the source. A functional reviewer follows links, selections and submissions. A subject owner confirms that promises about availability, eligibility and commercial terms remain correct. One person may cover more than one role, but the questions should still be separated. This prevents a polished translation from being accepted merely because it sounds fluent, even when the underlying operation is wrong.
A practical test for this stage is straightforward: Does the localized query reach the correct SKU and product page? Write down the source setting, the target locale, the expected result and the observed result. If the two differ, identify whether the content, routing, permissions or commerce behavior is responsible. That record is more useful than an unsupported claim that the translation is complete.
18. Translate account and checkout messages
Cart, checkout, login, error and address messages can combine core translations with third-party extensions. A successful locale switch on the homepage is not evidence that payment and account surfaces are translated. Test a safe end-to-end account and purchase journey.
Use a small but realistic testing matrix. At minimum, select a target language, one desktop viewport, one narrow mobile viewport, a clean browser session and one full user task. Add cases for a missing translation, an unavailable item, a failed form and a direct link from search. Record the expected result before clicking. When something fails, capture the exact URL and locale alongside the visible text so that developers and editors can reproduce the problem without guessing.
A practical test for this stage is straightforward: Are failed payments, validation errors and next steps understandable? Write down the source setting, the target locale, the expected result and the observed result. If the two differ, identify whether the content, routing, permissions or commerce behavior is responsible. That record is more useful than an unsupported claim that the translation is complete.
19. Review transactional emails and templates
Sales confirmation, shipping and account emails can use store-view-specific templates and dynamic variables. A message that is fluent but replaces an order ID or amount incorrectly is not fit for publication. Create safe test orders and inspect the actual outgoing message.
Publishing is a change to a living service. A language edition should be staged so that readers do not encounter a half-localized journey, and changes to primary content can invalidate previously approved target-language statements. Separate draft, review and live states where Adobe Commerce and Magento permits. Before launch, sign off a short release checklist: entry route, navigation, key content, forms, purchases if relevant, messages, search metadata and support contacts. After launch, repeat the same smoke test on the public domain.
A practical test for this stage is straightforward: Does the recipient see the correct language and unaltered order details? Write down the source setting, the target locale, the expected result and the observed result. If the two differ, identify whether the content, routing, permissions or commerce behavior is responsible. That record is more useful than an unsupported claim that the translation is complete.
20. Consider headless storefront variants
Adobe’s newer Commerce Storefront documentation includes multistore and localized content patterns with subfolders or domains and headers selecting store views. Those workflows should not be merged blindly with classic Admin screenshots. Identify the actual front end before following setup instructions.
Language quality changes with time. A new product attribute, policy revision, SEO title or feature addition can create an English-language island inside a localized experience. Treat changes as signals that translation review may be necessary. Maintain a simple log of what changed, when, who reviewed it and what locale was affected. The log should be short enough to use, not a ceremonial document. Recheck high-risk pages more often than low-risk evergreen explanations.
A practical test for this stage is straightforward: Do locale routes send the correct store-view header to the backend? Write down the source setting, the target locale, the expected result and the observed result. If the two differ, identify whether the content, routing, permissions or commerce behavior is responsible. That record is more useful than an unsupported claim that the translation is complete.
21. Stage deployment and SEO validation
Before a language view goes live, test its routes, menus, metadata, categories, product variants, shipping and return policies. Verify public language signals and avoid indexing unfinished or duplicate-language pages prematurely. Use a deployment checklist with rollback ownership.
A working glossary is a decision record, not a dictionary for its own sake. Explain which term is preferred, what it means in this product, what alternatives should be avoided and where exceptions are justified. Keep proper names, units, variable names and system identifiers distinct from language that should be localized. Train reviewers on the glossary with a few actual screens rather than asking them to memorize a long abstract list. Good consistency serves understanding; it should not erase natural expression.
A practical test for this stage is straightforward: Can a buyer from search navigate and complete a supported transaction? Write down the source setting, the target locale, the expected result and the observed result. If the two differ, identify whether the content, routing, permissions or commerce behavior is responsible. That record is more useful than an unsupported claim that the translation is complete.
22. Maintain translations as extensions evolve
Updates to Commerce, a custom theme, new catalog attributes or revised merchant policies can invalidate previously complete translations. Compare phrase dictionaries, content changes and customer-facing routes after releases. Assign maintenance ownership for packages and authored fields.
Finish with independent practice. Give a learner one multilingual page, one dynamic item and one transaction or submission to examine. Ask for a short explanation of the user’s intent, the language promise, the evidence of successful translation and the first unresolved risk. The learner should be able to justify a change without claiming authority over product facts. Repeat the exercise after a source update. This tests the capacity to maintain a system, not just to prepare a one-time translation.
A practical test for this stage is straightforward: Which simple smoke test would detect a newly English-only checkout label? Write down the source setting, the target locale, the expected result and the observed result. If the two differ, identify whether the content, routing, permissions or commerce behavior is responsible. That record is more useful than an unsupported claim that the translation is complete.
Twenty-four real-world problems and how to diagnose them
1. A Spanish store view still shows English product names
The locale setting translates some interface phrases, not merchant-authored product fields; edit the correct store-view scope. Ask what the visitor expected before changing the wording. Record the source route, target route and actual result; then decide whether the problem is content, configuration, entitlement or an integration. That diagnosis prevents a copy edit from concealing a broken process. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
2. A product name change affects all languages
Check whether the field still uses its default inherited value or was edited at global scope. Reproduce the problem in a private browsing session. Editors often see controls or cached versions that ordinary visitors do not. Compare the published page with its draft, and report which one supplied the misleading signal. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
3. The team confuses a store code with a locale code
Document the difference between stable store-view identifiers and display language configuration. Check whether the issue concerns a display label or a stable technical identifier. A visible label may need natural translation, while an API key, SKU, status code or field key may need to remain unchanged. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
4. A language pack translates buttons but not custom payment labels
Find the payment extension’s phrase source and maintain a compatible translation resource. Review the most consequential claim first. Price, date, service availability, location, order action and consent should be corrected before polishing less important phrasing. The right priority reduces harm while keeping the release manageable. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
5. A CSV translation breaks a formatted price
Check placeholders, quotation, escaped values and the phrase dictionary format. Follow the destination of each link rather than deciding from its anchor text. Correct words with an incorrect destination still mislead the visitor. Test the same route after changing languages and after returning to the original version. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
6. A package works in development but fails in production
Review deployment steps, version compatibility, caches and the live locale assignment. Compare the language editor’s view with the page viewed by a non-editor. A setting that appears complete in a management panel may have no effect until a language or page is published to the public site. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
7. The developer enables inline translation on the live store
Move diagnosis to a controlled environment and review cache and security implications. Keep a screenshot and a one-sentence expected outcome. A useful issue report says what the person attempted, the language, where it failed, and the next action. Such reports can be verified by someone who did not write the translation. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
8. Spanish product filters show English attributes
Translate applicable store-view attribute labels and verify variant relationships. Distinguish a missing translation from an intentional source-language name. A brand, product code or official publication title may properly remain unchanged; a consent sentence or error message usually should not. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
9. A translated category link leads to an old route
Inspect translated URL keys and permanent redirect settings. Test with a long translation, not only the shortest English label. Layout defects frequently hide until a heading wraps, a button expands or a mobile navigation item becomes two lines. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
10. A page shows correct text but wrong brand header
Check website, store and store-view scope and the route’s assigned storefront. Read content in context with its surrounding prices, options and warnings. A correct isolated sentence can become inaccurate next to the wrong currency, stock badge or product variant. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
11. The team has two CMS pages with conflicting returns terms
Identify the active store-view association and approved policy owner. Check the language selected in the interface against the language of emails and external links. A mismatch may come from separate preference stores rather than the visible page. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
12. The translated footer points to an English privacy page
Check CMS blocks and links separately from the interface language pack. Treat legal and safety statements as source-controlled material. Get approval from an appropriate owner instead of creatively rewriting an ambiguous warning. The translator’s role is accuracy and clarity, not legal authorization. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
13. Search finds the wrong product in Portuguese
Inspect index context, product data and relevant custom search modules. Ask what the visitor expected before changing the wording. Record the source route, target route and actual result; then decide whether the problem is content, configuration, entitlement or an integration. That diagnosis prevents a copy edit from concealing a broken process. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
14. An extension upgrade reintroduces English strings
Compare phrase dictionaries and run regression tests after deployment. Reproduce the problem in a private browsing session. Editors often see controls or cached versions that ordinary visitors do not. Compare the published page with its draft, and report which one supplied the misleading signal. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
15. The French view displays prices in the wrong currency
Review currency and market configuration rather than translating the currency symbol. Check whether the issue concerns a display label or a stable technical identifier. A visible label may need natural translation, while an API key, SKU, status code or field key may need to remain unchanged. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
16. An order email appears partly in English
Check the store-view email template and any extension-generated messages. Review the most consequential claim first. Price, date, service availability, location, order action and consent should be corrected before polishing less important phrasing. The right priority reduces harm while keeping the release manageable. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
17. A customer account error has an untranslated field name
Inspect core phrases and the relevant account extension. Follow the destination of each link rather than deciding from its anchor text. Correct words with an incorrect destination still mislead the visitor. Test the same route after changing languages and after returning to the original version. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
18. The page claims delivery in a region the store cannot serve
Correct localized copy against supported shipping settings. Compare the language editor’s view with the page viewed by a non-editor. A setting that appears complete in a management panel may have no effect until a language or page is published to the public site. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
19. The product’s image alt text remains English
Review media labels and alt text at relevant scope as part of catalog translation. Keep a screenshot and a one-sentence expected outcome. A useful issue report says what the person attempted, the language, where it failed, and the next action. Such reports can be verified by someone who did not write the translation. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
20. A headless storefront shows the wrong locale despite a French URL
Check front-end routing and the headers selecting the Commerce store view. Distinguish a missing translation from an intentional source-language name. A brand, product code or official publication title may properly remain unchanged; a consent sentence or error message usually should not. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
21. A category URL change destroys existing bookmarks
Plan and verify permanent redirects before exposing the new route. Test with a long translation, not only the shortest English label. Layout defects frequently hide until a heading wraps, a button expands or a mobile navigation item becomes two lines. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
22. The team translates SKU values
Restore technical identifiers; translate only intended human-visible labels. Read content in context with its surrounding prices, options and warnings. A correct isolated sentence can become inaccurate next to the wrong currency, stock badge or product variant. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
23. The browser language is French but the shopper receives English
Check store selection, routing behavior and configured locale rather than assuming browser detection is enabled. Check the language selected in the interface against the language of emails and external links. A mismatch may come from separate preference stores rather than the visible page. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
24. A release adds a new untranslated checkout step
Update translation dictionaries or extension resources and retest the full order journey. Treat legal and safety statements as source-controlled material. Get approval from an appropriate owner instead of creatively rewriting an ambiguous warning. The translator’s role is accuracy and clarity, not legal authorization. On Adobe Commerce and Magento, verify the consequence on the public-facing route before closing the issue.
Worked example: from a source-language page to a verified customer journey
A furniture retailer uses Adobe Commerce and wants a German-language store view while keeping the same core product inventory. Its project team maps the existing website, store and view hierarchy before making changes. It chooses one desk with size options, one category, the delivery policy and a safe checkout journey as the pilot. The merchant confirms dimensions, stock, assembly conditions and the actual countries served.
An administrator creates the appropriate store view and selects its locale at the correct configuration scope. A developer verifies the language package and a few theme phrases in staging. The translator does not change SKU codes, quantities or default inventory; instead they make approved text entries for the chosen store view and inspect where inherited values still appear.
The product team translates the desk name, description, accessible image labels, SEO fields and visible attribute labels. Category names, descriptions and URL keys are reviewed separately, with redirects planned for any changed public route. The content team checks the associated CMS delivery and returns pages rather than assuming language packages will translate them.
A tester finds the desk through a natural German search, chooses a size, follows the category and reaches checkout. They inspect localized forms, delivery address validation, tax presentation and payment errors using an approved safe test method. Then they read the transaction email and verify order ID, price, product variant and links. Any mismatch becomes an issue owned by the correct system team.
Once the pilot passes, the retailer expands to more catalog categories in controlled batches. A subsequent Commerce extension update adds a new checkout phrase, so the developer checks the phrase dictionary while the translator approves its wording. The product owner verifies the meaning and the QA reviewer repeats the order journey. This division of responsibilities makes localization sustainable.
A four-week learning and launch plan
Week 1 — Understand and inventory
Choose one representative user, target locale and source-to-target route. Map static pages, CMS or catalog fields, shared components, search labels, accessibility, forms, commerce services and all messages a visitor could receive. Record each content owner and mark platform limits. Do not begin with an entire catalogue because a small sample reveals mismatches at far lower cost. Finish the week with a clear definition of what a completed language journey must achieve.
For Adobe Commerce and Magento, the deliverable is a short evidence sheet: the language or store view, one successful task, the URLs tested, who signed off the claims, and any open issue that restricts publication. This makes the project teachable to a new colleague and prevents a future editor from mistaking an attractive translation for a fully maintained service.
Week 2 — Translate a controlled sample
Create the applicable draft language resources and translate one representative record per content type. Use a terminology sheet and an approved fact sheet. Keep variables, IDs, codes, prices and contractual facts under controlled ownership. Check the sample in its actual interface, including any inherited values, and ask a second reviewer to identify ambiguous statements. Do not use the number of translated entries as the readiness score. Finish with source-linked corrections and a short list of uncovered surfaces.
For Adobe Commerce and Magento, the deliverable is a short evidence sheet: the language or store view, one successful task, the URLs tested, who signed off the claims, and any open issue that restricts publication. This makes the project teachable to a new colleague and prevents a future editor from mistaking an attractive translation for a fully maintained service.
Week 3 — Run independent functional review
Open the test version from fresh sessions and follow real tasks. Check a deep link, navigation, mobile text expansion, screen-reader labels, a search query, at least one form and the purchase or appointment journey where relevant. Examine confirmation, error and recovery messages. Ask a reviewer to state what service or product they believe they will receive. Compare their answer with the merchant’s verified promise. Record failures using URLs, exact locales and expected outcomes.
For Adobe Commerce and Magento, the deliverable is a short evidence sheet: the language or store view, one successful task, the URLs tested, who signed off the claims, and any open issue that restricts publication. This makes the project teachable to a new colleague and prevents a future editor from mistaking an attractive translation for a fully maintained service.
Week 4 — Release and maintain
Review the issues, obtain owner approval for high-risk text, and publish only the portions of the language edition that are ready. Repeat the same smoke test on the public site immediately after deployment. Tell customer-support staff which languages and regions are genuinely supported. Keep a change log for new pages, catalog fields, policy revisions and extension updates. Schedule focused rechecks of transactional content so that translated pages do not drift away from current service facts.
For Adobe Commerce and Magento, the deliverable is a short evidence sheet: the language or store view, one successful task, the URLs tested, who signed off the claims, and any open issue that restricts publication. This makes the project teachable to a new colleague and prevents a future editor from mistaking an attractive translation for a fully maintained service.
Translation quality standards for a world-facing service
Meaning
The target text must preserve the source’s important facts, relationships, conditions and exclusions. Natural language is desirable, but translators cannot invent eligibility, stock, prices, health advice, legal promises or technical capability. Confirm terms that change purchasing or service decisions with the responsible person.
Completeness
Review all surfaces a reader encounters, not only the first page. Menus, labels, related CMS items, filters, errors, receipt messages, alt text, search snippets and follow-up contacts may be separately owned. Use a coverage inventory that says not only what was translated but also what the platform cannot currently support.
Function
The localized interface must perform the correct action. Opening a modal is not the same as submitting an order. Choosing a variant is not the same as changing the SKU. A language switch is not necessarily a matching-page redirect. Test clicks, form states, direct URLs and recovery routes from a clean session.
Clarity
Prefer short, intelligible sentences with explicit subjects and actions. Preserve necessary technical terminology but explain it in ordinary language. Ask whether an international reader can tell what happens next without knowing the source language. Keep regional examples useful rather than assuming a single country’s institutions or slang are universal.
Accessibility
Check readable fonts, language metadata, focus order, keyboard use, alternative descriptions and text direction. Long translations can wrap differently, especially on phones. A translated error message is not accessible if it appears only by color or cannot be reached by an assistive technology user.
Evidence
Use a clear distinction between a passed test and a plausible assumption. Write down the source of each important claim, test the real public route and capture a failure that another person can reproduce. When documentation changes, follow official product guidance rather than copying an old screenshot blindly.
Maintenance
Every new source field, product option, policy, promotion or theme update can affect more than one language. Keep terminology decisions and dependencies visible, assign review owners and make localized checking part of ordinary releases. This is a maintained educational and commercial service rather than a one-off translation exercise.
Frequently asked questions
Does changing an Adobe Commerce store view locale translate all products?
No. Adobe documentation distinguishes interface translation tables from merchant-authored product and category text, which must be translated separately at the appropriate scope.
What is a store view in Magento?
A store view is a level of the Commerce website/store hierarchy frequently used to present a store in a different language or locale.
Do I need a language pack?
A compatible pack can supply interface phrase translations, but the exact needs depend on installed Commerce version, theme and extensions.
Where do Magento i18n phrases live?
Developer documentation describes locale-specific CSV dictionaries and language packages, with controlled CLI workflows for collecting and packaging phrases.
How do I translate product attributes?
Use the applicable attribute-label controls for the store views, while keeping identifiers and relationships intact.
Can category URLs be translated?
Adobe’s store localization guide describes translated category URL keys and permanent redirect options. Plan the route change and test old links.
Is inline translation a routine public editing feature?
It is documented as a developer tool with caching and configuration implications; use a controlled environment and deployment process.
What should I test before a new store view goes live?
A representative product, category, CMS page, navigation route, search query, checkout, transactional email and policy. Confirm business facts independently of language fluency.
Practice exercises for readers and implementation teams
Exercise 1
Exercise one: Choose a page in the target language and write a four-sentence description of what a first-time visitor will learn, decide, do and receive. Compare that description with the source owner’s verified facts. If you cannot identify the action, find the missing link or unclear wording. This exercise reveals whether the page actually serves a reader.
Exercise 2
Exercise two: Inventory six visible strings: a heading, navigation item, button, form error, product or service description, and confirmation message. For each, record the source, target, owner and dependency. Identify which parts are free translation and which are technical or contractual facts. Then imagine the source changes tomorrow and determine whether the target edition will update safely.
Exercise 3
Exercise three: Follow a deep link in the source language and use the selector to change languages. Record the destination, not just its appearance. Repeat from a different page, from a collection or category, and from the browser’s address bar. Note whether the second language has a true counterpart, inherits content or returns to a default destination.
Exercise 4
Exercise four: Test one deliberately awkward phrase and one long piece of text. Examine wrapping at mobile width, keyboard access, language-sensitive punctuation and the intended action. Rewrite the phrase in natural target-language terms without altering what the action does. Ask a new reader to predict the next screen before interacting.
Exercise 5
Exercise five: Make one safe sample submission or purchase simulation under the target locale. Trace every status, error and acknowledgment, including any email or linked external service. Do not use real personal information in a test account. Write a concise defect report naming the expected result and actual failure. Correct the owner-controlled cause rather than translating around an unsupported function.
Exercise 6
Exercise six: Give a reviewer a localized page without its source and ask three questions: What does it offer? What limitations apply? What will happen after the next action? Compare their answers with the verified operational promise, then resolve any discrepancy. A reader-centered review tests understanding, while a word-for-word comparison tests only correspondence.
Useful glossary for this implementation
primary locale: The default language or language-and-region context used as the structural source for the site or storefront.
secondary locale: An additional language or regional edition whose content, publishing and routing should be checked on its own terms.
language selector: The control that changes what language a visitor sees, which may or may not retain the current deep-page context.
source text: The authorized statement from which meaning is carried into another language; it may contain facts that cannot be improvised.
localized override: A value explicitly authored for one locale instead of inherited from the source; it often needs independent maintenance.
fallback: The language, route or content shown when a requested translation does not exist or is unavailable.
publishing state: Whether a translation is only drafted, reviewed or actually accessible to the public.
CMS field: A structured content property used by a CMS or catalog, which may be a label, reference, description or technical identifier.
translated slug: The language-appropriate readable portion of a page URL, which is distinct from the whole platform route structure.
metadata: Information about a page such as search title, description and social preview, subject to locale-specific review.
accessibility label: Text that gives an assistive technology user the function or meaning of an element without depending on its visual appearance.
transactional message: An order, booking, account or service communication that may use a separate template or language-preference system.
Final release checklist, further reading and official sources
A complete release has accurate first-page text, a coherent language selector, reliable deep links, translated dynamic content where supported, honest regional claims, checked accessibility, correct search metadata, successful visitor tasks and tested communications. Every unsupported element should be identified rather than hidden behind an automatic translation score. The safest launch is smaller and complete, not larger and misleading.
Official product documentation used for this guide: https://experienceleague.adobe.com/en/docs/commerce-admin/stores-sales/site-store/store-localize ; https://experienceleague.adobe.com/en/docs/commerce-admin/stores-sales/site-store/store-views ; https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cli/localization ; https://experienceleague.adobe.com/en/docs/commerce-admin/systems/tools/developer-tools ; https://experienceleague.adobe.com/en/tools/commerce-storefront/setup/configuration/multistore-setup/ ; https://experienceleague.adobe.com/en/tools/commerce-storefront/dropins/all/commerce-tasks. Features may change by edition, plan or rollout. Confirm the current documentation and the actual platform configuration before making production changes.
For the broader learning architecture, read Master Art of Translation at https://edukatesg.com/2026/09/18/master-art-of-translation-complete-system-moving-meaning-between-languages/ and the Translate Like a Pro series index at https://edukatesg.com/translate-like-a-pro-series-index/. The next useful skill is to carry the same verification discipline into a different publishing platform without assuming its technical controls are identical.