From pascale.nalon at mines-paristech.fr Tue May 3 13:48:51 2011 From: pascale.nalon at mines-paristech.fr (Pascale Nalon) Date: Tue, 3 May 2011 13:48:51 +0200 Subject: [koha-Infos] import SUDOC Message-ID: <8EC06475-2CBD-46C5-98D4-3B728F335D91@mines-paristech.fr> Bonjour, Lors du transfert régulier des notices SUDOC dans notre installation Koha, des signes parasites sont générés dans le champ "title" de la table biblio, en lieu et place de l'"@" du SUDOC. L'édition de la notice fait disparaître ces signes. Ces signes bloquent la recherche sur le premier mot significatif du titre dans une recherche par titre. Actuellement, nous procédons à une suppression régulière de ces parasites pour les notices qui n'ont pas été éditées après l'import. Certains d'entre vous connaissent-ils les mêmes difficultés et si oui comment les ont-ils résolues ? Notre version est la 3.00.06.013 cordialement -- Pascale Nalon Bibliothèque de Mines ParisTech 35, rue St Honoré 77300 Fontainebleau Tel : 01 64 69 48 79 -------------- section suivante -------------- Une pièce jointe HTML a été nettoyée... URL: From paul.poulain at biblibre.com Tue May 3 14:19:06 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 03 May 2011 14:19:06 +0200 Subject: [koha-Infos] import SUDOC In-Reply-To: <8EC06475-2CBD-46C5-98D4-3B728F335D91@mines-paristech.fr> References: <8EC06475-2CBD-46C5-98D4-3B728F335D91@mines-paristech.fr> Message-ID: <4DBFF2BA.3010801@biblibre.com> Le 03/05/2011 13:48, Pascale Nalon a écrit : > Bonjour, Bonjour Pascale et tous, > Lors du transfert régulier des notices SUDOC dans notre installation Koha, des signes parasites sont générés dans le champ "title" de la table biblio, en lieu et place de l'"@" du SUDOC. > L'édition de la notice fait disparaître ces signes. C'est un problème de NSB/NSE. Cela signifie que qqc n'a pas été bien mis en place (par nous) parce qu'on sait traiter ce cas. > Ces signes bloquent la recherche sur le premier mot significatif du titre dans une recherche par titre. > Actuellement, nous procédons à une suppression régulière de ces parasites pour les notices qui n'ont pas été éditées après l'import. > Certains d'entre vous connaissent-ils les mêmes difficultés et si oui comment les ont-ils résolues ? Bref, je t'invite à ouvrir un ticket sur la plateforme de maintenance de la société qui fait ton support :D La suite en privé, donc ;-) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From jean.bernon at univ-lyon3.fr Tue May 3 14:35:51 2011 From: jean.bernon at univ-lyon3.fr (BERNON Jean) Date: Tue, 3 May 2011 12:35:51 +0000 Subject: [koha-Infos] RE : import SUDOC In-Reply-To: <8EC06475-2CBD-46C5-98D4-3B728F335D91@mines-paristech.fr> References: <8EC06475-2CBD-46C5-98D4-3B728F335D91@mines-paristech.fr> Message-ID: <6538CC8147CB8E4DBC30E650AA1462170BEFD390@exch-mb3.ad.univ-lyon3.fr> Bonjour Pascale, Sans être totalement sûr, je pense que ces parasites sont les caractères NSB (non sorting beginning) et NSE(non sorting end) utilisés sur plusieurs grandes bases bibliographiques dont le SUDOC. Leur codage hexadecimal est 88/89 en marc 8bits et C298/C29C en UTF8. Nous ne rencontrons pas de problème avec ces caractères. A coup sûr ils sont éliminés de l'affichage des notices (dans Output.pm). Il faut aussi sans doute les éliminer au moment de l'indexation (cela dépend du paramétrage de ton indexation). Je ne pense que le chargeur les élimine (en tout cas visiblement pas sur votre instance). A priori il vaut mieux les garder dans les notices et les éliminer seulement à l'affichage et à l'indexation, mais ça ce discute. Cordialement Jean ________________________________ De : infos-bounces at listes.koha-fr.org [infos-bounces at listes.koha-fr.org] de la part de Pascale Nalon [pascale.nalon at mines-paristech.fr] Date d'envoi : mardi 3 mai 2011 13:48 À : discussions générales générales sur Koha Objet : [koha-Infos] import SUDOC Bonjour, Lors du transfert régulier des notices SUDOC dans notre installation Koha, des signes parasites sont générés dans le champ "title" de la table biblio, en lieu et place de l'"@" du SUDOC. L'édition de la notice fait disparaître ces signes. Ces signes bloquent la recherche sur le premier mot significatif du titre dans une recherche par titre. Actuellement, nous procédons à une suppression régulière de ces parasites pour les notices qui n'ont pas été éditées après l'import. Certains d'entre vous connaissent-ils les mêmes difficultés et si oui comment les ont-ils résolues ? Notre version est la 3.00.06.013 cordialement -- Pascale Nalon Bibliothèque de Mines ParisTech 35, rue St Honoré 77300 Fontainebleau Tel : 01 64 69 48 79 -------------- section suivante -------------- Une pièce jointe HTML a été nettoyée... URL: From fridolyn.somers at progilone.fr Tue May 3 15:06:15 2011 From: fridolyn.somers at progilone.fr (Fridolyn SOMERS) Date: Tue, 03 May 2011 15:06:15 +0200 Subject: [koha-Infos] import SUDOC In-Reply-To: <4DBFF2BA.3010801@biblibre.com> References: <8EC06475-2CBD-46C5-98D4-3B728F335D91@mines-paristech.fr> <4DBFF2BA.3010801@biblibre.com> Message-ID: <4DBFFDC7.6030503@progilone.fr> Bonjour, Ce problème est traité (coté indexation Zebra) par le patch du bug n°6098 (en attente de validation) : http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6098 Ces caractères sont en effet retirés pour l'affichage. Cela a un effet de bord : lors de l'édition d'une notice "à la main", le titre s'enregistre (même s'il n'a pas été modifié) sans ces caractères. Cordialement, -- Fridolyn SOMERS Société PROGILONE 24b, rue Jean Baldassini 69007 LYON +33(0)4.72.76.29.22 fridolyn.somers at progilone.fr Le 03/05/2011 14:19, Paul Poulain a écrit : > Le 03/05/2011 13:48, Pascale Nalon a écrit : >> Bonjour, > Bonjour Pascale et tous, >> Lors du transfert régulier des notices SUDOC dans notre installation Koha, des signes parasites sont générés dans le champ "title" de la table biblio, en lieu et place de l'"@" du SUDOC. >> L'édition de la notice fait disparaître ces signes. > C'est un problème de NSB/NSE. Cela signifie que qqc n'a pas été bien mis > en place (par nous) parce qu'on sait traiter ce cas. >> Ces signes bloquent la recherche sur le premier mot significatif du titre dans une recherche par titre. >> Actuellement, nous procédons à une suppression régulière de ces parasites pour les notices qui n'ont pas été éditées après l'import. >> Certains d'entre vous connaissent-ils les mêmes difficultés et si oui comment les ont-ils résolues ? > Bref, je t'invite à ouvrir un ticket sur la plateforme de maintenance de > la société qui fait ton support :D > > La suite en privé, donc ;-) > From camille.chandra at gmail.com Tue May 3 15:08:28 2011 From: camille.chandra at gmail.com (Camille Chandra) Date: Tue, 3 May 2011 15:08:28 +0200 Subject: [koha-Infos] Retrait de la liste de diffusion Message-ID: Bonjour, Pouvez-vous me retirer de la liste de diffusion. Merci Cordialement Camille C. -------------- section suivante -------------- Une pièce jointe HTML a été nettoyée... URL: From paul.poulain at biblibre.com Tue May 3 15:11:26 2011 From: paul.poulain at biblibre.com (Paul Poulain) Date: Tue, 03 May 2011 15:11:26 +0200 Subject: [koha-Infos] Retrait de la liste de diffusion In-Reply-To: References: Message-ID: <4DBFFEFE.4030402@biblibre.com> Le 03/05/2011 15:08, Camille Chandra a écrit : > Bonjour, Bonjour, > Pouvez-vous me retirer de la liste de diffusion. Pour vous désinscrire, il suffit de cliquer sur le lien dans la signature : > https://listes.koha-fr.org/cgi-bin/mailman/listinfo/infos et de suivre ce qui est indiqué. Cordialement -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 From frederic at tamil.fr Wed May 4 09:19:12 2011 From: frederic at tamil.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_Demians?=) Date: Wed, 04 May 2011 09:19:12 +0200 Subject: [koha-Infos] import SUDOC In-Reply-To: <4DBFF2BA.3010801@biblibre.com> References: <8EC06475-2CBD-46C5-98D4-3B728F335D91@mines-paristech.fr> <4DBFF2BA.3010801@biblibre.com> Message-ID: <4DC0FDF0.4090301@tamil.fr> > La suite en privé, donc ;-) Nonobstant toute considération d'ordre privée :-), il ne serait pas inintéressant de discuter du sort à réserver à ces fameux caractères NSB et NSE... De multiples tentatives de phagocytage ont été faites. A chaque fois, ils réapparaissent ici ou là. C'est une discussion assez technique qui concerne les développeurs mais qui intéresse également les bibliothécaires, me semble-t-il. Les NSB/NSE sont gênants à l'affichage, à l'indexation et dans les champs des tables MySQL (voir premier message de Pascale Nalon). Ce qui a pu être fait jusque-là : 1. Suppression ciblée à l'affichage dans les titres via la feuille de style XSL. 2. Suppression globale à l'affichage via le code Perl qui renvoie toutes les pages de Koha (module Output.pm) 3. Suppression dans les index de Zebra au moyen d'une configuration appropriée des règles d'indexation. 4. Suppression dans les notices bibliographiques avant leur chargement dans Koha. C'est ce que peut faire un chargeur SUDOC, BNF, Electre ou réseau. D'où certaines questions. D'abord faut-il garder les NSB/NSE ? En les éliminant des notices, on règle une fois pour toute le problème. On peut considérer que ce n'est pas bien grave dans la mesure où, pour le moment, Koha ne s'en sert pas pour créer les clés de tri des titres, mais ça peut changer et en les éliminant on appauvrit son catalogue. Ensuite, certaines de ces solutions sont redondantes et impactent les performances du système. 1 et 2 font la même chose. 2 applique une expression régulière sur toute la longueur de toutes les pages renvoyées par Koha, pas seulement sur le bloc contenant la notice bibliographique, avec l'effet de bord signalé, à savoir la disparition des caractères mêmes dans la page de saisie des notices, là où justement on voudrait peut-être les conserver. Le problème signalé par Pascale Nalon -- NSB/NSE dans le champ title de la table biblio -- n'est résolu que par 4. En effet, ce champ biblio.title est pour le moment la copie exacte de 200$a. Il faudrait éliminer NSB/NSE au moment de la copie en 200$a si on voulait à la fois conserver les NSB/NSE dans ses notices MARC et avoir un champ de la table MySQL qui soit utilisable. Cordialement, -- Frédéric DEMIANS http://www.tamil.fr/u/fdemians.html From jean.bernon at univ-lyon3.fr Wed May 4 10:41:00 2011 From: jean.bernon at univ-lyon3.fr (BERNON Jean) Date: Wed, 4 May 2011 08:41:00 +0000 Subject: [koha-Infos] RE : import SUDOC In-Reply-To: <4DC0FDF0.4090301@tamil.fr> References: <8EC06475-2CBD-46C5-98D4-3B728F335D91@mines-paristech.fr> <4DBFF2BA.3010801@biblibre.com>,<4DC0FDF0.4090301@tamil.fr> Message-ID: <6538CC8147CB8E4DBC30E650AA1462170BEFE8D5@exch-mb3.ad.univ-lyon3.fr> Cette discussion quoique technique concerne en effet tout à fait les bibliothécaires. En gros il y a trois méthodes pour avoir des tris corrects des zones titre dans un catalogue informatisé : 1 - L'usage de liste d'articles qui sont éliminés pour faire l'indexation et les tris. Deux difficultés : a) il vaut mieux avoir des listes par langue b) même avec des listes par langue on n'échappe jamais à des cas où l'élimination de l'article n'est pas pertinente. 2 - L'usage d'un indicateur avec le nombre de caractères du début du titre qui ne doivent pas être pris en compte pour les tris. Cette technique propre à LCMARC est efficace à condition que le catalogueur ne fasse pas d'erreur. 3 - L'usage de NSB/NSE pour délimiter la zone à ne pas trier. Même remarque que pour la technique précédente. La troisième technique reste utilisée par la plupart des grandes bases nationales dont les deux principales en France, SUDOC et BnF. Elle est censée régler tous les cas de figure et être utilisable dans n'importe quel format marc et dans n'importe quelle zone marc. Je suis plutôt partisan de garder les NSB/NSE dans nos données parce que de manière générale les catalogues survivent à plusieurs logiciels et que des données qui posent difficulté à un logiciel peuvent se révéler indispensables dans le suivant. En même temps il est vrai qu'on peut très bien les regénérer (avec des risques d'erreur sur les cas où ils sont le plus utiles) à l'occasion d'une migration. Les garder n'est donc pas un dogme, même si cela semble préférable. Cordialement Jean Bernon ________________________________________ De : infos-bounces at listes.koha-fr.org [infos-bounces at listes.koha-fr.org] de la part de Frédéric Demians [frederic at tamil.fr] Date d'envoi : mercredi 4 mai 2011 09:19 À : 'paul POULAIN'; discussions générales sur Koha Objet : Re: [koha-Infos] import SUDOC > La suite en privé, donc ;-) Nonobstant toute considération d'ordre privée :-), il ne serait pas inintéressant de discuter du sort à réserver à ces fameux caractères NSB et NSE... De multiples tentatives de phagocytage ont été faites. A chaque fois, ils réapparaissent ici ou là. C'est une discussion assez technique qui concerne les développeurs mais qui intéresse également les bibliothécaires, me semble-t-il. Les NSB/NSE sont gênants à l'affichage, à l'indexation et dans les champs des tables MySQL (voir premier message de Pascale Nalon). Ce qui a pu être fait jusque-là : 1. Suppression ciblée à l'affichage dans les titres via la feuille de style XSL. 2. Suppression globale à l'affichage via le code Perl qui renvoie toutes les pages de Koha (module Output.pm) 3. Suppression dans les index de Zebra au moyen d'une configuration appropriée des règles d'indexation. 4. Suppression dans les notices bibliographiques avant leur chargement dans Koha. C'est ce que peut faire un chargeur SUDOC, BNF, Electre ou réseau. D'où certaines questions. D'abord faut-il garder les NSB/NSE ? En les éliminant des notices, on règle une fois pour toute le problème. On peut considérer que ce n'est pas bien grave dans la mesure où, pour le moment, Koha ne s'en sert pas pour créer les clés de tri des titres, mais ça peut changer et en les éliminant on appauvrit son catalogue. Ensuite, certaines de ces solutions sont redondantes et impactent les performances du système. 1 et 2 font la même chose. 2 applique une expression régulière sur toute la longueur de toutes les pages renvoyées par Koha, pas seulement sur le bloc contenant la notice bibliographique, avec l'effet de bord signalé, à savoir la disparition des caractères mêmes dans la page de saisie des notices, là où justement on voudrait peut-être les conserver. Le problème signalé par Pascale Nalon -- NSB/NSE dans le champ title de la table biblio -- n'est résolu que par 4. En effet, ce champ biblio.title est pour le moment la copie exacte de 200$a. Il faudrait éliminer NSB/NSE au moment de la copie en 200$a si on voulait à la fois conserver les NSB/NSE dans ses notices MARC et avoir un champ de la table MySQL qui soit utilisable. Cordialement, -- Frédéric DEMIANS http://www.tamil.fr/u/fdemians.html _______________________________________________ Infos mailing list Infos at listes.koha-fr.org https://listes.koha-fr.org/cgi-bin/mailman/listinfo/infos From Jean-Manuel.Broust at univ-lyon2.fr Wed May 4 17:16:01 2011 From: Jean-Manuel.Broust at univ-lyon2.fr (Jean-Manuel BROUST) Date: Wed, 4 May 2011 17:16:01 +0200 (CEST) Subject: [koha-Infos] =?iso-8859-1?q?r=E9ception_dans_koha_3=2E2?= Message-ID: <3826735.59803.1304522164005.JavaMail.root@co4> Bonjour à tous, Nous utilisons la version 3.2.0 de Koha. Nous nous posons quelques questions sur la réception : Au fur et à mesure qu'on les réceptionne, les commandes en attente (pending orders) passent dans un deuxième tableau "déjà réceptionné" (already received). Très bien. Si l'on quitte la page de réception et qu'on revient sur le bon de livraison, les documents "déjà réceptionnés" ont disparu. Idem si l'on affiche les commandes en cours chez un fournisseur, le tableau des documents "déjà réceptionnés" pour ce fournisseur n'apparait jamais. Est ce un fonctionnement habituel de KOHA ou un bug ? Enfin, si l'on s'est trompé sur le prix lors de la réception, comment corriger ? Il semblerait qu'on ne puisse pas revenir sur les "détails financiers" après réception. Merci de votre aide, Jean-Manuel Broust Service commun de documentation - Lyon 2 jean-manuel.broust at univ-lyon2.fr 04 78 69 77 47 (lun. mardi, vendr.) 04 78 77 31 69 (mer. jeud.)