[spip-dev] Coordonnées adresses et découpageS administratifS

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/spip-zone@rezo.net/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. :slight_smile:

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 ?

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 ?

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.

Oui tout à fait, j'ai mis ça un peu à l'arrache, c'était surtout pour la question de principe d'avoir des champs plus génériques.

Mais oui totalement d'accord pour Nomenklatura et trouver mieux ! :slight_smile:

J'aime bien de garder "admin" raccourci, ça reste compréhensible et pas qu'en français (m'enfin les autres champs sont que en français donc bon…), c'est le fait d'ajouter d'autres mots (zone, area, etc) qui fait qu'on comprend mieux.

Pour rappel, les gros trucs comme Google, Paypal, Mapquest etc, yen a plusieurs qui utilisent la même chose : admin_area_X allant de 1 à 4.
https://github.com/paypal/api-standards/blob/master/v1/schema/json/README_address.md#why-admin_area

Si on traduit un peu, nous ça ferait "zone_admin_1", "zone_admin_2" ("niv" n'est pas courant comme "admin", donc je dirais soit "niveau" en entier, soit pas du tout)

La norme HTML5 directement contient aussi une nomenclature de ça (oui oui) pour le système d'autofill : address-levelX de 1 à 4.
https://www.w3.org/TR/html51/sec-forms.html#autofill-field

Ils donnent tous l'exemple, le niveau 1 étant "le comté pour le UK, l'état pour les US, la préfecture pour le Japon, le canton pour la Suisse…".

Yop,

bonjour,

Ils donnent tous l'exemple, le niveau 1 étant "le comté pour le UK, l'état pour les US, la préfecture pour le Japon, le canton pour la Suisse… ».

dans ces cas, le principe du plugin rôles ne pourrait pas aider ?

Claude

"subdivision" c'est pas mal aussi oui, et c'est le terme utilisé par la lib de Drupal qui elle-même utilise celle de Google déjà cité. À priori je pense utiliser cette lib, vraiment super.
https://github.com/commerceguys/addressing/tree/master/resources/subdivision

Par contre le module officiel des adresses de Drupal, qui utilise cette lib de composition/vérification des champs d'adresses, a cette liste de champ, suivant la norme OASIS :
https://www.drupal.org/project/address
(j'ai retiré les champs de noms qui sont un peu à part)

Address line 1
Address line 2
Postal code
Sorting code
Dependent Locality (Neighborhood / Suburb)
Locality (City)
Administrative area (State / Province)
Country

C'est donc plus "zone_administrative" que "subdivision" là…

On voit qu'il nous manque aussi une division qui est SOUS la commune (Dependent Locality) qui est demandé dans certains pays. Et le "Sorting code".
Sinon le reste on l'a bien déjà.

Oui c’est bien zone_administrative aussi.
Moi je suis parti de cette ressource ISO : par exemple pour la Belgique https://www.iso.org/obp/ui/fr/#iso:code:3166:BE
Le plugin Nomenclatures accepte un format d’import pour la table associée et peut renvoyer les informations au format JSON via son API REST.
Je pense que le plugin de Drupal fait plus ou moins la même chose.
La différence c’est que le plugin Nomenclatures est censé être un aggrégateur de codes normatifs (ISO, IANA…) pour les langues, les pays, les monnaies… et un serveur de données via son API REST. J’avais prévu de modifier Pays et/ou Géographie en utilisant Nomenclatures.

Je ne sais pas si ça peut t’aider ou te donner des idées mais voilà un peu le topo.

Je prends le train en retard, et pas mal de messages à lire

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.

Avant de voir apparaître cette version, j’avais l’habitude de surcharger l’intitulé français en « Canton/Département/État » …puis j’ai du systématiquement cacher le nouveau champ tant que la migration n’était pas faite (la région désignant alors un territoire autrement)

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/spip-zone@rezo.net/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.

Il me semble que nombre de grands/gros groupes/sites fonctionnent ainsi… Quand je passe l’interface de Google Contacts en français, il indique par exemple « Code postal » & « Département » là où j’avais « Zip code » & « State » en anglais, et je suis prêt à parier que si je bascule en japonais ça me dira « Préfecture » et en Mandarin « Canton »… Et les différents locuteurs, à l’heure d’Internet, savent faire la correspondance par rapport à leur résidence : pour avoir travaillé avec d’autres pays francophones, j’ai bien vu que les gens remplissaient les champs qui les concernent et qui ne porte pas forcément le même nom chez eux… Je doute qu’il y ait une solution ultime mais je peux me tromper.

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 ».

Nous sommes d’accord, il y a les champs qu’il faut. Juste un souci de nommage (ou pas.)
Par contre, comme cité, « admin_area_1 » se traduit par « zone_administrative_niveau1 » et la zone/aire en question est appelée « subdivision » (ou « division » si on ne veut pas paraître trop France-cemtrée) En tout cas, juste « admin » peut laisser croire qu’on veut unne administrateurice pour quelque raison, ou certaines pourraient penser qu’on demande de quelle administration (préfecture ou sous-préfecture) illes dépendent.

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.

Dans ce cas, go…

À 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 ?)

Normalement ce sont deux concepts différents… Si les 2 sont remplis, ils vont dans les niveaux 1 & 2, et c’est tout.

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 ?)

Ça c’est parce-que historiquement là depuis plus longtemps non ? Et en général, chez moi, les gens y foutaient leur département (sousdivision 1) et non leur région (sousdivision 2)

La refonte des adresses de Coordonnées est presque terminée. Les anciens champs sont migrés, et la génération des champs par pays fonctionnent, aussi bien au chargement qu'après coup en JS, et aussi bien dans un formulaire contenant une seule adresse (editer_adresse quoi) que dans un formulaire pouvant contenir X adresses à la fois (Profils par ex).

En fait pour les adresses, un seul niveau administratif maxi est demandé dans le monde *au dessus* de la ville. En revanche il y en a parfois un *en dessous* et qui parfois est obligatoire (l'arrondissement, le quartier, etc, notamment dans des pays avec des très grandes communes). Il faudrait donc rajouter ce champ ("dependent locality" en anglais, je sais pas trop pour nous…).
Et il faudra gérer le champ "boite_postale" qui n'existe nulle part, pas même en France, et qui est juste un complément à l'adresse : je propose de le fusionner dans le champ "complement".

J'ai un soucis par contre pour ajouter facilement un paramètre au CVT editer_adresse. Il a été généré avec les params par défaut qu'on voit sur les objets, mais qui franchement sont quasiment jamais utiles, et c'est super pénible. Ça rend très compliqué d'ajouter facilement un paramètre à un formulaire (et plus encore rigoureusement impossible l'extension par des sous-plugins de plusieurs options sans se casser les uns les autres). Franchement, tous les CVT (d'objets ou pas) devraient en fait avoir comme seul param un tableau associatif, ça serait bien plus pérenne et extensible. Mais bon… en attendant editer_adresse a ces params :

$id_adresse = 'new', $retour = '', $associer_objet = '', $lier_trad = 0, $config_fonc = '', $row = array(), $hidden = ''

Seuls les 4 premiers sont réellement utilisés. Il me semble que tous les autres sont juste du copier-coller utilisé nulle part dans la vraie vie. Est-ce que des gens ici les utilisent ? Est-ce que dans le cadre d'un changement X de version, on pourrait pas les virer ? (ou au moins les décaler)

Rien que "$config_fonc" par ex, je crois qu'à part celui existant pour les articles (qui déjà est là juste pour 2 pauvres options), il doit y avoir une ou deux utilisations *au monde*, et malgré cette quasi inutilisation flagrante, on se le traine partout sur tous les CVT d'objets, avec impossibilité de rajouter des params sans casser les appels… franchement c'est gavant…
#dette_technique

Coquille, je voulais dire les TROIS premiers seulement. $lier_trad n'est absolument pas utilisé pour les adresses, et ya peu de chance que ça ait une quelconque utilité…

En fait pour les adresses, un seul niveau administratif maxi est demandé dans le monde au dessus de la ville. En revanche il y en a parfois un en dessous et qui parfois est obligatoire (l’arrondissement, le quartier, etc, notamment dans des pays avec des très grandes communes). Il faudrait donc rajouter ce champ (« dependent locality » en anglais, je sais pas trop pour nous…).

Je crois que c’est l’équivalent de certains lieux-dit ou bourgs. En France le problème se présente dans l’autre sens : on indique la localité au niveau habituellement appelé ville, mais il dépend d’un « bureau distributeur » partagé avec une autre localité (du coup ils ont le même « code postal » qui n’est pas discriminant)

Et il faudra gérer le champ « boite_postale » qui n’existe nulle part, pas même en France, et qui est juste un complément à l’adresse : je propose de le fusionner dans le champ « complement ».

Je ne sais pas ce que tu entends par « n’existe nulle part » …mais c’est la seule adresse postale de beaucoup en Afrique de l’Ouest par exemple, où le courrier n’est pas distribué à résidence. Cela existe aussi aux États-Unis ces « postes restantes ».

Et il faudra gérer le champ « boite_postale » qui n’existe nulle part, pas même en France, et qui est juste un complément à l’adresse : je propose de le fusionner dans le champ « complement ».

Je ne sais pas ce que tu entends par « n’existe nulle part » …mais c’est la seule adresse postale de beaucoup en Afrique de l’Ouest par exemple, où le courrier n’est pas distribué à résidence. Cela existe aussi aux États-Unis ces « postes restantes ».

Le service existe encore officiellement en France <https://www.laposte.fr/produits/article/prenez-de-l-avance-sur-le-facteur> et en Belgique <https://www.bpost.be/site/fr/recevoir/lettres-cartes/boites-postales> aussi !

Ce n'est pas un champ existant, dans aucun pays. Quand il y a un service de boite postale, c'est à remplir dans le champ d'adresse de base ou dans la ligne de complément, avec un mot clé (par ex en France c'est "BP" puis un numéro).
https://fr.wikipedia.org/wiki/Adresse_postale#France

D'où le fait que je propose de déplacer les contenus actuels des gens qui auraient utilisé "boite_postale" dans le champ "complement", puis de supprimer "boite_postale".

Je ne sais pas ce que tu entends par « n’existe nulle part »

Ce n’est pas un champ existant, dans aucun pays. Quand il y a un service de boite postale, c’est à remplir dans le champ d’adresse de base ou dans la ligne de complément, avec un mot clé (par ex en France c’est « BP » puis un numéro).
https://fr.wikipedia.org/wiki/Adresse_postale#France

D’où le fait que je propose de déplacer les contenus actuels des gens qui auraient utilisé « boite_postale » dans le champ « complement », puis de supprimer « boite_postale ».

Ah… Je comprends mieux et n’ai pas vraiment d’avis du coup.
J’en étais resté à « vCard 3/4 » <https://tools.ietf.org/html/rfc6350#section-6.3.1> et son homologue « xCard » <https://tools.ietf.org/html/rfc6351>

Bon alors… après maintes péripéties de Git, merci Cédric et Camille, il semblerait que la branche master de Coordonnées contienne enfin la version avec la refonte des adresses.

Je vous invite donc à tester cette version, surtout les gens qui ont déjà des contenus (region, etat_federe, boite_postale…), vu qu'il y a des migrations de champs.

Résumé pour pas tout relire :
- Migration de "region" et "etat_federe" dans "zone_administrative"
- Mapping de #REGION sur #ZONE_ADMINISTRATIVE pour casser un peu moins
- Migration de "boite_postale" dans "complement"
- Ajout d'un champ "localite_dependante", nécessaire dans certains pays
- Utilisation du pays par défaut de la config du plugin Pays
- Intégration de la lib Addressing permettant de générer le bon formulaire correspondant à chaque pays, avec les bons champs, dans le bon ordre, et avec les bons labels
- Modification dynamique en JS pendant la saisie dès qu'on change de pays, pour afficher les champs de ce pays
- Chargement des champs du bon pays quand on édite une adresse existante
- Bon entente avec le plugin Profils, qui sait gérer plusieurs adresses dans le même formulaire, et chaque ensemble de champs est alors bien indépendant, et quand on change le pays, ça change juste les champs associés