setup-config errors are not localised

[johnbillion]

There are two error messages shown in setup-config.php that are not localised.

1. If wp-config-sample.php is missing during the initial installation, the error message stating this is always shown in English rather than the language chosen in the first step of installation (from $_REQUEST['language']).
   • To reproduce, delete or rename both wp-config.php and wp-config-sample.php and then attempt tp proceed through the installation steps.
2. Manually visiting wp-admin/setup-config.php during normal site operation will show an error message stating that the wp-config.php file already exists. This is always shown in English rather than the installed site language (from the WPLANG option).
   • To reproduce, visit wp-admin/setup-config.php during normal site operation.

Affected error messages: ​https://github.com/WordPress/wordpress-develop/blob/fc96319aa770050d22cfdc1bbab437154017bcf7/src/wp-admin/setup-config.php#L43-L82

[swissspidy]

For (1):

When I rename/delete both wp-config.php wp-config-sample.php, I don't even get to the language chooser. I immediately get redirected to setup-config.php with "Sorry, I need a wp-config-sample.php file to work from.". In this case no language information is available of course and this will always be in English.

Can you perhaps clarify this part?

For (2):

The main issue here seems to be that the found wp-config.php file isn't actually loaded, so wp-settings.php (which was loaded earlier by itself) and wpdb don't know the actual table prefix, so the locale information can't be loaded from the database.

To change the behavior here, I think the file would need to be refactored quite a bit so that if a config file already exists, it is actually loaded. Then the locale information is known and the translation could be loaded.

[johnbillion]

Looks like I got confused while testing this. The wp-config-sample.php error message is correctly localised when you attempt to install a localised package, for example the de_DE package from ​https://de.wordpress.org/latest-de_DE.zip:

Die Datei wp-config-sample.php ist erforderlich. Bitte lade diese erneut zu deiner WordPress-Installation hoch.

There doesn't appear to be a way to reach this error message in the standard package, unless you manually delete wp-config-sample.php after you've selected a language.

So it looks like the only actual issue is the second one, whereby visiting wp-admin/setup-config.php during normal site operation always shows the message in English.

[swissspidy]

The wp-config-sample.php error message is correctly localised when you attempt to install a localised package

Huh, I wonder why that is though.

[johnbillion]

Probably due to the $wp_local_package = 'de_DE'; line in wp-includes/version.php.

[swissspidy]

Really not sure what would be the best way to address (2), additional suggestions welcome.

[abhishekfdd]

Replying to @swissspidy in comment:6. I built a working fix for (2) and then talked myself out of attaching it. Posting what I found instead, since the constraints seem more useful than the patch.

Why the straightforward approaches do not work

The file has changed since this ticket was opened, so a couple of these are worth recording:

1. setup-config.php now requires wp-settings.php directly near the top, so loading wp-config.php after that point does nothing for the bootstrap (require_once), and SHORTINIT has no effect either.
2. get_option() returns false unconditionally while WP_SETUP_CONFIG is defined (wp-includes/option.php), so the locale has to be read with a direct query.
3. The wpdb constructor returns before db_connect() under WP_SETUP_CONFIG, so the connection has to be made by hand, as the existing code already does further down when validating submitted credentials.
4. Loading wp-config.php after wp-settings.php emits Constant WP_DEBUG already defined, because wp_initial_constants() has already run and wp-config-sample.php defines it unguarded.

That leaves loading wp-config.php before wp-settings.php as the only place it can happen cleanly. That works: I tested it on trunk with PHP 8.3 and a non-default table prefix, and the message renders in the site language with the 409 preserved and a clean error log. Plugins and themes stay unloaded, since WP_INSTALLING is defined before anything and both wp_get_active_and_valid_plugins() and wp_get_active_and_valid_themes() bail while installing.

The problems with doing that

Four, and together I do not think they are worth one string:

1. A malformed wp-config.php breaks the page. error_reporting( 0 ) at the top of the file swallows the E_PARSE, so under PHP-FPM you get HTTP 200 with an empty body and nothing logged anywhere. Under other SAPIs you get a 500. Today setup-config.php renders its notice regardless of what is in that file.
2. On a site with WP_DEBUG enabled and stale credentials in the config, the manual connect surfaces mysqli_real_connect(): Access denied from the unsilenced branch at class-wpdb.php:1999. Silencing it works, but it means adding another phpcs:ignore WordPress.PHP.NoSilencedErrors.Discouraged to core.
3. Mu-plugins and drop-ins such as object-cache.php would start loading from the site's real WP_CONTENT_DIR on this path, where today they load from the default.
4. It only covers half the problem anyway. WordPress supports wp-config.php one directory above ABSPATH, and that layout hits the second wp_die() further down, which would still be in English. Covering both means loading a config from either location, which widens the blast radius again.

Suggestion

Given (1) and (4) in particular, wontfix looks reasonable to me, or narrowing the ticket to something achievable. If you think the trade is worth making I am happy to clean up the patch and attach it, including the dirname( ABSPATH ) case, but I did not want to put a patch on the ticket that quietly makes a broken config harder to diagnose.

Previously, wp-admin/setup-config.php always bootstrapped WordPress without a configuration file (WP_SETUP_CONFIG), even when a wp-config.php file already existed. As a result, the "already exists" error message could not be translated into the site's language, because the table prefix and thus the WPLANG option were unknown.

Check for an existing configuration file first, mirroring the lookup in wp-load.php, and if one is found, load WordPress through it like any other request would. The site's locale is then known and the message is displayed in the site language, both for a wp-config.php file in the WordPress root and for one located one level above it.

Trac ticket: https://core.trac.wordpress.org/ticket/63009

Use of AI Tools

Used Claude Code

Some trade-offs/notes:

• A broken wp-config.php now breaks setup-config.php the way it breaks every other page. I think that is correct, since the old notice told people with a broken config to delete it and reinstall, but it is a behavior change.
• mu-plugins and drop-ins load in that branch like on any request. Plugins and themes do not, because of WP_INSTALLING.
• Not tested on multisite. install.php uses the identical bootstrap there, so I expect no difference.

[johnbillion]

In 63926:

Upgrade/Install: Load the existing configuration and locale before rejecting a request to setup-config.php.

Visiting wp-admin/setup-config.php on a site that already has a wp-config.php file will now show the error message in the site language instead of always in English.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/13631.

Props swissspidy, abhishekfdd.

Fixes #63009.