# Synchroniser une billetterie d’événement culturel sans doublon de calendrier

> Étapes concrètes pour garder une seule source de vérité sur les dates et lieux d'un événement traduit en plusieurs langues, sans créer de calendrier fantôme.

- Auteur : WordPress Développement
- Publié le : 2024-01-11
- Mis à jour le : 2024-01-11
- Catégorie : Multilingue
- URL : https://www.wpmoderne.fr/multilingue/billetterie-evenement-sync-calendrier-langues/

## L’essentiel

- Une session d'événement = un objet, jamais un par langue
- Les créneaux et lieux restent des données partagées, pas traduites
- Un contrôle avant publication évite les doublons de date

Comment éviter que la version anglaise d'un concert affiche une date différente de la version française du même concert ? C'est la question posée par une salle de spectacle qui venait d'ouvrir sa billetterie en ligne à un public international, avec Polylang installé pour gérer le contenu éditorial du site autour de la programmation.

Le problème ne vient presque jamais du plugin de traduction lui-même, mais de la façon dont les données d'un événement sont modélisées. Ce tutoriel détaille la structure à mettre en place pour qu'une billetterie multilingue ne génère jamais deux calendriers divergents.

## Étape 1 : séparer contenu traduisible et données partagées

Un événement se compose de deux familles de données très différentes : d'un côté le contenu éditorial (titre, description, biographie de l'artiste), qui doit être traduit ; de l'autre les données factuelles (date, heure, lieu, capacité de la salle, prix), qui doivent rester strictement identiques quelle que soit la langue consultée.

La première étape consiste à déclarer un type de contenu `seance` dont les champs éditoriaux sont traduisibles via Polylang, mais dont les champs factuels sont gérés par un champ ACF de type relation pointant vers un objet `evenement_source` unique, non traduit, qui porte la date, le lieu et la capacité.

## Étape 2 : verrouiller la synchronisation des champs partagés

Dans les réglages de Polylang, la synchronisation des métadonnées permet de forcer certains champs ACF à rester identiques entre toutes les traductions d'un même contenu. On y coche les champs `date_evenement`, `lieu` et `capacite` :

```
add_filter( 'pll_copy_post_metas', function ( $metas ) {
    $metas[] = 'date_evenement';
    $metas[] = 'lieu';
    $metas[] = 'capacite';
    return $metas;
} );
```

Avec ce filtre, toute modification de la date sur la fiche française se répercute automatiquement sur la fiche anglaise lors de l'enregistrement, sans intervention manuelle du programmateur.

> L'essentiel à retenir : Une session d'événement = un objet, jamais un par langue ; Les créneaux et lieux restent des données partagées, pas traduites ; Un contrôle avant publication évite les doublons de date

## Étape 3 : brancher la billetterie sur l'objet source, pas sur la traduction

Le système de réservation ne doit jamais interroger l'ID de la traduction affichée, mais toujours l'ID de l'`evenement_source` partagé. C'est ce détail qui évite le doublon de calendrier : si la billetterie créait un panier de réservation par ID de traduction, deux personnes réservant la même séance dans deux langues différentes videraient deux stocks de places distincts pour la même salle physique.

1. Récupérer l'ID de l'objet source associé à la séance affichée, quelle que soit sa langue.
2. Interroger le stock de places disponibles sur cet ID source, jamais sur l'ID de la traduction.
3. Décrémenter ce même stock partagé à chaque réservation confirmée.

## Étape 4 : afficher la bonne date dans la bonne langue

Une fois la source de vérité unique en place, il reste à formater l'affichage de la date selon la langue courante, sans toucher à la valeur stockée :

```
$date = get_field( 'date_evenement', $evenement_source_id );
$formateur = new IntlDateFormatter(
    pll_current_language( 'locale' ),
    IntlDateFormatter::LONG,
    IntlDateFormatter::SHORT
);
echo esc_html( $formateur->format( strtotime( $date ) ) );
```

`IntlDateFormatter`, disponible via l'extension PHP `intl`, gère nativement les conventions de date propres à chaque locale sans qu'il soit nécessaire de traduire la date elle-même.

## Étape 5 : verrouiller la publication avec un contrôle avant mise en ligne

Une dernière garantie : un contrôle automatisé, exécuté avant chaque publication, compare les champs synchronisés de toutes les traductions d'un même événement et bloque la mise en ligne si un écart est détecté. Ce filet de sécurité a évité, sur ce projet, deux publications accidentelles où un programmateur avait modifié une date directement en base sans repasser par le formulaire.

> Une billetterie multilingue ne se pense pas en « pages traduites », mais en « données partagées habillées de contenu traduit ». Inverser cette logique, c'est ouvrir la porte aux doublons de calendrier.

## Pour aller plus loin

Cette architecture se généralise à d'autres cas où plusieurs langues décrivent un même fait immuable : un festival avec plusieurs dates, une formation avec plusieurs sessions, ou un salon professionnel avec plusieurs créneaux. Le principe reste identique : une seule source de vérité factuelle, autant d'habillages éditoriaux que de langues.