« Ne t’inquiète pas, WordPress gère toutes les langues. » C’est la remarque qu’a reçue une petite maison d’édition du Finistère quand elle a annoncé vouloir publier une partie de son catalogue en breton, en plus du français. La remarque n’était pas fausse sur le fond — WordPress lui-même n’impose aucune limite d’alphabet — mais elle passait à côté du vrai problème : ce n’est pas WordPress qui pose difficulté avec le breton, ce sont les outils périphériques construits autour, pensés pour des langues bien plus dotées en ressources numériques.
Cet article revient sur les limites concrètement rencontrées, pas pour décourager ce type de projet, mais pour que la prochaine structure qui s’y attelle sache où porter son attention en priorité.
Le premier obstacle : aucun correcteur orthographique fiable
Le breton ne bénéficie d’aucun dictionnaire intégré aux correcteurs orthographiques des navigateurs ou des suites bureautiques les plus répandues. Les rédacteurs qui saisissaient leurs textes directement dans l’éditeur WordPress voyaient chaque mot souligné en rouge, ce qui rendait la relecture visuelle pénible et masquait les vraies fautes de frappe au milieu du bruit. La solution retenue a été d’installer un dictionnaire de correction communautaire disponible pour certains navigateurs, mais sa couverture restait partielle sur le vocabulaire technique du secteur de l’édition.
La traduction automatique, un outil qui aide peu ici
Les moteurs de traduction automatique grand public, DeepL en tête depuis son lancement en 2017, ne proposent pas le breton parmi leurs langues cibles : le volume de textes bilingues disponibles pour entraîner ce type de système reste trop faible face aux grandes langues européennes. Là où une équipe traduisant vers l’espagnol ou l’allemand aurait pu s’appuyer sur une traduction automatique comme point de départ à corriger, l’équipe bretonnante devait partir d’une feuille blanche à chaque texte.
Le clavier et la saisie des caractères propres au breton
Le breton utilise des caractères et des combinaisons peu fréquents en français standard, notamment le c'h qui représente un son distinct et doit impérativement conserver son apostrophe typographique, différente de l’apostrophe droite utilisée par erreur dans certains claviers. Une confusion entre les deux apostrophes rendait certains mots méconnaissables pour les moteurs de recherche interne du site, qui ne normalisaient pas ce caractère avant indexation.
// Normalisation appliquée avant indexation par la recherche interne
function normaliser_apostrophe_bretonne( $texte ) {
return str_replace(
array( "\u{2019}", "'" ), // apostrophe typographique et apostrophe droite
"'",
$texte
);
}
add_filter( 'relevanssi_content_to_index', 'normaliser_apostrophe_bretonne' );Les polices d’écriture et les signes diacritiques rares
Certains signes diacritiques utilisés dans des variantes orthographiques du breton (le tilde sur le ñ dans certains toponymes, par exemple) n’étaient pas toujours rendus correctement par la police de titre choisie par le thème, qui ne couvrait qu’un jeu de caractères latin de base. Un test systématique de chaque police retenue sur un échantillon de textes bretons réels, avant intégration définitive au thème, aurait évité une correction tardive et coûteuse.
- Vérifier la couverture Unicode réelle d’une police avant de l’adopter pour un site multilingue.
- Tester la recherche interne avec des mots contenant les caractères spécifiques de chaque langue publiée.
- Prévoir une relecture humaine systématique : aucun correcteur automatique ne la remplace ici.
Ce qui a fonctionné malgré tout
Malgré ces limites d’outillage, la structure interne de WordPress n’a posé aucun problème particulier : Polylang a géré sans difficulté la déclaration du breton comme langue à part entière, avec son propre drapeau personnalisé et son propre fichier de traduction pour l’interface du site. Le vrai travail supplémentaire s’est concentré entièrement en amont, sur la qualité de la saisie et la relecture, pas sur la configuration technique du site lui-même.
Publier dans une langue peu dotée en outils numériques ne change rien à l’architecture du site ; cela change entièrement le temps à prévoir pour la relecture humaine.
En résumé
WordPress et ses extensions de traduction n’imposent aucune limite d’alphabet ou de langue. Les limites viennent des outils périphériques — correcteurs orthographiques, traduction automatique, polices — qui restent calibrés pour les langues les mieux dotées en ressources numériques. Une structure qui publie dans une langue régionale doit budgétiser ce déséquilibre dès le départ, en temps de relecture humaine plutôt qu’en configuration technique.
