How do you translate a DNN Platform website while keeping localized pages, modules and language activation under control? This DNN content localization guide explains adding languages, creating language-specific page versions, translating modules, reviewing publication status and testing a multilingual visitor journey. It is written for editors, administrators and developers serving audiences in more than one country or language.
DNN Platform offers content-localization features, but enabling a language is not the same as completing a translated site. The page may exist without approved copy, a module may remain in the default language, or a new language may be inactive for ordinary visitors. Translation also has to preserve navigation, forms, accessible labels, URLs, search visibility and the underlying facts that people rely on.
This practical DNN multilingual website tutorial follows a fictional international community arts centre from its English source pages to Spanish and German destinations. It uses the documented DNN language and page-localization workflow while separating version-dependent settings, translation decisions and public delivery tests. The goal is an auditable release in which each reader sees truthful, usable content rather than a collection of copied pages with translated headings.
Quick answer: the multilingual DNN launch sequence
Identify the site’s existing default language and the languages it intends to support. Review DNN’s installed version and the permissions of the editors who will do the work. Add a language through the site’s language management, enable it as appropriate and decide how pages will have localized counterparts. Create one test page, copy or associate its modules using the documented content-localization controls, replace the visible content with reviewed translation and confirm the target version’s status.
Before activating the language publicly, walk an entire reader task: landing page, related event, form, confirmation and exit route. Test a page whose translation is deliberately missing. Check direct URLs, page titles, language selection, navigation and search metadata while signed out. Record the source revision and target-language approval. Activation is a release decision; it should not happen simply because a new language appears in the control panel.
First separate interface language, page language and module content
DNN uses languages in more than one context. An administrative interface may display translated labels while public pages remain in the default language. A language-specific page may exist but contain modules copied from another language. A module may render text from an independent extension or external system. These layers need different ownership and tests.
When someone reports that German is not working, ask exactly where the English text appears. Is it a system menu, the page title, a content module, an error from a form or an email sent afterward? The answer determines whether the fix belongs in language resources, page content, module configuration or application integration. Without that distinction, teams can spend hours re-translating visible pages while the actual failure is a reused component. Build a surface inventory before selecting a translation tool.
Inspect the installed DNN version and configuration
Documentation for DNN content localization includes version-specific interface paths. The community documentation describes a workflow in which administrators manage languages under site settings and enable content localization. Exact menu names, available options and behavior can differ among DNN Platform releases, themes and extensions. Confirm the installed environment before using any published screenshot as a literal instruction.
Start with a nonproduction copy. Record the default language, existing language list, site aliases and modules with their versions. Test what happens when one new language is added but not activated. Check whether users have permission to create and edit localized content. Preserve the configuration before making changes. A multilingual migration should not be used as an experiment on a busy public site. The most useful first report says which version was tested, which control was used and what the visitor actually received.
Why the default language deserves careful planning
DNN’s documented setup warns that the default language cannot simply be changed after content localization has been configured in the demonstrated workflow. Treat the original language as an important architectural choice. A team should understand where its source content lives and how new translations relate to that source before enabling localization across a large existing site.
For a global arts centre, English may be the source of program descriptions, but local German and Spanish teams must still own their regional policies. Do not try to solve a mistaken source-language decision by renaming every visible label or rewriting URLs without a migration plan. If the site already exists, investigate the supported migration route for that version. Preserve link identity, source revisions and approvals. Planning at the outset is much cheaper than trying to reconstruct relationships after hundreds of pages have been localized.
Adding a language does not translate content
DNN community documentation outlines adding a language in site settings, checking that it is enabled and then proceeding to localized page work. This prepares a destination for content, not a translated result. The language may exist in the control panel while every public article remains English. It may also have resource strings available for the interface without any page-level translation.
Run a controlled test with a new language and one representative page. Ask an editor to describe which properties changed merely by adding the language. Confirm which properties require separate translation and review. Avoid using the number of enabled languages as a progress metric. Instead measure how many meaningful reader journeys have approved destination content, functioning modules and public verification. A small honest launch is better than a language dropdown that leads to widespread English fallback without warning.
Enabling content localization changes page workflow
The DNN documentation discusses making pages translatable and creating language-specific page copies. This is distinct from switching the language of the administration interface. A page in a target language can then be edited, translated and eventually published according to the platform’s state model. Changes to localization configuration should therefore be treated as an editorial architecture decision.
Before applying the setting across an established site, test how pages and modules are represented. Check whether a target page is independent in its body text and whether the menu structure remains aligned. Determine what happens to a newly created source page after localization is enabled. Document the differences between an original page, an unreviewed copy and an approved translation. Do not allow copied source text to masquerade as completed destination content. An explicit state register protects editors from confusing structural readiness with linguistic readiness.
Creating a language-specific page is only the beginning
When a localized page is created, its structure may resemble the source. The editor still has to translate titles, summaries, body content and meaningful interactions. Copying a page is useful because it preserves some layout and navigation context; it is not proof that every copied component is appropriate for another language or market.
Take an arts centre page advertising a pottery workshop. The title can be translated, but the venue address, eligibility, date, price and booking conditions must be checked as facts. A German visitor needs the same supported information or a clearly identified local adaptation. The editor should compare target against an identifiable source revision, not a memory of how the page looked last week. A translation is ready when the reader can follow the actual task without discovering that the text, module or form contradicts the promised destination.
Understand the page-localization controls
DNN documentation describes a localization interface associated with pages, and DNN support material describes using a page’s localization settings to copy modules into another language version. The details of the control and its naming depend on the product version. Administrators should inspect the actual site instead of relying only on examples from another deployment.
Use one page with two modules in staging. Create its target-language version, copy the modules by the supported method and examine what happened to their content. Did each module create a localized instance? Was any source content still shared? Can the editor identify the correct target version before making a change? Record the behavior. A localized page’s container may exist even when an individual module requires its own language content or extension-specific settings. Reusing the same layout should not mean reusing the same untranslated instructions.
Modules are the place multilingual completeness often breaks
A DNN page can contain modules serving different purposes. Some display rich-text content. Others provide forms, events, search, video or third-party applications. A module may have its own storage, language support, configuration and permissions. Therefore the content-localization mechanism for a page cannot be assumed to translate every module automatically.
Inventory modules by name, version, data source, target audience and localization behavior. For each one ask who owns its source text, whether a separate language version is available and how status is exposed. A language-specific page with an English registration module is not a complete German registration journey. If a module is intentionally language-neutral, record why. If it cannot be localized safely, decide whether to replace it, limit its availability or clearly describe the language boundary to visitors. The final standard is understandable function, not visual similarity to the source page.
Copying modules requires a post-copy review
The DNN support guide for translating pages describes copying modules from the master-language page to a localized destination and then editing the corresponding target content. This makes it efficient to preserve layout, but it also means a copied source module can carry the wrong text, links or data. The editor must know whether subsequent source changes can affect the copy.
After copying a module, inspect its text, hyperlinks, media and action settings. Translate reader-facing labels while preserving machine keys and appropriate identifiers. If the module sends a message or stores a submission, test that behavior. Review authorization and publication state before allowing public access. A good module checklist distinguishes copied, translated, factually reviewed and publicly tested. It also includes which version of the source was used. These distinctions help the next editor understand why the target differs from the master.
Use the translated state honestly
The documented DNN flow includes an editorial step for marking localized pages as translated and preparing them for publication. That label should be backed by real review, not used as a shortcut to make the interface look complete. A page can be linguistically translated yet factually outdated, or correct in its body while containing an untranslated module.
Define meaningful review gates. A fluent reviewer checks target-language clarity, grammar and equivalence. A program owner checks dates, conditions, service availability and any regional changes. A release owner checks public routes, redirects and functionality. For lower-risk content some roles may be combined, but the checks should remain separate. Keep a record of who approved the page and which source revision was used. When content changes, the target may need to return to review rather than automatically retain a status that no longer describes the current page.
Language activation should be a deliberate launch gate
DNN documentation distinguishes enabling a language from activating its pages for public use. In the described workflow, editors can prepare translated pages and then activate them when appropriate. This allows a team to work toward a destination without exposing incomplete content to readers. The exact controls vary by version and installation.
Before activation, enumerate the pages that visitors can reach under the new language. Check the homepage, navigation, forms, policy pages and any high-risk instructions. Test a missing page and confirm the expected fallback or unavailability message. Decide whether a partial launch is permitted and how gaps will be presented. Activation should follow acceptance testing, not precede it. A false sense of completeness is particularly harmful when a translated page invites visitors to register, pay, consent or follow safety guidance.
Map content variants to real reader needs
For each page type, list the information a visitor needs to complete its purpose. An event page has title, program, audience, location, time, price and registration action. A policy page has eligibility, conditions, exceptions and revision date. A contact page has local channels and availability. This map guides translators and reviewers more effectively than simply counting words.
Mark fields as shared, translated, market-specific or generated at runtime. Preserve IDs and data values where appropriate. Translate human-facing descriptions and accessibility text. Regional fees or legal statements may need independent approval rather than direct translation. A map of the whole journey also reveals where the source page links to a module or downloadable document outside the page-localization workflow. The project is ready to scale when this mapping can be repeated consistently by editors who were not involved in the first pilot.
Preserve claims, conditions and intended actions
The important unit of translation is the meaning the reader takes away. A ticket description saying admission may be discounted for eligible residents does not mean every resident receives a discount. A German translation that removes the condition changes the promise. A calendar instruction saying registration closes by noon on Friday does not mean registration opens then.
Reviewers should compare a target page against the source’s claims and dependencies. Highlight numbers, modal verbs, negation, named entities, time zones and legal terms. Ask what the visitor will do after reading the sentence. Use local examples only when they do not silently replace actual facts. Document any approved market-specific differences. A DNN page may be technically localized and still mislead people; editorial review is how the site protects against that failure.
Language-specific navigation must stay meaningful
A visitor switching languages should be able to find an equivalent page if one exists. A menu built from localized pages needs a sensible order and understandable labels. Do not assume that translating page titles automatically fixes every breadcrumb, sidebar, footer link and related article. Third-party navigation modules may handle localization differently.
Walk a realistic route from homepage to category to event to registration. Switch languages at several points and observe the destination. If the localized counterpart is absent, avoid silently presenting an unrelated page as though it were equivalent. A clearly labeled fallback or deliberate unavailable message may better serve the reader. Test links received through email and search, not just the route a visitor takes from the main menu. Direct URL behavior is especially important because most readers do not begin on the homepage.
URL aliases and language selection need explicit rules
A DNN site may use aliases and URL settings to manage how languages appear on public routes. Extensions and configurations can affect precedence among language paths, cookies and browser preferences. Document the rules for the actual installation rather than assuming every deployment handles them identically. A shared German URL should normally remain a dependable reference even when the recipient’s browser prefers English.
Test the page with fresh sessions, stored language choices and direct links. Check for redirect loops, accidental source-language redirects and duplicate accessible routes. If a language route changes, preserve important old links through an intentional redirect plan. Do not translate internal route identifiers carelessly or invent alternate URLs that do not exist. The correct result is a stable mapping from the reader’s chosen destination to an approved content version.
Canonical links and hreflang must describe published reality
International SEO is a description of actual public language content, not a substitute for creating it. A published German page should have suitable language metadata and a meaningful preferred URL. Alternate-language relationships should point to real counterparts, not draft pages or the English homepage. A copied canonical tag pointing every language at English can undermine discovery of genuine translations.
Inspect rendered HTML rather than trusting a control-panel field. Check titles, descriptions, URL response codes, redirects and search snippets. If the site supports a localized page but has not activated it, do not advertise it as a complete public alternative. Use an indexable policy based on content readiness and public accessibility. Search engines and readers should be given the same truthful map of the site. Recheck these relationships after a new locale is activated or a page moves in the navigation.
Translation requires more than a page meta description
A useful translated page has a destination-specific title and summary that accurately describe the content. But metadata also includes accessible names, images, social sharing text and possibly structured data supplied by modules or templates. A DNN page title can be translated while a sharing card, banner caption or event widget still speaks another language.
Review what appears in search results and when the page is shared externally. Test a direct visit and the visible content. Where structured data describes an event, check that dates, place, currency and availability match the actual page. Do not invent regional offerings simply to make a language version appear local. The aim is consistency between the claims made before the click and the information available after it. Search-oriented wording should be natural, informative and grounded in the published page.
Localization and accessible design belong together
A translated page should declare the appropriate content language and provide meaningful heading order, descriptive links, labels and visible focus. Screen readers use language information to pronounce text correctly. If the public page is Spanish but its HTML metadata declares English, the words may be difficult to hear correctly. Mixed-language passages may need individual annotations.
Check keyboard navigation through language selection, menus and forms. Translated strings can be longer than English and should not be truncated until they lose essential meaning. If the site adds Arabic or Hebrew, test text direction, punctuation and mixed numbers rather than merely reversing layout. Images containing embedded words need language-specific equivalents or accessible explanations. A language launch is not complete when only sighted mouse users can understand the journey.
Forms should be tested with incorrect answers
The arts centre’s German event page leads to a contact form. The labels are translated, but the required-field error comes from a shared module in English. A content editor may not have access to that string. Identify the form module’s localization capabilities, then test its success and failure paths. Review both client-side messages and server-side responses.
Use test data with a missing required value, incorrect date and invalid email. Check that data types and identifiers remain stable, while visible language is understandable. Confirm what the final action actually does: submit an enquiry, reserve a place or complete a payment. A target-language button must not suggest confirmed booking when the backend simply creates a pending request. Include privacy notices and confirmation emails in the same test. The visitor’s trust depends on the consistency of the whole transaction.
Regional data must not be disguised as translation
Opening hours, prices, telephone numbers and policies may vary among locations. A translated sentence should not silently change factual values to make them look familiar. Store data with clear ownership and represent it according to suitable locale formatting. A date such as 05/06 is ambiguous across cultures. A price in euros is not automatically equivalent to a number in another currency.
Create test cases for dates, time zones, decimals, currency labels and eligibility statements. Ask the local content owner to approve values that genuinely differ. A machine translation can help draft explanatory prose, but it cannot authorize a regional price or policy. If a German-language page serves a reader outside Germany, clarify which market the offer applies to. Language and jurisdiction are connected in the reader’s experience, but they are not identical categories in the content model.
Images and downloadable guides need separate review
A page can be accurately translated while its hero image contains English text or a linked PDF has obsolete instructions. Make an asset inventory for each language-specific page. Identify images with embedded wording, captions, alt text, video captions, downloadable forms and promotional banners. Determine whether the same file is valid across markets and whether an adapted asset needs its own approval.
If a Spanish event page links to an English-only brochure, say so plainly. If the brochure contains requirements essential to registration, consider withholding the promise of a fully Spanish experience until an appropriate file is ready. Verify file links and access permissions in public mode. Record versions so the next editor knows whether a source update requires new subtitles or a revised PDF. A meaningful translation includes the resources needed to act on what the page says.
Search and listing modules are separate language surfaces
A DNN page may appear correctly in Spanish while a search result or card listing still uses the source-language title. Search tools can have their own indexing, language filtering and caching. Do not assume that page localization automatically produces multilingual search behavior. Test a distinctive word from the approved destination article and follow the result.
Inspect title, snippet, language, date and URL in the results. Also test a proper name and a term with diacritics. Determine what happens to results for a language version that is not activated. Stale or unapproved content should not remain discoverable after withdrawal. If the search engine indexes a fallback copy, be honest about the language of the actual destination. A site is not truly navigable in several languages if users cannot discover the right page without guessing its URL.
Workflow permissions should reflect editorial responsibility
DNN sites may distinguish administrators, content editors and translators or other roles through configured permissions and workflows. The exact role model varies by installation. Test who can create, edit, review, activate and publish a target-language page, and whether individual modules have separate permissions. An administrator successfully completing a pilot does not prove that the actual translator can do the work.
Define who approves language quality, facts, regional policy and technical release. Restrict broad rights to those who need them; do not bypass review merely to clear a workflow blockage. Keep a reversible path to correct a wrongly published page. Good permission design is not about maximum restrictions, but about making it easy for each responsible person to do the right thing. A team that cannot tell who changed a target claim will struggle to preserve accuracy over time.
Update tracking after a source page changes
A public program page can change after translation because the venue postpones a workshop, adjusts eligibility or updates an instructor. The editor must identify every target-language version and any dependent modules or downloads. Do not assume a localized page automatically inherits the correct new meaning. A separate German page may remain fluent but outdated.
Record source version, change type, affected language pages, reviewer and public verification. A cosmetic edit may not require target text changes. A new deadline or safety condition usually does. If a correction is urgent, the site needs an approved interim warning or withdrawal route while translations are completed. The goal is to make multilingual accuracy sustainable after the first launch, not to treat every language page as a static copy that never needs another review.
Troubleshooting: a language is enabled but not visible
Check whether it is enabled in the site’s language management, whether content localization is configured and whether the language’s pages have been activated for public access. The DNN documentation distinguishes these steps. Then check theme or navigation support for language selection and inspect whether the expected page version exists.
Reproduce the problem while signed out. A language may be visible to editors but not to public visitors because the final activation gate was never completed. Conversely, a selector can display a language even when the target content is not ready. Avoid guessing by repeatedly toggling unrelated settings in production. Make a short record of the expected and observed behavior, test a safe change in staging and repeat the whole path after correction. A predictable troubleshooting method protects existing content and site design.
Troubleshooting: the page is translated but a module is English
Identify the exact module, its version and source of visible strings. Was it copied from the master language and never edited? Is it using shared content or an independent language resource? Is its public output cached? Determine whether the module supports language-specific configuration and what its documentation recommends. Do not overwrite the original page in an attempt to fix only the destination module.
Create a test variant and change one unmistakable visible label. Verify which locale receives the change. Restore approved wording and test links, errors and data display. Where the extension cannot provide a safe localized experience, document the limitation and choose a reader-facing alternative. Claiming a complete translation while knowingly leaving a critical untranslated registration component is worse than clearly explaining that the service is currently offered only in one language.
Troubleshooting: a source edit damaged the translation
Compare the target version against its prior approved revision. Determine which source fields, modules or templates are shared and what change propagated. Recover any overwritten local facts through ordinary revision and publishing controls. Avoid responding by duplicating entire pages without a relationship plan; that often creates stale content and duplicate URLs later.
Update the field-level ownership map. Shared scientific facts might need coordinated correction; local opening hours should remain locally controlled. Test another source change in staging to prove the new behavior. Include a regression case for the same module and language. If a content workflow silently marks an old translation complete after source changes, improve the review state so it reflects actual correctness. A resilient multilingual system makes the distinction between shared information and local adaptation explicit.
Troubleshooting: preview works but public navigation fails
A logged-in editor can sometimes see language pages, modules or unpublished versions that anonymous visitors cannot. Record the exact preview URL, public URL, status and permissions. Check activation, publication, menu visibility, redirects and caches. An accessible editor preview is not sufficient proof that the public user journey works.
Visit the site in a clean browser, follow direct links, and try the language selector from both a page with a translated counterpart and one without. Inspect the real target URL. If the route works but the search result is stale, investigate indexing separately. If a form works only for administrators, check module access settings. Fix the specific layer rather than rewriting translated content. Repeat the original failure case after every change and document the public result.
Practical launch checklist and evidence
For each language, check approved source revision, page translation, module content, public activation, direct route, language switch, menu, forms, metadata, accessibility, assets, search and intended reader action. Add one negative case for a missing translation. Store the URL, date, reviewer and observation. A checklist without recorded outcomes is merely a statement of hope.
Decide which defects block launch. A misspelled decorative title is different from a misrepresented consent condition or a broken ticket checkout. Verify a complete task end to end and have a target-language reader explain what they believe the site promises. After publication, monitor feedback, link failures and source changes. Maintain the ability to withdraw a flawed target without harming the source page or the rest of the website. Small, observable release gates are more reliable than announcing that every enabled locale is finished.
Ten worked examples for real DNN multilingual sites
Worked example: Spanish page, English ticket module
The arts centre translates its Spanish workshop page but leaves a ticketing module in English. A visitor sees a Spanish price explanation and an English purchase flow. The team identifies the extension’s separate language settings and translates or replaces the relevant interface. It submits test orders in an isolated environment, checking error messages and confirmation status. The page is approved only when the purchase steps preserve the actual fee, refund conditions and outcome. This is a module-localization defect, not a failure of the page-title translation.
Worked example: a German page remains hidden after review
The team has completed a German translation, yet readers cannot find it. An administrator checks language enablement, page localization status, activation and navigation permissions in that order. The direct URL is tested while logged out. Once activated safely, the team verifies the public title, body, language selection and relevant sitemap. This shows why review and activation are separate states. A private preview can be useful but must not be reported as live publication. The issue is resolved without modifying the original English article or its URL.
Worked example: a copied disclaimer claims more than the source
The English source says discounts may apply to qualifying visitors. The German copy, prepared from a template, implies that discounts always apply. A subject reviewer compares conditions and corrects the claim before release. The team also checks linked ticket descriptions and form confirmation. The problem was semantic, not technical. A localized page with a valid route and a completed workflow would still have misled readers. The acceptance record preserves which factual condition was reviewed and the source revision on which the correction was based.
Worked example: two destinations share a language
An arts organisation has English-speaking audiences in Australia and the United Kingdom. Both can read the same core programme description, but ticket prices, tax language and contact details differ. The team avoids inventing a single generic market policy and makes the local fields explicit. A language version is not a substitute for market identity. Each public route is tested with the correct values and authoritative policy. The shared explanatory text remains under one source while the local details stay with the people responsible for the venue.
Worked example: switching languages loses an article
A reader opens an English event article and chooses Spanish. The site takes them to a generic Spanish homepage because the counterpart has not been published. The product team decides whether this should be a documented fallback or a specific unavailable-translation notice. It checks the behavior with existing and fresh sessions. When the counterpart is later approved, the language control is retested from both versions. The page is not advertised in hreflang until the destination really exists. A dependable language selector should communicate the actual availability of content.
Worked example: a form says confirmed when it means pending
A German registration form sends a success message translated as Your place is confirmed. The backend, however, has only created an enquiry awaiting approval. A reviewer compares the action state with the wording and changes the message to a faithful description of receipt. Confirmation email and status page are checked. The defect is important because it shapes visitor decisions about attendance and travel. The correct translation preserves what the system has actually done, including any conditions or next steps, rather than offering unwarranted reassurance.
Worked example: an event date changes after launch
A storm postpones the community event. English is updated, but Spanish and German pages retain the old date, as do a shared listing card and a downloadable schedule. The source owner records the approved change, identifies affected destinations and arranges translations or interim warnings. Public URLs, search results and registration messages are rechecked after publication. The team marks a target current only when its actual reader-facing content reflects the new event. Tracking source changes is necessary to preserve consistency long after the initial translation is celebrated.
Worked example: an English PDF under a Spanish download label
The Spanish page offers a Program guide but opens an English PDF. The team does not pretend the file is Spanish. It changes the label to identify the available language, determines whether an approved translation is needed and records the PDF’s version. Once the Spanish file exists, the download is replaced and its accessible text checked. The visitor’s task drives the decision: an optional background brochure differs from the only source of participation requirements. This illustrates why a page-level localization checklist should include essential off-page materials.
Worked example: language metadata describes the wrong text
The template declares Spanish because the route is Spanish, but a module renders a long English fallback explanation. A screen reader may apply Spanish pronunciation to English words. The team corrects routing or explicitly marks mixed-language content and reviews the SEO consequences. It does not claim an English fallback is a fully approved Spanish article. The final test inspects the rendered HTML and spoken experience alongside visual content. Correct language metadata depends on what is actually delivered, not merely which navigation item the visitor selected.
Worked example: a translated search card opens the source page
A Spanish search result displays a translated title but points to the English source URL. The team traces the search module’s stored destination, indexing state and language routing rules. The corrected card opens the matching approved Spanish content. An unpublished variant is excluded rather than advertised prematurely. QA repeats a keyword search, clicks the result, checks direct access and compares visible claims with the source. This prevents a multilingual site from becoming fragmented at the point where many readers first discover its content.
Frequently asked questions
Does adding a DNN language automatically translate pages?
No. Language setup prepares a destination. Editors must create or manage localized page content and ensure modules and public routes are ready.
Why can administrators see a translation that readers cannot?
Publication state, activation, permissions or routing may differ between preview and public delivery. Test the specific URL as a signed-out visitor.
Are page modules translated automatically?
Not necessarily. Modules may have independent data sources and localization behavior. Inspect each important module and follow its extension-specific documentation.
Can the default language be changed after enabling localization?
DNN documentation for the described setup warns against assuming that it can be changed later. Verify your installed version and plan a migration rather than attempting an untested switch.
Should a language be activated before its pages are approved?
No. Treat public language activation as a release decision based on a defined minimum set of complete, reviewed reader journeys.
What is the fastest reliable test?
Open one translated page from a fresh browser, follow its modules, submit an invalid form, change languages and verify the actual published result.
Official DNN documentation and version notes
Check the documentation against the version of DNN Platform and the module extensions actually installed. The linked material includes a DNN 9.2-era community configuration guide and vendor support instructions; menu labels and capabilities can vary in newer releases.
- DNN Docs: About Localization and site language activation
- DNN Support: Translating pages and copying modules for localization
- DNN community documentation home
Continue through eduKate’s translation library
The Master Art of Translation explains the deeper principles of meaning, evidence and cross-language revisions. The Translate Like a Pro series index offers implementation-specific guides. This article focuses on DNN Platform language setup, page/module localization and public activation without duplicating the general translation methods addressed elsewhere.
When a language version becomes available, a reader should find more than familiar words. They should find accurate conditions, an understandable path through the site and a trustworthy explanation of what will happen after they act. The strongest translation is the one that remains useful after the page changes, the session ends and a visitor follows the link from somewhere else.