Intégrer la fonction slugify #4628

Closed
opened 2 years ago by tcharlss · 16 comments
tcharlss commented 2 years ago
Owner

Depuis le temps la fonction slugify du plugin Bonux a été testée et éprouvée, elle serait très utile directement dans le noyau, je suggère de l'intégrer en 3.3 : https://git.spip.net/spip-contrib-extensions/spip-bonux/src/branch/master/spip_bonux_fonctions.php#L142-L213

Elle pourrait ainsi dors et déjà être utilisée par les plugins sans avoir a réinventer la roue à chaque fois : urls, pages uniques, formidable, identifiants, etc.

Depuis le temps la fonction slugify du plugin Bonux a été testée et éprouvée, elle serait très utile directement dans le noyau, je suggère de l'intégrer en 3.3 : https://git.spip.net/spip-contrib-extensions/spip-bonux/src/branch/master/spip_bonux_fonctions.php#L142-L213 Elle pourrait ainsi dors et déjà être utilisée par les plugins sans avoir a réinventer la roue à chaque fois : urls, pages uniques, formidable, identifiants, etc.
b_b commented 2 years ago
Owner

+1 reste à voir si on travaille à lui trouver un nom francisé ou si on l'intègre avec ce terme chelou :p

+1 reste à voir si on travaille à lui trouver un nom francisé ou si on l'intègre avec ce terme chelou :p
Poster
Owner

Oui on se demande un peu d'où sort ce terme qui semble n'avoir aucun rapport avec son utilisation dans un contexte informatique : un court terme pour identifier une ressource = une limace ???
Il y a une explication un peu détaillée quant à son étymologie sur stack : https://stackoverflow.com/questions/4230846/what-is-the-etymology-of-slug
Il semble être apparu de façon assez informelle et organique dans le milieu de l'édition, mais ça dit pas pourquoi ce terme a été choisi précisément.
Bref maintenant il est utilisé tel quel « parceque c'est comme ça ».

Pour franciser, je pense pas qu'il soit pertinent de faire une traduction littérale, l'autre option serait de trouver un nom qui traduise bien le sens du terme, à savoir selon wikipedia : « un court texte utilisable [...] pour décrire et identifier une ressource. ». Mais je vois pas trop.

Oui on se demande un peu d'où sort ce terme qui semble n'avoir aucun rapport avec son utilisation dans un contexte informatique : un court terme pour identifier une ressource = une limace ??? Il y a une explication un peu détaillée quant à son étymologie sur stack : https://stackoverflow.com/questions/4230846/what-is-the-etymology-of-slug Il semble être apparu de façon assez informelle et organique dans le milieu de l'édition, mais ça dit pas pourquoi ce terme a été choisi précisément. Bref maintenant il est utilisé tel quel « parceque c'est comme ça ». Pour franciser, je pense pas qu'il soit pertinent de faire une traduction littérale, l'autre option serait de trouver un nom qui traduise bien le sens du terme, à savoir selon wikipedia : « un court texte utilisable [...] pour décrire et identifier une ressource. ». Mais je vois pas trop.

Bah "identifier une ressource" donc… "identifiant" comme ce qui est effectivement utilisé dans Menus, Formidable, Sélections éditoriales, etc…

Donc là comme il s'agit d'une action, ce serait avec un verbe : "generer_identifiant($titre)" par exemple, quelque chose dans ce genre.

Bah "identifier une ressource" donc… "identifiant" comme ce qui est effectivement utilisé dans Menus, Formidable, Sélections éditoriales, etc… Donc là comme il s'agit d'une action, ce serait avec un verbe : "generer_identifiant($titre)" par exemple, quelque chose dans ce genre.
Owner

Plutôt qu'utiliser identifiant qui fait référence au numéro unique attribué pour identifier chaque item d'un objet, est-ce que tatouage / tatouer ne serait pas plus clair en permettrant de ne pas confondre les deux termes ?
"generer_tatouage($titre)"

  • Un tatouage est unique (et inscrit dans la peau forever) et en tant qu'image encrée il peut être du texte, alors que l'identifiant est plutôt un numéro.
    mes 2 sous
