0 octet : c’est la taille du nouveau fichier .mo censé contenir la traduction française fraîchement mise à jour, dans le dossier wp-content/languages/ d’un site hébergé chez un prestataire mutualisé. L’écran d’administration affichait pourtant un message de succès après le clic sur « Mettre à jour maintenant », sans la moindre alerte visible pour l’administrateur du site.
Ce décalage entre un message de confirmation et un résultat réellement absent trompe souvent l’administrateur, qui referme l’écran de mise à jour convaincu que tout s’est bien passé, avant de découvrir plus tard que certaines chaînes du thème ou du cœur sont toujours restées en anglais malgré plusieurs tentatives de mise à jour.
Symptôme : une mise à jour annoncée réussie, sans effet réel
Le tableau de bord WordPress affiche une notification de traductions disponibles, l’administrateur clique pour les installer, et l’écran confirme l’opération sans erreur apparente. Pourtant, en rechargeant le site, certaines chaînes du cœur ou du thème restent identiques à avant, comme si la mise à jour n’avait jamais eu lieu. Aucun message d’erreur PHP ne remonte dans les journaux habituels du site, ce qui complique le diagnostic initial.
Diagnostic : des droits d’écriture insuffisants sur le dossier cible
WordPress télécharge ses paquets de traduction directement dans le dossier wp-content/languages/, en utilisant le système de fichiers direct quand les permissions le permettent, ou en demandant des identifiants FTP dans le cas contraire. Sur certains hébergements mutualisés, ce dossier appartient à un utilisateur système différent de celui sous lequel s’exécutent les processus PHP, ou ne dispose simplement pas des droits d’écriture nécessaires pour ce compte applicatif précis.
Dans ce cas de figure, WordPress tente l’écriture, échoue silencieusement côté système de fichiers, mais l’interface d’administration affiche malgré tout un message de succès générique, sans distinguer cet échec précis d’une véritable réussite. Une vérification directe en ligne de commande confirme rapidement le problème :
ls -la wp-content/languages/
stat -c "%a %U %G" wp-content/languages/
Si le propriétaire du dossier ne correspond pas à l’utilisateur sous lequel PHP s’exécute, ou si les permissions affichées ne permettent pas l’écriture pour ce compte, la cause est confirmée : le processus PHP ne peut tout simplement pas créer de nouveaux fichiers à cet endroit.
Correctif : rétablir des permissions correctes
La correction consiste à ajuster les permissions du dossier concerné, généralement via une commande SSH si l’hébergement le permet :
chown -R utilisateur-php:groupe-web wp-content/languages/
chmod -R 755 wp-content/languages/
Sur un hébergement mutualisé sans accès SSH, la même opération se fait généralement via l’interface de gestion de fichiers du panneau d’hébergement, en modifiant les permissions du dossier languages et de son contenu depuis cette interface graphique. Une fois les droits corrigés, une nouvelle tentative de mise à jour des traductions, depuis l’écran habituel du tableau de bord, télécharge normalement les paquets manquants.
- Vérifier le propriétaire réel du dossier
wp-content/languages/avant toute autre hypothèse. - Comparer ce propriétaire à l’utilisateur sous lequel PHP s’exécute réellement sur ce serveur.
- Retenter la mise à jour depuis l’administration une fois les permissions corrigées, plutôt que de télécharger le fichier .mo manuellement.
Prévention : surveiller ce dossier après chaque changement d’hébergement
Ce problème réapparaît typiquement après une migration vers un nouvel hébergeur, où les permissions par défaut appliquées au transfert de fichiers diffèrent de celles de l’environnement d’origine. Un contrôle systématique des permissions du dossier wp-content/languages/, au même titre que celui de wp-content/uploads/, mérite de figurer dans la liste de vérifications suivant toute migration de site.
Un repère utile pour ne pas se laisser piéger par le message de confirmation à l’écran : toujours vérifier physiquement la présence et la date de modification du fichier .mo attendu, plutôt que de faire confiance uniquement au message affiché après une mise à jour de langue.
En résumé
Un message de succès affiché par l’administration WordPress ne garantit pas toujours qu’une opération a réellement abouti côté système de fichiers, en particulier pour une opération d’écriture soumise aux permissions du serveur d’hébergement. Sur un hébergement mutualisé aux droits restrictifs, vérifier directement l’état du dossier concerné reste le seul moyen fiable de confirmer qu’une mise à jour de langue s’est réellement produite.
