Le langage de squelettes est resté simple : id_article / ARTICLES
est la seule règle à ce niveau là, facile à appréhender
et intuitive en français (mais ce n'est pas la seule possible intuitive !)
L'interrogation concerne donc la programmation PHP uniquement
le code noyau et les API.
Elle concerne tous les développeurs de plugins et les coredev actuels et futurs :
plus le code du noyau SPIP est simple et lisse,
mieux l'équipe du noyau et la communauté de la galaxie pourront se renouveler,
s'étoffer, intégrer facilement les apports de chacun.
La suite en réponse à Rastapopoulos :
Plus sérieusement, pourrait-tu faire la liste exhaustive des points que
tu considères problématiques actuellement ?
Ca aiderait fortement à évaluer la charge de travail et la manière d'y
arriver, en particulier, le degré d'incompatibilité qu'une telle
correction pourrait engendrer dans SPIP.
Je pense que le plus évident, peu importe qu'on reste en français ou en catalan ou en arabe, c'est : supprimer
complètement la notion de singulier/pluriel dans les *noms techniques*.
UN seul nom pour UN type d'objet éditorial. Ensuite on utilise le même identifiant partout : nom de la table, nom de la
clé, nom de l'objet dans les fonctions.
Du coup, peu importe qu'il soit singulier ou pluriel, après c'est au choix du développeur, même si on peut dire :
préférez le singulier au maximum par exemple.
spip_article
BOUCLE1(ARTICLE)
id_article
autoriser('manger', 'article')
Apprentissage facilité et intuitif.
Voilà, ça c'est un tâche concrète qui peut être estimer en temps et en degré d'incompatibilité (SPIP 4 quoi).
Je pense que c'est la bonne piste, en effet, mais ça ne s'arrête pas là.
1) Actuellement, il y a un certaine certaine gestion des exceptions
qui fait qu'on peut gérer avec spip des tables qui ne respectent pas
les déclinaisons actuellement "normales".
Doit-on / voudra-t-on greffer sur un noyau 'simplifié'
des mécanismes d'exceptions qui permettront de gérer tout aussi bien
id_truc / truc (normal simplifié)
que id_article / articles, et id_child / children ?
Je pense qu'on ne voudrait pas s'en passer, surtout que ça permettra de réutiliser
les squelettes actuels sans les modifier, et c'est donc à prévoir dés le début.
Mais on peut espérer que ça sera plus simple à implémenter,
par exemple sous la forme d'un plugin,
et il serait bien que ça n'aie pas de coût CPU lorsqu'on ne s'en sert pas
et pas de conséquence sur le codage partout, qui doit rester simple et systématique.
2) Un autre domaine de complication actuelle, et de simplification souhaitable
est dans la gestion des mots composés.
Il faut bien : SPIP assemble les mots pour pouvoir exprimer des relations.
Il y aurait un travail de recensement à faire comme le demande Eric.
Certaines difficultés semblent difficilement extricables actuellement
cf http://core.spip.org/issues/2415
JLuc
