Le WordPress d'aujourd'hui, décodé pour les développeurs

Multilingue

Sélecteur de langue en pur PHP pour un site bilingue d’agence immobilière

Deux langues, zéro extension lourde : un sélecteur de langue en PHP natif, basé sur une variable de requête et un cookie, suffit pour un site vitrine bilingue.

Par WordPress Développement • 17 juillet 2020 • 4 min de lecture • Aucun commentaire
Sélecteur de langue en pur PHP pour un site bilingue d'agence immobilière

Deux langues, un catalogue de biens qui change peu d’une semaine à l’autre, et un budget qui ne prévoit pas l’achat d’une extension multilingue premium : c’est le point de départ d’un sélecteur de langue écrit à la main, sans dépendance externe, pour une agence immobilière proposant ses annonces en français et en anglais.

La solution tient en une quarantaine de lignes de PHP, exploitables dans le fichier functions.php d’un thème enfant. Elle ne remplace pas un système de traduction complet, mais elle couvre parfaitement un cas fréquent : un nombre de langues fixe, un contenu qui se duplique manuellement plutôt qu’il ne se synchronise automatiquement.

Le problème à résoudre

Le site utilise un type de contenu personnalisé bien_immobilier pour chaque annonce. Chaque fiche existe en deux versions : une en français, une en anglais, saisies comme deux articles distincts reliés entre eux par un champ personnalisé stockant l’identifiant de l’article correspondant dans l’autre langue. Il faut :

  • détecter la langue choisie par le visiteur et la mémoriser d’une visite à l’autre
  • rediriger vers la fiche liée quand le visiteur change de langue sur une fiche donnée
  • afficher un sélecteur simple dans l’en-tête, sans dépendre d’un widget tiers

Le snippet commenté

La détection s’appuie sur une variable de requête lang et un cookie de secours pour les visites suivantes :

function agence_get_langue_courante() {
    if ( isset( $_GET['lang'] ) && in_array( $_GET['lang'], array( 'fr', 'en' ), true ) ) {
        setcookie( 'agence_lang', $_GET['lang'], time() + WEEK_IN_SECONDS, '/' );
        return $_GET['lang'];
    }
    if ( isset( $_COOKIE['agence_lang'] ) && in_array( $_COOKIE['agence_lang'], array( 'fr', 'en' ), true ) ) {
        return $_COOKIE['agence_lang'];
    }
    return 'fr';
}

function agence_lien_fiche_liee( $post_id, $langue_cible ) {
    $id_lie = get_post_meta( $post_id, 'fiche_liee_' . $langue_cible, true );
    return $id_lie ? get_permalink( $id_lie ) : home_url( '/' . $langue_cible . '/' );
}

La fonction agence_get_langue_courante() est appelée en tête de gabarit pour conditionner l’affichage des textes fixes (« Contactez-nous » devient « Contact us »), tandis que agence_lien_fiche_liee() construit le lien du sélecteur à partir du champ personnalisé rempli manuellement par l’agent lors de la saisie de chaque fiche.

L'essentiel à retenir : Une variable de requête et un cookie suffisent pour deux langues fixes ; Le contenu se duplique via des champs personnalisés, pas via un plugin ; Solution adaptée à un catalogue de biens stable, pas à un blog actif

Le sélecteur dans le gabarit d’en-tête

Dans header.php, l’affichage se résume à une liste de deux liens, sans widget ni marqueur JavaScript superflu :

<ul class="langues">
  <li><a href="<?php echo esc_url( agence_lien_fiche_liee( get_the_ID(), 'fr' ) ); ?>">FR</a></li>
  <li><a href="<?php echo esc_url( agence_lien_fiche_liee( get_the_ID(), 'en' ) ); ?>">EN</a></li>
</ul>

Variantes possibles

Plusieurs ajustements restent envisageables selon les besoins du client :

  1. remplacer le cookie par la détection de l’en-tête Accept-Language du navigateur pour une langue par défaut plus pertinente à la première visite
  2. ajouter une troisième langue en étendant simplement le tableau array( 'fr', 'en' ) et les champs personnalisés associés
  3. stocker la relation entre fiches dans une table personnalisée plutôt que dans des métadonnées, si le nombre de fiches dépasse plusieurs centaines

La dernière variante mérite réflexion : au-delà d’un catalogue conséquent, la saisie manuelle du champ fiche_liee_en devient une source d’erreur humaine, et un outil dédié reprend alors tout son sens.

Une règle simple guide ce choix : tant que la liste des langues ne dépasse pas deux ou trois entrées fixes et que le volume de contenu reste maîtrisable à la main, le PHP natif évite une dépendance et une charge de maintenance inutiles.

Notre verdict

Pour une agence immobilière avec un catalogue stable et deux langues bien identifiées, ce sélecteur artisanal tient parfaitement la route et évite l’empilement d’une extension supplémentaire sur un thème déjà chargé de fonctionnalités métier. La limite apparaît dès que le contenu éditorial se densifie ou qu’une troisième langue s’ajoute avec des besoins de synchronisation plus fins : à ce stade, une extension dédiée reprend l’avantage sur la simplicité initiale du code maison.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi