[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

calculer_voir_reponses : prendre en compte le cas des saisies fichiers, où il faut installer le lien de téléchargement

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

[Salvatore] [source:lang/ formidable] Export depuis https://trad.spip.net de la langue de
            La langue 'de' devrait être supprimée car trop peu traduite (34.39 %)

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

Close #35, close #36
fix #32, fix #34

date_soumission devient date_envoi, plus proche du langage courant, tout
en évitant de confondre avec date_reponse qui pourrait être la date de
l'objet.
On fait pas de migration de structure SQL car il s'agissait d'une branche de dev qui n'a existait que 24h et n'a a priori été déployé que chez le dev.

close #33

bonus: pouvoir suffixer automatiquement les sujets d'email avec [Modification d'une réponse], si pertinent

issue #33 : modifier l'entête d'email pour indiquer la date de la précédente réponse en cas de modif

issue #32 champ date_soumission : déclaration + installation + remplissage avec la date actuelle si on est sur une ancienne version

On profère l'appelation date_soumission à date_reponse car date_reponse
est peu clair, puisque c'est un champ d'un objet _reponse.
date_soumission permet de dire : "là date à laquelle la réponse a été
soumise"

oups