Sujet: Conversion de caractères à l'import gedcom

[BLefebvre]

Je reçois un ged dans lequel tous les noms sont en minuscules, ou un autre dans lequel tous les prénoms sont en majuscules, ce qui ne correspond pas à ce que j'ai mis dans mes préférences. D'où le passage par un traitement de textes pour modifier tout ça dans le ged. Pour les prénoms, j'ai une moulinette que j'enrichis au fur et à mesure, mais pas pour les noms. C'est long et source d'oublis ou d'erreurs.

Est-ce que, à l'import, ancestrologie ne pourrait pas comparer le contenu du ged avec les préférences et proposer, en option, de faire la conversion?

[DDdeBerdeux]

Il me semble que le BOA (au moins dans sa version 1.7 sait faire tout çà, option mise à jour de masse, modifications de la casse?

A+

André

[BLefebvre]

Faudra que je regarde, parce que je ne me suis jamais servi du BOA.

Mais ce qui est fait à l'import n'a plus à être fait ensuite. Autant mettre les choses au carré d'emblée, plutôt que devoir faire des manipulations plus ou moins risquées.

[DDdeBerdeux]

Je critique quelques fois le BOA parce qu'il n'a pas toutes les possibilités des vrais outils de requête comme IBOConsole ou IBEasy, mais il est très pratique pour exécuter certaines fonctions spéciales préprogrammées. Et les modifications de la casse en font partie.

Je viens de m'apercevoir en voulant vérifier la casse des prénoms, que l'état statistique des prénoms, affichait les prénoms en mettant en majuscule la première lettre et en minuscules la suite. Le problème c'est qu'il ne considère que la virgule comme séparateur, et non l'espace. Si bien qu'il me classe dans le prénom "André rené marcel jean". Encore une procédure à modifier pour la version 4.005?

A+

André

[BLefebvre]

Pour en revenir à ma demande, c'est vrai qu'on se demande pourquoi faire simple quand on peut faire compliqué.

Pourquoi changer cent noms en import d'un gedcom quand on peut en changer dix mille dans la base qui n'en ont pas besoin?

[Horemans]

Pourquoi changer cent noms en import d'un gedcom quand on peut en changer dix mille dans la base qui n'en ont pas besoin?

Parce que chacun fait comme il veut. Beaucoup préfèrent les noms en majuscules, pas tous.

A l'extrême, quand tu récupères un gedcom, demande le dans la casse que tu souhaites.

Il y a un outil qui donne le choix, je ne voie pas l'intérêt dans créer un second. Je préfère que le BOA soit amélioré. Aucun autre programme du commerce n'offre une telle facilité de modifications de masse dans la base.

Et 10000 modifs en 1mn, çà vaut le coup



En tous cas, je trouve qu'il y a des priorités supérieures.

[BLefebvre]

1) Il y a des préférences pour que chacun fasse comme il l'entend, pourquoi n'en tient-on pas compte à l'import. J'ai suggéré que ce soit en option, non une obligation. Il y a bien l'option pour les noms à particule de la laisser comme ça ou de la mettre derrière le nom. Faut être cohérent.



2) J'ai pris l'exemple des noms en minuscules pour les convertir en majuscules, je n'ai pas dit que tout le monde préfère comme ça. Tu inverses si tu veux, la question reste.



3) Si le code existe déjà, il doit être récupérable. Ce n'est pas à un vieux développeur comme moi qu'on apprend à le faire. Ceci dit, ne connaissant pas le source d'ancestrologie, je ne présume de rien, et donc je ne sais pas si c'est faisable ou pas.



4) Je n'ai pas dit que c'était prioritaire. Corriger les bogues restantes doit passer avant.



