Dictionnaires

Présentation

Le plugin Dictionnaires sert à définir des choses, regroupées dans des dictionnaires. Une définition peut avoir plusieurs statuts comme les articles, tandis qu’un dictionnaire peut juste être actif ou inactif. Lorsqu’un dictionnaire est activé, cela signifie que ses définitions seront cherchés dans tous les textes du site.

Par défaut, deux types de définitions sont disponibles : normale ou abréviation (sigle, acronyme ou autre).

Chaque définition peut lister des termes supplémentaires qui seront reconnus aussi (le pluriel par exemple). Pour les abréviations, le système ajoute automatiquement une version avec p.o.i.n.t.s, il n’est dont pas nécessaire de les ajouter vous-mêmes.

Un plugin proche existe : le plugin Glossaire mais SPIP a tendance à mouliner lorsque la liste des définitions (un groupe de mots-clés) est trop importante. Moins proche et entièrement manuel, le raccourci Wikipedia de SPIP : [?Wikipedia].

L’avantage du plugin Dictionnaires est qu’il demande moins de ressources et qu’il présente deux nouveaux objets qui suivent l’analogie Rubriques/Articles et peuvent chacun recevoir des logos et des documents.

Fonctionnement

Lorsqu’un dictionnaire est actif, toutes ses définitions publiées sont recherchées dans les textes qui passent par la fonction propre(). Les termes trouvés sont alors remplacés par une fonction personnalisable (cette fonction est aussi personnalisable suivant le type de définition).

La fonction par défaut ajoute un lien « Définition » en note <sup> après le mot, lien qui pointe vers la page de la définition (pour info, le plugin fournit des squelettes compatibles avec Zpip pour afficher une définition et un dictionnaire).

Ce comportement n’est fait que pour les premières occurrences de chaque texte. Ceci est personnalisable depuis la page de configuration du plugin.

Une option « sensible à la casse » est disponible pour chaque définition. Ceci indique au détecteur de prendre en compte uniquement le terme exact (« ce » ne sera pas reconnu pour « CE »).

Pour chaque dictionnaire, vous pouvez définir le type par défaut des nouvelles définitions qui y seront crées.

Lors de l’installation, le plugin propose une fonction d’importation des acronymes définis à l’aide du plugin Forms&Tables. Les éléments sont importés en tant qu’abréviations (modifiable ensuite).

Installation du plugin

L’installation se fait par la méthode habituelle, Dictionnaires ne demande que le plugin Saisies comme plugin complémentaire pour fonctionner.

Configuration du plugin

Une fois l’installation faite, le menu « Configuration » de SPIP affiche un item « Dictionnaires ».

Par ce lien, vous arrivez à la page « Configurer les dictionnaires » qui propose deux cases déjà cochées :

  • Remplacer uniquement la première occurrence d’une définition
  • Remplacer uniquement la première occurrence d’une abréviation

Cela vous permet d’afficher les définitions sur tous les termes d’un texte ou seulement la premier fois qu’ils sont rencontrés.

La constante define('DICTIONNAIRES_DETECTION_MANUELLE', true); permet de spécifier que l’auteur des squelettes se charge d’appliquer le filtre |definitions sur les balises souhaitées, et non sur tout les textes qui passent par la fonction propre().

Saisie des dictionnaires

Il faut d’abord créer un ou des dictionnaires et, pour chacun, créer des définitions. Le menu « Édition » de SPIP contient aussi une entrée « Dictionnaires ». Il vous suffit de cliquer sur « Ajouter un nouveau dictionnaire ».

Liste des champs pour l’objet Dictionnaire :

  • Titre (champ obligatoire)
  • Descriptif (champ)
  • Abréviation par défaut (case à cocher)

Cet objet a deux statuts possibles : Inactif (par défaut)/Actif. Un dictionnaire actif aura ses termes détectés dans les contenus du site.

Accessoirement, le plugin permet d’utiliser un raccourci supplémentaire : [mon texte->dictionnaireXXX].

Saisie des définitions

Une fois un dictionnaire créé, sa page de "vue" propose d’ajouter des définitions.

Cliquer sur « Ajouter une nouvelle définition » donne une liste de champs pour l’objet Définition :

  • Titre (champ obligatoire)
  • Dictionnaire (menu déroulant, obligatoire)
  • Texte (champ)
  • Termes (champ listant "Des termes supplémentaires qui permettront de détecter la définition, séparés par des virgules.") [1]
  • Abréviation (case à cocher, « Est-ce un sigle, un acronyme ou autre abréviation ? »)
  • Sensibilité à la casse (case à cocher : « La détection de ce terme sera sensible aux minuscules et majuscules. »)

Cet objet a trois statuts possibles : « proposé à l’évaluation » (par défaut)/« publié en ligne »/« à la poubelle ».

La date de création d’une définition ne peut être modifiée que sous le statut « publié en ligne ».

Accessoirement, le plugin permet — ici aussi — d’utiliser un raccourci supplémentaire : [mon texte->definitionXXX].

Utilisation dans vos squelettes

Comme cité plus haut, le plugin fournit des squelettes compatibles avec Zpip pour afficher une définition et un dictionnaire. Vous pouvez consulter ces squelettes dans le répertoire contenu du plugin.

Le plugin met aussi aussi à disposition deux modèles utilisables depuis vos squelettes ou le texte de vos pages :
-  <dictionnaires> affiche la liste des dictionnaires
-  <dictionnaire> affiche la liste des définitions d’un dictionnaire.

Les balises de l’objet « dictionnaire » sont :

  • #ID_DICTIONNAIRE
  • #URL_DICTIONNAIRE
  • #LOGO_DICTIONNAIRE
  • #TITRE
  • #DESCRIPTIF

Les balise de l’objet « definition » sont :

  • #ID_DEFINITION
  • #URL_DEFINITION
  • #LOGO_DEFINITION
  • #TITRE
  • #TEXTE
  • #TERMES
  • #INTRODUCTION

