# wp_get_available_translations : les langues que WordPress sait installer

> Définition de la fonction cœur qui liste les traductions officielles disponibles, et comment l'utiliser pour proposer une langue dès l'installation d'un site multilingue neuf.

- Auteur : WordPress Développement
- Publié le : 2023-04-29
- Mis à jour le : 2023-04-29
- Catégorie : Multilingue
- URL : https://www.wpmoderne.fr/multilingue/wp-get-available-translations-langues-installation/

## L’essentiel

- La fonction interroge directement les serveurs de traduction de WordPress.org
- Elle sert de base à un sélecteur de langue lors d'une installation neuve
- Elle ne concerne que les traductions officielles, pas les extensions

Le Codex de WordPress décrit sobrement `wp_get_available_translations()` comme une fonction retournant « les traductions disponibles au téléchargement », sans plus de détail sur son fonctionnement interne ni sur ses cas d'usage réels. Pourtant, cette fonction constitue la brique de base de tout écran de choix de langue à l'installation, y compris celui que WordPress affiche lui-même lors d'une nouvelle installation.

Ce sujet s'attarde sur cette fonction du cœur, sans aborder les extensions de traduction de contenu comme Polylang ou WPML, qui résolvent un problème différent : traduire du contenu, pas installer des fichiers de langue pour l'interface.

## Ce que fait concrètement la fonction

`wp_get_available_translations()` interroge l'API de traduction de WordPress.org (via la fonction interne `translations_api()`) pour récupérer la liste complète des locales pour lesquelles des fichiers de traduction officiels de l'interface d'administration existent. Le résultat inclut, pour chaque locale, son code (`de_DE`, `es_ES`, `pt_BR`...), son nom natif, son nom anglais, et l'URL du paquet de traduction téléchargeable.

- La fonction retourne un tableau associatif indexé par code de locale
- Chaque entrée contient le nom natif de la langue, essentiel pour un affichage correct du sélecteur
- Le résultat est mis en cache via un transitoire pour éviter une requête réseau à chaque appel

## Fonctionnement interne : un appel réseau mis en cache

En coulisses, la fonction s'appuie sur `translations_api( 'core', array( 'version' => $wp_version ) )`, qui contacte `api.wordpress.org`. Le résultat est stocké douze heures dans un transitoire nommé `available_translations`, ce qui signifie qu'un serveur sans connexion sortante vers `api.wordpress.org` (cas fréquent sur un hébergement mutualisé restrictif ou un environnement isolé) verra cette fonction retourner un tableau vide, sans erreur explicite.

> L'essentiel à retenir : La fonction interroge directement les serveurs de traduction de WordPress.org ; Elle sert de base à un sélecteur de langue lors d'une installation neuve ; Elle ne concerne que les traductions officielles, pas les extensions

C'est un point de vigilance important pour un site multilingue en cours de construction sur un serveur interne d'entreprise ou derrière un pare-feu strict : l'absence de connexion sortante casse silencieusement cette fonction, sans qu'aucun message n'alerte l'administrateur sur la cause réelle du problème.

### Cas d'usage : proposer une langue dès l'installation

Pour un site institutionnel destiné dès le départ à plusieurs pays, il est possible d'exploiter cette fonction dans un script de provisionnement automatisé, afin d'installer directement les bons paquets de langue avant même que l'administrateur ne se connecte pour la première fois. WP-CLI propose d'ailleurs un raccourci direct pour cet usage, sans avoir à manipuler la fonction PHP soi-même :

```
wp language core list --field=language
wp language core install de_DE nl_NL --activate
```

La commande `wp language core list` s'appuie en interne sur le même mécanisme que `wp_get_available_translations()`, ce qui en fait l'équivalent en ligne de commande pour un script d'installation automatisé.

## Distinguer traduction de l'interface et traduction du contenu

Un piège courant pour un développeur découvrant cette fonction consiste à croire qu'elle a un rapport avec la traduction du contenu du site (articles, pages) : ce n'est pas le cas. Elle concerne uniquement les fichiers `.mo` de traduction de l'interface d'administration et des chaînes du cœur de WordPress, complètement indépendants du contenu géré par Polylang ou WPML.

| Élément | Concerné par wp_get_available_translations |
| --- | --- |
| Menus de l'administration | Oui |
| Messages d'erreur du cœur | Oui |
| Contenu des articles et pages | Non |
| Chaînes d'un thème ou d'une extension tierce | Non, sauf si elle utilise le même système de traduction officiel |

## Les pièges à connaître

Au-delà du problème de connexion réseau déjà mentionné, cette fonction ne garantit pas que la traduction retournée soit complète à cent pour cent : certaines locales moins courantes n'ont qu'une traduction partielle de l'interface, avec des chaînes manquantes qui basculent silencieusement vers l'anglais. Un site multilingue destiné à un marché avec une locale rare mérite donc une vérification manuelle de la complétude de la traduction avant d'en faire la promesse à un client.

## Ce qu'il faut en retenir

Discrète mais essentielle, `wp_get_available_translations()` constitue le socle technique de tout écran proposant un choix de langue à l'installation d'un site WordPress. La comprendre permet d'anticiper des comportements déroutants sur des serveurs à connexion sortante restreinte, et d'automatiser proprement le provisionnement linguistique d'un nouveau site multilingue via WP-CLI.