Log:
Le traitement des raccourcis non standards était incorrect dans l'espace privé. Le pire est qu'il suffisait de plus partagé le code dans {{{ generer_url_ecrire }}}. Et faut-il toujours garder les fonctions {{{calculer_url_* }}} dont le nom est trompeur et qui pourraient être simplifiées ?
Et faut-il toujours garder les fonctions {{{calculer_url_* }}} dont le nom est trompeur et qui pourraient être simplifiées ?
gogogo
--
Fil
C'est moi qui avait introduit ces fonctions dans la 1.9, pour gérer des raccourcis persos qui ne rentraient pas bien dans le cadre generer_url_*, c'est plutot du hack. Mais je viens de réaliser que ces raccourcis relèvent plutot du glossaire: j'en ai une palanquée comme [nom->manN] [nom->htmlN] [nom->phpN] qui sont des pointeurs vers les sections N des docs Unix, Html et PHP respectivement. Le pb est que la syntaxe SPIP pour les liens vers un gloassaire ne permet d'avoir qu'un seul glossaire défini globalement (Wikipedia par défaut), et pas de spécifier l'URL du glossaire à chaque coup.
Si on veut lever cette restriction, sachant que | et {} sont déjà pris dans le raccourci des glossaires
(on peut écrire: [?texte|infobulle[lang}])
il reste # comme caractère interdit par Wikipedia et donc utilisable pour étendre ce raccourci sans risquer de provoquer des incompatibilités.
On pourrait écrire [?texte#glossaire] ou [?texte|infobulle#glossaire[lang}])
et faire de la variable de personnalisation url_glossaire_externe un tableau d'URL plutôt qu'une simple URL comme actuellement (suffit de tester sa valeur pour assurer la compatibilité).