Duda multilingual website localization creates language-specific versions of site content, but those versions still need careful review and ongoing maintenance. This complete guide explains Duda’s Site Languages workflow, its optional automatic AI translation, manual editing, language switching, dynamic pages, navigation, storefront considerations and international SEO quality checks. It is for agencies, translators and site owners who want readers to reach useful pages in their own language rather than merely see machine-translated text.
The central decision is when to add languages. Duda’s support documentation warns that content added to one language edition after the multilingual site is created does not automatically synchronize across the other language copies. This makes source-page planning, precise re-translation decisions and language-specific testing especially important. Dynamic pages add a separate choice because their data may come from linked collections, while a native or third-party store has its own translation requirements.
First finish and audit the primary-language site; choose supported languages and review automatic translation settings; map the new language copies; translate menus, widgets and forms; test dynamic collections and store experiences; inspect language URLs and SEO metadata; validate mobile journeys; and plan how every later source edit reaches the other languages.
- Identify the real source and destination audience.
- Map every published page and its intended counterpart.
- Keep business facts distinct from translated language.
- Test navigation, dynamic content, forms and mobile screens.
- Review search metadata, release status and continuing maintenance.
Definition lock: what this translation system actually means
In Duda, the Site Language setting for built-in widget text is not the same thing as the multilingual site feature, which creates translated versions of site pages. A language copy is an editable version of a page, not a live mirror of all future source edits. A dynamic-page collection is structured content displayed through a page template. A language switcher is a route to an equivalent translated page, not proof that all visible and transactional content is translated.
Quick answer: the complete multilingual publishing workflow
Duda translation should begin with an honest description of the visitor’s journey. Decide who needs the content, which pages must correspond, what terminology is approved and where operational facts are owned. The visible copy is only one part of the experience. Navigation, search, source data, support, consent and the success message should remain coherent when a visitor changes language.
A practical approach is to complete one journey in the source language, translate that journey for a single destination audience, prove that it works on public URLs, and only then enlarge the release. This reduces the risk of scaling a hidden routing, data or editorial problem. The objective is not maximum translated page count; it is dependable understanding.
The essential distinction: language, locale and market
Language describes the words and grammar used to communicate. Locale describes a selected language and regional convention, such as date or number formatting. Market describes the place where a service is offered and may introduce business rules that translations cannot decide. Keeping these categories separate makes multilingual publishing easier to maintain and far safer for visitors. Two pages can be written in French yet carry different appointment conditions because they serve different markets. A translator must preserve the approved conditions for each one.
1. Choose languages from readers, not flags in Duda
Choose languages using actual customers, then inspect Duda’s supported options before starting. The language feature can produce copies of pages, and the correct market variant may demand changed examples even when the underlying service is identical.
A language is not a country, and a market is not simply a language. French written for a customer in Quebec may need different examples, delivery explanations and customer-support vocabulary from French intended for Paris. The useful first question is who will read the page and what they need to accomplish. Rank languages by visitor demand, business readiness and the team’s ability to maintain the translated version. Define one primary source language and a clear fallback rule, then write the specific locale rather than a vague universal audience.
Begin with an example the reader can actually encounter, such as a visitor following a search result on a mobile phone. Identify the promise made by the heading and verify that the next action remains available after the language changes. If the task is unclear, write down the page’s purpose in one sentence before editing words. A translation that obscures the purpose is incomplete even if every sentence is grammatically correct.
Practical exercise 1: verify the reader’s result
Build a language matrix containing a language tag, a reader persona, a primary conversion action, the owner who can approve meaning and the required legal or product variations. Test it against an actual visitor arriving from a search result, not only a colleague clicking the homepage selector. Which language and market does this specific page serve? What would a reader reasonably expect to do next? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
2. Define a translation, a duplicate and a true local edition in Duda
Duda duplicates the site when new languages are enabled. A new copy still needs an editorial sign-off: its purpose and promises must remain equivalent even though the translation looks fluent.
A translated edition is an equivalent page that expresses the same underlying claims and lets a reader perform the same task. A duplicate is merely a copied page, even when it has a different URL. A local edition may legitimately change prices, eligibility, contact options or examples, but every intentional difference needs an accountable owner. This distinction keeps a publication system from producing false equivalence between two pages that no longer offer the same product or outcome.
Look at the content’s relationship with its neighbouring pages. What is introduced earlier, and what does the reader reasonably expect to find next? This helps avoid treating translation as a sequence of isolated text boxes. Small contextual clues often settle terminology disputes faster than prolonged arguments about dictionary alternatives.
Practical exercise 2: verify the reader’s result
Write an equivalence card for one page: the source identifier, destination locale, essential claim, action promised and which details may change. If a change affects a policy or promise, treat it as a controlled local adaptation rather than a translator’s stylistic preference. Does the localized version communicate the same promise and all necessary qualifications? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
3. Inventory pages before translating anything in Duda
Inventory the primary site before adding languages. Duda recommends completing the main design first because later content edits in one language are not automatically synchronized to other language copies.
Many multilingual launches fail because teams translate visible headlines while forgetting search pages, navigation labels, consent messages, thank-you screens, product details and old campaign URLs. A complete inventory is organized by reader journey rather than content volume. Record each page’s purpose, template, owner, current URL, dependency on shared data and whether its localized counterpart is ready. The inventory is a planning instrument, not a requirement to publish every URL in every language.
Work with a tiny but representative sample first. One informational page, one conversion page and one exceptional state reveal more about the real system than a bulk import whose results nobody has read. Record specific defects and correct the method before increasing the volume. The aim is to learn where this platform stores meaning and where it simply displays it.
Practical exercise 3: verify the reader’s result
Start with one representative journey: search result to landing page, navigation to details, form submission and confirmation. Mark every string encountered, including those generated by widgets. The gaps often matter more than the beautifully translated hero sentence. Which part of the journey has been omitted from the language inventory? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
4. Establish source-of-truth and editorial responsibility in Duda
Assign ownership for source edits and each translated copy. Re-translation can bring over updated source content and design, potentially replacing target-specific work, so record deliberate local adaptations.
Translation becomes unstable when several people edit what they consider the original. Choose a source record and name the person who approves claims, the reviewer who judges language and the publisher who controls release. Keep a change log tied to concepts rather than merely timestamps. A new sentence about an offer may require a legal review, while a corrected typo may only need a linguistic check. Separate these decisions so a simple improvement does not trigger needless retranslation.
Notice how editing authority and technical behaviour interact. A translator may be able to modify visible copy while the software or business team controls the source data, routing and permissions. When responsibilities blur, corrections are made in the wrong place and disappear during the next update. Agree in advance which changes are editorial and which require an administrator.
Practical exercise 4: verify the reader’s result
For each important page, record the latest approved source revision, dependent localized revisions and the next review date. When the source changes, ask whether the meaning changed before reusing an existing translation. This protects accurate translations from accidental replacement. Who can authorize a changed fact and who can approve the translation? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
5. Design a stable language URL strategy in Duda
Expect language-specific paths, and check actual public URLs rather than assuming a translated label produces a functioning language route. Keep a page-to-page correspondence table.
A good language URL is predictable, linkable and understandable without browser memory. Decide whether the site uses language folders, distinct domains or another supported pattern. Keep a mapping between counterpart pages rather than guessing from similar slugs. Redirects should take a visitor to an equivalent destination, not silently to the homepage. Changing the route after indexing can require redirects, canonical review and updated internal links.
Test the failure path as carefully as the happy path. A missing translation, an unavailable service and an invalid form entry are normal situations that real visitors encounter. Explain what the site should do in those circumstances, and check that the visitor never has to guess whether their request was accepted.
Practical exercise 5: verify the reader’s result
Write a table of five real source URLs and their approved counterparts. Open each directly in a private browser window. Check the content language, menu, page title, canonical and destination after language switching. Treat a correct URL that displays the wrong language as a release failure. Can a new visitor open the target URL directly and reach the correct language? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
6. Plan for missing translations and incomplete sections in Duda
Consider pages translated only where the site has useful local content. The editor’s ability to show a new language does not justify sending search visitors to a half-English page.
A multilingual website seldom has perfect simultaneous coverage. A new page may exist only in the source language; a translated article may be pending review; an old event may have no useful equivalent. Decide whether missing content is hidden, visibly offered in another language or represented by a clear notice. Avoid manufacturing a nominal localized page whose entire body remains in the source language simply to fill an SEO index.
Keep the evidence small and concrete: a source URL, a target URL, the exact string, the expected result and one screenshot or test record. That makes a problem reproducible and allows another editor to verify the correction without inheriting the entire conversation. Clear records are useful long after the original launch.
Practical exercise 6: verify the reader’s result
Classify every missing page as scheduled, deliberately unavailable or obsolete. Give the reader an honest route to the closest relevant content. Record how the language selector behaves when no counterpart exists, because that exception is common and easy to overlook. What happens when this particular counterpart does not exist or is not approved? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
7. Translate navigation as a service, not as decoration in Duda
The Duda language selector and menu need inspection on all templates. Support documentation notes restrictions involving external navigation links after languages are added, so plan menu architecture early.
Menus tell readers what they can do, and that meaning matters more than matching the number of characters. A label such as ‘Support’ can mean technical help, a knowledge base or a way to contact a person. Translators need the actual destination and visitor intent, not just a list of isolated words. Test dropdowns, footer links, mobile menus, breadcrumbs and buttons after translation; a label can be linguistically correct and still lead nowhere.
Prefer a clear reader instruction over an ornate literal equivalent. A heading may legitimately be shorter, a call to action more explicit and a support label different from the source, provided the underlying action stays the same. The translation should help somebody do the job, not display the translator’s cleverness.
Practical exercise 7: verify the reader’s result
Choose three menu labels that are ambiguous without context. Ask a reviewer to open each destination and write the action the visitor expects. Approve the translation only when it guides that action. Follow every menu path in each enabled language. Does every navigation label lead to the page it appears to promise? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
8. Separate shared components from page-specific copy in Duda
Header and footer changes need deliberate attention. Duda’s redo-translation guidance warns that header and footer content are not translated in the page re-translation process.
Headers, footers, global calls to action and reusable blocks appear across many pages, so a small mistake can spread widely. Conversely, a page translation may not automatically translate a shared component. Identify where each reusable element is stored, whether it has independent language variants and which release controls govern it. Do not assume that changing a header in one language will update other language editions.
Check both the content and the surrounding interface. A message can be accurate while its button is hidden, its confirmation is in another language or its link points to a stale page. If these parts disagree, readers experience one broken journey rather than several unrelated minor defects.
Practical exercise 8: verify the reader’s result
Create a component register containing logo alt text, search placeholder, privacy link, contact button, cookie text and footer address. Inspect a fresh page and an older page in two languages. If their shared components disagree, fix the ownership model before expanding the rollout. Which shared component is still using the source language? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
9. Treat structured and dynamic content as a separate system in Duda
Dynamic pages are created and managed primarily from the site’s primary language. A translated dynamic page may still point to the original collection until the editor selects a translated collection or a language-aware external source.
A translated landing page may retrieve cards, products, events or catalogue items from a collection that has its own language model. The page template and the data source are different responsibilities. Keep identifiers and numerical facts stable while translating display labels, descriptions and permitted localized attributes. A dynamic page that still points to a source-language collection can appear finished in the editor but fail for real visitors.
Build a simple test table with source language, target language, expected content, actual result and decision. Do not count a field as complete merely because it is non-empty. The useful distinction is between reviewed, awaiting approval, intentionally absent and defective content. These statuses tell an editor what can safely go live.
Practical exercise 9: verify the reader’s result
Test a data-driven listing with at least two records, one missing translation and one recently changed record. Check what appears in the card, detail page, search result and related-content block. A single screenshot cannot establish that the entire data pipeline is correct. Does this dynamic record come from the correct language-aware source? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
10. Keep forms and contact journeys understandable in Duda
Translate every customer-facing form label and message. Test the captured data in the destination workflow because copied pages can retain form settings even while visible text differs.
A page can be perfectly translated and still lose a reader at a form. Field labels, validation errors, consent text, dropdown values, confirmation messages and follow-up emails all belong to the language journey. The submission destination and data handling must remain correct, and consent language must match what actually happens. Translating a field name does not require translating the database key that receives its value.
Pay attention to changes over time. An accurate translation today can become wrong when a policy, deadline or offer changes tomorrow. The system needs a human-readable reason for the revision and a practical path to update related editions. This is where many otherwise polished global websites lose trust.
Practical exercise 10: verify the reader’s result
Submit test entries in each language using a dedicated test contact. Force a required-field error, an invalid email and a successful submission. Verify the visitor sees clear messages and the team receives usable structured data. Inspect the follow-up message rather than stopping at the form screen. Can a visitor submit the form, read errors and understand confirmation? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
11. Localize commerce and service promises carefully in Duda
On Duda multilingual sites, stores require a separate investigation. Native Stores have language support documented separately, and third-party stores may not automatically translate with the website.
Price, tax, delivery, appointment availability and cancellation rules are business facts. They should not be invented by translation software or altered for smoother wording. Distinguish what is genuinely language-specific from what changes by market, currency, location or customer eligibility. If a site does not provide the same checkout capability in every language, describe the limitation clearly instead of making the translated page promise more than the workflow delivers.
Ask which facts must remain identical. Product identifiers, appointment dates, contract terms or supporting evidence may have a stable underlying value even if their presentation changes. Separating invariant facts from changeable presentation prevents accidental promises. It also makes future quality checks much easier.
Practical exercise 11: verify the reader’s result
For one offer, compare the product statement, price display, payment option, refund explanation and customer-service route. Have the appropriate owner confirm the claims for each destination market. Keep immutable identifiers in transaction data even if visible names differ. Which claims are regulated business facts rather than translatable style? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
12. Translate images, captions and media relationships in Duda
Widget text and media embedded within text may need manual correction. Duda’s support notes that some links can disappear from translated hyperlinked text and that rich-text formatting in certain widgets can change.
Images can carry text, assumptions and context that are invisible in a conventional word-count inventory. Review embedded typography, diagrams, captions, alt text, filenames used in editorial workflows and subtitle or audio tracks. Alt text should describe the meaningful image in the page’s language; it is not a place to paste search keywords. A translated callout over an image may need redesign if its length changes.
One reader may arrive directly from a search result and another may switch languages inside an article. Test both situations. The language selector should not depend on a hidden earlier step, and the target URL should explain where the visitor has arrived. Direct entry is the ordinary behaviour of the web.
Practical exercise 12: verify the reader’s result
Inspect a hero image, an instructional screenshot and a product image. Ask whether a reader using a screen reader receives equivalent information, whether the image contains untranslated words and whether the media’s example is culturally intelligible. Update the asset only when the evidence calls for it. What information is conveyed only through an untranslated image or caption? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
13. Use machine translation as a draft that needs a decision in Duda
Automatic AI translation can be used when adding a language, but Duda warns that it may be inaccurate. Review all high-impact claims before publication, even when automatic translation is provided without AI credit consumption.
Automated translation can be useful for initial coverage but must not be confused with a factual review. It cannot determine whether a discount exists in a market, whether a phone number works or whether a product claim is legally permitted. Human reviewers should concentrate on ambiguous terminology, high-impact claims, interface constraints and the customer’s next action. Preserve the option to reject or rewrite the automated suggestion.
Give reviewers a decision rule rather than an impossible demand for perfection. A reversed meaning or broken contact route blocks publication. A harmless stylistic preference can be recorded for later. Use the severity of the reader’s likely harm and confusion to order the corrections, especially when many locales are launching together.
Practical exercise 13: verify the reader’s result
Sample low-risk informational text and high-risk transactional text separately. Track defects by severity: meaning reversed, action broken, terminology inconsistent, awkward but usable. Release decisions should be based on impact, not the percentage of text that happens to have been filled. Which draft suggestion could mislead a buyer or change an instruction? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
14. Maintain a small, enforceable terminology guide in Duda
Build a glossary for repeated agency or service terms, especially location names, booking categories and support actions that appear across the copied pages.
A glossary is a collection of decisions about meaning. It should explain a term’s concept, its approved translation, prohibited misleading alternatives and a usage example. Product names may remain unchanged; regulatory phrases may need a jurisdiction-specific form; internal labels may not belong in public copy. The glossary needs a single owner and a simple way for reviewers to propose corrections. Otherwise, a long list of words becomes an ignored document.
Remember that shared terms gain meaning through repetition. If the same feature has one name in the menu, another in a form and a third in an email, readers may think they are different things. Keep names consistent unless the destination language genuinely requires a different grammatical form.
Practical exercise 14: verify the reader’s result
Start with ten terms that appear in the most important journey: offer names, account status, contact action, appointment words and policy terms. Use the same approved decision in page titles, forms, emails and support articles. When a term changes, search for its older form across all published editions. Are recurring terms consistent across page, form and support journey? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
15. Write naturally for the destination reader in Duda
Because language versions are editable independently, shape every headline and service description for real destination readers while maintaining the same underlying promise.
Faithful translation is not word-for-word imitation. Natural word order, appropriate politeness, complete explanation and clear verbs help readers recognize the intended action. Maintain the source’s underlying promises and evidence without importing idioms that do not travel. Short text is not automatically better: a button may need more characters for clarity, while a legal notice may need a fuller sentence. Evaluate meaning and usability together.
Invite someone unfamiliar with the source page to carry out the task. People who know the English text too well may unconsciously fill gaps in a weak translation. An independent reader exposes missing context, strange terminology and dead-end navigation that an editor can overlook.
Practical exercise 15: verify the reader’s result
Ask a native-language reviewer to complete the site’s main task without looking at the source. Then compare what they understood with the intended offer. If readers can pronounce every word but misunderstand the action, the language still needs work. Can a native speaker complete the task without consulting the source? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
16. Control dates, quantities, names and formatting in Duda
Test dates, opening hours, delivery limitations and phone numbers on translated Duda pages. Do not let the availability displayed in one language imply a different service schedule without authorization.
Locale conventions are part of accurate communication. A date that reads as 03/04 can mean different days; a comma can be a decimal separator or a thousands separator; time zones and telephone formats matter to real appointments. Units, currencies and measurements need explicit context. Some values should be converted by the business system; others should remain unchanged with a readable label. Translation alone cannot decide which.
A local adaptation should be traceable to a real reason. If an example changes because the destination audience uses different measures, note the factual change. If a policy changes because the market has different rules, obtain the required approval. Do not silently mingle localization with business-policy writing.
Practical exercise 16: verify the reader’s result
Create a factual test sheet with one date, one price, one percentage, one dimension, one phone number and one delivery interval. Read each in the destination language and verify that a customer would make the same decision. Document any conversion rather than disguising it as a wording change. Are times, numbers and contact details unambiguous? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
17. Make page titles and search descriptions useful in Duda
Page titles and meta descriptions need review in every language. The Duda website can provide language-specific URLs, but search intent and snippet accuracy still require editorial work.
Search engines and human readers see the page title before they see the body. A translated title should communicate the page’s actual purpose using natural phrases in that language, not a mechanical copy of the source keyword string. Descriptions should summarize the specific page and avoid fabricated claims or generic promises. Localized metadata also needs a revision workflow when the underlying page changes.
Use the actual public result as evidence. Editors may show drafts, placeholder text or cached content differently from what visitors see. Check the rendered page, including its title and links, after publication. This is particularly important for a page reached without signing in.
Practical exercise 17: verify the reader’s result
For each version, draft a title that a local reader would recognize, then write a plain-language description that distinguishes the page from neighbouring pages. Confirm both match the content and that the visible heading supports the same search intent. Would the title make sense as a real search result in the destination language? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
18. Treat canonical and language-alternate signals carefully in Duda
Inspect the rendered canonical and alternate-language configuration for a real translated pair. Do not infer correct hreflang from the editor’s presence of a language switcher.
An international search configuration needs to distinguish duplicate URLs from language alternatives. A canonical generally identifies a preferred version of equivalent content within a language, while hreflang identifies language or regional alternatives when implemented. Do not force every translated page to canonicalize to the source language, and do not claim that a visual language switcher automatically proves the correct tags exist. Inspect rendered output and current search guidance.
Search visibility is earned by useful content, not by repeating keywords. Ask what question a local reader is trying to answer, then make the translated page answer it plainly. Search metadata should describe the page accurately and lead to an experience that matches the promise made in the result.
Practical exercise 18: verify the reader’s result
Sample one published page pair. View the HTML head and verify that the canonical points where intended, that alternate references are reciprocal when used and that each destination returns the appropriate language. The tags are evidence, not decoration in a settings panel. Do the published search annotations point to verified counterpart pages? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
19. Handle search, internal links and redirects as one network in Duda
Test internal search and direct links, especially where dynamic pages load content from collections. Make sure source-language cards do not redirect local readers to another language unexpectedly.
A locale can work on the homepage while search results, old links and related-article cards constantly send readers back to the source language. The solution is not to translate isolated URLs but to audit how pages connect. Distinguish the site’s internal search index, external search indexing, recommended-content blocks and redirects. Each can have different language-awareness and update schedules.
Consider how the system behaves when part of the content is unavailable. There may be no local version of a related story or a service may not operate in that country. A clear explanation and an intentional route are better than a silent jump into another language or an apparently broken page.
Practical exercise 19: verify the reader’s result
Search for a common product or service term in two languages. Open the first result, a suggested article and a breadcrumb. Then test an old campaign link. Record every unexpected language jump and the system that produced it, rather than correcting the visible text alone. Which link sends a reader into an unexpected language? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
20. Protect accessibility and right-to-left behaviour in Duda
Check language attributes, accessible labels and any right-to-left requirements in the delivered page. Manual edits may be necessary when automatic output looks correct but confuses assistive technology.
Translation should not make a website harder to use with a keyboard, assistive technology or reduced-vision settings. Lang attributes, heading order, focus behaviour, descriptive links, colour contrast and readable form errors all remain necessary. For right-to-left languages, alignment is only one part of the problem: bidirectional phone numbers, Latin brand names, punctuation and embedded code may require additional care.
Accessibility checks are not an optional final polish. A keyboard user must still reach the menu, a screen-reader user must understand the form, and someone on a small device must be able to submit it. Language changes can expose flaws that already existed in the original layout.
Practical exercise 20: verify the reader’s result
Check keyboard navigation and a screen-reader pass on at least one important translated journey. If right-to-left support is needed, test mixed-script addresses, numerals and form values. Document a real product limitation rather than announcing full accessibility based on visual inspection alone. Can assistive-technology users understand the translated control? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
21. Verify layouts across real devices in Duda
Translated Duda widget labels may wrap on mobile. Check accordions, tabs, language navigation and pages with dense cards after translation; Duda documents formatting limitations for certain widgets.
Translated copy expands and contracts. Buttons wrap, menu columns widen, cards become different heights and a mobile header can hide a language selector. A beautiful desktop screenshot proves very little about a narrow screen. Test on the actual templates and breakpoints that carry the site’s main conversions, including translated error messages and longer legal statements.
Inspect the longest likely strings, not just the easiest example. Legal notices, error messages and button labels are often longer in translation than the corresponding English text. Test the layout with real translated copy, then adjust the presentation before cutting essential meaning.
Practical exercise 21: verify the reader’s result
Use a short and a long locale in the same page template. Check tap targets, sticky elements, dropdowns, headings, image crop and the final submit button on mobile and desktop. When the interface fails, fix the layout or wording without cutting away essential meaning. Does the longest translated label fit on a narrow screen? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
22. Publish in controlled, observable stages in Duda
Publish a few representative Duda pages first and check the public version. A redo-translation operation may create a backup, but it does not replace an explicit review of localized changes.
Publishing is a change to a live service, not the last click in a translation editor. Before release, decide which languages and pages are in scope, which approvals are required and what the team will do if a critical link or form fails. A small representative launch exposes problems more safely than enabling an entire catalogue without verification. Separate editorial readiness from technical readiness.
Design the release to teach the team something. Choose a small set of pages that includes one exception, not merely the prettiest pages. If the pilot passes, its checklists become a practical starting point for the next language. If it fails, the scope remains small enough to repair.
Practical exercise 22: verify the reader’s result
Use a release card: exact URL set, source revision, language reviewer, form test, SEO test, rollback owner and approval date. Open the public site after publication, since the editor preview and the visitor’s page can differ because of caching or publication state. Is the public journey genuinely ready for release and rollback? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
23. Measure comprehension and outcomes in Duda
Measure contacts, appointment starts, form errors and on-site searches by locale. Search traffic alone can hide confusing translated menu names.
Traffic alone cannot tell whether translation improved the visitor’s experience. Compare useful measures such as language-specific task completion, inquiry quality, exit points, search terms and form abandonment. Segment carefully: a small new locale may have too little volume for confident conclusions, and a different customer mix can explain apparent changes. Treat measurement as a way to discover confusing passages, not as permission to change facts.
Interpret numbers in context. A newly translated page might have low conversion because the audience is still small, because the language is confusing or because the service is not attractive in that market. Data suggests questions; it rarely supplies the explanation on its own.
Practical exercise 23: verify the reader’s result
Keep a baseline for the source journey, then compare each locale’s steps and errors. Review failed on-site searches and user questions for terminology gaps. If a localized page attracts visits but no one completes the promised action, examine the whole journey before rewriting the headline. Which outcome would show that readers understand the translation? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
24. Maintain translation after the launch in Duda
Create a source-change checklist because the Duda translated copies do not stay in sync automatically. Mark which language pages require re-translation and which should preserve manual edits.
A multilingual site is a continuing editorial commitment. Source pages change, promotions expire, forms gain fields, team members leave and platform features evolve. Establish an update trigger: which changes require new translation, who approves them and how a stale localized page is marked. Avoid automatic copying that silently overwrites good target-language editing. Scheduled reviews matter most for dates, pricing, eligibility and policies.
The durable result is an editorial habit. Make it routine to check what changed, who approved the new meaning, whether the target URL still works and when it was last reviewed. The best multilingual architecture is not the one with the most switches; it is the one a team can maintain reliably.
Practical exercise 24: verify the reader’s result
Practise a realistic source change on one page and trace its effect through every locale. Note which content updates automatically and which does not. Record approvals and unresolved gaps. A maintenance workflow should work when the original editor is on holiday. How will the next source edit reach this language edition? Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
25. Diagnose failures by tracing the reader journey in Duda
undefined
When a site shows the wrong language, the apparent cause is often downstream: an unlinked counterpart, an untranslated global header, a cached URL, a dynamic collection field or a form that returns to the primary language. Avoid guessing from the first broken screenshot. Reproduce the problem with the page address, selected locale, browser context, device and exact action. Change one dependency at a time.
undefined
Practical exercise 25: verify the reader’s result
Create a defect record with expected behaviour, actual behaviour, reproduction steps, affected locale and severity. Retest the original failure and one neighbouring route after fixing it. This stops a small change from hiding another problem or moving a defect to a different language. undefined Document the conclusion in a brief editorial note so another reviewer can reproduce the result.
A complete worked example: from source page to a dependable second language
Imagine a small physiotherapy practice with an English Duda site and a new Spanish edition. The main page lists treatments and clinicians, the booking page uses a form, and service pages are produced by a dynamic collection. First build and approve the English journeys. Then enable Spanish with automatic translation disabled or reviewed carefully, inspect each corresponding page, replace ambiguous treatment descriptions with approved wording and check every form. A Spanish service card must open the Spanish detail page; if the collection holds English-only titles, create an appropriate localized dataset or use a supported language-aware external collection. After publication, change one English booking rule and trace whether that rule reaches the Spanish edition. Do not assume the site will synchronize it.
Now run the same journey as a visitor rather than as an editor. Begin from a published search URL, check the page heading and language, open a relevant detail page, encounter an ordinary form or transaction state, and find the confirmation. Repeat with the destination locale. A language is ready when the user can understand the promise, complete the task and tell what happened. Merely seeing translated paragraphs at the top is not a sufficient test.
Make the acceptance decision explicit. A wrong price, misleading condition, missing consent notice or broken form is a stop-ship defect. A minor layout difference might be acceptable if it remains readable and usable. Keep a record of the test language, URL, reviewer, date, screenshots or form submissions and any correction made. A short, reproducible test is more useful than a long statement that the translation looks fine.
Troubleshooting: five common failure patterns
- The translated page still shows English cards: inspect the dynamic collection connection and its language data.
- A new source paragraph never appears in Spanish: edit the Spanish copy deliberately or use the documented re-translation workflow with a change review.
- A translated hyperlink disappears: inspect the specific rich-text widget and reinstate an approved link.
- The header remains untranslated after re-translation: review header and footer independently.
- A store remains English: inspect the particular Native Store or third-party store multilingual workflow rather than treating page translation as store translation.
A four-week learning and implementation plan
Week 1 — Understand the system and map one real journey
Read the official Duda multilingual guidance and draw a simple journey from a direct URL to the main customer action. List source pages, translated counterparts, shared components and dynamic data. Agree on languages, target markets, essential terminology and business facts. Before changing anything, ask what the current source site promises and which parts of that promise may legitimately differ in another market. Finish the week with a page map, a language matrix and a shortlist of high-risk strings.
Week 2 — Translate a complete pilot, not a random assortment
Choose one useful landing page and its dependent detail and confirmation steps. Translate the body, title, navigation and calls to action. Check structured content, media and the form or checkout. Ask a native-language reviewer to perform the task without the source text. Record comprehension problems and missing translated strings. Complete the entire small journey instead of spreading translation work across dozens of unconnected pages.
Week 3 — Test public delivery, search signals and exceptions
Open every pilot URL in a clean browser, including the destination URL entered directly. Test language switching, missing counterparts, internal links, mobile layout, accessibility, metadata and actual form behaviour. Verify facts and compliance language with their owners. Review the public output rather than trusting editor previews. Rank failures by impact, correcting misleading meaning and broken actions before stylistic preferences.
Week 4 — Release, observe and establish maintenance
Publish the approved pilot and confirm the public pages still work. Monitor where visitors exit or encounter errors and note repeated terminology questions. Define who checks new source changes and who approves updated translations. Expand to more pages only when the model remains maintainable. At the end of the month the team should have a reusable workflow, not just a one-time collection of localized URLs.
Frequently asked questions
Should every page be translated?
No. Prioritize complete, useful journeys in languages the organization can maintain. An untranslated page should not be disguised as a completed edition. A smaller collection of accurate pages with working navigation, forms and support is often more useful than a large collection of copied pages whose content and business conditions have not been checked.
Is an automatic translation good enough to publish?
Sometimes low-risk text can be reviewed quickly, but the engine alone cannot certify a fact, service condition, regional law or transaction. Review meaning, terminology, links and key actions. Use a higher standard for prices, consent, booking, health, finance or safety claims. An editor should be able to identify who approved the final language.
Do translated URLs require their own SEO work?
Yes. A different path does not guarantee an appropriate title, description, internal link network or alternate-language annotation. Search intent differs across languages, and every published URL should deliver the information promised in its search result. Inspect the actual output, not only a setting in the editor.
How should we handle a page with no translated counterpart?
Choose a deliberate missing-content behaviour: explain that the content is unavailable in that language, offer the best relevant alternative or omit the destination from the switcher. Avoid misleading users by linking to an unrelated homepage. Record why the edition is absent and whether it is scheduled, unsupported or obsolete.
Does a language switcher translate the whole website?
No. It selects a route or page edition. The translated version may still contain source-language global components, collection records, images, form errors or transactional steps. Test each part of the visitor journey separately before calling the experience complete.
Can we change prices or product claims while translating?
Only when a responsible business owner authorizes the market-specific facts. Currency formatting is different from changing the price. A local edition may be required to show different delivery rules or product availability, but those differences should come from approved data and be documented independently of wording.
What is the smallest useful quality-assurance test?
Use one direct public URL, one language switch, one important internal link, one form or transaction step, one mobile pass and one search-head review. Include a missing-translation state. This small matrix often detects architectural failures before the team translates hundreds of pages.
How do we keep translations updated?
Record the source revision, the target-language owner and which changes affect meaning. After source edits, review every dependent edition and distinguish changes that require factual approval from simple style corrections. Perform scheduled checks for time-sensitive content such as terms, deadlines, contact information and prices.
Should translated pages have the same wording length as the source?
No. Good translation preserves meaning and usability rather than a character count. Some languages need longer explanations or labels, and a clear local call to action may use different syntax. Test the layout instead of deleting essential qualifications to force the words into an English-sized space.
What should a bilingual reviewer report?
Ask for the page URL, language, issue, expected meaning, actual wording or behaviour, severity and a concrete correction. A vague note that a page ‘sounds unnatural’ is less helpful than showing how the current expression changes a reader’s understanding or blocks the next step.
Final release checklist
- Every enabled language has an identifiable audience and an accountable editor.
- The source and destination page equivalents are mapped and truthful.
- Public URLs can be opened directly without relying on earlier navigation.
- Header, footer, forms, dynamic records and follow-up messages were inspected.
- Search titles, descriptions and available language-alternate signals were checked.
- Dates, amounts, identifiers and market conditions were approved by their owners.
- Mobile, accessibility and missing-translation paths were exercised.
- The team has a record of review, defects, release and source-change maintenance.
Official documentation and further reading
Duda: Add and Manage Multiple Languages
Duda: Dynamic Multilanguage Pages
Continue with the Master Art of Translation: Complete Translation System for the principles of faithful meaning transfer, and the Translate Like a Pro series index for related technology-specific guides.