array( '01' => 'Janvier', '02' => 'Février', ... ) : ce genre de tableau, codé en dur en tête d’un fichier de thème, se rencontre régulièrement dans un widget de calendrier ou une liste d’archives groupées par mois, écrits sans faire appel à la moindre fonction native de WordPress. Le résultat fonctionne, jusqu’au jour où le site devient multilingue : le tableau reste figé en français, quelle que soit la langue réellement affichée à l’utilisateur.
Ce billet ne traite pas du cas où une vraie date PHP existe déjà et doit simplement s’afficher traduite — ce cas relève de date_i18n(), traité par ailleurs. Il s’agit ici d’un scénario différent, fréquent dans un widget de calendrier ou une liste d’archives : on manipule un simple numéro de mois ou de jour, sans objet date associé, et l’on a besoin de son nom traduit.
Le cas d’un widget de calendrier fait maison
Un widget de calendrier personnalisé, affichant douze cases nommées d’après le mois plutôt qu’une grille jour par jour, n’a souvent besoin que du nom du mois correspondant à un numéro déjà connu. Plutôt que de reconstruire un objet DateTime uniquement pour en extraire un nom de mois, la méthode get_month() de WP_Locale répond directement au besoin :
global $wp_locale;
foreach ( range( 1, 12 ) as $numero_mois ) {
$numero_formate = str_pad( $numero_mois, 2, '0', STR_PAD_LEFT );
echo '<li>' . esc_html( $wp_locale->get_month( $numero_formate ) ) . '</li>';
}Chaque case du calendrier affiche ainsi « Janvier », « Février »… en français, ou leur équivalent traduit dans n’importe quelle autre langue active, sans jamais manipuler de véritable objet date. La méthode consulte directement le tableau $wp_locale->month, déjà rempli à partir des fichiers de traduction du domaine default au chargement de la locale courante.
Le cas d’une liste d’archives groupées par mois
Une liste d’archives maison, construite à partir d’une requête SQL directe sur la table wp_posts plutôt que via wp_get_archives(), produit typiquement un tableau de résultats groupés par année et par numéro de mois, sans nom de mois associé. Reconstituer ce nom traduit pour l’affichage se fait avec la même méthode :
global $wpdb, $wp_locale;
$resultats = $wpdb->get_results(
"SELECT YEAR(post_date) AS annee, MONTH(post_date) AS mois, COUNT(*) AS total
FROM {$wpdb->posts}
WHERE post_status = 'publish' AND post_type = 'post'
GROUP BY annee, mois
ORDER BY annee DESC, mois DESC"
);
foreach ( $resultats as $ligne ) {
$numero_formate = str_pad( $ligne->mois, 2, '0', STR_PAD_LEFT );
$nom_mois = $wp_locale->get_month( $numero_formate );
echo '<li>' . esc_html( $nom_mois . ' ' . $ligne->annee ) . ' (' . (int) $ligne->total . ')</li>';
}
Les noms de jours pour un en-tête de calendrier
La méthode get_weekday() répond au même besoin pour les jours de la semaine, utile en particulier pour l’en-tête d’une grille de calendrier qui affiche les sept jours avant de dérouler les cases numérotées du mois :
global $wp_locale;
foreach ( range( 0, 6 ) as $indice_jour ) {
echo '<th>' . esc_html( $wp_locale->get_weekday_abbrev( $wp_locale->get_weekday( $indice_jour ) ) ) . '</th>';
}get_weekday_abbrev(), appelée avec le nom complet du jour déjà traduit, retourne l’abréviation correspondante déclarée dans les fichiers de traduction ; elle évite de tronquer soi-même une chaîne traduite, ce qui produirait une abréviation incorrecte dans certaines langues où la troncature d’un nom complet ne donne pas l’abréviation d’usage.
Ce qu’il ne faut pas coder en dur
- Un tableau de noms de mois écrit directement dans le thème, qui reste figé dans une seule langue quel que soit le site multilingue.
- Une numérotation de jour qui suppose que le premier jour de la semaine est toujours le lundi :
$wp_locale->get_weekday()ne décide pas cet ordre, à vérifier séparément via l’optionstart_of_weekdu site. - Un index de mois non complété par un zéro (
'3'au lieu de'03'), qui peut ne retourner aucune correspondance selon la façon dont le tableau interne a été rempli.
Un numéro de mois ou de jour n’a besoin d’aucune date complète pour être traduit correctement : WP_Locale répond directement à ce besoin précis, sans détour par un objet DateTime superflu.
En résumé
Un calendrier ou une liste d’archives construits à la main, sans passer par une date PHP complète, gagnent à consulter directement $wp_locale->get_month() et $wp_locale->get_weekday() plutôt que de coder en dur un tableau de noms dans une seule langue. Cette approche reste distincte du cas où une vraie date existe déjà et doit simplement s’afficher traduite, qui relève de date_i18n().
