[nodebb-plugin-glossary] Glossary Plugin for NodeBB

phenomlab

@baris I noticed that the GitHub feature has been closed. Well this new feature be added to the version in npm ?

Thanks

<baris>

It is in version 0.0.5

phenomlab

@baris thanks

phenomlab

@baris [email protected] doesn't seem to exist ?

nodebb-plugin-glossary

A glossary plugin. Latest version: 1.1.0, last published: a year ago. Start using nodebb-plugin-glossary in your project by running `npm i nodebb-plugin-glossary`. There are no other projects in the npm registry using nodebb-plugin-glossary.

npm (www.npmjs.com)

<baris>

Hmm that's weird, maybe I forgot to publish. It is published now.

phenomlab

@baris Thanks - I see it now.

phenomlab

@baris One thing I've noticed here is that the plugin seems gratuitous in terms of REGEX - it's matching on any part of the word, meaning things like AI is detected inside disdain and certain - is there any way we can have a setting that looks for a complete match rather than partial ?

<baris>

That sounds like a bug, please file it on the github repo. It should only match on whole words.

phenomlab

@baris I found the issue (for my case). In library.js the regex statement looks for insensitive as below

keyword.nameRegex = XRegExp(`(?:^|\\s|\\>|;)(${keyword.name})`, 'gi');

I've changed it to

keyword.nameRegex = XRegExp(`(?:^|\\s|\\>|;)(${keyword.name})`, 'g');

Which works fine for my use case (virtually all of the acronyms I have are in upper case). However, lower case words are still affected.

Issue with over gratuitous regex · Issue #3 · NodeBB/nodebb-plugin-glossary

One thing I've noticed here is that the plugin seems gratuitous in terms of REGEX - it's matching on any part of the word, meaning things like AI is detected inside disdain and certain - is there any way we can have a setting that looks ...

GitHub (github.com)

<baris>

Seems like it is already matching the whole world AI it just matches lowercase as well. I can make the case-sensitivity an option in the ACP page.

phenomlab

@baris Yep, that would be great..

phenomlab

@baris From what I see, the plugin is actually firing on whole words

In this case, it's matching on bits as well as bit (which it should)

And also matching on dev inside devil

EDIT: Sorry - this was due to the CSV import I have... Ignore that

phenomlab

@baris another suggestion would be to empty the table storing the glossary items. When you import 1000 plus from a CSV it's very clunky to have to delete them all one by one if you need to.

Allow option to empty glossary content · Issue #5 · NodeBB/nodebb-plugin-glossary

A suggestion would be to empty the table storing the glossary items. When you import 1000 plus from a CSV it's very clunky to have to delete them all one by one 🙂 if you need to.

GitHub (github.com)

<baris>

Published 0.0.7, with bunch of fixes and new options.

phenomlab

@baris Thanks. I spotted a bug in 0.6 when performing a large import. The mapping being returned should be (for example SNMP Simple Network Management Protocol comes back with SNMP something completely wrong)

Examples

and

Not sure if my data is incorrect (I'll check), but wanted to report this in case it is actually an issue. Reverting back to 0.5 the issue is not present

and

So, I think there is a bug somewhere

<baris>

Yeah the csv import is pretty picky, it expects the format to be

keyword1, description1 
or 
keyword2, "description2"

If you provide a small csv sample that doesn't work I can take a look.

<baris>

add csvtojson support · Issue #7 · NodeBB/nodebb-plugin-glossary

use https://www.npmjs.com/package/csvtojson instead of custom code

GitHub (github.com)

phenomlab

@baris thanks. So a space is required between the comma and the next field. Odd that this doesn't seem to happen in 0.0.5

<baris>

I updated the plugin to use https://www.npmjs.com/package/csvtojson so it is using the csv spec from https://www.loc.gov/preservation/digital/formats/fdd/fdd000323.shtml

phenomlab

@baris This doesn't seem to work for me at all using the latest version sadly. It doesn't matter which format I use, the import always seems to work, but exhibits the same issues as I highlighted earlier. Version 0.5 does not have these issues from what I can tell.