Plutôt qu'utiliser _identifiant_ qui fait référence au numéro unique attribué pour identifier chaque item d'un objet, est-ce que tatouage / tatouer ne serait pas plus clair en permettrant de ne pas confondre les deux termes ? "generer_tatouage($titre)" - Un tatouage est unique (et inscrit dans la peau forever) et en tant qu'image encrée il peut être du texte, alors que l'identifiant est plutôt un numéro. mes 2 sous
Poster
Owner

Dans ce contexte, « tatouage » me fait plutôt penser à une empreinte, à une sorte de hash donc, pas précisément un slug.
Pour le verbe, « generer » ça m'évoque quelque chose qui créerait du texte ex-nihilo (comme uniqid par ex.), du coup je pencherais plus pour « normaliser » → normaliser_identifiant, ou normaliser_.
Voilà mes remarques très subjectives.

Dans ce contexte, « tatouage » me fait plutôt penser à une empreinte, à une sorte de hash donc, pas précisément un slug. Pour le verbe, « generer » ça m'évoque quelque chose qui créerait du texte ex-nihilo (comme uniqid par ex.), du coup je pencherais plus pour « normaliser » → normaliser_identifiant, ou normaliser_<machin>. Voilà mes remarques très subjectives.
Owner

http://gdt.oqlf.gouv.qc.ca/ficheOqlf.aspx?Id_Fiche=26532630

Toujours demander aux québécois·es :)

http://gdt.oqlf.gouv.qc.ca/ficheOqlf.aspx?Id_Fiche=26532630 Toujours demander aux québécois·es :)

