Sauf pour les importes depuis f&t, vu que tjr en .yaml + chaine de
langue + maintien compat historique

On en profite pour passer systématiquement datas à `saises_chaine2tableau()`, afin
de profiter systématiquement de `_T_ou_typo()` (même si en l'occurence,
ca passait deja tout le temps, on ne sait jamais pour l'avenir si on
stocke autrement les saisies de formidable...)

saisies masquées par afficher_si. Lors de l'enregistrement des réponses
d'un formulaire, on cherche les saisies qui ont masquées et ont les mets
à `null`.

perf sur export csv : plutot que de parcourir les réponses pour vider les IP, ne les inserer au moment où l'on prépare les lignes que si on les demande explicitement

Message de DD sur contrib : si pas d'export des IP lors de l'export des réponses, ne pas mettre l'entete correspond

fielset + ne pas proposer les saisies de type explication + diverses
corrections syntaxique.

formulaire.
Mais un slug ne peut pour l'heure pas contenir des majuscules.
Pour éviter de force la main aux gens (au risque de casser l'existant),
on rétabli pour l'instant l'ancienne verif en regex.
A voir comment on fait à moyen terme dans le ticket #60

utiliser le paramètre saisie_id plutôt que de le reconstruire après coup. Evite d'avoir une redirection foireuse en cas de suppression de champ (!)

`saisies_afficher_si_js_saisies_form` en `saisies_afficher_si_saisies`. Même
si une compat est prévu pour un temps, on anticipe.

décide s'il affiche ou pas son message spécifique, en connaissant par
ailleur le message general.

Up de y.
Fix #58 (again !)

maintenant que le formulaire s'occupe lui même de concatener les messages_ok, on peut s'épargner ces 2 tests

fix #59 : ne pas appliquer propre sur tous les retours de traitements, charge à chaque traitement de le faire

[Salvatore] [source:lang/ formidable] Mise a jour du bilan depuis https://trad.spip.net

Puisque maintenant le javascript est à part, on peut mettre une case à
cocher pour demander d'afficher explicitement les messages de retour de chaque
traitement si jamais on a défini un message général.

allons y carrément : formulaire/editer_formulaire.html est vide, et c'est saisies qui s'occupe de tout (mais pas encore pour le chargement des valeurs)

deleguer à saisies la verification de formulaire_editer_formulaire (y compris slug, avec la dernière version de slugify

formulaire_editer_formulaire > déclaration des saisies en tableau, pour pouvoir jouer sur les afficher_si après. Pour l'instant je met à l'identique

note : un de ces 4 il faudra voir à améliorer saisies pour faire
l'ensemble d'un formulairer _editer avec un automagique, comme on fait
pour les config... mais plus tard.

cas de succès (formidable_subscribers). Ces scripts ne passent par
propre, contrairement aux vrais message_ok. Ils ne sont donc pas
échappés.

cerdic a rédigé il y a 4 ans et salvatore a validé il y a 4 ans

[Salvatore] [source:lang/ formidable] Mise a jour du bilan depuis https://trad.spip.net

ajout des roles sur les message de retour (inspiré par https://git.spip.net/spip/dev/commit/25c2fa85

crayons sur les champs d'une réponse : passer par objet_modifier, afin de pouvoir profiter si besoin des pipelines (cas du plugin formidable_participation)

[Salvatore] [source:lang/ formidable] Export depuis https://trad.spip.net de la langue fr
[Salvatore] [source:lang/ formidable] Export depuis https://trad.spip.net de la langue nl
[Salvatore] [source:lang/ formidable] Export depuis https://trad.spip.net de la langue pt_br
[Salvatore] [source:lang/ formidable] Mise a jour du bilan depuis https://trad.spip.net