5) Respecter le gedcom en export est pour moi plus prioritaire qu'améliorer un outil intéressant certes, mais annexe qu'est le BOA. Voir les problèmes de gedcom sur les autres fils. J'en ai moi même un que j'ai soumis récemment (pointeur sur "rien"), et un autre que je dois analyser pour voir quel est exactement le problème avant de le soumettre (du style conjoint manquant alors qu'il est dans ma base).

[DDdeBerdeux]

Pour en revenir à ma demande, c'est vrai qu'on se demande pourquoi faire simple quand on peut faire compliqué.

Pourquoi changer cent noms en import d'un gedcom quand on peut en changer dix mille dans la base qui n'en ont pas besoin?

Parce qu'un traitement par SQL dans la base (ex: update INDIVIDU set NOM=UPPER(NOM)), est plus rapide et plus simple à mettre en oeuvre que dans le programme lors de l'importation.

A+

André

[Lau]

Désolé pour la parenthèse que je poursuis ici :

Je viens de m'apercevoir en voulant vérifier la casse des prénoms, que l'état statistique des prénoms, affichait les prénoms en mettant en majuscule la première lettre et en minuscules la suite. Le problème c'est qu'il ne considère que la virgule comme séparateur, et non l'espace. Si bien qu'il me classe dans le prénom "André rené marcel jean". Encore une procédure à modifier pour la version 4.005?

Non : c'est voulu : le séparateur est la virgule, pas l'espace. Certains prénoms composés n'ont pas de trait d'union (ex prénoms vietnamiens). Les séparer en 2 est un non sens... La règle dans Ancestrologie (et peut-être aussi dans le Gedcom d'ailleurs) est la virgule comme séparateur des prénoms.



Fin de la parenthèse

[Lau]

3) Si le code existe déjà, il doit être récupérable. Ce n'est pas à un vieux développeur comme moi qu'on apprend à le faire. Ceci dit, ne connaissant pas le source d'ancestrologie, je ne présume de rien, et donc je ne sais pas si c'est faisable ou pas.

Le vieux développeur n'a pas pris en compte que l'import est un traitement Delphi unitaire (ligne Gedcom par ligne gedcom) et le BOA effectue une mise à jour de masse après import. Et une fois le Gedcom importé, les nouvelles fiches sont mélangées aux anciennes. La reprise du SQL du BOA n'est donc pas possible.

En revanche, le BOA te permet d'être beaucoup plus fin sur les modifications de patronymes a posteriori (tu as même le droit de changer d'avis plusieurs fois   )



Mais cela n'empêche effectivement pas que Philippe implémente une conversion (facultative) à la volée lors de l'import... KOMSA tout le monde est content...  

[Ransac]

Mais cela n'empêche effectivement pas que Philippe implémente une conversion (facultative) à la volée lors de l'import... KOMSA tout le monde est content...  

je crois qu'il y a plus urgent dans les import/export que d'ajouter une routine de conversion ; d'autant que le BOA le fait très bien et rapidement !

[DDdeBerdeux]

Je rouvre les parenthèses entrouvertes par Laurent, juste pour dire que YB avait règlé ce problème de séparateur de prénoms dans Webexport, en laissant à l'utilisateur le choix du séparateur qu'il utilise. Cà me semble le plus judicieux. Ou bien il faut mettre dans le mode d'emploi, que le séparateur de prénoms est obligatoirement la virgule. N'y a-t-il pas eu dans le passé une discussion sur ce sujet?

Fermez la parenthèse.

A+

André

[Ransac]

N'y a-t-il pas eu dans le passé une discussion sur ce sujet?

si, même plusieurs !

j'ai le souvenir qu'il avait été largement suggéré d'utiliser la virgule comme séparateur. Dans le temps, j'utilisais l'espace, j'avais passé 2 soirées à éditer toutes mes fiches pour mettre des virgules ! (le BOA n'existait pas encore ou venait juste de paraitre et personne n'avait pondu de routine SQL pour régler le problème !)

Je crois que certains avaient parlé de faire un export GEDCOM pour faire une routine automatique sur le GEDCOM (VisualBasic ?)



Donc pour moi le problème est réglé, c'est la virgule le séparateur !

[DDdeBerdeux]

personne n'avait pondu de routine SQL pour régler le problème !)

Bof, çà ne doit pas être si difficile. Mais çà ne serait pas une requête, mais une procédure stockée dans la base à exécuter à partir du BOA par un select * from PROCEDURE(ancien séparateur, nouveau séparateur). Si çà vous intéresse, on peut mettre çà dans le prochaine mise à jour de la base.

A+

André

[Bruno T.]

Bonsoir,

Je vous rappelle que mi-juin, j'ai traité le problème de formatage des noms et prénoms lors de la saisie, et le problème des séparateurs de la manière suivante (en substance) suite à diverses réflexions:

