Drupal vs WordPress multilingual: which fits a multi-language site
Drupal ships four core modules for multilingual work: Language, Interface Translation (Locale), Content Translation and Configuration Translation. Together they translate the interface, content entities field by field and configuration text such as field labels and Views. WordPress has no multilingual support out of the box, so a team either adds a community plugin or runs one site per language on a multisite network, which the WordPress handbook notes adds management overhead. The right choice depends on how many languages you publish, how deep your editorial workflow goes, and what your team already knows.
Start with the translation workflow. If translators need to work on structured content fields, review each language before publication, and keep configuration such as menus and field labels consistent across languages, the Drupal core modules describe that model directly. If your content is mostly short pages translated by one agency, a WordPress plugin or a per-language site may be enough. Ask each option to show how a single post is translated, reviewed and published in two languages, and how a new language is added, before you commit.
Then check the team and the number of languages. A Drupal multilingual site depends on PHP and Drupal's module configuration, so confirm that your developers and editors can maintain it, and plan for the module upgrades that come with each major release. For WordPress, check which translation plugin you would use, who maintains it, and whether it is compatible with the blocks and themes you plan to use. Put these questions to each vendor or implementation partner in writing, and read the overall Drupal vs WordPress comparison alongside this section for licensing and upgrade effort.
How each platform handles multilingual publishing, part by part
This table takes multilingual publishing apart into the parts a team has to build, buy or maintain, and shows how Drupal's core modules and WordPress's plugin-based approach handle each one. Read each row as a question to answer for your own site, then check the plugin rows against the exact plugins and versions you plan to run. The main takeaway is that Drupal ships translation parts in core, while WordPress leaves most of them to third-party code you must test and maintain.
| Part | Drupal | WordPress |
|---|---|---|
| Language selection | The core Language module defines the languages and their detection and negotiation order for each request. | No built-in language layer. Language selection depends on the plugin you install, so confirm its URL and locale handling. |
| Interface translation | The core Interface Translation (Locale) module translates the admin and theme interface strings. | Core and theme strings are translated through WordPress locale files. Confirm which strings your theme and plugins expose for translation. |
| Content translation per field | The core Content Translation module translates content entities field by field, so each language version keeps its own field values. | Community plugins typically link separate posts or pages per language. Confirm how each plugin handles custom fields and custom post types. |
| Configuration translation | The core Configuration Translation module covers field labels, Views and other configuration text. | No core equivalent. Labels in custom fields and plugin settings depend on each plugin, so confirm them in a staging copy. |
| Built-in versus plugin support | Multilingual is part of core, delivered through four core modules that work together. | Multilingual is not supported out of the box. The WordPress handbook says community plugins fill the gap and core support is planned for a later phase of the Gutenberg project. |
| Multisite per-language sites | Drupal handles multiple languages within one site, so a separate site per language is not required for most setups. | The handbook describes one site per language within a multisite network as an alternative approach that adds management overhead. |
| License and paid edition status | Drupal is GPL-2.0-or-later with no paid edition of Drupal itself. Contributed modules are free under the same license. | WordPress is GPLv2 or later. Premium multilingual plugins may be sold separately, so check each plugin's own license and terms. |
| What the team must maintain | Core module updates on the Drupal release cycle, plus testing of translation workflows during each major upgrade such as Drupal 12. | Plugin updates, compatibility testing after each WordPress release (for example 7.1.x), and ongoing checks that translation plugins still work with the theme. |
Which multilingual model fits which kind of site
Drupal treats multilingual support as a set of core capabilities. The Language module handles the languages and detection rules, Interface Translation (Locale) covers the theme and module strings, Content Translation handles per-field translation of entities, and Configuration Translation covers labels such as field names and Views text. This model suits a single site where one editorial team publishes the same structure in several languages, with translators working in the same content model and a shared review workflow. The official guide on choosing and installing multilingual modules explains how these pieces fit together.
- One content model: Translations of a node share its fields, so editors see the same structure in every language.
- Interface and content handled separately: Theme strings and editorial content can be translated by different people at different times.
- Configuration is translatable: Field labels and Views text can be localized without duplicating the site.
- Ongoing ownership: The team owns the language list, translation workflow, module updates and testing across languages after each Drupal upgrade.
- Build effort: Setup and theme work for multilingual output is a one-time cost, but translation operations recur with every new page.
Before committing, confirm with your implementation partner which contributed modules you need for machine translation or translation management, and how each is maintained for your target Drupal version.",
WordPress does not support a bilingual or multilingual site out of the box. The WordPress handbook says core multilingual support is planned for the final phase of the Gutenberg project and that community plugins fill the gap in the meantime. This model suits a single site with a modest number of languages, a small editorial team, and content that is mostly page-level rather than deeply structured. The plugin adds language switching, translation records and related management screens on top of the standard post model, so the team depends on the plugin's data model and its release cadence.
- Familiar editing: Editors work in the standard post and page screens with added language controls.
- Plugin dependency: Language handling, URL structure and translation records live in a third-party plugin that the team must keep current.
- Core change risk: Because core multilingual support is still planned rather than shipped, the plugin choice may need revisiting as WordPress evolves.
- Content structure limits: Deep, cross-referenced content models are harder to keep consistent across languages than in Drupal's entity model.
- Ongoing ownership: The team owns plugin selection, compatibility testing after WordPress and plugin updates, and sitemap and hreflang checks.
Confirm which plugin the vendor supports, how it stores translations, and whether its data can be exported if you change approach later.",
The WordPress handbook describes one site per language within a multisite network as an alternative approach. Each language gets its own site with its own content, theme settings and users, and the network shares installed code and some administration. This model suits organizations where each language edition is run by a separate local team with different content, approvals and legal pages, and where cross-language consistency matters less than local autonomy. The handbook notes that this approach adds management overhead, which is the main cost to plan for.
- Separate editorial control: Each language team can publish without touching other sites in the network.
- Duplicated work: Shared content, menus, and structural changes must be made or synchronized on each site.
- Network management overhead: The handbook identifies the added management effort as the trade-off of this approach.
- Shared code, separate data: Plugin and theme updates apply across the network, so one compatibility problem can affect every language site at once.
- Ongoing ownership: The team owns the network administration, cross-site content consistency and the language switcher logic.
Illustrative example: a network with five language sites needs five content reviews after each structural change unless the team builds a synchronization process, so ask any partner how they would staff that work.
Factors that change the multilingual result in practice
The same multilingual goal can lead to very different builds depending on language count, translation depth, editorial process, content model needs, team skills and upgrade habits. These six factors connect the Drupal and WordPress choice to the work your team will carry after launch.
Number of languages and locales
Drupal's Language module handles language detection, negotiation and content language settings in core, so each added language is configured within the same site. WordPress has no multilingual support out of the box, so a plugin or a one-site-per-language multisite network must cover the same ground. Ask each candidate how it handles locale-specific formats, URLs and fallback content for every language you plan to launch, and test with your real language count before you commit.
Field labels and Views translation
Drupal's Configuration Translation module covers field labels, menu text and Views headers, not just page copy. Interface Translation (Locale) covers theme and module strings. On a WordPress build, labels in custom fields, theme text and any listing templates each need checking against the plugin you choose. Make a list of every label and listing your editors see, then confirm which layer translates it.
Editorial workflow across translators
Translation work runs through a review chain: a source editor, an external or internal translator, and a publisher. Content Translation in Drupal tracks translation status per entity and per field, which helps when only some fields change. Check whether your translation vendor needs export files, a shared login or an API, and whether your chosen WordPress plugin supports the same review states. Ask for a written walk-through of one article moving through all steps.
One shared content model
If every language must share one set of content types, fields and permissions, Drupal's entity model fits that requirement directly. Separate sites per language in WordPress multisite keep languages apart, which can suit regional teams, but every shared change then runs across each site. Decide early whether a product page or policy document must exist once for all markets, because that answer usually determines the platform.
Team skills in PHP and each platform
Drupal development and module administration call for PHP skills and Drupal knowledge, and Drupal 11 requires PHP 8.3 or later. WordPress.org recommends PHP 8.3 or greater, so the runtime matches on paper, but plugin administration and theme work are different skill sets. Confirm who will configure translation modules, test plugin conflicts and handle the database work each platform needs before you choose.
Upgrade cadence and translation drift
Drupal core releases follow a fixed schedule, and Drupal 10 reaches end of life on December 9, 2026, so multilingual modules and translated configuration must move with each major release. WordPress applies automatic background updates for minor and security releases by default, but plugin updates still need testing against translated content. Schedule a test upgrade on a copy of the site with all languages loaded before each major version.
What happens to translations when you upgrade
The upgrade path for a multilingual Drupal site is set by the core release calendar. Drupal 11 is the current major version, Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026. A site running several languages on Drupal 10 therefore has a short window to plan a move to Drupal 11 and then Drupal 12. That move touches the four core modules that carry translation: Language, Interface Translation, Content Translation and Configuration Translation. Your translated field values, interface strings and translated View labels all depend on them, so the upgrade plan should name each one and its test cases. Check the Drupal core release schedule before you set an internal deadline.
WordPress follows a different pattern. WordPress 7.1 is the actively maintained series, with 7.1.3 released on October 6, 2026, and the releases archive says only the latest release in that series receives active maintenance. Core has no multilingual layer, so translation comes from plugins that follow their own release cycles. The WordPress handbook says automatic background updates reach plugins and themes only in special cases chosen through the WordPress.org API, so a translation plugin will often wait for your manual update. Each translation plugin therefore becomes a separate upgrade item that can lag behind the core version you run. Confirm the auto-update settings on your existing sites, since the default for newly created sites differs from older installs.
Whichever platform you choose, every translation plugin or contributed module must be retested with each upgrade. Build a fixed test set covering the language switcher, translated URLs, translated menus, forms, search and any translated product or content fields, and run it on a staging copy before each release. On the Drupal side, confirm with the maintainers of each contributed module in your translation workflow that a release supports Drupal 11 and Drupal 12, and check the module's project page for its stated compatibility. On the WordPress side, ask each plugin author which WordPress versions they test against, how they store translation data, and what happens to that data if the plugin is deactivated or replaced. Get those answers in writing before you commit to an upgrade date.
How to test multilingual fit in your own environment
This sequence turns a general sense of multilingual fit into evidence from your own content, languages and editors. Run it against both candidates before you commit, so the decision rests on what your team can actually build, translate and maintain.
Define languages and content types
Content owners and the localization lead list every language the site must publish in, including fallback expectations, right-to-left scripts and any languages that need separate URL paths. Then list the content types in scope, such as landing pages, product or service descriptions, legal notices and news items, and note which fields each type carries. The step closes when this list is signed off by the content owner and the localization lead, because every later test uses it as the acceptance baseline.
Build a two or three type pilot
The platform team builds a pilot in each candidate with two or three representative content types from the list, using the same languages and field structure. For Drupal, this means enabling the Language, Interface Translation, Content Translation and Configuration Translation modules and defining translatable fields. For WordPress, it means choosing a translation plugin or planning one site per language on multisite, and recording what each choice adds to administration. The step is complete when both pilots run in a non-production environment and the team has written down every configuration decision.
Translate a field-level sample
Translators or the vendor's localization team translate a fixed sample of entries field by field, including menus, navigation labels, taxonomy terms and a View or equivalent listing page. Check that interface strings, configuration text such as field labels, and content fields all translate separately and do not overwrite each other. The output is a short defect log per candidate that records untranslated strings, mixed-language output and any step that required custom code or manual copying.
Test fallback and URL structure
Test how each pilot behaves when a translation is missing, when a page is unpublished in one language, and when a visitor requests a language the site does not serve. Confirm the URL pattern for each language, the hreflang output, and how menus and breadcrumbs behave across languages. Record the observed behavior in the same defect log, and mark each item as built-in, plugin-supplied or custom work. This step closes when the search and SEO owner signs off on the URL and fallback results.
Measure one translation cycle
Have an editor and a translator complete one full cycle for the same entry in each pilot: create the source content, send it for translation, return the translation, review it and publish. Time each handoff and note every point where the editor leaves the admin screen, switches tools or waits for a plugin or developer. Compare the two logs on the same entry. The output is a workflow record that shows where effort concentrates, which is more useful to your team than any published benchmark.
Confirm module and plugin maintenance
For every contributed module or third-party plugin used in the pilots, record the maintainer, last release date, supported core versions and open security advisories. For Drupal, check each module's compatibility with the core version you plan to run, and for WordPress, check plugin compatibility with the core release you will use. Confirm the PHP version each stack requires. Drupal 11 requires PHP 8.3 or later, Drupal 12 requires PHP 8.5 or later, and WordPress.org recommends PHP 8.3 or greater. The step closes when a dependency register exists for each candidate.
Decide with the evidence
Bring the defect logs, workflow records, fallback results and dependency registers to a decision meeting with the CIO or CTO, the content owner and the security lead. Compare the custom work each candidate needs against the maintenance burden of its plugins or modules, and identify which findings a vendor or implementation partner must confirm in writing. The step ends with a recorded decision, the open questions list and the scope items to request in any quote.
When multilingual support should decide the choice
Translation depth should decide the choice when your content is structured and the same record is published in many locales. Drupal's Content Translation module translates content entities field by field, so a product description, a legal notice and an image caption can each carry their own translation state and reviewer. Interface Translation (Locale) handles the strings in templates and modules, and Configuration Translation covers text such as field labels and Views, which editors would otherwise see only in the source language. This matters most when you have many content types, more than a handful of locales, and translators or legal reviewers who work field by field under a formal workflow. Before deciding, list every content type and field that must be translated, and confirm which configuration text editors will see in each language.
Plugin-based translation is a reasonable choice when the site is modest, covers a few languages and the team already edits in WordPress. WordPress does not support a bilingual or multilingual site out of the box, and its handbook points to community plugins to fill the gap. Running one site per language inside a multisite network is documented as an alternative, but it adds management overhead. The advantages of this route hold only under specific conditions: editors know the dashboard, the plugin ecosystem covers the languages and integrations you need, and the content model stays simple enough that translation does not touch many custom fields. Confirm that the plugin you choose is actively maintained, supports your locales and keeps translations intact through updates. The WordPress multilingual documentation sets out the official position.
Use a short test to make the call. Pick one page with a custom field, a menu and a listing view, then ask how each platform would translate, review and publish it in every target locale. If the answer requires field-level status, translated configuration and reviewer roles, Drupal's four core modules cover that model, and the Drupal multilingual guide explains how they fit together. If the answer is a few pages per language with one plugin and a small editing team, WordPress may be enough, provided the plugin's update history and language support hold up in your own environment. Ask any implementation partner for written scope covering the translation workflow, testing of each locale and ongoing module or plugin maintenance before you compare quotes.
Questions buyers ask before hiring help with multilingual sites
What drives the cost of a multilingual Drupal build?
Cost follows the number of languages, the amount of content that must be translated, and how much of the configuration (field labels, Views, menus) needs translating. Drupal's four core multilingual modules are free under GPL-2.0-or-later, so the spend is on planning, configuration, theming, testing and translation workflow. Contributed modules you add for translation management or machine translation carry their own maintenance. Ask any provider for a written quote that separates one-time build work from recurring hosting, module updates and translation fees.
What drives the cost of a multilingual WordPress build?
On WordPress the main cost driver is the plugin layer, because core has no multilingual support and the gap is filled by community plugins. Costs include the plugin licenses you choose, the work to keep translations synchronized across plugins and themes, and the overhead of one site per language on multisite if you take that route. The WordPress handbook notes that the multisite approach adds management overhead. Ask for a quote that lists every multilingual plugin, its license terms and who maintains the integration after launch.
How long does a multilingual build take?
The duration depends on scope: the number of languages, content types, templates, integrations and how much existing content must be migrated. No fixed timeline applies to every site, so treat any single number as unreliable. DeployOpen's engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for a written quote that ties the timeline to named deliverables and to the content that must be translated and reviewed.
Can our own team build a multilingual site without outside help?
A team with Drupal or WordPress experience can build a multilingual site in-house, but the work is more than installing modules. Drupal needs decisions about language negotiation, which entities are translatable, and how configuration translation is handled across environments. WordPress needs a deliberate plugin choice and a policy for keeping plugins and themes translated. Outside help is most useful for the architecture decisions, the migration and the testing. Assess your team against those tasks before deciding, and confirm the skills you have in-house.
What does a multilingual site need from editors and developers?
Editors need a clear translation workflow, including who translates, who reviews and when a page is published in each language. Developers need to maintain translatable templates, configuration and any custom code that outputs text. On Drupal, developers manage the four core modules and the translation of configuration such as field labels and Views. On WordPress, they manage plugin compatibility and check that each language version still works after updates. Agree on these roles before the build starts, and confirm them in the statement of work.
How does the platform choice affect later upgrades?
Upgrade effort depends on the release model and on how many multilingual add-ons you run. Drupal major versions are scheduled, with Drupal 12.0.0 planned for the week of December 7, 2026, and Drupal 10 reaching end of life on December 9, 2026, so a Drupal site needs a planned major upgrade path. WordPress receives automatic background updates for minor releases and automatic major updates on sites created since WordPress 5.6, but plugin compatibility still needs testing. Check your language modules and plugins against each new release before you commit to a schedule.
Which licenses apply to the multilingual components?
Drupal core and contributed files derived from it are licensed under GPL-2.0-or-later, and WordPress is under GPLv2 or later. Neither platform charges a license fee for core, but third-party multilingual plugins and translation services may have their own terms. Ask each vendor and plugin author to confirm the license of every component in the proposed stack, and ask whether any paid tier is required for the features you need.
What should we confirm in a quote for a multilingual site?
Ask the provider to list the languages, the content types and fields to translate, the configuration to translate, the integrations in scope, and the testing and handover deliverables. Request separate line items for planning, build, migration, translation workflow, documentation and post-launch support. Confirm who holds the license relationships, who maintains modules or plugins, and what happens to the site at each platform's end-of-support date. A written scope makes these answers comparable across vendors.
How DeployOpen helps evaluate and implement multilingual sites
DeployOpen plans, implements, customizes, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure. For a multilingual site, that means deciding whether Drupal's core multilingual modules or a WordPress plugin approach fits your languages, content model and editorial workflow, then building and documenting the chosen route in your environment.
How we scope
- Written scope lists the languages, content types, translation workflow and roles each site needs before any build starts.
- We confirm which content is translated per field, which interface strings and configuration text need translation, and who owns each.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing ahead of work.
How we build
- Build covers language detection, URL structure, translation workflows and the hosting stack in your own cloud account or data center.
- Each candidate route is tested against the same sample pages so you compare real editorial steps, not assumptions.
- Integrations with your identity provider, translation vendors and analytics are scoped and built as written in the agreement.
How we hand over
- Handover includes configuration documentation, runbooks for adding a language and a record of every module or plugin used.
- Editors and administrators receive training scoped to the translation workflow your team will run day to day.
- Documentation records the upgrade path for each component so your team can plan major and minor releases.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover module or plugin updates, translation workflow changes and security testing of multilingual pages.
- Ask any provider to confirm response terms, upgrade scope and who is accountable for third-party extensions in writing.
