De nos jours, là, en 2011, s'inscrire sur un site est très souvent pour tout autre chose que participer à des forums. Ou en tout cas pas que. Ce n'est plus du tout l'usage majoritaire à mon avis. Et dans tous les cas : cela n'a pas de sens de préjuger du besoin du webmestre qui active cette fonction.
Donc qui est pour supprimer toute chaîne de langue inutile à ce formulaire ? Pour ne laisser que ce qui concerne vraiment l'inscription.
Les chaînes de langue, c'est à chacun de les mettre dans son site là on veut ajouter des explications, mais ce n'est pas à SPIP de les forcer.
L'exemple le plus évident étant :
"""
Vous avez demandé à intervenir sur un forum réservé aux visiteurs enregistrés.
"""
=> ben non, aucun rapport avec mon site dans 99% des cas où j'insère ce formulaire... et ça vaut pour tout site contributif.
En pratique sur la plupart des sites on ne s'inscrit pas, mais on
s'identifie. Avec Facebook, ou twitter, OpenID pour les plus barbus,
ou son email.
J'aurais désormais tendance à parier sur BrowserID, la proposition de
Mozilla, qui permet de s'authentifier en deux clics en disant "oui je
suis bien le propriétaire de l'email fil@rezo.net". Ensuite c'est au
site de me demander des précisions s'il en veut, et de me dire ce que
j'ai le droit de faire, maintenant que je me suis présenté. La notion
de "compte", toujours problématique (comment se souvenir si on a déjà
un compte sur tel ou tel site où on est allé il y a 3 ans?) n'est plus
centrale.
J'ai un prototype de plugin BrowserID, c'est très facile à coder, car
tout ce qui est chiant à faire est géré par eux. Il ne nous reste
"plus qu'à" décider ce qu'on propose à un utilisateur qui vient de
s'authentifier. Et c'est vrai que ça peut varier énormément d'un site
à l'autre.
Oui, c'est tout le problème de tous les plugins d'authentification : fb, oauth, openid ou autre.
Mais je parlais bien de l'inscription minimale en tant qu'utilisateur (cad sans forcément avoir accès à l'espace privé) : être enregistré quelque part comme étant utilisateur du site, et donc avoir tel ou tel droit par rapport à un anonyme.
Actuellement c'est le formulaire d'inscription qui fait ça, sauf qu'il préjuge du sens qu'on veut donner à cette inscription. Il ne devrait pas (et depuis longtemps d'ailleurs, dès 2.0 on aurait pu enlever ces phrases).
Dans ce cas on ne pourrait pas les enlever mais les remplacer par un item de langue que l’on pourrait passer en paramètre quitte à proposer par défaut l’item actuel si le paramètre est null (pas chaine vide) ?
Oui. Ca fait quelques années que je les ré-écris systématiquement quand je ne les supprime pas. Je vais essayer de retrouver les tournures de phrases que j'ai essayées, pour rendre ça plus générique, afin de les partager ici.
Le problème est surtout que ça génère un <p> pour chaque phrase (3 au total, si je ne me trompe pas), ce qui est chiant stylistiquement (mais contournable avec un margin: 0; ) et sémantiquement inapproprié lorsque vide (ce qui n'est pas contournable).
Je voterais pour un formulaire d'inscription réduit au strict nécessaire fonctionnel (ie: legend, fieldset, label, input, label, input, button), non verbeux donc, et pour déporter une nos verbeuses chaînes de langues (j'ai toujours trouvé chouette que le système parle aux humains) juste au dessus, dans la dist, mais hors de #FORMULAIRE_INSCRIPTION, de façon à faire une proposition formellement dans la lignée de SPIP, tout en apportant davantage de liberté d'adaptation.
C'est exactement ce à quoi je pensais. C'est à la dist d'utiliser ces chaînes pour proposer un exemple, mais pas à l'intérieur du formulaire (fut-ce configurable). Les explications longues dans le squelette, le fonctionnel dans le CVT.
Dans cette direction je crois, je me disais que l'inscription était trop exigante, lourde et rigide,
à l'image de la différence monolithique de statut de l'internaute
entre l'espace "public" hyper-personnalisé et ouvert à tous vents,
et l'espace "privé" de SPIP, non personnalisable dans son apparence et sa navigation et restreint aux "inscrits"
(l'apparence commence à se dégèler avec SPIP3 mais c'est tout un univers spécifique et donc lourd à personnaliser,
et qu'en est il de la navigation ?).
Souvent un ou plusieurs statuts intermédiaires conviendraient mieux,
entre "identifié inscrit vérifié validé confirmé" et simplement "ni identifié ni vérifié ni validé",
entre "public volatile" et "pleinement auteur du site, initié à spip, ses raccourcis et sa partie privée".
J'imaginais un statut : "Identifié par un mail pas encore validé", avec certains droits
(comme par exemple de consulter et déposer des messages pour en rester aux forums)
mais certaines restrictions (par exemple la publication d'un forum requiert la validation de l'identité par l'envoi d'un mail avec un lien codé).
Plus généralement, la souplesse de l'authentification amène probablement à sortir des 5 statuts actuellement
prédéfinis, et à vouloir gérer de plus nombreux statuts, voir des statuts multidimensionnels.
J'imaginais un statut : "Identifié par un mail pas encore validé", avec
certains droits (comme par exemple de consulter et déposer des messages
pour en rester aux forums)
mais certaines restrictions (par exemple la publication d'un forum requiert
la validation de l'identité par l'envoi d'un mail avec un lien codé).
en plusieurs endroits (plugins) cela existe, et j'ai fait attention à
le coder partout de la même manière : c'est dans la session du
visiteur, on enregistre #SESSION{session_email} et #SESSION{session_nom} quand ils sont renseignés ; et #SESSION{email_confirme} quand un email a été confirmé (par envoi d'un
jeton dans l'email, ou par browserid).
Dès lors le test pour savoir si un visiteur possède bien l'email qu'il
prétend, serait :
if ($GLOBALS['visiteur_session']['session_email']
AND $GLOBALS['visiteur_session']['session_email'] ==
$GLOBALS['visiteur_session']['email_confirme']) {
echo "salut tu es bien le détenteur de
$GLOBALS['visiteur_session']['session_email']";
}
1) quel rapport ?
2) je rappelle la direction depuis SPIP 2.0 (4 ans !) : *enlever* tous les objets éditoriaux du noyau afin que chaque objet éditorial soit contenu dans un plugin séparé
Donc ta question n'a pas vraiment de sens.
Après qu'il y ait des distributions qui incluent ce plugin d'office, c'est une autre question...
