Un fabricant de composants industriels, présent en France, en Allemagne et en Pologne, avait besoin d’un site vitrine où la structure de page reste identique d’un pays à l’autre, mais où certains blocs (mentions réglementaires, unités de mesure, formulaire de demande de devis) nécessitent un rendu spécifique par langue. Le choix technique s’est porté sur Timber pour la couche de gabarits, avec une hiérarchie de dossiers pensée dès le départ pour cette contrainte de surcharge partielle.
Ce schéma d’organisation ne traite pas du rendu JavaScript côté client, absent de ce projet qui reste un rendu serveur classique : il se concentre uniquement sur l’arborescence de fichiers Twig et la logique de résolution utilisée par Timber pour choisir le bon gabarit selon la langue active.
Le constat de départ : dupliquer, ce n’est pas maintenir
La première approche envisagée par l’équipe consistait à dupliquer intégralement chaque gabarit Twig pour chaque langue, dans des dossiers séparés fr/, de/, pl/. Cette approche a été abandonnée dès les premiers tests : la moindre modification de mise en page devait être répercutée manuellement dans trois fichiers distincts, avec un risque d’oubli à chaque itération, en particulier sur un projet où les évolutions de gabarit restaient fréquentes durant les premiers mois.
- Duplication complète : risque élevé d’oubli lors des modifications ultérieures
- Aucune garantie de cohérence structurelle entre les trois versions linguistiques
- Effort de maintenance multiplié par le nombre de langues, sans bénéfice réel
L’arborescence retenue : socle commun et surcharges ciblées
La solution retenue place les gabarits communs dans un dossier views/ classique, et n’isole dans des sous-dossiers par langue que les fragments réellement spécifiques à chaque marché :
views/
├── base.twig
├── page-produit.twig
├── partials/
│ ├── fil-ariane.twig
│ ├── formulaire-devis.twig
│ └── mentions-reglementaires.twig
└── overrides/
├── de/
│ └── partials/
│ ├── formulaire-devis.twig
│ └── mentions-reglementaires.twig
└── pl/
└── partials/
└── mentions-reglementaires.twig
Sur cette structure, le gabarit page-produit.twig n’existe qu’une seule fois, commun aux trois langues. En revanche, formulaire-devis.twig possède une surcharge spécifique pour l’allemand (champs supplémentaires exigés par les acheteurs industriels allemands), tandis que le polonais utilise le gabarit commun sans modification.
La fonction de résolution du bon fragment
Une fonction utilitaire, appelée en tête de chaque gabarit parent, détermine le chemin du fragment à charger en fonction de la langue active, avec repli automatique vers le fragment commun si aucune surcharge n’existe pour cette langue :
function resoudre_fragment( $nom_fragment ) {
$langue = pll_current_language();
$chemin_surcharge = "overrides/{$langue}/partials/{$nom_fragment}.twig";
if ( file_exists( get_template_directory() . '/views/' . $chemin_surcharge ) ) {
return $chemin_surcharge;
}
return "partials/{$nom_fragment}.twig";
}
Les mentions réglementaires, cas d’usage le plus fréquent
Le fragment mentions-reglementaires.twig a nécessité une surcharge pour l’allemand comme pour le polonais, chacune adaptée aux exigences locales de certification des composants industriels. C’est précisément ce type de contenu, sensible et propre à chaque marché, que ce schéma d’organisation permet d’isoler sans complexifier le reste de la structure de gabarits.
| Fragment | Surcharge allemande | Surcharge polonaise |
|---|---|---|
| Formulaire de devis | Oui, champs supplémentaires | Non, gabarit commun |
| Mentions réglementaires | Oui | Oui |
| Fil d’Ariane | Non, gabarit commun | Non, gabarit commun |
Ce que la logique métier n’a pas à connaître
Un point de conception important : les fonctions PHP qui préparent les données transmises aux gabarits (récupération des caractéristiques produit, calcul du prix selon la zone) ignorent complètement l’existence de ces surcharges. Elles fournissent toujours le même contexte de données à Timber, quelle que soit la langue ; seule la couche de présentation Twig décide du fragment à afficher. Cette séparation stricte a évité que la logique métier ne se retrouve polluée par des conditions liées à la langue, dispersées dans tout le code.
Une règle que je retiens de ce projet : la langue doit rester une décision de présentation autant que possible, jamais une ramification de la logique métier elle-même.
Bilan de cette organisation
Cette organisation en socle commun et surcharges ciblées a permis de maintenir un rythme d’évolution rapide sur les gabarits communs, sans jamais risquer d’oublier une langue lors d’une modification, tout en isolant clairement les quelques fragments réellement spécifiques à un marché. Pour un site multilingue avec Timber, c’est un schéma bien plus robuste qu’une duplication complète de l’arborescence par langue.
