Choosing between glossary-type modules

There are several glossary-type modules available, all of which are designed for slightly different needs. This page is here to help you choose which module you should probably be using, or if you should really write your own.

* _{G2's support for 5.x is intended as a bridge from 4.7 to 6.x.}

Obviously, in all cases, a "No" actually means: "roll your own", as in all Open Source software.

Rationale for G2 specificities

G2 is not intended as a direct replacement for the glossary module already available with Drupal for quite some time now.

A more detailed comparison for choosing a glossary-type module can be found at audean.

• Optimization for large glossaries: this is the need expressed by OSInet, which funded development, to support its 5000+ term glossary of computing, for which glossary.module, even when coupled with flexinode to bind blob content to terms, is not really efficient enough.
• Single glossary: multiple glossaries were not necessary to the initial sponsor
• Explicit linking to terms with dfn elements:
  • limits system workload
  • allows invisible marking of entries made of other entries. Think: XML-RPC, points to XML and to RPC with glossary.module and various wiki filters, but can point to "XML-RPC" with G2. Wrapping XML-RPC in quotes is necessary to allow linking to this entry in glossary, but the quotes remain visible, degrading the UI.
  • allows redactor-level choice of:
    • whether to link to an entry: Glossary typically links if the term matches, which is not always meaningful ("and" can be present in a glossary and you don't want "and" to be linked from in all nodes on the site).
    • where to link to an entry: glossary allows only a predefined set of positions (first, last or all matches).
• nodes vs terms: this is the most salient difference.
  • Using custom node types in G2 allows large definitions, with the complete Drupal feature set for nodes.
  • Using terms (glossary.module) allows definitions to be bound to custom nodes instead of being nodes on their own.
• Alphabar maintenance: large glossaries will, most of the time, use all available initials, so the processing cost of maintaining it is not justifiable.

Glossary Design

• Customizable
• Administrator options.
• Glossary display.
• Alphabet / Alphabar.
• Input Formats.
• Indicator style.
• Link type.
• Choice of HTML elements.
• Term matching flexibility.
• Liberal CSS usage.
• Multiple glossaries.
• Add-on modules.
• Taxonomy options.
• Related terms link to each other.
• Synonyms will filter the same.
• Drupal filter. Cacheable.
• Translation template provided.

The Glossary module has largely been designed by its users. Many, if not most, of its features have been added and refined by the input of the community. It is actively maintained and there have been performance efforts to make sure it runs as fast as possible. Considerable work has been done to make sure that i18n (internationalization) can be effectively used with Glossary.

Glossary uses Taxonomy to define its terms. While most sites have a smaller glossary than the one G2 was designed for, there are also sites with larger glossaries. The ability to handle multiple vocabularies as glossaries gives Glossary additional flexibility.

The Glossary module acts as a Drupal filter, locating terms within administrator-selectable content and adding additional HTML to them to show or (optionally) link the term's definition to the end-user as they view the content. The terms may be marked with a superscript or icon that links to the term or the term may be converted to an "acronym," "abbr," "cite," or "dfn" element with browser help tips. If the Hovertips and Clicktips module is installed, it may be used to provide hovertips. There are also three mechanisms for marking a section of the content to not be filtered. Matching of terms may be selected as whole words or substrings, and may be either case-sensitive or not.

Since Glossary filters content, the first time a piece of content is shown, there will be a small delay while the filtering is done. The filtered content is then cached, so the next time, the filtering is unnecessary and the delay does not occur.

When a user clicks on a linked term, they will go to the entire glossary or the individual term, depending on which option the administrator chose. When displaying the entire glossary, there is an alphabar on top, which fills in automatically. The administrator may define his/her own alphabet for those who use some language other than English. The terms are then organized by the first letter of the term's name. Each section may be separated by a CSS-themable separator. At the bottom of the display, if the user has the appropriate permissions, are shortcut links to the vocabulary and module settings pages.

Within the glossary display, each term may be followed by a link that will initiate a search for the term, if the search module is enabled. For those who have the proper permission, there will also be a link to edit the term itself.

The type of glossary indicator that is used is specified for each input format, so, for example, "Filtered HTML" may use a superscript type of indicator, while "Full HTML" may use a hovertip. Additionally, each input format also selects which vocabularies are to be used. So one may, again for example, specify that "Filtered HTML" filter for Bible verses, while "Full HTML" filters for technical terms.

Since Glossary is taxonomy-based, that opens the range of taxonomy-based modules to work together. For example, Taxonomy Image may be used to show images for the terms and Taxonomy Delegate may be used to delegate vocabulary maintenance to sub-administrators or editors.

Lexicon

The Lexicon module started out as a fork of the Glossary module for Drupal 6.x improving the output to be XHTML strict compliant for use in a project for the Dutch government. Soon after the release of Drupal 7.0 a 7.x version of the module was released and has been improved since then.