If you inherited a Drupal 8 site and the business now wants all existing content to be Swedish instead of English, this is not a simple settings change. Drupal's multilingual docs still warn against changing the default language after content has been added, and as of June 7, 2026, Drupal 8 has been unsupported since November 17, 2021. For business owners and operations leads, that changes the framing: this is a controlled legacy-data change, not a quick admin task.
The old shortcut of exporting a few tables, replacing en with sv, and importing again gets one thing right: in many cases you are re-labeling existing source content, not translating it. What it gets wrong is scope. On a real Drupal 8 site, language data is not stored in one neat place, and updating only node and taxonomy_term_data is incomplete more often than not.
Why the Old Advice Needs an Update
Current Drupal documentation explicitly says not to change the default language after content exists, because things can break. That is the first correction. If the live site already has articles, taxonomies, revisions, or translated fields, this is closer to a small migration than a UI tweak.
The second correction is technical. Drupal's content translation model keeps one entity ID across translations, while translated field values and metadata live in additional data tables. In practice, that means a blanket database search-and-replace is harder to audit than a reviewed SQL file that touches only the tables you actually need.
For agency teams, this is the difference between a recoverable maintenance job and an expensive cleanup. For site owners, it is the difference between a planned change window and a multilingual bug hunt after launch.
A Safer Working Pattern
- Clone production to staging and take a full database backup before touching language data.
- Confirm the exact target language code, such as
sv, and confirm the real job: changing the source language of existing content is different from adding proper multilingual content. - Inventory the affected entity types. At minimum, review nodes, taxonomy terms, revisions, and any custom entities or integrations that store language codes.
- Keep the SQL in a file and review it like code. If several people are involved, put that file under version control.
If the site already serves multiple languages, uses moderation heavily, or has custom translation logic, stop and re-scope the work. On a legacy Drupal 8 build, it is often cheaper to plan a repair as part of an upgrade path than to patch multilingual data in production and revisit it later.
Example: Explicit SQL Beats a Blind Replace
For a simple one-language legacy site where existing English content should become Swedish source content, targeted SQL is safer than editing a dump with a global replace. The exact table list depends on the site, but this is the minimum shape worth reviewing for core nodes and taxonomy terms:
UPDATE node SET langcode = 'sv' WHERE langcode = 'en';
UPDATE node_field_data SET langcode = 'sv' WHERE langcode = 'en';
UPDATE node_revision SET langcode = 'sv' WHERE langcode = 'en';
UPDATE node_field_revision SET langcode = 'sv' WHERE langcode = 'en';
UPDATE taxonomy_term_data SET langcode = 'sv' WHERE langcode = 'en';
UPDATE taxonomy_term_field_data SET langcode = 'sv' WHERE langcode = 'en';
UPDATE taxonomy_term_revision SET langcode = 'sv' WHERE langcode = 'en';
UPDATE taxonomy_term_field_revision SET langcode = 'sv' WHERE langcode = 'en';
-- Review custom entity tables separately.
-- Do not blindly rewrite default_langcode or content_translation_source.A text replace across a narrow export can still help you draft or compare changes, but it should be treated as a review step, not the live fix you trust blindly.
Once the SQL is reviewed, run it through Drush from the project root or via a site alias. If you are on multisite, use the correct alias or --uri:
drush sql:dump --result-file=../before-language-change.sql
drush sql:query --file=change-language.sql
drush updatedb -y
drush cache:rebuild -yThe warning about default_langcode and content_translation_source matters. Those fields describe translation state, not just human language. Changing them blindly can confuse what Drupal believes is the default record versus a translation.
Checks Before You Sign Off
- Open a sample of content and taxonomy terms in the admin UI and confirm the language now matches the intended source language.
- Check views, exposed filters, search pages, menus, and any API responses that depend on language-aware queries.
- Create one new content item and one new taxonomy term to verify that fresh content inherits the expected language.
- Ask editors to validate one real workflow before you touch production. If they cannot edit normally, the job is not finished.
The practical takeaway is simple. Yes, changing Drupal 8 content language is possible. No, it is not a harmless settings flip. The reliable approach is to stage it, make the SQL explicit, test editor workflows, and use the moment to decide whether the site should be stabilized temporarily or moved onto a supported Drupal version.
If you need help untangling a legacy multilingual setup, planning the cleanup, or deciding whether this should be a repair or an upgrade, I can help map the safest path before anyone touches production.
Need help with this kind of work?
Need a practical second opinion on a legacy Drupal language cleanup? Get in touch with Greg.