Négociation de contenu

Une page traduite en français ou en anglais, une réponse d’API en JSON ou en XML : plusieurs formes légitimes peuvent coexister derrière une seule et même adresse. Plutôt que de créer une URL distincte pour chaque variante, HTTP prévoit que le client indique ses préférences dans des en-têtes de requête (Accept, Accept-Language), et laisse le serveur choisir, parmi ce qu’il sait produire, la version la plus adaptée.

Application dans WordPress

L’API REST de WordPress s’appuie sur l’en-tête Accept pour décider du format de réponse, JSON étant en pratique la seule option couramment supportée nativement. Côté contenu multilingue, un plugin comme Polylang ou WPML peut lire l’en-tête Accept-Language envoyé par le navigateur pour proposer automatiquement la langue la plus proche des préférences du visiteur, avant même qu’il n’ait cliqué sur un sélecteur de langue.

Exemple

GET /wp-json/wp/v2/posts/42 HTTP/1.1
Accept: application/json
Accept-Language: fr-FR, fr;q=0.9, en;q=0.5

Le facteur q exprime une préférence relative : ici le français est nettement préféré à l’anglais.

Bon à savoir

• La négociation de contenu reste une proposition : rien n’oblige un serveur à honorer la préférence du client s’il ne dispose pas du format ou de la langue demandés.
• Pour le SEO multilingue, il est généralement recommandé de garder des URL distinctes par langue plutôt que de se reposer uniquement sur Accept-Language, plus difficile à indexer pour un moteur de recherche.
• À ne pas confondre avec la simple détection de langue côté navigateur (attribut lang du HTML), qui décrit la langue du contenu envoyé, pas une négociation avec le serveur.