ProcessWire multilingual translation begins with a useful architectural idea: the same structured page can present language-dependent field values and, when configured, language-specific page names and URLs. A reliable ProcessWire website translation therefore involves the core Language Support modules, multilingual field types, content editing, URL activation, template strings, fallback behavior and careful quality assurance. Translating paragraphs without checking those related elements leaves readers with an incomplete experience.
If you are searching for how to translate a ProcessWire site, how LanguageSupportFields works, how to create multilingual page URLs or why a translated field shows its default-language value, this guide provides a practical route from configuration to release. ProcessWire offers language-aware fields and page-name functionality, but editors still have to decide which meanings to preserve, which values may fall back and which URLs should be publicly accessible.
For a world-facing content service, the right outcome is not simply a series of flags at the top of a page. Each language should communicate the correct information through readable titles, accurate body fields, functional links and clear forms, while maintaining stable technical relationships. The process here starts with a content inventory, enables the appropriate language modules, adds and reviews translations, validates URLs and templates, and tests real visitor journeys before release.
The short explanation: one page, multiple language views
ProcessWire stores pages using templates and fields. A multilingual field can hold different text for supported languages, and the site’s current language influences which value is returned when the page is rendered. This allows a publisher to maintain the identity of an article or service page while showing suitable language-dependent values to different readers.
That model is not a license to ignore language boundaries. A field can be multilingual while an adjacent field remains ordinary, a template string remains in English, or a file download contains text in the wrong language. A visible page is a composition of many elements, each of which must be audited. The important question is whether the rendered page is coherent to the visitor.
Think of an educational foundation maintaining one scholarship page. Its title, summary, instructions and help link may each require language-specific values. Its application deadline remains the same underlying fact, while the way the date is written may differ by locale. Successful localization maintains those relationships without creating contradictory versions.
Identify the required core modules
ProcessWire’s official documentation describes the Language Support module as the foundation for multilingual capabilities. Language Support Fields adds support for fields with multiple language values, while Language Support Page Names enables language-specific page names and URLs. These pieces are related but serve different jobs. An alternate administrator language pack alone does not create an international publishing system.
Check which modules are installed before designing the content workflow. A site might support translated interface strings yet still render one-language content fields. Another might have multilingual fields but no language-sensitive page URLs. Both are plausible configurations. A useful diagnosis identifies the exact missing capability rather than prescribing a generic plugin.
Make changes in a tested environment, especially on an established public site. Converting field types or changing the way page names are resolved can affect content and routes. Record the current configuration and take the database or deployment backups appropriate to your hosting arrangement. Translation should extend a stable site, not put its existing readers at risk.
Add languages and define their purpose
Create the intended languages under the system’s language administration and verify that they appear consistently for editors. Use recognizable names and document which audience each language serves. A choice between general French and a region-specific French service may carry implications for terms, examples, contact details and legal conditions. The code should express the project’s real use case.
Separate a language from a market. An Arabic-language page may serve readers across several countries; translating it does not automatically mean that prices, tax rules or delivery conditions are valid everywhere. If the organization does operate distinct regional services, maintain the necessary region-specific facts instead of hiding those distinctions beneath a language selector.
Write a configuration register with a default language, target language names, public URL paths, relevant field types, editorial owner and release status. When editors are working simultaneously, this prevents a value intended for one language from landing in a similarly named field. Structured publishing is most reliable when the team shares one definition of each locale.
Choose the right field model
ProcessWire’s multilingual field types include language-aware versions of text, textarea and title fields. A standard text field has one value. A multilingual field can present a set of values across installed languages. Language-alternate fields offer another model in which separate fields are named with a language suffix and can substitute for the main field when the current language calls for it.
Use the native multilingual field type for straightforward editorial text where a single field represents one concept in multiple languages. Consider alternate fields when the site’s architecture or field type requires that arrangement and the development team understands its behavior. These are not automatically interchangeable in every template or workflow.
Document the field choice in the content model. A title field, an application instruction and a legal footnote may all be multilingual, but they have different validation needs. Do not transform a numeric identifier or a database key into a language field merely because it appears near translated text. Keep language-neutral data stable and localize its presentation.
Convert existing fields deliberately
When an existing page already uses a conventional text or textarea field, ProcessWire documentation describes converting it to a corresponding multilingual field type through field settings. That is a schema-level operation, not a cosmetic toggle. It may affect database storage and field settings, so review the documentation for the installed version and back up before proceeding.
Start with one low-risk test field. Verify that its default-language content remains available after conversion, that the editor can enter target values, and that the front-end template renders the correct value. Then inspect the field’s other settings; a rich-text field may have editor configurations or formatting behaviors that need to be checked again.
Avoid a mass conversion without a map of where fields are used. The same field might appear across many templates. A successful conversion on a news article can influence service pages that use the identical field definition. Your change plan should describe the affected templates, the expected behavior when target values are blank and the rollback path.
Understand default-language fallback
For multilingual fields, ProcessWire commonly substitutes a default-language value when the selected language’s value is empty. This can make a partially translated site appear functional, but it also conceals gaps. A visitor may see a French heading and then an English instruction because the target textarea is blank. The CMS has returned a value, but editorial quality has not been achieved.
Classify fields according to fallback risk. A registered trademark or a person name may legitimately remain unchanged. A safety warning, medical instruction, eligibility condition or consent statement may be dangerous if silently shown in another language. Decide whether a missing translation should block publication, display a clearly labeled original or use an approved explanatory notice.
Measure fallback explicitly. Make a language-coverage checklist for each page and each significant field. A valid returned value is not proof of a reviewed translation. Treat fallback as an application behavior to understand and control, not as a substitute for human meaning transfer.
Set up multilingual page names and URLs
Language Support Page Names allows pages to have language-specific URL names and helps determine the current language from the URL. ProcessWire’s documentation describes using language-aware names at the homepage, with optional language segments such as /es/ or /de/. A consistent URL plan makes translated pages easier to share and helps search systems distinguish alternatives.
After configuration, verify public paths for the default and target languages. Check the homepage and several deep pages. A page can have translated body fields but still use an untranslated or inactive URL name. Also review the documented active state for each language. If the page is not active for a target language, a visitor may not be able to reach it even though an editor sees translated text.
Think through existing links before changing page names. A popular English path may have accumulated links from other websites and email campaigns. When a URL changes, plan a supported redirect strategy and update internal links. Do not rename paths impulsively to make every language identical. Clarity and stable behavior matter more than visual symmetry.
Activate pages appropriately for each language
ProcessWire’s multilingual page-name functionality includes language-specific activation behavior. This allows a site to distinguish between a page that is available in a language and one that is not yet ready. An inactive target page should be treated as a publishing decision, not as proof that the translation text has vanished.
A public library might have a page about a temporary event that is relevant only in the default language. It can legitimately leave the target version unavailable. A core membership page, however, should not be advertised as translated until its terms, form and visitor path are complete. Use activation to reflect readiness instead of publishing partial content and hoping fallback text will conceal it.
Check language availability with a nonlogged-in browser. Editors may have access to unpublished or inactive content that ordinary readers cannot see. Verify the URL response, navigation entry and what happens when someone chooses an unavailable language from the switcher. The objective is predictable access and no false promises.
Use current-language behavior correctly in templates
ProcessWire’s API exposes the active language through the current user context, and language-aware field values can reflect that language during normal output formatting. The official documentation shows that setting the language and reading a field can produce a language-specific value. This is useful for developers, but it requires care around context and state.
If a template temporarily switches language to produce a language menu or alternate URL, restore the original language afterward. Otherwise code that follows may accidentally render text in the temporary language. Test templates under more than one locale and with both logged-in and anonymous visitors. A bug can remain hidden when developers always view the default language.
Do not build elaborate language logic into each page template unless necessary. Use the CMS’s language-support mechanisms wherever appropriate and keep custom logic auditable. The more independent language switches and fallbacks a project implements, the harder it becomes to explain why an individual field displays a particular value.
Account for output formatting and raw field access
The documentation distinguishes ordinary rendered field access from situations where output formatting is disabled. With output formatting enabled, a multilingual text field may behave like a language-dependent string. With output formatting disabled, the underlying value can expose a multilingual field value object. That distinction matters for imports, background jobs and custom APIs.
A developer who tests only the front end may not notice that a migration script reads or writes values differently. When building a translation import, verify the exact field API for the installed version and test one page before touching a large dataset. Ensure that setting a target-language value does not unintentionally overwrite the default-language text.
Keep editorial and technical verification separate. A successful database write establishes that content exists; a source-to-target review establishes that it is accurate; a public rendering test establishes that the reader sees the right version. All three are required when a project needs dependable results.
Translate static template strings too
A ProcessWire template may include static text that is not stored in a page field. Examples include “Read more,” “Back to search,” “Request information” or an error message written directly in a template. ProcessWire provides a code translation mechanism for such strings. If the template has not been prepared for translation, multilingual fields alone will not fix these labels.
Inventory template strings across the main site. Group them by context, since the same English word can mean different things in different places. “Apply” may describe submitting a scholarship request or applying a filter. Translate for the intended action and keep any variables or placeholders intact so dynamic values appear in the correct place.
Review generated text on real pages. An isolated string list can conceal grammatical problems that become obvious when the label sits next to a noun or number. Check plural messages, error conditions and the longer text created by some translations. A language pack can cover the administrator interface while custom template code still needs its own translation work.
Do not confuse admin language packs with public translation
Language packs can change what editors see in the ProcessWire administration interface. They are helpful for multilingual teams but do not by themselves populate public title and body fields. A site can serve visitors in Spanish while its development team operates the control panel in English, and that is perfectly consistent.
Write this distinction into onboarding material. New editors should know where to find a public field translation, where to change a language-specific page name and where a technical colleague maintains template strings. Without that map, an editor may waste time looking for a contact-button translation inside an article body.
Also consider mixed-language editing. An administrator who switches their own interface language should still recognize stable page identifiers and workflows. Use clear roles for translators, reviewers and publishers, and avoid making the language of the control panel determine who is allowed to approve public content.
Localize image text, documents and media
A multilingual text field does not change words embedded in an infographic, screenshot or downloadable PDF. Inventory all visual and document assets on high-priority pages. Record which need localized replacements, which are language-neutral and which may remain in the source language with an explicit label.
Consider a diagram explaining a permit process. If its arrows contain English instructions, a Spanish article that surrounds it with Spanish paragraphs still leaves a central part of the task untranslated. Provide a localized diagram or an accessible textual equivalent. Make the same check for charts, captions and file names that readers encounter before downloading.
Alternative text should be meaningful in the target language and match the image’s purpose. A decorative photograph may not need descriptive alt text; a chart conveying dates or eligibility information does. Verify that the final page remains understandable without requiring the reader to interpret text inside an image.
Plan language switchers as navigation, not decoration
A useful language switcher should allow readers to choose an available alternative of the page they are viewing, or clearly explain when no equivalent is published. ProcessWire’s language-aware URLs provide building blocks for this behavior, but the actual switcher presentation and routing should be tested in the site’s template or chosen module.
Use language names that readers recognize, not a row of national flags as the only labels. English is used in many countries; a flag cannot uniquely represent it. Test the switcher with a screen reader, keyboard and mobile device. Make sure the current language is indicated and that switching does not lose the reader’s place unnecessarily.
Do not show a destination as available if its page is inactive or lacks essential translation fields. A clear fallback to a language index can be better than a misleading link. The decision should follow the publisher’s promised coverage and the importance of the content.
Keep page relationships stable while language varies
A ProcessWire page identity can remain the same while language-dependent values change. That simplifies many editorial tasks, but it can also encourage accidental assumptions that every part of the page is shared equally. The publisher still needs to identify which facts are universal and which details differ by audience.
For a research institution, a study’s identifier, dataset link and publication date may be invariant. Its explanatory title, introduction and safety note may need translation. A contact address may vary by region rather than language. Store the shared facts in suitable stable fields and present region-specific data through an explicitly designed content model.
Avoid using language-specific prose fields to carry values that must be interpreted by software. A payment integration should not depend on the translated text of a currency label, and an application status should not be inferred from a natural-language word. Preserve machine-readable identifiers while localizing what the reader sees.
Build and maintain a terminology register
Reliable translation depends on choosing the right equivalent for a concept, not choosing the first dictionary result. Create a terminology table with source expression, concept definition, approved target-language wording, forbidden alternatives, examples and review owner. Update it when a new subject area introduces a distinction.
An environmental organization might need to distinguish “habitat restoration,” “species recovery,” “invasive species control” and “reforestation.” Replacing these with one broad environmental term can distort actual activities. A healthcare site may require even more rigorous controls. Professional review should focus first on terms that change decisions or safety.
Let translators adapt sentence structure naturally where meaning allows. A target article may need more words or different order. Do not force a translated sentence into the English character count unless the interface imposes a real limit, and even then test whether a shorter expression remains accurate. The glossary is a guide to meaning, not a command to mimic every sentence.
Translate search and list output with care
A ProcessWire site may build its own search using selectors and page fields. The documentation explains that language-aware field matching can interact with the current language and default values. This means a search result may appear because of fallback rather than a fully translated target field. Developers should understand the site’s query behavior before claiming that the search index is localized.
Test queries in each target language. Include common expressions, exact names, accented terms and a term that exists only in the default language. Observe which pages return, the language of the result title and excerpt, and the final URL when clicked. A search page that returns English excerpts in a German context may be technically consistent with fallback rules but editorially confusing.
For content-rich sites, also review filters and sorting labels, category names and pagination messages. These are often generated by templates. A translated article body is only one piece of the discovery system. Readers must be able to locate it without knowing the source-language term.
Treat URLs, canonical tags and hreflang as a system
Each public language version should have a stable, indexable URL when the publisher wants it discoverable. Language Support Page Names can help form appropriate paths. SEO then requires checking page titles, descriptions, canonical URLs and alternate-language links in the actual rendered HTML. Do not assume a language module automatically supplies every SEO requirement for every template.
Where hreflang is used, link only genuine language alternatives and use valid language or language-region codes. The targets must resolve to published pages. Check reciprocity and avoid pointing a target-language page’s canonical tag indiscriminately at the default-language URL. The correct canonical policy depends on the site’s content and duplication strategy.
Keep SEO copy natural for each language. A German query about research permits may use a different noun phrase from a literal English translation. Write a useful title for the German reader, not a mechanical list of translated keywords. Search performance comes after informational accuracy and reliable page structure.
Check accessibility and mixed-direction scripts
Language and reading direction affect more than visible words. If a ProcessWire site supports Arabic, Hebrew or another right-to-left script, examine how templates render navigation, punctuation, form controls and content containing English names or numbers. Mixed-direction strings can appear confusing without suitable markup.
Review the language attribute of the rendered page, accessible names on controls and meaningful link text. An icon-only language switcher can be difficult to use without a spoken label. A translated infographic with no accessible explanation can exclude readers who rely on assistive technology. These defects should be part of the same content quality process as spelling and terminology.
Test enlarged text and narrow screens as well. A long translated label may wrap, and a rigid layout can clip a crucial verb. It is better to improve responsive behavior than to remove essential meaning. Include at least one native-language tester and one accessibility-focused pass for high-impact public services.
Prevent stale translations when content changes
A shared page identity does not automatically synchronize the meaning of language values after an editor changes the default-language field. Create an update process that marks affected languages for review. A changed fee, deadline, exclusion rule or application instruction should be treated as a material update, not a routine copy edit.
Maintain a record of what changed, who reviewed the target, when it was released and whether any linked PDF or form also changed. This is particularly important for pages that stay published for years. Language fallback can mask an unfinished revision if the target field is cleared or not updated.
Give important content a higher review frequency. A public emergency notice needs immediate consistency; a historical essay can follow a slower schedule. The point is to align translation maintenance with the consequences of being wrong, not to revise every paragraph on an arbitrary calendar.
Worked example: multilingual wildlife conservation reports
Suppose a conservation organization uses ProcessWire to publish field reports in English, Spanish and French. Each report has a title, short summary, full findings, region, observation date, downloadable map and species identifiers. The organization wants international volunteers to find and understand the same scientific evidence without creating separate contradictory records.
The development team configures the required Language Support modules and chooses appropriate language-aware field types for title, summary and explanatory body. Stable scientific identifiers and observation measurements remain controlled data. Localized page names are designed for clarity; a report’s shared identity stays connected even when its public title changes across languages.
Editors receive a glossary distinguishing “observation,” “estimated abundance,” “confirmed nesting” and “possible breeding.” These are evidence categories, not stylistic synonyms. If a source report says a species may be present, the Spanish page must not claim confirmed presence. Units, GPS coordinates and dates are checked separately from prose. A chart showing a count should not change because a translated sentence sounds more certain.
The team populates the three language fields and reviews the output on public pages. When a Spanish summary is missing, default-language fallback may display English; the reviewer marks the page incomplete instead of treating its presence as a finished translation. Image captions and map legends receive language-specific attention. Source files and data links remain stable, but the download page labels each file’s available language honestly.
Next, test the language URLs and activation state. A visitor follows a French report link directly, moves to the Spanish version, and returns to the French report without being redirected to an unrelated homepage. The site search returns reasonable results for French scientific terms; excerpts are checked for unintended default-language fallback.
Finally, inspect canonical and hreflang markup, page-language attributes, accessibility and mobile layout. The successful result is a credible multilingual report that preserves the certainty and provenance of the scientific record while letting readers access it in different languages. This is more demanding than substituting translated field strings, and that is exactly why the workflow matters.
Troubleshooting frequent ProcessWire translation problems
A field remains English after changing language
Check that the field is actually multilingual, the target-language value is populated and the active language is what you expect. Default-language fallback may be working as designed. Review the specific field rather than assuming the entire page lacks language support.
The translated URL returns a missing page
Verify Language Support Page Names, the language-specific page name and the page’s active state. Inspect the expected URL prefix and any routing or redirect rules. Test without editor permissions because admin visibility can differ from public availability.
An import overwrites the wrong language
Review the API context, output formatting state and how multilingual field values are set. Test one record with a complete backup and read it back in every language before running a bulk migration.
A template renders the wrong language after a menu
Check any custom code that temporarily switches language to generate alternate URLs or navigation. Restore the previous context after the operation. Test several independent components on the same page.
A button label will not translate
Identify whether it is a page field, a static template string or text supplied by a third-party module. Translate in the correct layer. Preserve parameters and retest the action the button initiates.
Language switching loses the subject
Check that the alternate URL is constructed for the same page and an active target language. Avoid sending readers to a generic homepage when a true page equivalent exists.
The translated page exists but search cannot find it
Review the site’s search implementation, language context and selector behavior. Test a known target-only term and inspect returned titles, excerpts and links. Do not assume every site’s search uses the same index or query logic.
Images are still in the source language
Check infographics, file downloads, chart labels, captions and alt text individually. Provide localized media or an accessible explanation; changing the body textarea does not alter image pixels.
A regional detail differs unexpectedly
Review whether the value is shared, language-specific or region-specific. A translated field may not be the right place to store a market-dependent address, policy or price. Correct the data model or editorial instructions before fixing the copy.
A legal warning silently falls back
Define a no-silent-fallback policy for safety-critical content. Mark the target version unavailable or clearly label source-only content until reviewed, depending on the organization’s requirements.
Hreflang points to an inactive language
Generate alternate links only to valid, publicly accessible language URLs. Check the page’s active state and metadata rendering. Search systems cannot use a promised alternative that returns an error.
Text looks correct but mobile controls fail
Test long labels, mixed-direction content, language switching and form focus at small widths. Give the layout enough flexibility instead of forcing a translation to copy the source’s word length.
A four-week plan for site teams
Week one is the content audit. Inventory important page templates, fields and language-dependent strings. Decide which languages and audiences the site serves, identify the default-language route and document the required modules. Create a terminology register for high-impact concepts. Make a map of page fields, static template text, media and user actions.
Week two is a limited technical prototype. Install or verify the language support modules in staging, convert one representative text field if necessary and configure target page names. Add a small set of translated values and test fallback, active status and public URLs. Confirm that developers understand output formatting and language context before creating import tools.
Week three expands the editorial library. Translate priority content, review terminology and numbers, localize static template strings, and audit search, downloads and forms. Test complete tasks with native readers. Track every missing target field that currently falls back to the default language, distinguishing acceptable proper names from untranslated instruction text.
Week four releases and validates. Publish only the language paths that meet the quality threshold, verify link sharing and search discovery, and inspect metadata and accessibility. Monitor feedback from actual readers. Create a source-change process so translations remain accurate after the launch, especially for deadlines, fees and safety notices.
Final quality checks before publication
Pick representative page types rather than inspecting only the homepage. Check a short article, a long report, a page with media, a listing, a form and a downloadable file. For each, verify target field values, language-specific URL, public active state, menu context, link destinations, metadata and correct language in static labels.
Compare evidence-related words, quantities, negations, dates and names against the authoritative source. Ask whether a target-only reader can understand and act. Look for silent default-language fallback; it is often the easiest defect to overlook because the page still appears to load successfully.
A successful release preserves shared record identity while delivering faithful, accessible language-specific meaning. The technical model and the editorial review reinforce one another; neither can replace the other.
Frequently asked questions
Is ProcessWire multilingual support a third-party translation service?
No. ProcessWire provides core language support modules for fields, URLs and interface strings. A translator or translation service may still be used to produce content, but the CMS structure determines how those values are stored and displayed.
Will a blank translated field display nothing?
Not always. The official multilingual field documentation describes default-language fallback when a target value is blank. Test the field’s actual configuration and decide whether such fallback is appropriate for the page’s purpose.
What does Language Support Page Names do?
It enables language-aware page names and URLs and helps select the visitor’s language based on the URL. It does not guarantee that every content field, image or form has been translated.
Can two language versions share one page identity?
Yes. That is a central part of the native field model. However, the publisher must still distinguish invariant data, translated explanation and region-specific information to avoid contradictory outputs.
Should I use language-alternate fields or native multilingual fields?
Choose according to the site’s content model, field types and maintenance needs. Native multilingual text fields are useful for ordinary translated prose. Alternate fields can support other structures, but require clear naming and developer understanding.
Do I need translated URL slugs?
They can improve readability and language consistency, but stability is also important. Use an intentional URL scheme and test links, redirects and public activation. Changing an established path without a migration plan can damage access.
What is the most useful practical test?
Give a target-language reader a specific task such as locating a report, reading an instruction, finding the right form and completing the action. Inspect each transition for meaning, navigation and interface language.
Official references and learning routes
Read ProcessWire’s official multiple language support guide, multilingual fields documentation and multilingual URL guide for the mechanics and their version-specific behavior. For the broader principles of accurate meaning transfer, continue to Master Art of Translation and the Translate Like a Pro series index.