Serait-ce envisageable de rajouter pour SPIP 1.9.3 au minimum une variable technique oui/non dans le core avec la case à cocher ? (plus un filtrage natif des boucles MOTS et GROUPES).
Cela permettrait de fournir un début d'uniformisation pour les mots clés techniques. Si l'on désire un fonctionnement plus complexe et un typage plus poussé des mots clés, il reste les plugins (par exemple mots partout).
Quel intérêt à l'avoir dans le core ? Cela amène une certaine uniformisation d'un squelette à un autre, uniformisation si on commence à travailler avec des noisettes.
Lorsque l'on fait un ensemble complet de squelettes, on peut très bien adopter une convention sur le nom des groupes de mots clés et faire un filtrage sur l'ensemble des squelettes.
Par contre, si on travaille avec des noisettes que l'on met bout à bout pour former ces squelettes, on peut envisager une noisette listant les mots clés associés à un article. Cette noisette de base liste par défaut tous les mots clés avec une boucle MOTS. Si par la suite, on insère dans ces squelettes une noisette utilisant un mot clé technique, il faudrait alors aller modifier la noisette listant les mots clés d'un article.
Par contre, si dans le core on introduit la notion de mots clés tecniques avec le filtrage associé, alors la noisette de base (qui ne tient pas compte des mots clés techniques) restera valable puisque le filtrage sera nativement pris en compte.
D'autre part, si on suppose un site fonctionnant avec un jeu de squelettes codés sous la forme de plugin. On souhaite changer le style avec un autre jeu de squelettes également sous forme de plugin (par exemple lorsqu'on utilise habillage). On devrait pouvoir passer d'un ensemble de squelettes à un autre puis revenir en arrière si on le souhaite (distinction entre style et contenu). Si chaque plugin de squelettes utilise une convention différente de filtrage des mots clés techniques propre à chaque squelette, alors au changement de squelette les mots clés techniques du premier squelette, qui étaient filtrés auparavant ne le seront plus avec ce second squelette. Si, au contraire, il y a une convention commune liée au core avec l'ajout de la case à cocher technique sur les groupes de mots clés, alors au changement de squelette, on aura toujours un filtrage de l'ensemble des mots clés techniques, à la fois ceux du premier ensemble de squelette et ceux du second ensemble de squelettes. Les ensembles de squelettes, quant à eux, peuvent récupérer l'information de leurs propres mots clés techniques en préfixant les groupes de mots clés tecniques qui les concernent avec le nom du squelette par exemple. Ainsi, la présence de deux ensembles de mots clés techniques (certains pour un ensemble de squelettes et d'autres pour un second ensemble) pourront cohabiter sans problème. Ils seront dans tous les cas filtrés sur le site public et seuls les mots clés techniques du squelette actuellement activé seront utilisés. Ainsi, je peux changer l'ensemble de squelettes que j'utilise sur mon site, essayer cet ensemble de squelettes pendant quelques mois avant de choisir de garder ce nouvel ensemble ou de revenir à l'ancien ensemble, sans avoir besoin de supprimer de suite les mots clés du premier ensemble. Si à terme je désire ne plus revenir en arrière, il suffira au webmaster de supprimer les mots clés techniques devenu inutiles. Si, je désire revenir en arrière, je n'aurai pas perdu toutes les associations de mots clés techniques du premier squelette.
Il me semble donc pertinent d'envisager, dans le core, un distingo mots-clés techniques et mots-clés sémantiques avec filtrage sur l'espace public afin d'avoir un minimum de cohérence entre squelettes et entre plugin. Par contre, un typage des mots clés dans le cas d'une utilisation avancée des mots clés, pourrait, quant à elle, être réglé par un plugin.
Joseph