Notes

[1Par exemple, pour la définition « Dioïque », vous pouvez aussi lister les termes : dioïques, dioïcie ; pour la définition « Tomenteux », les termes, tomenteuse, tomenteuses…

Discussion

29 discussions

  • 21

    Hello, and thanks for the plugin,
    I was trying to use this plugin but found that I cannot have a proper way to have template specific to a language, despite I created definition.html for the default language of the site which is RTL and definition.en.html for English. I also enabled the translation function for the definitions.
    How can I code this feature and is it possible for you to add it in the next release ?
    Thank you

    • Hello, since SPIP 4.X you have to install some plugin for that (before template by lang code was in the default distribution) : https://www.spip.net/en_article4363.html?var_lang=en

      Did you have it already ?

    • Good day,
      I have used the documentaion provided in https://www.spip.net/en_article4363.html?var_lang=en and created template variants :
      definition.html for rtl which is the primary language of the multilingual site.
      definition.en.html for ltr/en
      dictionnaire.html for rtl
      dictionnaire.en.html for ltr/en
      I do not have installed any extra plugin to have Variants of templates for definition and dictionnaire. But I have enabled the translation of the definitions.
      By plugin, if you mean something like Squelettes par Rubrique, I couldn’t find such for for definition and dictionnaire. Is there any ?

    • Hello,
      I just enabled translation feature for the definitions and created template variants as following :
      dictionnaire.html for rtl (the primary language of the multilingual site)
      dictionnaire.en.html
      definition.html
      definition.en.html
      By plugin, if you mean something like Squelettes par Rubrique, I couldn’t find such for the dictionnaire and definition.

    • The documentation we both linked, explicitely says that you *have to* install the plugin (the link is in the doc, you just have to follow), to be able to do variants by lang code.

    • Right. I have that plugin enabled for the sections long before. But that doesnæt help with the dictionary.
      The problem is that despite the language of the definition (English) and the existence of the template file definition.en.html, it still returns definition.html which is for the definitions in the default language of the site unless I manually add  ?lang=en at the end of the URLs.

    • Ooook so we put aside that source of problem if you have it. So I had to dig deep in the code to find an issue for all content that are not in sections : https://git.spip.net/spip/spip/issues/5783

    • ok, hopefully, we can get it fixed as soon as possible.
      The same issue seems to be with author template variants.

    • Seems #TEXTE and #INTRODUCTION produce the same output, and there is no field in the private area for #INTRODUCTION.

    • Is there any way to activate public forums for definitions ?

    • new feature : you ought to create a squelette and dedicated code for that

    • @Kamran : public comments are always specific to your public templates, so there is nothing to « activate », but just front integration. For that, the very simpliest way is to use the Comments plugin and include its generic inclusions for that. Like

      <INCLURE{fond=inclure/forum, objet=definition, id_objet=#ID_DEFINITION, ajax}>
      

      and then style as you want.

      Comments 3 pour SPIP 3

    • Perfect. I added a public forum by adding id_definition ? to the BOUCLE_comments in /squelettes/inclure/forum.html.
      I also used the plugin Champs Extras to have some fields for pronunciations and word classes.
      I wonder, what if id_definition can inherit the full features of the article while it is still an object, or have regular sections and articles for dictionaries and articles while they have their own URL sets ?

    • You don’t have to (and it’s always better to not) modify inclusions from plugin. Normally you can pass « objet=definition » and « id_objet=#ID_DEFINITION » to work properly, it’s generic for any object.

      Don’t really understand the need of the last question :p

    • The page doesn’t load completely if I use

      <INCLURE{fond=inclure/forum, objet=definition, id_objet=#ID_DEFINITION, ajax}>

      But the forum and the comments load by adding id_definition ? to the BOUCLE of /squelettes/inclure/forum.html

      <BOUCLE_comments(FORUMS?) {id_rubrique ?}{id_article ?}{id_definition ?}{id_breve ?}{id_syndic ?} {par date}>
      .....
      </BOUCLE_comments>

      and include the page :

      <INCLURE{fond=inclure/forum,id_definition} />

      By inheriting the full features of the article I mean having, for example, the author for definitions.
      Seems, still no fix for the template variants.

    • Sorry, Seems my last comment was filtered. Anyway :
      By inheriting all features of the article, I mean having all features such as author, that the articles have while it has its table in the database as an object.
      Forum doesn’t load by adding “objet=definition” and “id_objet=#ID_DEFINITION”. I could load the forum when I add id_definition ? to the BOUCLE of my template file /squelettes/inclure/forum.html.
      I have updated SPIP to the latest, but still, the issue with thetemplate variants is not fixed.

    • to explain better, here is an example page for definitions using plugin Dictionnaires.
      Here isalso an example article to compare article futures using for definitions. In this example, I can get the benefits of all article features, but while having all article features, it could be much better to have the definition as the object, incrementing definition, and not the article. In the case of Dictionnaires vs RUBRIQUES, Dictionnaires is much better but still can manage with RUBRIQUES.

      Another question :
      How the definitions can get the same search benefits as the SPIP articles ? The internal SPIP search works well with definitions, but I mean search engines.
      In my case, when posting a new article, search engines like Google index the article almost immediately. One reason is that the site’s backend file for articles can be submitted to search engines as a sitemap. Any possibility of having an XML/RSS backend file for definitions ?

    • Hello Kamran, end of the year festivities here, I will try to answer at the end of the week or next week :)

    • right, enjoy, and thanks again for the plugin !

    • Hello and happy new year,
      I installed two plugins, Auteurs partout and Statistiques des objets to have author and statistic for definitions. As you know adding more plugins has its consequences.
      Still, I wonder how to have RSS/XML for definitions like backend Syndication files.

    Répondre à ce message

  • 10

    Bonjour. Fantastique plugin ! Comment lister les titres des définitions se référant à un mot-clé, sur une page mot-clé, où on liste des articles, rubriques, sites, etc. d’un mot-clé ?

    • bonjour,

      tu peux construire une page dictionnaire.html qui apparait à l’adresse :
      mon site/ ?dictionnaire1

      <BOUCLE_principale(DICTIONNAIRES) {id_dictionnaire}>
       etc 

      il y a des briques dans les modèles du plugin

    • en fait, j’ai répondu à côté.

      Dans ta page de mot-clé tu peux utiliser les boucles DEFINITIONS, les champs #TITRE et les id_mot comme dans les autres boucles objets

      J’ai bien compris ?

    • Bonjour, j’ai mis en place ce code, mais sans succès :

    • Désolé mais pour l’instant je n’ai pas compris ce que tu cherches à faire, à obtenir, du coup difficile d’aider. Cela a l’air très propre à ton site, aux liaisons que tu fais dedans. Mais comme je n’ai pas le contexte, l’architecture des contenus, je ne comprends pas de quoi il s’agit.

    • Merci de votre patience et attention. J’ai cette page avec une liste d’articles, etc par mot-clé, comme tous les sites ont, e crois. Par ex. : http://sofia.hyperlogos.info/spip.php?mot1018

      Je voudrais qu’une liste de définitons soit aussi présenté sur cette même page. J’ai mis le code ci-dessus sans succès. Merci de faire une observation.

    • Bé la boucle ci dessus fonctionne si t’as effectivement des définitions *liées aux mots clés* mais ça j’en sais rien.

    • je vois des définitions liées aux articles liés à ce mot clé.

      Est-ce les définitions apparaissant dans ces articles que tu veux voir lister sur ta page mot ?

    • Non, je voudrais bien que la page mot-clé puisse montrer non seulemente les articles, etc, mais aussi les définitions que j’avais associé à ce mot-clé.

    • En effet, cela m’intéresse aussi : peut-on associer des mots-clés aux définitions ? Actuellement, cette fonction ne semble pas disponible.

    • Je ne comprends pas trop vos remarques :

      • d’une part on peut parfaitement ajouter des mots-clés aux définitions, ça marche pour tout objet SPIP bien déclaré, et donc à fortiori pour les définitions. Quand dans un groupe de mots on dit que c’est autorisé sur l’objet Définitions, ensuite dans une définition il y a parfaitement la boite pour ajouter/retirer des mots.
      • d’autre part quand on est sur la page d’un mot déjà existant qui est associé à des contenus, et bien ça affiche aussi parfaitement les définitions en plus de tout autre objet, je l’ai sous les yeux là

    Répondre à ce message

  • 2

    Bonjour,

    1/ Sur une nouvelle installation d’un spip 3.2.7, je constate que soit depuis l’espace privé (lien « voir en ligne » sur une définition) ou meme depuis l’espace public dans un article, quand je clique sur un lien de définitions, alors j’ai une erreur 404.

    Afin de contourner le PB j’ai dû copier / coller les différents modèles HTML du plugins dans mon répertoire SQUELETTES, c’est étonnant, non ?

    2/ Dans un article si je survole le «  ? » d’un mot avec définition, un court résumé apparaît ce qui est très bien. Cependant si dans ma définition j’ai des caractères SPIP de type puce par exemple, c’est a dire un TIRET + ETOILE, alors dans l’info bulle de mon lien j’ai aussi l’affichage des raccourcis SPIP. Est ce que cela vous le fait aussi ?

    Comment est ce que cela peut - i l se corriger ou contourner ?

    Merci a tous et bonne journée.

    • 1) le plugin génère pas de page publique, mais fournit un « contenu » minimal (mais ça ne marche qu’avec une vieille version de Z en plus ça), donc bah oui, c’est à chacun de construire ses pages suivant son squelette (faudrait au moins fournit « content » plutôt, pour être compat avec tous les nouveaux Z càd beaucoup de sites)

      2) Effectivement « propre » n’est pas utilisé là, je ne saurais pas du tout te dire pourquoi de mémoire. C’est typo() seulement (que pour les titres normalement) alors que c’est bien un « texte » qui permet tout comme les autres textes longs. Il faudrait sûrement changer ça, et c’est ici :
      https://git.spip.net/spip-contrib-extensions/dictionnaires/src/branch/master/inc/dictionnaires.php#L194

    • Hello Rasta,
      Merci de ton retour,

    Répondre à ce message

  • 1
    spipfactory

    Bonjour,

    je rencontre un soucis, lorsque je donne une définition et que le mot est composé celui-ci prend en compte la définition

    exemple : SPIP (je donne la défnition est un lien
    mais si dans mon texte j’ai le mot SPIP-Cli celui-ci m’indique la définition sur SPIP alors que le mot est SPIP-CLi.

    est ce un comportement normal ?
    comment ne pas avoir la définition SPIP sur le mot compose SPIP-Cli

    merci pour votre éclairage

    Répondre à ce message

  • 1

    Bonjour à tous,
    Pour les chaînes de caractères identifiées par le plugin, est-il possible de souligner (typiquement, en pointillé) plutôt que d’ajouter un point d’interrogation, merci.

    Répondre à ce message

  • 1

    Pour info, le code source semble indiquer que le lien inséré contient une erreur : il faut ajouter un espace entre <a href =« spip.php ?definition1 » et title=« le titre »

    Répondre à ce message

  • 1

    Bonjour,

    Autre petite erreur : lorsqu’un MEGA TAG Title ou Description contient un mot d’un dictionnaire, ce mot est affecté du point d’interrogation.

    • La recherche des mots s’applique sur tout texte qui passe dans « propre » (la transformation de la syntaxe spip). Dans ce pipeline il n’y a absolument aucune info de qui que quoi comme texte on est en train de chercher, ça peut être une balise (souvent) ou tout autre chose, et si c’est une balise on n’en sait rien laquelle. Il n’y a donc pas de discrimination possible pour parfois appliquer parfois pas.

      Si on ne veut pas l’appliquer partout, il faut soit désactiver le fait de l’appliquer partout, il y a une constante pour ça, et l’appliquer seulement volontairement sur les champs qu’on veut avec le filtre explicite, tout ça est dans la doc plus haut ; soit sur les balises où on ne le veut faire, il faut mettre * et n’appliquer que ce qu’on veut ou virer la def après coup.

    Répondre à ce message

  • 1

    Bonjour,

    Dans le cadre d’une galaxie de site, j’aimerais pouvoir :

    • soit avoir un site central qui contiendrait toutes les définitions, utilisables ensuite sur n’importe quel des autres sites
    • soit avoir les définitions sur chacun des des sites, mais utilisées sur tous les sites à fois

    Une idée de comment faire ?

    PS : sachant que j’ai un plan B : faire un plugin qui ait en dur les définitions dans son script d’upgrade et qui les crée dans tout les sites

    • Il y a un pipeline « lister_definitions » exprès pour ce genre de cas : pouvoir ajouter des définitions venant de n’importe quoi d’autres. Il te suffit de t’insérer dedans et remplir avec des définitions venant d’une autre base. Après ya pas de système de « webservice », sites « parent/enfants », etc tout prêt. Mais on peut bien remplir 500 définitions venant d’ailleurs si on le veut. Et tout ça est mis en cache dans le site hein, ça n’appelle pas le distant à chaque fois. Du moment que ça a déjà été généré, et qu’on n’a pas purgé, ça prend le fichier de cache.

    Répondre à ce message

  • 3

    A l’install du plugin, les tables ne sont pas créées :

    Erreur SQL HY000 / 1
    no such table: ddys_dictionnaires 

    Quelqu’un a t-il le même problème ?

    Cdlt

    Freed

    • tu serais pas chez ovh dès fois ? je sais que plusieurs personnes ont des souci d’install de plugin _en general_ chez eux.

    • Un passage par la page de maintenance afin de lancer une réparation des tables de la base devrait corriger le pb.

    • Oui, chez OVH, j’y ai passé l’après midi, passé les logs en mode debug, farfouillé partout, installé réinstallé le plugin et d’autres pour lesquels les tables ne se crée pas non plus, réparé la base plusieurs fois et....
      ... rien !!!
      Puis je vois vos réponses, refait une réparation par acquis de conscience ! Ça fonctionne !!!
      Vraiment Bizarre, comme si il y avait du cache sur les serveurs OVH (surtout que je suis en SQLite).

      Merci pour vos réponses, enquête à suivre.

      Cdlt

      Freed

    Répondre à ce message

  • 2

    Bonjour,

    est-il possible de n’appliquer un dictionnaire qu’à une seule rubrique ?

    Merci.

    • Non par défaut puisque c’est appliqué dès qu’il y a la fonction « propre », comme expliqué plus haut, fonction qui s’applique à n’importe quoi, pas forcément des objets SPIP et qui ne connait pas l’environnement.

      Par contre, là aussi plus haut, c’est expliqué que tu peux le décider toi-même dans tes squelettes :

      La constante define(’DICTIONNAIRES_DETECTION_MANUELLE’, true) ; permet de spécifier que l’auteur des squelettes se charge d’appliquer le filtre |definitions sur les balises souhaitées, et non sur tout les textes qui passent par la fonction propre().

    • Merci.

      J’avais bien intégré l’utilisation de « propre » mais je n’ai pas compris l’utilisation de la constante ’DICTIONNAIRES_DETECTION_MANUELLE’ Je vais donc essayer ça.

      Encore merci pour cette réponse rapide.

    Répondre à ce message

  • 4

    Re-Bonjour,

    Autre chose : j’aurais voulu éventuellement organiser 1 dictionnaire par langue.
    Comment peut-on ensuite, pour un même mot, n’afficher que la langue correspondante (les dictionnaires pouvant être nommé « fr », « en » pour faciliter) ?

    • Bé tu peux pas, ce n’est pas prévu. Ya bien un champ lang pour les définitions mais ya pas pour les dictionnaires, ni de système d’héritage par défaut (comme les rubriques de telle langue dont les articles ont la même langue par défaut à la création), ni encore moins de gestion de plusieurs définitions des mêmes termes, ça fait forcément conflit, ya pas de système qui choisirait la bonne définition suivant le contexte.

    • Bonjour RastaPopoulos,
      Merci pour cette réponse rapide. Aurais-tu une idée de comment procéder pour mettre en place ce dictionnaire sur un site multilingue ?
      Et, effectivement il y a un champ Lang pour les définitions, mais as-tu une idée de comment on pourrait s’en servir ?

    • Non là tout de suite je ne vois pas. Il faudrait une évolution du plugin déjà pour éditer ce champ (SPIP a un formulaire générique pour ça je crois), mais ensuite surtout il faudrait que lors du scannage des textes, on ait le contexte du moment (dont la langue) pour pouvoir alors sélectionner en priorité telle ou telle définition. Sauf que par défaut, quand on ne contrôle pas soi-même les appels, c’est appliqué automatique dans le pipeline « post_propre » pour tous les textes, et là on n’a absolument pas le contexte courant.

    • Bonjour RastaPopoulos,
      C’est ballot. Et je ne suis pas assez technos pour mettre les mains dans le cambouis. Dommage, parce que cette idée de dictionnaires est absolument brillante ! Merci quand même pour ta réponse, en espérant que quelqu’un de techniquement talentueux s’y mette un de ces 4 ;-)

    Répondre à ce message

  • 1

    Bonjour,
    Merci pour ce plugin fantastique !
    Petit bug en utilisant le plugin Multilang : les titres sont correctement traduits mais les URLs ne sont pas traduites, et on lit donc les balises au lieu du lien.

    • Tu veux dire que Multilang permet de traduire le champ « url_externe » ? Ça ne devrait pas normalement, généralement ça s’applique que sur les textes, titre, descriptif, etc.

      Soit il ne faut pas que multilang s’applique sur ce champ (ce qui est le cas dans les autres contenus il me semble, qu’il ne s’applique pas sur les champs d’URL, sur les articles ou autre). Soit il faut que la balise #URL_EXTERNE ait le filtre « typo » appliqué par défaut comme pour les titres afin que ça gère les multi.

    Répondre à ce message

  • 3

    Bonjour,

    On ne peut pas mettre à la poubelle une définition contrairement à ce qu’indique le libellé.

    Dans le fichier « dictionnaires_tables.php », à la ligne 159, le statut_textes_instituer pour « à la poubelle » est « refuse » au lieu de « poubelle ».

    Est-ce volontaire de la part des auteurs ?

    Merci !

    • Je constate la même chose.
      Comme ça, je dirais que c’est une erreur, les définitions mise à la poubelle n’étant alors jamais traitées par le cron « optimiser ».

      Je peux m’occuper de corriger. Go ?

    • Pour moi c’est Go !

      Merci Peetdu !

    • La version 1.2.0 corrige la chaine de langue pour le statut « Refusé » et introduit un nouveau statut « Poubelle ».

      Note pour ceux qui pensaient avoir avaient mis à la poubelle leur définitions :
      Ces définitions ont maintenant clairement le statut « Refusé ». Si vous voulez les supprimer, il vous faut passer leur statut à « à la poubelle »

      Les définitions misent à la poubelle seront supprimées de la base de données au bout d’environ 24h (note : c’est vrai pour n’importe quel objet mis à la poubelle, sauf Auteurs je crois).

    Répondre à ce message

  • Bonjour,

    Je crois que j’ai trouvé un bug potentiel dans instituer_definition
    appelé juste après insert_definition(), le id_dictionnaire de l’id_definition qui vient d’être créé vaut 0, et on va vouloir mettre à jour avec un vrai id de dico, mais l’autorisation porte sur l’id qui vaut 0 et non sur l’id final
    cf le commit que je viens de faire avec 2h perdue à identifier que je devais passer 0 et pas l’id_dictionnaire que j’avais
    spip-zone : https://zone.spip.net/trac/spip-zone/changeset/111124 (1 files) : Migrer les sigles du précédent plugin sans avoir besoin de la présence de F&T. + des autoriser_exception pour que ça marche avec SPIP-cli.

    Est-ce que je modifie instituer_definition pour utiliser le id_dictionnaire que l’on veut utiliser si le id_dictionnaire enregistré est 0 ?

    Répondre à ce message

  • 3

    Bonjour,
    Dans un site en construction sous spip 3.2 avec le plugin-squelette soyez créateur, j’ai voulu faire un dictionnaire. J’ai pour l’instant entré 4 ou 5 définitions. Elles apparaissent bien dans le pied de la page d’accueil. Mais j’ai fait un article test dans lequel se retrouvent ces mots (et d’autres que je définirai quand le problème sera résolu !). Seulement 2 de ces mots sont cliquables vers leur définition. Je ne sais pas ce que j’ai fait pour ceux-là, et pas pour les autres, (ou inversement !)
    Par ailleurs, comment mettre automatiquement ces mots en couleur par exemple, ou en caractères gras, parce que je trouve que le «  ? » n’est pas très visible.
    Merci de votre aide.
    http://www.loeilepleumien.fr ; http://www.loeilepleumien.fr/?Essai-pour-une-definition

    • Bé je ne sais ce que tu as dans ta config, donc je ne sais pas pourquoi certains sont détectés et d’autres pas… Après ya une différence entre abréviation pas définition classique, pas forcément le même rendu. La génération de comment sont transformés les mots détectés est dans une fonction PHP surchargeable par type de définition (à décrire dans cette doc ici, c’est un manque encore, désolé).

    • Merci pour cette réponse. S’il faut que j’aille regarder dans la partie programmation, alors là, c’est foutu... :-( Dommage ! Je trouvais l’idée du dictionnaire bien sympa, et elle correspondait bien à ce dont j’avais besoin) ! Je vais rechercher encore. Il y a peut-être quelque chose que je n’ai pas fait comme il fallait...
      Cordialement

    • Il se pourrait que https://zone.spip.net/trac/spip-zone/changeset/110957 réponde à la question des éléments non détectés...

    Répondre à ce message

  • 2

    Bonjour,

    SPIP 3.21, PHP 7.0, Windows (WAMP).
    Seuls plugins installés : Dictonaire + Saisie.

    Constat : le dictionnaire ne trouve que les mots pour lesquels on a coché « Sensible à la casse ».

    Répondre à ce message

  • Bonjour,

    Bravo et merci pour ce plugin que j’étudie pour une très certaine intégration.

    Je voulais modifier le code HTML généré par le filtre ... et je découvre donc, avec joie, les fonctions et la possibilité de surcharge commentée :

    /*
     * Fonction de remplacement par défaut pour les abbréviations trouvées dans les textes
     * Ceci est un EXEMPLE montrant qu'on peut mettre un truc différent pour un type de définition précis
     * Mais ce code est une MAUVAISE PRATIQUE en accessibilité
     * (car seuls les gens avec des yeux valides et un pointeur de souris ont accès à l'information)
     */
    function dictionnaires_remplacer_abbr_dist($mot, $definition){
    	return '<abbr title="'.couper(trim(attribut_html(supprimer_tags(typo($definition['texte'])))),80).'">'.$mot.'</abbr>';
    }

    C’est le commentaire qui me gêne, il me semble, au contraire, que l’emploi de la balise <abbr> est plus bénéfique en terme d’accessibilité.

    Voir Guide AccessiWeb

    Répondre à ce message

  • 1

    Bonjour
    J’ai un bug d’affichage depuis le maj en spip 312
    La réactivation de dictionnaires 114 affiche en boucle le message d’erreur suivant :
    Warning : preg_replace_callback() : Compilation failed : invalid UTF-8 string at offset 23 in /www/docs/plugins/dictionnaires/dictionnaires_fonctions.php on line 50

    J’ai de plus tout le site qui est passé en caractère iso latin avec des losanges sur tous les caractères accentués.
    Je ne sais pas si cela a un rapport ?

    Merci pour votre retour

    Répondre à ce message

  • Bonjour,

    Plugin très utile, bravo !
    Je suis en spip 3.1 et je souhaiterai faire apparaître en bas de l’article (façon notes) le récaptitulatif des définitions utilisées plus haut dans ce même article.
    Je sèche sur la boucle à utiliser ?
    Merci pour votre aide

    Répondre à ce message

  • 3
    spipfactory

    Dans cette page http://nature-en-tarentaise.org/spip.php?article109&lang=fr
    Sauter le premier paragraphe et aller jusqu’à l’énumération au deuxième paragraphe. Dans le premier terme de l’énumération il y a le mot « panicule », dans le deuxième terme il y a les mots « épillets », « mutique », on voit un petit point d’interrogation qui indique qu’il y a une définition.
    1- Cette présentation avec un point d’interrogation est pas top. Souligné ou des couleurs, ce serait compréhensible...(je suis sur que c’est possible, mais qu’il me manque un truc)
    2- Si je passe la souris dessus j’ai le début de la définition qui apparaît dans un cadre, peut être on peut dire qu’on veut la définition entière...
    3- Si je clique sur le point d’interrogation j’ai affichage de la page d’erreur 404 car il n’y a pas le squelette des définitions...

    J’espère que c’est compréhensible !
    Merci et bonne journée à tous.

    • Bonjour,
      Je vois que ce message n’a pas eu de réponse. Pourtant ce qui est décrit correspond bien à ce qui se passe sur le site en question. Et je n’ai pas trouvé de solution.
      Si vous avez une idée à suggérer pour trouver une solution.
      Merci

      Philippe Pellicier

    • Bah vous avez 404 parce que vous n’avez pas de squelettes dédiés à cet objet (« definition »), ça doit le dire dans le message d’ailleurs normalement. Le plugin fournit des squelettes dans « contenu » mais il faudrait le changer en « content » car c’est vieux comme le monde « contenu », maintenant tous les trucs qui utilisent z-core utilisent « content ». Mais si vous n’êtes pas en format Z ça peut toujours s’inclure dans un definition.html à vous à la racine.

      Pour ce qui est du lien, c’est fait exprès que ce ne soit pas sur le mot par défaut, mais bien un lien extérieur qui suit. Ça pourrait sûrement être plus long et plus accessible (le mot « définition » carrément ou bien « déf » avec un abbr dessus).

      Par contre dans tous les cas on peut personnaliser le rendu par défaut, et aussi le rendu par type de définition (abréviation etc).

      C’est la fonction « dictionnaires_remplacer_defaut_dist » qui est là :
      http://zone.spip.org/trac/spip-zone/browser/_plugins_/dictionnaires/trunk/inc/dictionnaires.php#L173
      et qui peut donc être surchargée en enlevant le « _dist » à la fin.

      Ou bien comme expliqué juste en-dessous, en ajoutant une fonction plus précise : « dictionnaires_remplacer_abbr_dist » par exemple, pour CE type de définition.

      (Oui cette partie de fonctions personnalisables n’est pas dans la doc : c’est mal.)

      Normalement vous devriez avoir tout pour personnaliser le rendu comme voulu.

    • claudeD

      oui, comme le dit RastaPopoulos, il manque un squelette definition.html mais aussi un squelette dictionnaire.html pour cet autre 404 :
      http://nature-en-tarentaise.org/spip.php?dictionnaire1

    Répondre à ce message

  • 4

    Bonjour,
    Est-ce qu’il existe #URL_EXTERNE pour utiliser dans les squelettes ?
    Merci !

    Répondre à ce message

  • 2

    Bonjour,
    Je viens d’effectuer la mise à jour du plugin SAISIES de 2.5.18 vers 2.5.20 et je rencontre un bug avec la page définition.

    Quand je souhaite modifier une définition (« exec=definition_edit »), j’obtiens des « 1 » dans tous les champs. Et si j’enregistre, c’est bien-sûr la cata. Tous mes champs sont effacés et remplacés par des « 1 ».

    Par contre, pour l’enregistrement d’une nouvelle définition, tout fonctionne normalement.

    (Avec Dictionnaires V1.1.2).

    Amicalement.

    Répondre à ce message

  • 2
    Aymeric

    Bonjour,

    Ce plugin s’avère très utile mais je n’ai pas trouvé comment l’empêcher de couper les libellés (à 75 caractères je crois).

    Il se trouve que je dois faire face à de très longs acronymes :)

    Merci de votre aide.

    Répondre à ce message

  • 6

    Bonjour,

    J’ai constaté une anomalie sur un de nos sites en utilisant la version 1.0.4, lorsque l’on créé une définition dont le titre possède un accent ça plante le site en front office et affiche cette erreur :

    Warning : preg_replace_callback() [function.preg-replace-callback] : Compilation failed : invalid UTF-8 string at offset 22 in /xxx/plugins/_externals/dictionnaires/dictionnaires_fonctions.php on line 50

    Je suis en SPIP 3.0.19 et j’utilise une surcharge des filtres dictionnaires_remplacer_defaut et dictionnaires_remplacer_abbr de cette manière :

    function dictionnaires_remplacer_defaut($mot, $definition) {
    	if (!isset($definition['url']) OR !$url = $definition['url']) {
    		$url = generer_url_entite($definition['id_definition'],'definition');
    	}
      
      return "<abbr class="popoverLink" rel="popover" data-toggle="popover" data-placement="top" data-html="true" title="".trim(attribut_html(supprimer_tags(typo($definition['titre']))))."" data-container="body" data-content="".htmlspecialchars(propre($definition['texte']), ENT_QUOTES)."">".$mot."</abbr>";
      
    }
    
    function dictionnaires_remplacer_abbr($mot, $definition){
    	return "<abbr class="popoverLink" rel="popover" data-toggle="popover" data-placement="top" data-html="true" title="".trim(attribut_html(supprimer_tags(typo($definition['titre']))))."" data-container="body" data-content="".htmlspecialchars(propre($definition['texte']), ENT_QUOTES)."">".$mot."</abbr>";
    }

    Ce problème je ne le constate pas sur un SPIP de base, j’en déduis qu’il s’agit d’une particularité de notre site.

    Si vous avez une idée... merci d’avance :)

    Freed

    • J’ai ajouté une option (u) aux regex pour mieux prendre en compte les accents (suite à une discussion sur ce forum) :
      http://zone.spip.org/trac/spip-zone/changeset/88279

      La doc dit :

      Cette option désactive les fonctionnalités additionnelles de PCRE qui ne sont pas compatibles avec Perl. Les chaînes sont traitées comme des chaînes UTF-8. Cette option est disponible en PHP 4.1.0 et plus récent.

    • Bonjour RastaPopoulos,
      Merci pour cet update du plugin, cependant en le testant j’obtiens la même erreur :(

      Warning: preg_replace_callback() [function.preg-replace-callback]: Compilation failed: invalid UTF-8 string at offset 22 in /xxx/plugins/_externals/dictionnaires/dictionnaires_fonctions.php on line 50
      
    • Non mais le plugin n’a pas bougé, c’est une modif qui date d’il y a 4 mois et qui justement pourrait être en rapport avec ton erreur.

    • Le problème que tu décris ressemble pas mal à celui corrigé ici :

      http://zone.spip.org/trac/spip-zone/changeset/91004/

      Tu as testé avec la version 1.0.5 ?

    • Oui je suis passé en 1.0.5 ce matin pensant qu’il s’agissait d’une correction du problème

      Le lien que tu viens de me donner semble bien correspondre à un des contats de mon problème (ces symptômes se produisaient en production seulement)

      Autre info :
      J’obtiens ces erreurs de preg_replace_callback en environnement de développement et recette
      En production j’avais pas d’erreurs affichées (peut-etre que l’environnement n’affiche pas les erreurs PHP) mais tous les textes disparaissaient.
      En local (XXAMP) je n’ai pas d’erreur, ni de disparition de texte, en revanche lorsque j’ai un terme avec un accent il semble ne pas être traité

    • Re-bonjour,

      Finalement en ayant livré la nouvelle version du plugin en production (1.0.5) le problème de textes vides était toujours présent, en réalité les erreurs PHP n’étant pas affichées en prod, nous ne voyions pas le problème qui finalement était le même (preg_replace_callback)

      Nous avons choisi de désactiver le filtre |definitions sur les textes en attendant de trouver une solution

      PS : notre serveur de production est en PHP 5.4.40 , je ne sais pas si ça peut jouer sur quelque chose.

      Merci

    Répondre à ce message

  • 2

    Bonjour,
    Je rencontre un souci avec ce plugin lorsque je tente d’afficher une liste d’articles avec pagination en AJAX et qu’un terme provenant du dictionnaire se trouve dans la balise #INTRODUCTION (c’est à dire en début de texte quoi)
    J’obtiens un « Aborted » sur l’url appelée.
    Existe-t-il un filtre qui désactive le dictionnaire volontairement sur certains textes ?

    Merci d’avance.
    Freed

    • La balise #INTRODUCTION passe par propre(), donc par la détection auto des définitions.

      Mais je ne saurais pas dire pourquoi en ajax ça ferait tout planter, ya pas de raison immédiate qui me vient à l’esprit. Peut-être qu’il faudrait détecter qu’on est dans un hit ajax (il me semble qu’il y a une globale ou un truc pour savoir ça) et ne pas lancer la machinerie dans ce cas. Mais bon yorait pas vraiment de raison de faire ça, un même contenu aurait alors des fois des définitions, des fois pas, suivant s’il est chargé en ajax ou pas, ce n’est pas très cohérent…

      Faudrait surtout comprendre pourquoi ça plante. :(

    • J’avais corrigé le problème en utilisant define(’DICTIONNAIRES_DETECTION_MANUELLE’, true) ; et en appliquant le filtre |definitions uniquement sur les textes complets.

      C’est un peu contourner le problème mais pas besoin d’avoir des définitions dans des listes selon moi.

    Répondre à ce message

  • 7

    Bonjour,

    Si j’ajoute le mot Marche dans un dictionnaire, le plugin fait un lien par exemple sur une partie du mot dé[marche]. Si j’enlève le é, ce mot n’est pas impacté...

    Voici un exemple du problème sur cette article (dans le paragraphe la cane de Montfort au 19e siècle) :
    -  > http://broceliande.brecilien.org/La-cane-de-Montfort-dans-les-traditions-populaires

    Quelqu’un rencontre-t’il ce phénomène ?

    Merci de plugin génial !

    • Oui c’est très bizarre, comme si la lettre accentuée était reconnu comme étant un caractère « hors-mot ».

      Le masque de recherche est généré ici :
      http://zone.spip.org/trac/spip-zone/browser/_plugins_/dictionnaires/trunk/inc/dictionnaires.php#L113

      Chaque masque DOIT débuter par [^\w@\.] càd PAS (^) un caractère de mot (\w) ni un arobase ni un point. La lettre accentuée est donc reconnue comme compatible avec ce truc, ce qui n’est pas normal (un problème de charset ?).

      Si tu es très fort en expression rationnelle ou si tu connais quelqu’un qui est très fort, je veux bien un indice parce que pour l’instant moi je ne vois pas. :(

    • j’ai essayé chez moi avec diverses lettres accentuées, je n’arrive pas à reproduire.

      SPIP 3.1.0-alpha — utf-8

      bibliothèque MySQL (5.0.51a) - serveur MySQL (5.5.41)

      interclassement utf8_general_ci

    • Si Claude n’arrive pas à reproduire, ça irait donc peut-être bien dans le sens d’un problème d’encodage, de charset chez Philippe.

    • Un test rapide sur https://regex101.com/ me montre que l’expression capture bien le caractère accentué de démarche. En ajoutant la modifieur u après la regex cela semble mieux.

      u modifier : unicode : Pattern strings are treated as UTF-16. Also causes escape sequences to match unicode characters

      Mais \w est locale-dependent : pour de l’UTF-8, ça implique le modificateur u sinon un setlocale préalable (encore faut-il que cette locale système soit disponible et active).

    • Philippe tu peux tester si en ajoutant « u » après le « s » à la fin du masque ça marche chez toi ? À l’endroit que j’ai pointé plus haut, la fin est ligne 122 :
      http://zone.spip.org/trac/spip-zone/browser/_plugins_/dictionnaires/trunk/inc/dictionnaires.php#L122

    • OK ça marche !

      Merci pour votre réactivité !

      Pour info, je suis sur SPIP 3.0.17 utf8, mySQL 5.5.41 interclassement utf8_general_ci.
      A noter que j’utilise le plugin Full Text.

    • Voilà j’ai commité sur les deux versions du plugin Philippe :
      http://zone.spip.org/trac/spip-zone/changeset/88279

    Répondre à ce message

  • 2

    A noter que le plugin permet de surcharger la sortie HTML

    Même s’il s’agit d’une mauvaise pratique en terme d’accessibilité de placer du contenu dans l’attribut title.

    Voici un exemple pour afficher la définition dans le titre d’un lien (pour réaliser une info-bulle type « tooltip »),
    on pourra ajouter dans mes_fonctions.php

    function dictionnaires_remplacer_defaut($mot, $definition) {
    	if (!isset($definition['url']) OR !$url = $definition['url']) {
    		$url = generer_url_entite($definition['id_definition'],'definition');
    	}
      
      return "<a class='tooltip' href='#' title='".trim(attribut_html(supprimer_tags(typo($definition['texte']))))."'>".$mot."</a>";
      
    }
    • Premièrement, il est possible de remplacer uniquement un seul type de définition, par exemple que les « abbr » :

      function dictionnaires_remplacer_abbr_dist($mot, $definition)

      Et deuxièmement, attention à ce que dit le commentaire dans le code, et qu’il faudrait que je rajoute dans la documentation :

      Fonction de remplacement par défaut pour les abréviations trouvées dans les textes
      Ceci est un EXEMPLE montrant qu’on peut mettre un truc différent pour un type de définition précis
      Mais ce code est une MAUVAISE PRATIQUE en accessibilité
      (car seuls les gens avec des yeux valides et un pointeur de souris ont accès à l’information

      Au niveau accessibilité, il ne faut pas que l’information se trouve uniquement dans le title.

      • Soit il faut un lien vers une autre page contenant la définition (une page par définition ou bien une grande page avec une ancre sur la bonne définition).
      • Soit il faut que les définitions se trouve dans la page courante, et qu’il y ait un lien pointant vers l’ancre de la bonne définition, exactement comme les notes de bas de page, par exemple. Après en javascript, on peut utiliser ces définitions de la page courante pour générer des infobulles, mais c’est une amélioration progressive en plus, qui vient après coup (tout comme il existe des JS pour afficher les notes de bas de page en infobulle, comme le plugin de b_b).
    • Tu as raison ^^.

      Pour des info-bulles, on m’a signalé le plugin bigfoot plus respectueux en accessibilité.

    Répondre à ce message

  • Je m’en suis sorti par une boucle recherche.
    Cela nécessite le plugin « Recherche Fulltext ».

    1. J’ai ajouté un fichier nommé « inc_recherche » dans mon squelettecontenant le code suivant :

    <BOUCLE_recherch(ARTICLES){recherche}{! par points}>
    <a class="bloc spip_in" href="#URL_ARTICLE">#TITRE</a>
    </BOUCLE_recherch>

    2. J’ai ajouté ces 2 lignes dans ma page :

    <INCLURE{fond=inc_recherche}{recherche="#TITRE"}>
    <INCLURE{fond=inc_recherche}{recherche="#TERMES|replace{',' , '" "'}|concat{'"'}}>           

    Je ne doute pas que tout cela soit perfectible, mais c’est une solution rapide.

    En parcourant le forum du plugin Fulltext, je me suis d’ailleurs aperçu qu’un autre développeur faisait le lien entre ces 2 plugins

    Répondre à ce message

  • 3

    Bonjour et merci pour ce plugin,

    Y a t-il un moyen de boucler les articles où sont présents les termes d’un dictionnaire ?

    Cordialement,

    • Salut, ça doit pouvoir se faire en bouclant sur les champs titre et termes des définitions associées à un dictionnaire. Puis ensuite, en bouclant sur les articles de ton site en cherchant les termes dans le texte des article.

    • Ça me parait très (TRES) couteux. Surtout ce qui est prévu (todolist) au départ, c’est de scanner un contenu dès qu’il est édité (un article par exemple) et d’ajouter le lien à la définition (il y a déjà une table definitions_liens de prévue dans la base). Bref : comme pour les documents quoi. Notamment pour l’afficher ensuite dans l’admin en-dessous de chaque définition.

    • Oui c’est coûteux, je proposais cette solution car je ne savais pas que c’est dans la todo :p Maintenant on le sait ^^

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom