Skip to main content
Construire un site bilingue (français + anglais) au-dessus de Le Commis demande quelques précautions, principalement autour du cache et du repli. Voici les règles à suivre.

​
Une requête par locale

Le contenu diffère par langue : faites un appel par locale pour chaque endpoint menus. 
curl -s "https://app.lecommis.fr/api/v1/establishments/au-bistrot/menus/menu-du-midi?locale=fr" \
  -H "X-Api-Key: $LECOMMIS_API_KEY"
Les endpoints establishment et hours ne sont pas localisés : un seul appel suffit, partagé entre vos pages fr et en.

​
Afficher la langue réellement reçue

À cause du repli en → fr, une réponse en peut contenir du texte français pour les champs non traduits. Affichez le texte tel qu’il arrive ; ne le rejetez pas et ne le masquez pas parce qu’il « n’a pas l’air anglais ». Côté markup, vous pouvez annoter au niveau du champ si la langue compte pour vous (lang="fr" sur un libellé retombé en français), mais ne vous fiez pas à un champ d’API pour deviner la langue d’un item.

​
Ne pas supposer la parité fr/en sur les fichiers du menu

Les fichiers du menu ne se replient pas (voir Comportement de repli). Avant d’afficher un visuel anglais :
  1. Lisez le language_scope de chaque fichier (fr, en ou fr_en).
  2. N’affichez l’URL /r/menus?...&locale=en que si un fichier couvre en ou fr_en.
  3. Prévoyez le 404 : masquez le visuel ou retombez côté intégrateur sur la version fr.
Choisir le fichier à afficher
function pickAsset(assets, locale) {
  return assets.find(
    (a) => a.language_scope === locale || a.language_scope === "fr_en"
  );
  // -> undefined si aucun asset ne couvre la locale : ne pas construire d'URL EN.
}

​
Cache, builds et webhooks

C’est le point le plus important pour un site multilingue.
content_revision est commun à toutes les locales : un même établissement a la même valeur en fr et en en. Une seule notification de changement invalide donc les deux langues à la fois.
Conséquences concrètes :
  • Mettez la locale dans votre clé de cache. Le contenu diffère par langue, pas la révision. Une clé du type establishment_slug + ":" + menu_type_slug + ":" + locale + ":" + content_revision évite de servir du fr là où vous attendez de l’en.
  • Une notif establishment.content_updated invalide fr ET en. À la réception du webhook, purgez (ou re-fetchez) les deux locales, pas seulement celle qui a déclenché le changement — le payload ne distingue pas la langue.
  • Comparez la révision pour éviter les re-fetch inutiles. Stockez la dernière content_revision connue et ne reconstruisez que si la nouvelle valeur est supérieure.
Exemple de clé de cache
au-bistrot:menu-du-midi:en:67
└── slug      └── menu     └── locale └── content_revision
La locale doit faire partie de la clé de cache, pas la content_revision qui est partagée entre fr et en. Sans la locale dans la clé, une entrée fr et une entrée en se télescopent et vous risquez de servir la mauvaise langue.

​
Schéma de build incrémental

1

Build initial

Pour chaque locale (fr, en), récupérez les menus, mémorisez content_revision.
2

Réception webhook

establishment.content_updated arrive avec une content_revision plus élevée et la liste changed_resources.
3

Invalidation

Purgez le cache des deux locales pour les ressources concernées, puis re-fetchez.
4

Rebuild

Régénérez les pages fr et en avec les nouvelles données, et mémorisez la nouvelle révision.

​
Pour aller plus loin

content_revision

Le compteur monotone commun à toutes les locales pour invalider votre cache.

Webhooks

Recevoir establishment.content_updated et savoir quoi re-lire.