Introduction

Although WordPress displays in U.S. English by default, the software can be used in any language, or 'localized' (see WordPress in Your Language for more information).

Usually, WordPress localization is performed using the Gnu gettext system (see Translating WordPress for more information). The gettext system runs text messages produced by WordPress PHP files through a look-up function, which finds and uses the non-English equivalent of a given word or phrase.

Gettext works well for most aspects of WordPress. However, there are a few components of the software that do not lend themselves to localization with gettext. This article explains why that is the case, and how to localize those components of WordPress.

Where gettext Doesn't Work

There are some components of WordPress that cannot or should not be localized with gettext:

• The main WordPress README file cannot be run through the gettext functions as it is a static HTML file, not a PHP file.
• Some error messages are generated very early in the WordPress loading cycle, before gettext is loaded.
• license.txt - This file should be kept in place for legal reasons. A translated version can be added to the archive.

Internationalizing Non-gettext Components

To internationalize or localize components of WordPress that cannot use gettext, you will need to replace the English version of the files with a manually translated version. A list of the files you should translate is given below.

Core files

• readme.html - This is a static HTML file, not a PHP file, and so cannot be run through gettext. The whole file must be translated.
• wp-admin/setup-config.php - This is a script that enables automatic generation of wp-config.php. It cannot be used with gettext as it runs independently of WordPress. The whole file must be translated.
• wp-config-sample.php - You must set this file's WPLANG variable to the correct locale in order for Wordpress to recognize the language you are localizing to. See section below for instructions on how to translate this file correctly.

Translating wp-config-sample.php

Translate the instructions in the PHP comments (so that they can be used by non-English speakers), and set the WPLANG variable to the correct locale. For example, you would change define ('WPLANG', ''); to define ('WPLANG', 'bg_BG');if you were using the bg_BG locale.

Replace the text after each salt and key definition with a similar phrase in the desired language. For example, the Bulgarian file would look like this:

dist/wp-config-sample.php:

[...]
define('AUTH_KEY', 'вашата супер-ултра-уникална фраза сложете тук');
define('SECURE_AUTH_KEY', 'вашата супер-ултра-уникална фраза сложете тук');
define('LOGGED_IN_KEY', 'вашата супер-ултра-уникална фраза сложете тук');
[...]

Note: Be careful of version conflicts if you plan to release your localized files for use by others. You will need to keep track of the version of WordPress that each file corresponds to, or release different versions of the files for different versions of WordPress.

You can find a list of different WordPress versions in the Release Archive. Alternatively, you can check the Trac Browser, which allows you to browse the WordPress SVN source code repository and offers even greater detail on version numbers.