Gestion de contenu multilingue en PHP : modèle et flux éditorial

Une application multilingue ne consiste pas seulement à traduire les libellés de l’interface. Si elle propose aussi des articles, des fiches produit ou d’autres ressources éditoriales, elle doit représenter la langue de chaque contenu, les liens entre ses différentes versions et ce que signifie le fait qu’une traduction soit prête à être publiée. Un modèle imprécis finit par afficher des textes obsolètes, des liens sans destination ou des brouillons à des utilisateurs qui ne devraient pas les voir.

Pour planifier la gestion de contenu multilingue en PHP, il est utile de distinguer les décisions liées à l’interface, aux données et au flux éditorial. L’implémentation peut s’appuyer sur des fichiers de traduction pour l’interface et sur la base de données pour le contenu variable, mais cette répartition doit répondre au domaine et aux besoins des personnes qui éditent le contenu.

Distinguer la langue de l’interface, la langue d’origine et la traduction

La langue de l’interface détermine les libellés, les messages de validation, les formats de date et les autres textes propres au produit. Dans une application PHP, elle peut être gérée à l’aide de catalogues de traduction, par exemple des fichiers organisés par locale, puis sélectionnée en fonction des préférences de l’utilisateur ou d’une configuration de session. Il ne faut pas la confondre avec la langue du contenu consulté.

La langue d’origine identifie, quant à elle, la langue dans laquelle une ressource éditoriale a été créée. Chaque traduction est une version associée à cette ressource et possède sa propre langue. Un utilisateur peut parcourir l’interface en espagnol et ouvrir une page dont le contenu original est en anglais ; l’application doit explicitement décider si cela est autorisé et comment le signaler.

Enregistrez des codes de langue normalisés et appliquez une politique cohérente pour les locales régionales lorsque cela est nécessaire. Ne partez pas du principe que langue et pays sont interchangeables : une variante régionale peut avoir une incidence sur le texte, mais aussi sur les formats, la disponibilité ou les exigences commerciales. Définissez les locales prises en charge par le produit et celles utilisées pour résoudre une préférence incomplète.

Choisir un modèle de données qui représente le domaine

Trois modèles courants présentent des compromis différents :

• Champs par langue : des colonnes comme title_es et title_en sont simples à gérer lorsqu’il y a peu de langues, un ensemble stable de champs et des requêtes directes. Elles perdent en flexibilité lorsque de nouvelles langues sont ajoutées et font dépendre chaque modification de schéma du catalogue des langues.
• Enregistrements indépendants : chaque version est enregistrée comme une ressource distincte. Ce choix peut convenir si les versions ont des cycles de vie ou des structures réellement indépendants, mais il faut alors un autre moyen fiable de les regrouper. N’utilisez pas un titre similaire ou une URL comme lien implicite.
• Table de traductions liée : une ressource commune est associée à une ligne par langue, par exemple au moyen de content_id et de locale. Cela facilite l’ajout de langues et la consultation des versions disponibles. Des contraintes sont nécessaires pour empêcher la création de plusieurs traductions dans la même langue pour une ressource.

La table liée est souvent adaptée lorsque les versions partagent une identité et une structure, mais ce n’est pas une règle universelle. Si certains champs ne sont pas traduits — une référence interne, par exemple — ils peuvent rester dans l’entité commune ; les champs éditoriaux localisés sont placés dans la traduction. Précisez également si une traduction peut avoir sa propre URL, ses propres métadonnées de recherche ou sa propre date de publication.

Dans la base de données, définissez des clés étrangères, l’unicité par ressource et par langue, ainsi que le comportement lors de la suppression des données. La logique applicative en PHP doit également vérifier que la langue est prise en charge et que la ressource associée existe. Les contraintes de base de données protègent contre les écritures concurrentes et les erreurs qu’une validation préalable, à elle seule, ne peut pas éviter.

Relier les versions sans exiger qu’elles soient toutes présentes

Toutes les ressources n’existeront pas dans toutes les langues, et toutes les traductions ne seront pas terminées au même moment. Modélisez cette réalité : l’absence d’une ligne ne doit pas être interprétée comme une erreur d’intégrité si la traduction est facultative. En revanche, un état éditorial doit indiquer ce qui se passe lorsqu’une ligne existe, mais que son contenu ne peut pas encore être publié.

