Recent files
moteur de recherche
Avec Google sur Yetanother...
http://www.google.com/search?q=poedit&Overview=1&as_sitesearch=http%3A%2F%2Fwww.yetanothercommunitysystem.com%2F&Overview=1&num=100&sa=Search
Avec YACS
http://www.yetanothercommunitysystem.com/yacs/search.php?search=poedit
Où est le problème?
N.B. Les résultats trouvés dans yacs correspondent à cet article seulement qui possède le mot-clé dans le titre alors que google en trouve d'autres.
Bernard from nearby-an-airport Associate 6555 posts registered on Sep. 12 2003 |
Il faudra sans doute faire évoluer YACS pour améliorer les fonctions de recherche, et une option intéressante à considérer serait d'accepter un moteur extérieur, type Google ou autre. Ceci étant, le moteur interne, tout simpliste qu'il est, basé sur MySQL, rend tout de même bien des services. En environnement intranet, lorsque le serveur n'est pas visible par Google, le moteur interne reste une fonctionnalité précieuse. De plus, les robots extérieurs sont considérés par YACS comme des surfeurs anonymes. Ils n'ont donc pas accès à toutes les pages. Le moteur de recherche interne considère aussi les pages protégées, en fonction du statut du surfeur. | ||||||||||||||||||||||||||||||||||||||||||||
Agnès from le Grésivaudan (grenoble-chambéry) Associate 2007 posts registered on Feb. 13 2006 |
Bernard : Pour autant, comment expliquer que la recherche interne se limite à un article, alors que google renvoie plusieurs entrées, où le mot est trouvé parmi les commentaires (ce qui ne semble pas le cas pour la recherche interne). Agnès Il n'y a pas de problèmes, que des solutions. | ||||||||||||||||||||||||||||||||||||||||||||
| Bernard from nearby-an-airport Associate 6555 posts registered on Sep. 12 2003 |
Agnès : Dans une version précédente de YACS le moteur interne recherchait aussi dans les commentaires, mais la présentation des résultats laisse à désirer. Au lieu de lister les commentaires trouvés, il faudrait sans doute présenter les fils de discussion associés. Pour réactiver la recherche dans les commentaires, retirer les caractères '//' ad hoc dans search.php. | ||||||||||||||||||||||||||||||||||||||||||||
| Vinc from Bruxelles Member 114 posts registered on Mar. 8 2006 |
Merci pour ces réponses. Je pense qu'effectivement, YACs est en perpétuelle mutation. Peut-être pourrait-on réfléchier à un système d'indexations style lucene (PHP via javabridge) ou index server (pour windows seulement) qui permettrait aussi d'indexer le contenu des documents annexes? Mais c'est aussi un chantier difficile. | ||||||||||||||||||||||||||||||||||||||||||||
| Vinc from Bruxelles Member 114 posts registered on Mar. 8 2006 |
Bernard : Peut-être peut-on rendre cette recherche dans les commentaires optionnelle? | ||||||||||||||||||||||||||||||||||||||||||||
| Bernard from nearby-an-airport Associate 6555 posts registered on Sep. 12 2003 |
Vinc : Je crois qu'il faudrait vraiment renforcer YACS sur cette fonction. La vie communautaire fait que de plus en plus d'apports intéressants se font dans les commentaires, d'où l'intérêt de les intégrer dans les recherches. La vraie question est plutôt de définir comment afficher les résultats. Lister brutalement les commentaires trouvés est un peu court, il faudrait remonter au niveau fil de discussion à mon avis. | ||||||||||||||||||||||||||||||||||||||||||||
| Vinc from Bruxelles Member 114 posts registered on Mar. 8 2006 |
Bernard : Je suis d'accord, je pense que la présentation des résultats effectivement doit se réaliser avec un lien unique pour chaque fil de discussion, que le mot trouvé le soit dans l'article initial ou dans les commentaires. Pour moi, cela ne fait pas de grande différence si le résultat est trouvé dans l'un ou dans l'autre ou dans topute autre ressource. Le résultat doit être complet. Mais j'apprécie l'esprit puriste de celui qui fait la différence entre article initial et commentaire car cela a un impact sur la qualité du résultat. Certainement, un mot trouvé dans le titre ou l'introduction d'un fil de discussion a plus d'impact que si ce mot est dans le corps de l'article ou encore dans les commentaires. Mais bien souvent comme tu les dis, la solution du sujet abordé se trouve dans les commentaires. Si c'est une question de présentation, on pourrait faire la différence entre un résultat trouvé dans un article et un autre dans un commentaire avec une petite icône significative voire une astérisque ou un commentaire en bas de page qui stipule que le résultat se situe dans un commentaire et présenter ceux-ci en fin de liste. Je penche plutôt pour la solution de l'icône. Il existe déjà une icône pour chaque réultat. Mais il n'existe pas de différence entre les icônes des articles, des commentaires, des lien internes ou externes, des fichiers attachés( leur description ou leur contenu)...ou toute autre ressource utile. Pour la présentation, on pourrait aussi opter pour une présentation de toutes les ressources trouvées (de manière arborescente peut-être), fil de discussion par fil de discussion, avec présentation du lien vers ce fil comme noeud et les différentes ressources trouvées comme branches. La seconde possibilité est de présenter les résultats par type de ressource trouvée, comme c'est le cas actuellement, mais en présentant bien le titre du fil de dicussion auquel il est attaché. De plus, je trouve que le texte attaché au résultat doit être limité à un nombre de caractères choisi par les associés (si ce n'est déjà le cas. ) Idéalement, si on conçoit le moteur sous forme de xml, il devrait égalment être possible d'en faire un métamoteur, mais ça, c'est une autre histoire de rêveur.
| ||||||||||||||||||||||||||||||||||||||||||||
Dobliu from L'Île de Pâques (en espagnol Isla de Pascua, en rapanui Rapa Nui) Member 203 posts registered on June 17 2006 |
Bien cette fonction CHERCHE me perturbe car je m'attends toujours à RECHERCHE que me semble plus complet ... Bref, en faisant des essais, j'ai remarqué qu'elle ne marche pas dans le cas suivant : une section de type R (menbres authentifiés) ou N (associé) ne peut faire l'objet de recherche même si vous êtes correctement identifié, ou/et éditeur. La recherche se solde par aucun article trouvé. la modification réalisée en écriture rouge dans le script articles/articles.php ci dessous, permet de résoudre ce problème mais pas pour les sections. A AMELIORER ? function search_in_section($section_id, $pattern, $offset=0, $count=10, $variant='full') { global $context;
// search is restricted to one section if($section_id)
$sections_where .= "sections.id LIKE '".mysql_real_escape_string($section_id)."'";
// select among active items
else {
$sections_where = "sections.active='Y'";
// add restricted sections to members
if(Surfer::is_member() || !isset($context['users_without_teasers']) || ($context['users_without_teasers'] != 'Y'))
$sections_where .= " OR sections.active='R'";
// add restricted sections to associates
if(Surfer::is_associate())
$sections_where .= " OR sections.active='N'";
// include managed sections
if(count($my_sections = Surfer::managed_sections()))
$sections_where .= " OR sections.id LIKE ".join(" OR sections.id LIKE ", $my_sections);
}
// select among active articles
$where = "articles.active='Y'";
.......
 AUTRE CHOSE :je crée un livre électronique avec plusieurs sections contenant des articles.
soit livre = chapitre introduction , chapitre xxxxxxx, chapitre yyyyyyyy, ....; ajouter dans chaque titre le mot début est faîte une recherche , le résultat ? il ne trouve pas !!! Maintenant modifier le mot début par débutes , faîtes une nouvelle recherche et YACS trouve !! Il semble qu'il ne comptabilise pas les lettres accentuées  | ||||||||||||||||||||||||||||||||||||||||||||
| Bernard from nearby-an-airport Associate 6555 posts registered on Sep. 12 2003 |
Dobliu : Oui, l'extension du champ de recherche est évidente, merci pour la suggestion. En ce qui concerne la recherche c'est différent. Je pense que le problème vient de MySQL. En effet, la recherche plein texte effectuée par ce moteur tient compte du nombre d'occurences du mot cherché. l'objectif est de masquer le "bruit" engendré par une trop grande fréquence. Le résultat, c'est qu'un mot trop fréquent est invisible. Tout simplement. | ||||||||||||||||||||||||||||||||||||||||||||
| Bernard from nearby-an-airport Associate 6555 posts registered on Sep. 12 2003 |
Vinc : Merci de cet apport. Pour le xml, c'est déjà fait, puisque le moteur de recherche YACS est capable de générer un fil RSS, exploitable par n'importe quel analyseur ad hoc. La preuve : Recherche XML sur 'menu' | ||||||||||||||||||||||||||||||||||||||||||||
| Dobliu from L'Île de Pâques (en espagnol Isla de Pascua, en rapanui Rapa Nui) Member 203 posts registered on June 17 2006 |
Bernard : la réponse demande un approfondissment .J'ai encore testé la recherche sur YetAnotherCommunitysysteme avec des mots peu UTILISES tels que pêche fraîche clés créer vidéo ... pas de résultat. Etonnant, une première approche de la source du problème pourrait venir du fait de l'encodage des caractères UTF8 ISO LATIN depuis le navigateur, ou les tables ? Bref sur site test voici ce que donne la recherche de crême, l'image début indique que YACS n'a rien trouvé et je montre la dernière page visitée dans laquelle se trouve le mot recherché. sur l'image suite en fait je retourne directement à la dernière page visitée et là, miracle le mot recherché crême est surligné en vert. YACS le trouve mais le signale pas hors l'occurence est de 1. Je propose de faire un sujet test avec des mots tels que blème bref des mots à occurence faible ou présent 1 fois Pourrait on moduler le nombre d'occurences , c'est à dire YACS les recherche toutes mais il n'affiche que les 30 dernières enregistrées | ||||||||||||||||||||||||||||||||||||||||||||
| Bernard from nearby-an-airport Associate 6555 posts registered on Sep. 12 2003 |
Dobliu : Normalement, YACS présente à MySQL les données dans le même encodage que lors du stockage des articles. Reste à savoir comment le moteur d'indexation de MySQL considère les chaînes Unicode, notamment l'ampersand de début et le point-virgule de fin... Le symptôme est-il le même avec une base supportant nativement l'Unicode ? Par défaut MySQL gère des tables ASCII, d'où la nécessité de l'encodage effectué par YACS. Mais quid d'une base MySQL configurée explicitement pour gérer l'Unicode ? | ||||||||||||||||||||||||||||||||||||||||||||
| Dobliu from L'Île de Pâques (en espagnol Isla de Pascua, en rapanui Rapa Nui) Member 203 posts registered on June 17 2006 |
Bernard : Bonjour , mes tables sont encodéess utf8_gneral_ci et l'interclassement (collate) en latin1_general_ci sur Mysql version 5.25 J'ai essayé un interclassement avec utf8_gneral_ci, cela ne change pas. J'ai mis à jour les index via YACS, pas suffisant? Si la définition des tables doit correspondre a un encodage pourquoi ne pas le figer dans le script ? Pour la recherche en mode booléen, passer le MATCH (..) IN BOOLEAN MODE est il suffisant ? encore un exemple de recherche infructueuse dévorée il netrouve pas , par contre peine Oui  | ||||||||||||||||||||||||||||||||||||||||||||
| Dobliu from L'Île de Pâques (en espagnol Isla de Pascua, en rapanui Rapa Nui) Member 203 posts registered on June 17 2006 |
Pour ne plus avoir 13 commentaires un complément d'infos sur la BD : Information sur les variables mySQL
| ||||||||||||||||||||||||||||||||||||||||||||
| Chacha Member 226 posts registered on Mar. 18 2006 |
Bonjour, Dans le même tonneau, recherche sur le site de yacs avec catégories, categorie, catégorie,ne donne pas la même quantité de résultats,donc attention aux fôtes ! | ||||||||||||||||||||||||||||||||||||||||||||
| Vinc from Bruxelles Member 114 posts registered on Mar. 8 2006 |
Quid de l'encodage HTML? Je pense que fckeditor utilise une fonction du type HTMLENCODE. Par conséquent, toute recherche doit d'abord être encodée en HTML pour donner les résultats édités avec FCK, je pense. Les données éditées avec YACScodes sont-ils aussi encodés? Même chose, apparemment pour tous les autres champs et les catégories...? Bref, Bernard, à ta connaissance, pourrait-il y avoir un problème d'encodage HTML? Cela aurait-il déjà été pris en compte? | ||||||||||||||||||||||||||||||||||||||||||||
| Bernard from nearby-an-airport Associate 6555 posts registered on Sep. 12 2003 |
Vinc: Une autre piste serait que le moteur MySQL considère les & et ; qui encadrent les caractères unicode comme de la ponctuation. Une recherche sur ce sujet pourrait aider... |
Reply
Quote
17 comments · 
Add a comment
Rate this page
Posted by Vinc on Aug. 14 2006, commented by Bernard on Aug. 14 2006, (popular)
