Ce que fait réellement l’attribut translate
Deux valeurs seulement existent pour cet attribut universel du HTML : yes, la valeur par défaut implicite de tout élément, et no, qui indique explicitement à un agent de traduction automatique de laisser le contenu de l’élément tel quel. Il ne s’agit pas d’une invention WordPress ni d’un attribut propriétaire à une extension multilingue : c’est une propriété du standard HTML, reconnue par les navigateurs qui embarquent une fonction de traduction et par les services qui analysent une page pour la traduire à la volée. Sur un site WordPress affichant un nom de marque, un nom de produit ou un acronyme technique, l’ajouter directement dans le balisage évite qu’un visiteur qui active la traduction automatique de son navigateur ne voie ce nom transformé en un mot qui n’a plus de sens.
Concrètement, la pose se fait sur la balise qui entoure le texte à protéger :
<p>Notre agence utilise <span translate="no">WP Moderne</span> au quotidien.</p>Le navigateur qui traduit la phrase laissera intact le contenu du span, tout en traduisant normalement le reste de la phrase autour. C’est une différence de comportement importante par rapport à une simple absence de traduction du paragraphe entier : seul le fragment marqué est épargné.
Portée HTML et héritage
L’attribut suit les règles d’héritage classiques du HTML : posé sur un élément parent, il s’applique à tous les descendants qui n’affichent pas eux-mêmes un attribut translate contradictoire. Cela permet de protéger un bloc entier, comme un encart de code ou une liste de références techniques, sans devoir baliser chaque mot individuellement.
<div translate="no">
<p>Nom de code interne : Falcon-9x</p>
<p>Référence produit : WPM-2024-A</p>
</div>À l’inverse, un sous-élément peut réactiver la traduction avec translate="yes", ce qui est utile lorsqu’un bloc technique contient malgré tout une phrase d’explication en langage courant destinée, elle, à être traduite normalement pour le visiteur.
Différence avec la balise meta notranslate
Beaucoup de développeurs confondent cet attribut avec la balise meta qui existe pour Google Traduction, déjà traitée ailleurs sur ce blog dans son fonctionnement au niveau de la page entière. Cette dernière agit à l’échelle du document complet : elle indique au service qu’aucune partie de la page ne doit être traduite. L’attribut translate, lui, agit à la granularité de l’élément HTML choisi, ce qui permet un contrôle bien plus fin. Sur un site WordPress multilingue où seule une poignée de termes doit rester intacte au milieu d’un contenu par ailleurs entièrement traduit, la meta de page est inutilisable : elle bloquerait la traduction de tout le reste. L’attribut ciblé est alors la seule option pertinente.
Un attribut mal placé sur un conteneur trop large protège un nom de marque, mais rend aussi intraduisible tout un paragraphe qui n’avait rien demandé.
Cette remarque maison résume le piège le plus fréquent constaté sur des templates de thème : un développeur pose translate="no" sur un div englobant par prudence, sans mesurer que ce conteneur héberge aussi le texte descriptif du produit, qui lui devrait rester traduisible.
Cas concret : protéger un nom de marque dans un composant WordPress
Dans un thème block-based ou dans un template classique, le nom d’une marque apparaît souvent dans un logo textuel, un pied de page ou une signature d’article. Voici un exemple d’intégration dans une fonction de rendu de pied de page :
function wpm_afficher_credit() {
printf(
'<p>Site propulsé par <span translate="no">%s</span>.</p>',
esc_html( 'WP Moderne' )
);
}La combinaison avec esc_html() reste indispensable : l’attribut ne dispense d’aucune règle d’échappement, il ajoute simplement une instruction destinée aux agents de traduction. Un piège fréquent consiste à l’appliquer sur un contenu généré dynamiquement à partir d’une saisie utilisateur, en pensant protéger une donnée sensible : l’attribut n’a aucun effet de sécurité, il n’empêche ni l’injection de script, ni l’affichage d’un contenu malveillant, il agit uniquement sur le comportement de traduction du navigateur.
- Le poser sur le nom exact d’une marque, d’un produit ou d’un acronyme technique amené à apparaître identique dans toutes les langues.
- Éviter de l’appliquer à un conteneur qui mélange nom propre et texte descriptif traduisible.
- Ne jamais compter dessus pour une protection de sécurité ou d’accessibilité : il reste un signal de traduction, rien de plus.
Quand ne pas l’utiliser : sur un site qui ne propose aucune traduction, automatique ou humaine, l’attribut n’a strictement aucun effet visible et n’a pas lieu d’être ajouté systématiquement à chaque nom propre par réflexe. Il devient utile uniquement lorsque le site est réellement consulté par des visiteurs susceptibles d’activer une traduction de navigateur, ou lorsqu’un service tiers de traduction automatique est branché en façade du site.
Conclusion
Un attribut HTML standard, sans dépendance, réglé finement au niveau de l’élément plutôt qu’au niveau de la page, protège efficacement un nom propre d’une traduction automatique malvenue. Sa simplicité ne dispense pas de la rigueur : bien cibler l’élément porteur évite de sur-protéger un paragraphe entier au détriment de l’expérience des visiteurs qui comptent justement sur la traduction automatique pour lire le reste du contenu.