- si on a , ou ; suivi ou pas d'espace on remplace par virgule+espace

- si on a espace pas suivi de espace ou - ou , ou ; on met l'espace sinon rien

En conclusion, c'est la virgule+espace qui devrait être la séparation standard a mon idée.

(Cette action ne se fait qu'avec la préférences 1ere lettre en majuscule, oubli ou autre, je ne me souviens plus)

La procédure que j'avais fourni à Philippe pourrait surement être réutilisée, mais il lui faut le temps de s'y pencher.

[Ransac]

En conclusion, c'est la virgule+espace qui devrait être la séparation standard a mon idée.

c'est ce que je voulais dire en disant virgule, pour moi la virgule se doit d'être toujours suivi d'une espace !

Sinon, au rique de me répéter, c'est effectivement ce qui avait été décidé comme séparateur standard des prénoms dans les discussions d'autrefois !

[BLefebvre]

On a dévié du sujet.

Je viens donc d'essayer ce BOA en pour changer la casse des patronymes en majuscules.

1 minute pour 10000 personnes, qu'il a dit le monsieur.

Au bout de dix minutes, j'ai du tuer ancestrologie par le gestionnaire de tâches, parce qu'il ne me rendait pas la main, et que je pouvais plus rien faire dedans. L'ordinateur n'était pas bloqué, j'ai pu entrer dans le menu démarrer et lancer un autre programme qui a fonctionné.

J'ai relancé ancestrologie, et je n'ai plus de patronymes en minuscules.

Par contre, dans mon BOA, je n'ai  pas vu la possibilité de changer les prénoms en minuscules.

[Bruno T.]

Bonjour,

Je ne pense pas que l'on ai vraimenent dévié,

Le traitement de masse de la casse des Noms et Prénoms, doit aussi intégrer la question des séparateurs.

Pour ce qui est de la mise en minuscule des Prénoms, il en est encore plus question, car si on veut en minuscule, on désire surement la 1ere lettre en majuscule, or cela est conditionné à un certain nommbre de règles (séparateur, particules, etc) qu'il faut prendre en compte pour cette reprise.

Et c'est ce que je pense qu'il avait était fait en juin dans la saisie.

Si ces règles conviennent, et si quelqu'un désire les mettre en oeuvre dans le BOA ou autre (en attendant mieux), on peut en discuter.

[BLefebvre]

Si, on a dévié. J'ai posé une question simple, et il m'a été répondu avec des considérations politico-pseudo-techniques n'ayant aucun rapport. Un peut comme si, montant dans une voiture que vous ne connaissez pas, vous demandez si le clignotant est à droite ou à gauche, et on vous répond avec les avantages et inconvénients d'avoir un moteur longitudinal ou transversal.



Je reprend donc depuis le bédut.



J'ai un gedcom que j'importe dans ancestrologie, et je demande s'il est possible de tenir compte des préférences que j'ai déclaré dans ancestrologie concernant la casse des nom et prénoms. On me répond BOA et SQL dont je n'ai rien à f..tr.



Voici ce que je trouve dans un gedcom :



1 NAME Jean Philippe François /de BAILLIENCOURT DIT COURCOL/



1 NAME Berthe Clémence Pauline /de LATRE du BOSQUÉAU/



J'ai volontairement pris des noms à particule qui n'ont rien à faire dans l'histoire. Dites moi où se trouve le problème de séparer les nom et prénoms puisque c'est déjà fait. Je ne demande pas de faire l'analyse de tout le fatras qu'on peut trouver dans un gedcom, mais d'utiliser ce qui est dedans, si c'est possible. Mais si vous ne savez pas qu'entre NAME et /, c'est le prénom, et entre les deux /, c'est le nom, inutile de perdre votre temps à me répondre à coté de la plaque.



Maintenant, c'est au développeur à dire si c'est faisable ou pas, pas à ceux qui n'ont pas mis le nez dans le code.



Bon dimanche à eux quand même, pour ce qu'il en reste.

[Horemans]

Pourquoi es-tu aussi agressif !

J'ai exprimé un avis différent du tien et non moins réversible. Le forum est fait pour donner son avis, discuter et enfin choisir.

Je trouve agressif pour un ancien développeur (j'en suis aussi), de n'avoir rien à faire du travail des autres développeurs, surtout quand ce travail répond, même partiellement à ta demande. Nul besoin de faire du SQL dans le BOA, les fonctions préprogrammées font partie du logiciel.

Alors ... un peu de sérénité ... c'est pas la guerre quand même !  

[BLefebvre]

Je me suis énervé, c'est vrai. D'ailleurs, j'ai été prendre l'air un moment.

Pour le développement, je travaille dans la vente par correspondance, où on traite des millions d'adresses, et il  faut qu'elles soient carré dans les fichiers. Ca prend le temps qu'il faut en traitement de vérification et de mise aux normes (il n'y a pas que le nom, il y a aussi l'adresse), mais c'est fait une fois pour toutes, à la saisie initiale. Cette saisie s'est faite suivant l'évolution des systèmes, en assembleur, en PL/1, en cobol, en basic, en pascal, en windev, en java. Alors me sortir des considérations de langage, s'il vous plait, pas à moi.

Maintenant, si ce que j'ai demandé n'est pas faisable, on tire un trait dessus.

[Bruno T.]

Ce n'est pas faisable dans l'état actuel du programme.

[BLefebvre]

Enfin une réponse claire et nette.

[DDdeBerdeux]

Maintenant que les esprits sont calmés, peut-être pourrions-nous rouvrir la parenthèse Bruno.

Pourquoi ne pourrais tu mettre en procédure stockée ta méthode? Et l'utiliser dans des triggers sur la table. Il y a un problème à surmonter parce que on ne sait pas (moi du-moins) depuis une procédure lire la BDR pour connaître les préférences de l'utilisateur concernant les formats. Ne pourrait-on proposer à PCM d'enregistrer certains paramètres dans la base au lieu de la BDR, dans la table dossiers par exemple,ou dans la table T_VERSION_BASE en ajoutant les champs nécessaires?

Pour décoder la date saisie en année et date, j'ai ajouté à la table des "token_date" un type_tag = 23 mémorisant l'ordre jour / mois/ année utilisé (chaîne "DMY" en français, "MDY" en anglais), et j'attend une réponse de PCM sur cette proposition d'ajouter un tag 23, accessible depuis la fiche "mots clés utilisés dans les dates".

J'ai l'impression que blefebvre n'a pas la dernière version 1.7 du BOA (il n'en est pas question sur le site Ancestrologie, et je n'en connais l'existence que par le forum BOA), car il devrait y trouver la fonction "Mettre les prénoms en minuscule". Avec un gros    parce s'il utilise la base du point 11 du site, il y manque la procédure PROC_LR_MODIF_CASSE_PRENOM.

A+

André

[BLefebvre]

Je suis effectivement en version 1.5.

J'ai bien dormi, j'ai fait de beaux rêves, je n'ai pas fait de cauchemards avec ces fichus prénoms. Je vois ce matin que j'ai oublié de remercier macpc pour sa réponse, ce que je fais maintenant.

Si l'utilisation du BOA est un moyen aussi simple qu'efficace pour faire des corrections dans la base, pourquoi pas, mais je n'ai jamais eu vraiment le temps de m'y plonger. Je rappelle le petit problème que j'ai eu : le BOA ne m'a pas rendu la main lors de la transformation de la casse sur les noms, et j'ai du tuer ancestrologie pour en sortir. Serait-ce à cause de la version?

[DDdeBerdeux]

Serait-ce à cause de la version?

Je ne saurai vous dire. Et même à lire le fil http://www.ancestrologie.org/forum/index.php?topic=4325.0&postdays=0&postorder=asc&start=0 annonçant la version 1.7, affirmer que ce sera mieux avec cette version. Certains signalent des instabilité ou erreurs du même style que ce que vous avez eu pour la 1.5.

Mais est-ce dû au BOA ou à une procédure qu'il exécute dans la base? Ce que je constate, c'est qu'il existe des bases qui bien qu'ayant en principe été migrées à la dernière version, ne contiennent pas les mêmes procédures ou que des tables de référence ne sont pas à jour. L'absence ou la non mise à jour de la base, peut très bien compromettre des fonctions du logiciel comme du BOA. C'est ce manque de rigueur, ce côté amateur pas dans le bon sens du mot qui m'inquiette.

A+

André