Internationalising templates

SPIP naturally displays interface elements (dates, button labels) in the language chosen by the user.

Creating multilingual templates

When you create a template, it is necessary to use the language strings so that the interface content is displayed in the requested language.

SPIP already provides the most common headings (such as "Site map", "Reply to this article", etc.).

This article shows you how to add new ones to suit your needs.

In addition, using language strings improves the maintenance of your template (when a language string is modified, all the pages are modified).

Using language files

Regardless of the structure decided for the site (language sectors or not), all you need to do is insert a "language string" like this <:language_string:> spip will look for the translation in one of the SPIP files or in a local_xx.php file (xx being the language code) that you have created.

The language suffix xx is the one generally used in ISO standards.
For example fr for French.

Regional variants are also supported:
For example pt_br for Brazilian Portuguese.

For example, we display a music section on our site


To internationalise, we pass the text in a language string


Depending on the language selected, the string <:music:> will be displayed
-  in French, in the ’Musique’ string,
-  in English, on the ’Music’ string,
-  in Japanese, on the "音楽" string,

You therefore need to create as many language files as the languages used by your site.
In the above example, you would create a lang/local_fr.php, lang/local_en.php and lang/local_ja.php.

The structure of a language file

A language file is stored in a lang directory.
It is structured as follows:
The language files contain the various translations of the codes you will be using; these are PHP files, each containing an array associating the corresponding strings in each language with the codes.

Caution :
The name of these language files must not contain the _ character ("underscore" or "hyphen") except to mark the separation with the code of the language (en, fr, it,...). For example, we would create "myperso_fr.php" and not "my_perso_fr.php".

These files will contain, for example:

French version (lang/myperso_fr.php) :

  $GLOBALS[$GLOBALS['idx_lang']] = array(
    'telechargement' => 'Télécharger la dernière version',
    'quoideneuf' => 'Modifications récentes'

Catalan version (lang/myperso_ca.php) :

  $GLOBALS[$GLOBALS['idx_lang']] = array(
    'telechargement' => 'Descarregar la darrera versió',
    'quoideneuf' => 'Modificacions recents'

Syntax of language files
-  Each line of the definition ends with a comma, except for the last line where the comma is not required.
-  Apostrophes within the string must be escaped, i.e. preceded by a backslash. For example, the string "what’s new" should be written: what\'s new.
-  It is possible not to escape apostrophes, as long as you use apostrophes of the "closing single inverted comma" type '.

Creating your own codes

It is also possible to create your own codes, corresponding to strings you want to add yourself.
This involves creating personal language files, based on the model of the public_xx.php files. To create your own files, install the following in a squelettes/lang directory (to be created if necessary)
-  local_fr.php to define strings in French,
-  local_en.php for English,
-  ...

The part you have to populate yourself consists of several lines of definitions, based on the model:

    'code' => 'String to display',

Plugins and language files

Many functions are provided by plug-ins, either core plug-ins such as Quill or SVP, or plug-ins added by webmasters because they want to use a specific function. All these plug-ins have language files.

See also

For more information on language strings, visit


the initial versions of this article presented solutions other than language files for making templates multilingual. Let’s just note here that these solutions are not recommended:
-  one template per language" (required the "squelettes_par_rubrique" plug-in): this is difficult to maintain and simply useless for basic use.
-  multilingual blocks": these <multi> blocks are very useful in the editorial section; they allow you to present a title in different possible languages, display different captions for each language... but should be avoided in the structure section.

Author George, jack Published :

Translations : عربي, English, français, Português do Brasil