Générateur de slugs

Ce que fait cet outil

Collez un titre dans n’importe quelle écriture et il revient sous la forme du slug qu’une URL peut porter : minuscules, sans ponctuation, mots reliés par le séparateur que vous choisissez. Les accents latins sont retirés, et l’hébreu, l’arabe, le cyrillique et le grec sont translittérés en lettres latines.

À côté du slug se trouve le même titre conservé dans sa propre écriture. Cette forme est un chemin légal elle aussi, et pour les écritures qui perdent le plus à la translittération elle est souvent la meilleure réponse — les deux sont donc produites à partir d’un seul titre plutôt que l’outil ne choisisse à votre place.

À quoi sert un slug

Un slug est la partie lisible d’une URL : le morceau après la dernière barre oblique qui nomme la page au lieu de la numéroter. Il existe parce qu’un chemin qui se lit comme des mots survit à être collé dans un message, imprimé sur une diapositive ou lu à voix haute au téléphone, ce qu’un identifiant numérique ne fait pas.

C’est aussi pourquoi sa forme est si contrainte. Un slug doit être stable — le changer casse tous les liens qui pointent déjà vers la page — et il doit être sans ambiguïté quand on l’écrit à la main, ce qui exclut les espaces, les majuscules qu’un lecteur reproduira ou non, et la ponctuation qui signifie quelque chose pour un interpréteur de commandes ou de Markdown.

Comment les accents disparaissent

La plupart des diacritiques latins sont retirés par la plateforme et non par une table. Unicode définit é comme décomposable en un e simple suivi d’un accent aigu combinant : normaliser vers cette forme décomposée puis écarter chaque marque combinante laisse donc la lettre simple. La même opération traite ñ, ç, ő et quelques centaines d’autres, et elle ne peut pas se périmer, puisqu’elle utilise les données Unicode que le navigateur embarque déjà.

Elle ne traite pas tout, et l’écart mérite d’être connu. Une lettre dont la marque est un trait barrant le glyphe plutôt qu’un signe au-dessus — ø, ł, đ, ħ, ŧ — est un caractère unique et indivisible sans aucune décomposition : retirer les marques la laisse exactement telle quelle. Il en va de même d’une ligature : ß, æ et œ représentent chacune une suite de sons, non une lettre plus un ornement. Toutes exigent une graphie explicite, faute de quoi elles disparaîtraient purement et simplement du slug.

Pourquoi le réglage de langue change la réponse

Il n’existe pas une seule romanisation correcte de ü. L’allemand l’écrit ue depuis avant que le tréma n’existe — les deux points ont commencé comme un petit e en exposant — donc Müller s’écrit proprement mueller, et un lecteur allemand trouvera muller fautif. Le français, l’espagnol et le portugais traitent leurs diacritiques comme des accents sur une lettre qui reste par ailleurs elle-même : crème brûlée donne donc proprement creme-brulee, et l’écrire cruemme n’aurait aucun sens.

Les langues nordiques se contredisent entre elles de la même façon. Le danois et le norvégien doublent la voyelle, suivant l’ancienne graphie que la lettre a remplacée ; le suédois non :

• Allemand — ä devient ae, ö devient oe, ü devient ue, ß devient ss. München donne muenchen.
• Danois et norvégien — æ devient ae, ø devient oe, å devient aa. Ålborg donne aalborg.
• Suédois — ä devient a, ö devient o, å devient a. Ålborg donne alborg.
• Générique — toute marque est écartée et la lettre de base conservée. Ålborg donne alborg, München donne munchen.

Ce ne sont pas des approximations concurrentes d’une seule réponse ; ce sont quatre réponses correctes différentes à quatre questions différentes. Une seule peut être celle par défaut : le réglage est donc visible et l’outil indique quelle convention a produit ce que vous regardez. Une lettre est identique partout : ß est une ligature et non un accent, l’écarter supprimerait donc un son, et elle vaut ss dans tous les réglages proposés ici.

Les écritures qui exigent une table

Rien dans le navigateur ne romanise le cyrillique, le grec, l’hébreu ou l’arabe : chacun est donc une table écrite à la main d’après une norme publiée. Deux d’entre elles s’en sortent bien, parce qu’elles écrivent leurs voyelles :

• Le cyrillique suit BGN/PCGN, la romanisation des cartes et des passeports anglophones : ж vaut zh, ч vaut ch, щ vaut shch, х vaut kh. Москва donne moskva et Чехов donne chekhov.
• Le grec suit ELOT 743, y compris les digrammes qu’il définit : ου vaut ou et non oy, et ευ vaut ev. Αθήνα donne athina et Ευρώπη donne evropi.

ISO 9 est l’autre norme cyrillique bien connue, et elle n’est délibérément pas utilisée ici. Elle est réversible, c’est tout son intérêt, mais elle y parvient avec des diacritiques : ж s’y écrit ž. Un slug n’a pas de place pour un caron : la lettre s’aplatirait aussitôt en z, et Жуков et Зуков deviendraient le même slug. Le digramme de BGN, lui, survit à cet aplatissement.

