tentative d'amenagement des pages de configuration avec la reprise du menu deroulant en colonne gauche
ce qui devrait permettre d'eviter les onglets superieurs
il y a de l'alignement a faire, c'est encore brouillon

l'envoi precedent sur tester_url_ecrire etait bien evidemment faux, puisque la fonction doit retourner une info sur l'exec php a executer.
On s'arrete donc au nom qu'on renvoie, charge a l'appelant de faire un charger_fonction() pour avoir le script

lors de la detection de l'existence d'#URL_ECRIRE{xxx} ne pas essayer de charger l'exec si il n'est pas en php, sinon ca declenche son calcul a tort

detection des formulaire de configuration deja presents dans des pages de config : un array_flip manquait et provoquait double entree dans le menu configuration

Les deux configuration/locuteur et configuration/referenceur sont regroupees en un seul #FORMULAIRE_CONFIGURER_MULTILINGUISME, ce qui devrait resoudre #1652

pour les questions type radio avec un long label principal, la classe long_label sur le li permet d'elargir la colonne des labels.
A utiliser de preference sur plusieurs questions consecutives pour avoir une coherence d'alignement

lorsqu'on change sa langue, il faut faire une redirection vers la page en cours pour que ce soit applique tout de suite, car on ne peut pas changer definitivement la langue dans CVT

supprimer les occurences de inc_discuter() qui est remplace par une insertion dans le pipeline afficher_fiche_objet par l'extension forum
Il reste le cas particulier des messages, dont les forum ont vocation a disparaitre et devront etre remplaces par des messages de reponses

evacuer la version PHP de la page de configuration des langues, des la barre onglet correspondante, et branchement de la version squelette (et definition des onglets dans core.xml)

et en ignorant les consignes de langue du public dans la fonction correspondante

bouton "Deplacer" et non "Changer"
En float right pour ne pas faire croire qu'il est associe a l'objet, mais au chemin en general
placeholder pour l'animation ajax

hierarchie : utiliser un squelette unique pour afficher le chemin avec un bouton changer qui charge en ajax le selecteur de rubrique (#1634)
Doit on encore garder le selecteur de rubrique dans le formulaire d'edition ?

un debut de fil d'ariane universel (ah ben tiens c'est possible avec #INFO_TITRE sur le dernier objet expose !)

le pipeline affiche_hierarchie ne devait pas etre bien utilise puisque id_parent=0 car reaffecte dans le corps de la fonction

rangement : les exec qui utilisent une authent FTP par inc/admin et declenchent une action scriptee dans base/xxx s'appellent de preference (et en coherence) exec/base_xxx. A defaut si exec/base_xxx n'existe pas, inc/admin renvoie sur exec/xxx comme avant pour assurer la compatibilite.

On renomme 
- admin_repair en base/repair et exec/base_repair
- delete_all en base/delete_all et exec/base_delete_all
pour s'y retrouver

Suite au début de migration des mots en plugin (http://zone.spip.org/trac/spip-zone/changeset/41050), on se déleste des fichiers et parties intégrées (telles quelles)

Il reste le cas du formulaire de declaration d'une autre base, issu de l'installation. Mais il faudra traiter son cas specifiquement, on le laisse donc comme ca pour le moment.

le form de connexion etant utilise aussi dans l'espace prive, il faut pouvoir l'injecter sans jquery lorsqu'il est deja present

oups : le pipeline recuperer_fond passe tout le tableau, il faut passer uniquement le texte a afficher_xxx