Chez nous (mais chez d'autres aussi), le slug n'est pas forcément toujours que pour l'URL, ça peut être pour sortir tel élément avec un identifiant donné par un humain, volontairement. Donc ils proposent plusieurs possibilités et quand on veut pas la notion d'URL dedans c'est bien : "identifiant" tout court.

Reste à décider d'un verbe puisqu'on agit pour transformer un texte quelconque en slug. "normaliser_identifiant" pourquoi pas, ou "convertir_identifiant" ?

Chez nous (mais chez d'autres aussi), le slug n'est pas forcément toujours que pour l'URL, ça peut être pour sortir tel élément avec un identifiant donné par un humain, volontairement. Donc ils proposent plusieurs possibilités et quand on veut pas la notion d'URL dedans c'est bien : "identifiant" tout court. Reste à décider d'un verbe puisqu'on agit pour transformer un texte quelconque en slug. "normaliser_identifiant" pourquoi pas, ou "convertir_identifiant" ?
b_b commented 2 years ago
Owner

Je croyais me souvenir que cette fonction était surtout utilisée pour générer un identifiant html (qu'on peut donc utiliser de manière safe dans un attribut id). Donc pourquoi pas "identifiant_html" ?

Je croyais me souvenir que cette fonction était surtout utilisée pour générer un identifiant html (qu'on peut donc utiliser de manière safe dans un attribut id). Donc pourquoi pas "identifiant_html" ?
Owner

tcharlss 🐽 a écrit :

Oui on se demande un peu d'où sort ce terme qui semble n'avoir aucun rapport avec son utilisation dans un contexte informatique : un court terme pour identifier une ressource = une limace ???

Ce n'est pas nouveau comme terme, c'est même très utilisé :)

Le terme de slug est repris depuis quelques années en informatique, et notamment sur le web, afin de désigner un label unique, pour identifier un élément.
On retrouve ce mécanisme au sein du framework Django, où un type de champ est spécialement conçu pour ce cas : SlugField
https://fr.wikipedia.org/wiki/Slug_(journalisme)

Identifiant je ne suis pas pour, confusion avec les id d'objets.
Je préfèrerais encore garder slug, qui a un sens technique bien précis (et on est bien là dans un contexte technique).

Et sinon :

En anglais, le terme "slug" signifie littéralement "limace", et était autre fois utilisé pour décrire les longues lignes de plombs formant une suite de caractères dans le monde de l'impression papier.
Le mot à traversé les époques en étant utilisé par les journalistes pour "identifier" un article qui passait de main en main du pigiste jusqu'au rédacteur en chef, jusqu'à être aujourd'hui beaucoup utilisé dans le web, notamment sur les blogs et les sites e-commerce.
https://blog.nicolas.brondin-bernard.com/qu-est-ce-qu-un-slug-et-pourquoi-faut-il-l-utiliser-dans-vos-urls/

tcharlss 🐽 a écrit : > Oui on se demande un peu d'où sort ce terme qui semble n'avoir aucun rapport avec son utilisation dans un contexte informatique : un court terme pour identifier une ressource = une limace ??? Ce n'est pas nouveau comme terme, c'est même très utilisé :) > Le terme de slug est repris depuis quelques années en informatique, et notamment sur le web, afin de désigner un label unique, pour identifier un élément. > On retrouve ce mécanisme au sein du framework Django, où un type de champ est spécialement conçu pour ce cas : SlugField https://fr.wikipedia.org/wiki/Slug_(journalisme) Identifiant je ne suis pas pour, confusion avec les id d'objets. Je préfèrerais encore garder slug, qui a un sens technique bien précis (et on est bien là dans un contexte technique). Et sinon : > En anglais, le terme "slug" signifie littéralement "limace", et était autre fois utilisé pour décrire les longues lignes de plombs formant une suite de caractères dans le monde de l'impression papier. > Le mot à traversé les époques en étant utilisé par les journalistes pour "identifier" un article qui passait de main en main du pigiste jusqu'au rédacteur en chef, jusqu'à être aujourd'hui beaucoup utilisé dans le web, notamment sur les blogs et les sites e-commerce. https://blog.nicolas.brondin-bernard.com/qu-est-ce-qu-un-slug-et-pourquoi-faut-il-l-utiliser-dans-vos-urls/
Owner

Sur data.gouv.fr par exemple, ils distinguent bien identifiant et slug. Pour moi ce sont deux notions sémantiques différentes.

La réponse en JSON contient les metadonnées du jeu de données créé, en particulier l’identifiant et le slug.
https://doc.data.gouv.fr/api/dataset-workflow/

Sur data.gouv.fr par exemple, ils distinguent bien identifiant et slug. Pour moi ce sont deux notions sémantiques différentes. > La réponse en JSON contient les metadonnées du jeu de données créé, en particulier l’identifiant et le slug. https://doc.data.gouv.fr/api/dataset-workflow/

Si on reste bien dans le cadre "dev", alors je ne vois que peu de confusion possible : dans nos divers API absolument nulle part on n'utilise le mot "identifiant" dans les fonctions et variables pour parler des autoincréments SQL. On parle soit de "id", soit de "id_objet", soit de "clé", mais jamais d'identifiant, et cela depuis le tout début de SPIP. Même dans une doc plus publique : https://www.spip.net/fr_article5477.html. Les quelques fois où c'est utilisé pour le noyau, c'est que dans du PHPDoc, et ça si on veut être sûr de clarifier, on peut toujours remplacer en masse sans rien casser, pour mettre "ID" ou "Identifiant SQL" à la place.

"identifiant" est en revanche :

  • la traduction officielle de slug en français pour son sens informatique (les québécois sont plus fort que la "french tech" du gouvernement français, pour les traductions !)
  • utilisé depuis des années dans divers plugins pour nommer un identifiant textuel contrôlable par un humain (ce qu'est précisément un slug)

En tout cas je ne vois que deux possibilités pour ma part :

  • soit on garde "slug" et on ne traduit rien, et basta :)
  • si on change pour autre chose, alors forcément "identifiant" au regard des arguments ci-dessus
Si on reste bien dans le cadre "dev", alors je ne vois que peu de confusion possible : dans nos divers API absolument nulle part on n'utilise le mot "identifiant" dans les fonctions et variables pour parler des autoincréments SQL. On parle soit de "id", soit de "id_objet", soit de "clé", mais jamais d'identifiant, et cela depuis le tout début de SPIP. Même dans une doc plus publique : https://www.spip.net/fr_article5477.html. Les quelques fois où c'est utilisé pour le noyau, c'est que dans du PHPDoc, et ça si on veut être sûr de clarifier, on peut toujours remplacer en masse sans rien casser, pour mettre "ID" ou "Identifiant SQL" à la place. "identifiant" est en revanche : - la traduction officielle de slug en français pour son sens informatique (les québécois sont plus fort que la "french tech" du gouvernement français, pour les traductions !) - utilisé depuis des années dans divers plugins pour nommer un identifiant textuel contrôlable par un humain (ce qu'est précisément un slug) En tout cas je ne vois que deux possibilités pour ma part : - soit on garde "slug" et on ne traduit rien, et basta :) - si on change pour autre chose, alors forcément "identifiant" au regard des arguments ci-dessus
Owner

+1 nicod_ j'utilise aussi beta.gouv.truc et Django et des jsons avec slug, le slug est devenu assez courant amha, je trouve donc pas mal de garder slug pour les codes courts en lettres, et identifiant plutot pour les numéros
donc ok pour slugify, on est plus à une fonction anglaise près !)
Purée, un thread aussi long pour une pauvre limace … sacrés escargots ! des bises

+1 nicod_ j'utilise aussi beta.gouv.truc et Django et des jsons avec slug, le slug est devenu assez courant amha, je trouve donc pas mal de garder slug pour les codes courts en lettres, et identifiant plutot pour les numéros donc ok pour slugify, on est plus à une fonction anglaise près !) Purée, un thread aussi long pour une pauvre limace … sacrés escargots ! des bises
Owner

L'inconvénient de la nommer slufigy c'est le risque de collision.
Je recherche dans mes mails d'il y a 4 ans pour trouver pourquoi, mais à l'époque, on avait switché de slugify vers filtre_slugify_dist et une définition optionnelle de la fonction slufigy() 9987b6f429

Ça m'embêterait de faire ça dans le core.

Donc soit on y va

  • pour slufigy() tout court, au risque de la collision,
  • ou un spip_slugify() peut-être qui sera plus sur, mais on perd la compat automatique avec les appels existants (cela dit bonux peut gérer le mappage de l'ancien vers le nouveau)
  • ou alors un autre nom ?

Faites vos jeux, rien ne va plus...
Statut changé à En cours

L'inconvénient de la nommer slufigy c'est le risque de collision. Je recherche dans mes mails d'il y a 4 ans pour trouver pourquoi, mais à l'époque, on avait switché de slugify vers filtre_slugify_dist et une définition optionnelle de la fonction `slufigy()` https://git.spip.net/spip-contrib-extensions/spip-bonux/commit/9987b6f429211364492560f63d66a73f3b5d41b2 Ça m'embêterait de faire ça dans le core. Donc soit on y va * pour `slufigy()` tout court, au risque de la collision, * ou un `spip_slugify()` peut-être qui sera plus sur, mais on perd la compat automatique avec les appels existants (cela dit bonux peut gérer le mappage de l'ancien vers le nouveau) * ou alors un autre nom ? Faites vos jeux, rien ne va plus... **Statut changé à En cours**
Owner

identifier_slug() peut-être, qui fait la synthèse des 2 idées et évite tout risque de collision ?

`identifier_slug()` peut-être, qui fait la synthèse des 2 idées et évite tout risque de collision ?
Owner

Il y a donc une PR et j'ai retenu identifiant_slug() #136

Il y a donc une PR et j'ai retenu `identifiant_slug()` https://git.spip.net/spip/spip/pulls/136
Owner

intégré donc
Statut changé à Fermé

intégré donc **Statut changé à Fermé**
Sign in to join this conversation.
No Milestone
No project
No Assignees
7 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.