Un détail de la table cyrillique est facile à manquer et mérite d’être dit. ё et й ressemblent à des lettres accentuées, et Unicode les décompose ainsi, mais la marque est ce qui en fait des lettres différentes et non un ornement sur la même. Retirer les marques avant de consulter la table — l’ordre correct pour toutes les autres écritures présentes ici — transforme silencieusement Ёлка en elka et Андрей en andrei.

L’hébreu et l’arabe, et ce qu’ils perdent

Les deux écritures notent les consonnes et laissent la plupart des voyelles à des points que le texte ordinaire ne porte pas. Ce n’est pas un problème d’encodage qu’une meilleure table résoudrait : l’information n’est pas dans le texte. « מאמר » compte quatre lettres, mem-aleph-mem-resh, et la lecture maamar vient d’un lecteur qui connaît déjà le mot. Lettre à lettre, cela ne peut donner que mamr.

Ce qui peut être fait l’est. Là où une lettre sert aussi de signe vocalique, la position est exploitée, car c’est le seul indice que laisse un texte non pointé :

• ו et י sont des consonnes en début de mot et des lettres vocaliques à l’intérieur, ce qui donne shlom pour שלום au lieu de shlvm.
• Un וו ou un יי doublé est la consonne dans les deux cas — ce doublement est précisément la façon dont l’hébreu lève l’ambiguïté entre les deux lectures.
• ב, כ et פ sont des occlusives en début de mot et des fricatives à l’intérieur. Le daguesh qui marque la différence est un point-voyelle : la position est donc tout ce qui reste.
• Une lettre suivie d’un guérech note le son auquel l’alphabet n’a pas de lettre : ג׳ vaut j, צ׳ vaut ch, ז׳ vaut zh. L’ignorer ferait de ג׳אז un autre mot.
• Les consonnes emphatiques arabes se confondent avec leurs équivalentes simples, car ASCII n’a nulle part où mettre le point souscrit qui les distingue. صابر et سابر produisent le même slug.

Le résultat est lisible et reconnaissable, et ce n’est pas une graphie que quiconque qualifierait de correcte. L’outil le dit sur chaque résultat hébreu ou arabe plutôt que de présenter une réponse lacunaire comme achevée — et il renvoie vers la forme ci-dessous, qui ne perd rien du tout.

Le chemin Unicode, qui n’exige aucune translittération

Le chemin d’une URL ne se limite pas à l’ASCII. Le RFC 3987 définit l’IRI — un identifiant pouvant contenir n’importe quel caractère Unicode — et la règle pour le mettre sur le réseau est d’encoder les octets UTF-8 en échappements pourcent. Tous les navigateurs le font depuis vingt ans, et c’est pourquoi Wikipédia sert ses titres hébreux et russes sous leur propre nom, que la barre d’adresse affiche lisiblement.

La deuxième sortie ici est donc le titre dont la ponctuation et les espaces ont été nettoyés, sans que rien d’autre soit touché, et la troisième est ce à quoi cela ressemble réellement sur le réseau. Ce sont le même chemin : la forme lisible est ce qu’affiche un navigateur et ce qu’une personne copie, la forme encodée est ce que le serveur journalise.

Laquelle utiliser est une vraie décision et non une formalité. La forme Unicode ne perd rien, se lit correctement pour quiconque parle la langue, et c’est elle qu’un moteur de recherche affichera. La forme translittérée survit à un collage dans des endroits qui abîment les encodages, s’insère dans des systèmes qui supposent des chemins ASCII, et se lit au téléphone. Pour l’hébreu et l’arabe en particulier, la forme Unicode est le plus souvent la meilleure réponse, justement parce que la translittération ne peut pas rendre les voyelles.

Les collisions, et pourquoi elles ne sont pas résolues pour vous

La mise en slug retire la ponctuation : les titres qui ne diffèrent que par elle cessent donc de différer. « Notre guide de CSS » et « Notre guide de CSS ! » font deux billets et un seul slug. En mode liste, chaque heurt de ce genre est signalé avec la ligne qu’il percute, car c’est l’échec qu’un gestionnaire de contenu dissimule : il ajoute un suffixe en silence, publie, et l’URL que vous attendiez appartient à l’autre billet.

Le suffixe est disponible comme interrupteur et produit le style WordPress et Django — notre-guide-de-css, notre-guide-de-css-2 — pour le cas où une liste doit être collée quelque part telle quelle. Il est désactivé par défaut, parce qu’une collision est généralement un problème de contenu plutôt que de nommage, et la collision reste signalée même interrupteur activé : l’activer ne cache donc rien.

La longueur, et couper au bon endroit

Une limite de longueur coupe sur une frontière de séparateur, jamais à l’intérieur d’un mot. Tronquer en plein mot ne produit pas tant un slug plus court qu’un slug différent — introduction-to-crypt n’est pas un introduction-to-cryptography plus soigné — et un demi-mot est un mot qui veut dire autre chose. Si un seul mot dépasse la limite, il n’y a pas de frontière où couper : il est rendu entier plutôt que tranché.

Il n’existe pas de limite universellement juste. Les moteurs de recherche affichent grosso modo les soixante à soixante-dix premiers caractères d’une URL, et de vieux systèmes plafonnent parfois un segment de chemin, mais rien ne casse à un nombre précis. Laisser le champ vide laisse le slug aussi long que le titre l’exige.