Drupal 8: Change Existing Content Language Safely

By Greg Nowak. Last updated 2026-07-08.

If you inherited a Drupal 8 site and the organisation now wants existing English content to become Swedish source content, treat the job as a controlled legacy-data repair. It is not the same as translating content, and it is not a safe one-click change in the language settings.

The distinction matters for business owners, operations leads, and agency teams because a language code is part of Drupal's content model. It can affect editorial screens, Views, search indexes, feeds, API responses, and any custom integration that filters by language. As of 8 July 2026, Drupal 8 has also been unsupported for years, so this work should be scoped like production maintenance on a legacy platform.

Situation	Working Assumption	Safer Route
One-language Drupal 8 site, content was entered in the wrong source language	You are relabelling existing source content	Use staging, backups, explicit SQL, and editorial sign-off
The site needs real English and Swedish versions	You are not relabelling; you are translating	Use Drupal content translation or a migration plan
Custom entities, moderation, search, or API consumers are involved	Language is part of workflow and integration logic	Inventory affected tables and test real user journeys
The site has no supported upgrade path	The language fix may be a temporary repair	Consider bundling the cleanup into a Drupal upgrade plan

A practical decision matrix before changing language data on a legacy Drupal 8 site.

First Decide What You Are Really Changing

Drupal documentation warns against changing the default language after content has already been added. That warning is there because language is not just a label on a settings page. Existing content, translated fields, configuration, and language-aware queries may already depend on the old value.

For a simple inherited site, the real task may be narrower: existing content says en, but the content is actually Swedish and should be treated as sv. That is a source-language relabel. If the business expects both English and Swedish versions, do not use this shortcut. Build a translation workflow instead.

Audit Before You Touch SQL

The old advice to export a few tables, replace en with sv, and import again is too broad for a live Drupal site. A blind replacement can change configuration, serialized data, translation metadata, or third-party records you did not intend to touch.

Start with a clone of production, a full database backup, and a list of affected entity types. At minimum, review nodes, taxonomy terms, revisions, menus, redirects, URL aliases, search indexes, and custom entities. On common MySQL or MariaDB hosting, this discovery query helps identify tables that carry language metadata:

SELECT TABLE_NAME, COLUMN_NAME
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND COLUMN_NAME IN ('langcode', 'default_langcode', 'content_translation_source')
ORDER BY TABLE_NAME, COLUMN_NAME;

Use that list to write a reviewed SQL file. Do not make the production database the place where you improvise.

A Safer SQL Shape

For a basic Drupal 8 site where existing English-labelled node and taxonomy content should become Swedish-labelled source content, the core table updates often start like this:

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 field storage tables separately.
-- Examples: node__field_body, node_revision__field_body,
-- taxonomy_term__field_* and taxonomy_term_revision__field_*.

The comments are important. Drupal stores translated field values in field tables, and custom fields can carry their own langcode. Review them by table and by field. Do not blindly rewrite default_langcode or content_translation_source; those columns describe translation state, not only human language.

Run It Like Maintenance, Not a Console Trick

Use the project-local Drush version from the Drupal root or the correct site alias. On multisite, pass the right alias or --uri. Keep the SQL in a file so the team can review it and repeat it on staging and production.

vendor/bin/drush sql:dump --result-file=../before-language-change.sql
vendor/bin/drush sql:query --file=change-language.sql
vendor/bin/drush cache:rebuild -y

# Only during a normal deploy with pending database updates:
vendor/bin/drush updatedb -y

Running updatedb is not required just because you changed language rows. Use it only when this work is part of a planned code deploy with pending database updates.

Checks Before Sign-Off

Open a sample of nodes, taxonomy terms, and revisions in the admin UI.
Create new content and confirm it uses the expected language defaults.
Test Views, menus, URL aliases, search pages, feeds, and API responses.
Ask an editor to complete one real workflow, including save, preview, publish, and rollback if relevant.
Check logs for language negotiation, access, or search indexing errors.

The practical takeaway is simple: changing Drupal 8 content language is possible, but it should be handled as a small migration with a rollback path. If the site is still important to the business, use the work to decide whether the sensible next step is a contained repair, a multilingual cleanup, or a supported Drupal upgrade.

Need a practical second opinion before anyone touches production? Get Greg involved early and turn the language cleanup into a planned, testable maintenance task.