Évitez de dupliquer dans chaque traduction des informations qui appartiennent à la ressource partagée, sauf si le domaine exige des variantes. Si les traductions peuvent être dissociées, déplacées ou conservées comme archive, définissez ces opérations et les autorisations correspondantes. Pour identifier le groupe de versions, utilisez une relation stable, et non des correspondances de texte, de slug ou de date.

Lorsqu’une traduction est modifiée, enregistrez la version de l’original qui a servi de référence si l’équipe a besoin de détecter les contenus potentiellement obsolètes. Ce signal ne prouve pas à lui seul que la traduction est incorrecte ; il permet de prioriser une révision. Pour certains produits, un indicateur de révision en attente suffira, tandis que d’autres nécessiteront un historique des versions et un audit.

Définir des états éditoriaux par langue

L’état de publication doit appartenir à chaque traduction lorsque chaque langue peut être rédigée, révisée et publiée indépendamment. Une ressource peut être publiée dans une langue et rester à l’état de brouillon dans une autre. Un seul booléen de publication au niveau de la ressource ne représente pas cette différence.

Concevez un flux réduit et explicite, comprenant par exemple les états brouillon, en révision et publié. Définissez qui peut modifier chaque état, quels champs sont obligatoires et si une révision nécessite une approbation. La date de publication, la personne responsable et l’historique des modifications peuvent être nécessaires au fonctionnement du processus ; évitez d’ajouter des états qui ne correspondent à aucune action réelle de l’équipe.

Les requêtes publiques doivent filtrer par état et par langue, sans compter sur l’interface éditoriale pour masquer les lignes non publiées. En PHP, centralisez ces règles dans une couche d’accès au domaine ou dans des requêtes réutilisables, et vérifiez que les contrôleurs, l’API et les tâches en arrière-plan les respectent. Les actions de modification et de publication doivent également vérifier les autorisations pour la langue et la ressource concernées.

Gérer les absences, les URL et la recherche de manière cohérente

Lorsqu’une traduction manque, plusieurs politiques sont possibles. L’application peut masquer la ressource dans cette langue, indiquer qu’elle n’existe que dans une autre langue ou afficher un contenu de remplacement. Faites votre choix en fonction du type de contenu et de ses effets sur l’expérience utilisateur ; un contenu de remplacement ne doit pas être présenté comme s’il s’agissait d’une traduction. Si du contenu dans une autre langue est affiché, indiquez-le clairement et permettez toujours de revenir à la version demandée.

Appliquez une règle différente à l’interface et au contenu. Le fait que les libellés de navigation puissent utiliser un autre catalogue comme contenu de remplacement ne signifie pas que les articles doivent être automatiquement remplacés par leur version originale. Le contenu éditorial de remplacement doit être limité aux langues autorisées et au contenu publiable, et ne doit pas renvoyer de brouillons.

Les URL doivent identifier une version réelle ou suivre une règle de redirection documentée. Lors d’un changement de langue, recherchez la traduction de la même ressource ; si elle n’existe pas, proposez une solution explicite au lieu de construire une URL qui semble valide. Pour le SEO, évitez de publier des pages vides ou dupliquées à cause de contenus de remplacement invisibles. La recherche doit indexer uniquement les versions admissibles et utiliser la langue correspondante pour filtrer et présenter les résultats.

Liste de contrôle avant publication

• La langue de l’interface, la langue d’origine et la langue de chaque traduction sont-elles des concepts distincts dans le modèle ?
• Est-il impossible d’enregistrer deux traductions d’une même ressource dans la même langue ?
• Une traduction peut-elle être absente sans créer un état incohérent ?
• L’équipe peut-elle distinguer les états brouillon, révision et publication pour chaque langue ?
• Les routes publiques et les liens de changement de langue vérifient-ils qu’une version visible existe ?
• Le contenu de remplacement est-il défini selon le cas d’utilisation, signalé à l’utilisateur et ne révèle-t-il jamais de brouillons ?
• La recherche filtre-t-elle par langue et par état, et cesse-t-elle d’indexer une version retirée ?
• Les autorisations, les modifications concurrentes, la suppression, les contenus incomplets et les changements de langue ont-ils été testés ?

Testez également le retrait d’une traduction déjà liée, la mise à jour de l’original après la publication d’une version et l’accès direct à une URL indisponible. Dans chaque cas, vérifiez la réponse, la navigation et la visibilité dans les résultats de recherche. L’objectif n’est pas d’imposer le même rythme à toutes les langues, mais de donner à chaque version une identité, un état vérifiable et un comportement prévisible pour les éditeurs comme pour les utilisateurs.