Re: Coordonnées adresses et découpageS administratifS

Ou carrément mettre le terme administrative qui montre au mieux qu'on est
pas en train de parle d'admin sys ou autre.
Donc zone_administrative_1 et 2.

++
Eric


Le jeu. 6 févr. 2020 à 11:54, Cerdic <[email protected]> a écrit :

> Je trouve que admin_1 et admin_2 sont des noms de champs pas du tout
> parlant et qui font penser à des champs d’administration de la base.
> Peut-être zone_admin_niv1 et zone_admin_niv2 ?
>
> --
> Cédric
> Le 6 févr. 2020 à 11:29 +0100, RastaPopoulos <[email protected]>, a
> écrit :
>
>
> Hello,
> on a un problème avec la généricité de la table spip_adresses pour
> permettre à des gens de remplir des adresses correctes dans plusieurs pays
> (Chili, Japon…).
>
> ## Problème
>
> En effet, à la base il y avait juste un champ "region", mais c'était
> vraiment conçu de manière quasi franco-française. Ensuite, Touti a eu
> besoin d'un autre découpage pour un pays (le Canada) qui n'a pas de
> "régions". Après discussion, un terme *semi* générique a été proposé
> (etat_federe) pour les pays qui n'ont pas des régions mais vraiment des
> états. Sauf que ce n'est pas générique non plus, ça ne concerne que les
> pays fédéraux. Le Japon a juste des "préfectures" par exemple.
> https://www.mail-archive.com/[email protected]/msg40953.html
>
> Or un même site peut permettre aux gens *de plusieurs pays* de remplir
> leurs adresses (exemple concret : un site japonais où des gens peuvent
> s'inscrire qu'ils soient au Japon, aux États-Unis, etc). Il n'est donc pas
> possible de juste surcharger le label, puisque ça ne va marcher que pour un
> pays précis, alors que le site n'est pas mono-pays.
>
> ## Solution dans la base
>
> Tout d'abord il faut savoir comment arriver à enregistrer les infos en
> base pour n'importe quel pays.
>
> On aimerait faire les moins de modifications possibles, en restant simple,
> le moins de champs.
>
> Il ne semble pas pertinent d'ajouter à chaque fois un champ différent pour
> chaque nouveau cas qu'on va rencontrer suivant tous les pays du monde,
> c'est infini et in-maintenable. Dans Google et OSM, il y a plutôt des
> champs génériques du type : "admin_area_1", "admin_area_2", ce qui
> signifique "découpage administratif de niveau X". Pour les adresses
> postales, à priori il n'y a jamais plus de 2 niveaux maximum en dehors de
> la voie/numéro et de la commune, et encore, même je crois qu'un seul suffit…
>
> L'idée serait donc peut-être d'avoir uniquement un champ "admin_1" et
> possiblement "admin_2" (à vérifier si utile), et de ne plus avoir ni
> "region" ni "etat_federe", qui de fait sont tous les deux le premier niveau
> administratif de plusieurs pays, donc devrait être dans "admin_1".
> Ce serait une nouvelle version majeure, donc pouvant casser des choses.
> Dans ce cas, des alias seraient codés quand même, pour que #REGION et
> #ETAT_FEDERE sortent la valeur de #ADMIN_1, afin de ne pas casser les
> squelettes.
>
> À priori il n'y a pas de cas où les gens auraient à la fois "etat_federe"
> ET "region" remplis. Est-ce que vous pensez qu'on peut déplacer les valeurs
> dans un nouveau champ "admin_1" en mise à jour ? (si jamais les deux sont
> remplis ont fait quoi, on pourrait les fusionner avec une virgule entre eux
> ?)
>
> ## Ergonomie
>
> Ensuite il faut résoudre le problème de l'interface de remplissage : le
> label doit être un truc humain.
>
> Pour les cas où le site est mono-pays, la config du plugin pourrait
> 1) avoir une valeur vraiment défaut en dur, dans tous les cas ("Région"
> car le plus courant pour celleux qui mettent à jour ? Car le plus
> d'utilisation en France pour l'instant ?)
> 2) permettre de configurer le label par défaut du champ "admin_1" avec une
> valeur libre
>
> Ainsi on ne casse à peu près pas l'existant.
>
> Le plus compliqué ensuite, quand on permet aux gens de choisir le pays de
> l'adresse ! Actuellement : RIEN n'est fait, on continue d'afficher les
> mêmes champs pour tout le monde, donc ça ne peut que être mieux. :)
>
> Pour ce point on a le projet de développer un système qui va changer
> dynamiquement les champs à demander suivant le pays, avec un système
> extensible où on va pouvoir déclarer l'ordre et les labels des champs
> attendus pour chaque pays (sachant que dans la base, ça sera toujours les
> mêmes champs génériques : c'est pour ça qu'il faut trouver une structure de
> base commune où on peut tout enregistrer !)
> C'est ce que fait Stripe par exemple quand on paye chez eux (screencast
> ici : https://cloud.mukt.fr/index.php/s/TicLCxtZFPEc2nx)
>
> Des remarques ? Des loups à soulever ?
>
> --
> RastaPopoulos
>
> _______________________________________________
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip
>
> _______________________________________________
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip