Menu de langue sans widget imposé : construire son sélecteur Polylang

Le directeur artistique d’un studio partenaire m’a envoyé une maquette Figma pour un site vitrine en trois langues : chaque drapeau devait apparaître sous forme de pastille ronde de 24 pixels, alignée horizontalement dans le header, avec la langue active soulignée d’un trait animé au survol. Le widget de langue livré nativement par Polylang, bien qu’efficace, ne propose aucune option pour ce rendu précis. Il fallait donc sortir du widget et écrire directement le HTML dans le gabarit du thème.

Ce cas se présente régulièrement : un widget générique convient pour un site où le design reste standard, mais dès qu’une charte graphique impose une structure HTML spécifique, mieux vaut appeler directement les fonctions PHP de Polylang plutôt que de forcer le widget avec des surcharges CSS fragiles.

La fonction pll_the_languages en détail

Polylang expose la fonction pll_the_languages(), qui accepte un tableau d’arguments et renvoie soit un affichage direct, soit un tableau de données exploitable manuellement selon la clé raw. Pour un contrôle total du balisage, je préfère systématiquement récupérer les données brutes plutôt que le rendu HTML par défaut :

<?php
$langues = pll_the_languages( array(
    'raw'            => 1,
    'hide_if_empty'  => 0,
    'show_flags'     => 1,
) );
?>
<ul class="selecteur-langue">
<?php foreach ( $langues as $langue ) : ?>
    <li class="<?php echo $langue['current_lang'] ? 'actif' : ''; ?>">
        <a href="<?php echo esc_url( $langue['url'] ); ?>">
            <?php echo esc_html( $langue['name'] ); ?>
        </a>
    </li>
<?php endforeach; ?>
</ul>

Ce tableau brut contient, pour chaque langue active, l’URL de la page équivalente, le nom de la langue, un indicateur booléen de langue courante et l’URL du drapeau si l’option est activée. À partir de là, le gabarit reste entièrement libre : classes CSS personnalisées, structure de liste, ordre d’affichage.

Récupérer la langue courante et l’URL d’accueil traduite

Pour des besoins plus ponctuels, comme afficher un simple lien vers l’accueil dans la langue active, deux autres fonctions suffisent : pll_current_language() renvoie le code de la langue affichée, et pll_home_url( $slug ) construit l’URL de la page d’accueil pour une langue donnée. J’utilise souvent ces deux fonctions combinées pour construire un logo cliquable qui renvoie toujours vers l’accueil dans la bonne langue, plutôt que vers l’URL du site par défaut.

Le cas des sites avec plus de trois langues

Au-delà de trois langues, un affichage horizontal de pastilles devient vite illisible sur mobile. J’ai déjà transformé ce même sélecteur en menu déroulant pour un client à cinq langues, simplement en encapsulant la boucle foreach précédente dans un élément <select> couplé à un petit script de redirection au changement de valeur, sans toucher à la logique PHP de récupération des données.

Ne pas oublier le paramètre hide_if_empty

Un piège classique concerne les pages qui n’ont pas encore de traduction dans une langue donnée. Par défaut, Polylang masque cette langue du sélecteur tant qu’aucune traduction n’existe pour le contenu affiché, ce qui est généralement le comportement souhaité. Mais sur certains projets, le client préfère afficher systématiquement toutes les langues actives, avec un lien vers la page d’accueil traduite en repli lorsque le contenu précis n’existe pas encore. Ce comportement se configure avec l’argument hide_if_empty mis à 0, comme dans l’exemple ci-dessus.

• show_flags active l’affichage des drapeaux si des images ont été configurées dans les réglages des langues Polylang.
• show_names, laissé à sa valeur par défaut, contrôle l’affichage du nom textuel de la langue à côté ou à la place du drapeau.
• Le tableau brut inclut aussi une clé flag avec l’URL de l’image du drapeau, utile pour un rendu en balise <img> plutôt qu’en arrière-plan CSS.

Gérer l’accessibilité du sélecteur sur-mesure

Construire son propre sélecteur signifie aussi reprendre à son compte les bonnes pratiques d’accessibilité que le widget natif applique déjà. Chaque lien doit porter un attribut hreflang cohérent avec la langue ciblée, et la langue actuellement affichée gagne à être annoncée visuellement autrement que par une simple couleur, pour rester perceptible aux utilisateurs de lecteurs d’écran.

Un sélecteur de langue fait maison n’est jamais un chantier fermé : je le considère comme une fonction du thème à part entière, versionnée et testée, au même titre que le menu principal du site.

Pour aller plus loin

Sortir du widget natif de Polylang pour composer son propre sélecteur ne demande que trois fonctions PHP bien maîtrisées : pll_the_languages() en mode brut pour la liste complète, pll_current_language() et pll_home_url() pour des besoins ponctuels. Cette approche donne un contrôle total sur le balisage tout en restant entièrement compatible avec les mises à jour futures de l’extension, puisqu’elle repose uniquement sur son API publique documentée.