mérite tout de même d'être traitée.

Le point médian en tant que forme d'écriture inclusive pose des
problèmes d'accessibilité. Il doit donc être évité autant que possible.
Voir notamment
https://legothequeabf.wordpress.com/2017/11/07/recommandations-pour-une-ecriture-inclusive-et-accessible/

C'est pourquoi après un travail collectif entrepris avec @touti,
@rastapopoulos et @Jack31, voici une première proposition pour des
chaînes de langue de Formidable inclusives (en terme de genre) et
accessible, aka sans point médian.

Ce travail a eu le mérite de repenser certains concepts en les précisant.

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

Reviewed-on: https://git.spip.net/spip-contrib-extensions/formidable/pulls/43

Au passage on déclare bien les jointures pour tout le monde comme pour les docs aussi, et le champ vu en exception pareil

Vérifier au moins les liens déjà existant pour mettre vu=oui si ya toujours le modèle trouvé dans le contenu

Issue 42 : améliorer la liaison des formulaires avec un champ vu comme pour les documents : il FAUT savoir quels liens ont été mis à la main et lesquels sont automatiques suivant les modèles dans les textes. Surtout qu'il y avait un bug : ça virait les liens même ceux mis à la main si on les trouvait pas dans les textes. Maintenant ça fait tout comme les documents : si le form n'est plus en modèles dans les textes, ça passe juste en vu=non, mais le lien reste.

[Salvatore] [source:lang/ formidable] Export depuis https://trad.spip.net de la langue en
[Salvatore] [source:lang/ formidable] Export depuis https://trad.spip.net de la langue es
[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] Export depuis https://trad.spip.net de la langue ru
[Salvatore] [source:lang/ formidable] Mise a jour du bilan depuis https://trad.spip.net

pour les filtres de statuts, se baser sur les titres (= etat) plutôt que sur les textes d'institution (=verbe)

Construire dynamiquement les onglets de statut, ce qui permet à n'importe qui d'ajouter ses propres statuts de réponse.
Du coup on perd le pluriel sur les onglets, car seule la forme singulier
est dispo dans la description des objets (et en plus singulier/pluriel
c'est parfois plus complexe pour l'internationalisation)
Fix #41

Quand on va chercher les réponses du visiteur en cours, on ne doit pas forcer à ce qu'il ne puisse que re modifier si déjà publié. Si c'était en modération à priori, sa réponse n'est pas validé par un admin mais c'est sa réponse quand même, elle n'est pas à la poubelle, donc il peut continuer de la modifier si on est en option modifiable.

Version Z pour correction des autorisations, qui fait que quand modération à priori, alors quand un visiteur quelconque répond, c'est bien en proposé, pas publié, comme demandé par la config.

Refonte de l'autorisation editer formulaire moins bazar, là si yavait l'option de liaison auteur ça testait même pas les admins restreints car return direct…

Vraie autorisation correct pour instituer une réponse : avoir le droit d'éditer le form parent ET si pas admin qu'il y ait l'option qui autorise les auteurs simples à modérer les réponses. Et pour modifier les réponses : pas besoin de refaire les mêmes tests : c'est comme instituer donc on l'appelle directement. Du coup il n'y a plus d'utilisation de la mauvaise fonction formidable_auteur_admin_reponse() qui ne faisait pas les bons tests. On la laisse quand même pour rien casser.

Meilleur rangement de formidable_auteur_admin_reponse + prise en compte dedans des admins restreints aussi (mais cette fonction reste encore merdique puisque ne teste pas que CET auteur a le droit pour TEL formulaire, alors que c'est le principal à savoir…)

systématiquement le cas en base.
Par conséquent les comparatifs de md5 pour vérifier des modifs //
peuvent parfois foirer (PRX38, spipfactory, Nat33 via @marcimat).

On résoud cela en
1. Identifiant retrospectivement les saisies
2. S'assurant avant d'enregistrer en base que les saisies soient bien
identifiées