Select which terms will link to a term

Marbux - March 19, 2008 - 01:08
Project:Glossary
Version:5.x-2.1-beta4
Component:Miscellaneous
Category:feature request
Priority:normal
Assigned:NancyDru
Status:closed
Description

It would be nice if this capability is already there and I'm simply too dense to figure out how to invoke it.

I have an issue with the automatic back categorizing of terms. Here is an example. I am building a vocabulary of interoperability terms and definitions here. If I create a new term "XHTML 1.0 Strict" and select "XML" as a "see also" category it will be associated with, the Glossary module also automatically adds a "see also" reference from "XML" to XHTML 1.0 Strict." But I do not want all XML-derived terms to appear as "see also" references under "XML" because there are so many XML-derived markup languages that the terms more relevant to XML will be buried in a seemingly endless list of related terms.

It appears that now I can only deal with such issues by constantly editing the XML entry to remove the unwanted "see also" terms. Now multiply that issue for other terms as the vocabulary grows. I am finding that the more terms I create with "see also" links, the more I have to go back and edit terms I want cross-referenced in only one direction. At the same time, the 2-way referencing feature is a real time saver with many terms.

Feature request:

I would like an optional glossary feature that works past such issues, e.g., by:

  • performing a dry run on a draft glossary entry prior to saving the entry;
  • displaying the editing dialog as before with a selector populated by the terms the module has chosen for 2-way cross-referencing;
  • allowing the user to deselect terms from that selector so that deselected cross-references will be one-way only, from the term being edited to the other terms.
  • allowing the user to then save the term, definition, and modified cross-referencing state.

I have no idea how difficult it would be to implement the feature in the manner suggested. I am new enough to Drupal not to yet have a good idea where the taxonomy feature ends and the glossary module begins. The glossary module is the first use I have made of the taxonomy feature. The suggested user interface behavior is merely intended to illustrate the issue and desired functionality, rather than being intended to advocate a particular method of solving the problem.

It would also be useful, I think for the user to be able to set either one-way or 2-way relationships as the default, and to choose to enable/disable the suggested feature.

#1

NancyDru - March 19, 2008 - 15:44
Assigned to:Anonymous» NancyDru
Status:active» postponed (maintainer needs more info)

Hmm, my first thought was to use the synonym feature, but Glossary doesn't use that at the moment.

My second thought was that perhaps using a hierarchy might help you. Rather than defining a term as "related" you would make it a child term. I had to make some minor changes to the module to create the attached screen shot, but those changes could be incorporated into the module. Take a look at it and see if it might meet your display needs. If not, perhaps I can mock up something using the synonym feature - I just don't know what to call it on the display.

As far as your suggested "preview" feature, I don't see how to do that within the framework of taxonomy. That might have to wait for a possible feature to change to nodes. There is another glossary module (G2) that might provide that capability.

AttachmentSize
glossary_children.jpg 43.02 KB

#2

Marbux - March 25, 2008 - 13:22

Hi, Nancy,

G2 Glossary isn't an option for me unless I upgrade to Drupal 6. It doesn't have a version compatible with Drupal 5.

I like the formatting you designed. Is the bolding of the initial caps in "Integrated Development Environment" applied automatically or manually? In any event, I think this formatting would be a nice option in the module.

I will do some playing with hierarchical entries to see if that will cure at least part of my problem. The weakness I see there is that second level terms wind up not being displayed alphabetically along with first-level terms. Conceivably, this might be worked around with an algorithm for second-level terms that automagically creates a corresponding top-level entry that, using your example, might say "Dreamweaver, see IDE > Dreamweaver," or some such, with "IDE" linked to the IDE term. I think the downside of this approach, even if feasible, is that this might add a lot of processing overhead that would slow the system down prematurely as a glossary expands.

I'm also making some progress by being less effusive with my cross-references.

Another method I've been thinking about is to experiment with a supplemental separate taxonomy. I'm not sure how that might work yet, but it seems (vaguely) like there might be a solution lurking there.

Yet another approach to think about (which I think would be very useful by itself) is to display a link for a "permalink" below each glossary term, for obtaining a hyperlink to that term. This would be useful for folks who want to link to terms from external sites. Right now, I have glossary set to display only a single term when the term is selected from a content page. I can obtain a permalink from the glossary itself by navigating to the desired term, clicking on a cross-reference, then in the resulting page, click on the backlink to the original term. That produces a URL in the browser location bar that can be used for external links. But it would be nice to have each glossary entry to be followed by a "permalink" link; it saves a lot of explanation for my users and the functionality of the term "permalink" is widely understood.

From there, if a standard bit of markup might be introduced to insert permalinks in the text of term descriptions, I think we'd be there because "permalinks" are one-way. So if a user might insert in a description a bit of markup — e.g., like <!-- glossary:ide --> or <!-- glossary:application-level interoperability --> — that would automagically insert the corresponding permalink in the description text as a relative URL with the correct entry title as the link title, I think that would serve all of my needs. I suspect the trickiest part might be developing an algorithm to translate the markup into the correct node URL name to form the hyperlink.

That might also set the stage to make other uses of the permalinks, e.g., piping all permalinks to a single page/block so that folks who are familiar with the glossary and wish to externally link to terms could open a single browser tab to have permalinks to any term at their disposal with one click.

But again, I don't know whether this concept is do-able.

#3

NancyDru - March 25, 2008 - 13:47

The formatting you see is "standard," in the sense that the current CSS allows it. I don't recall off the top of my head if I have my own personal change there or not. There are a few minor tweaks to the code to make it work the way you see it in the example but they are already done in my copy of the 5.x module (still have to port to 6.x).

I did consider adding a "parent path" for child (sub) terms, but thought that could be even more confusing.

Since no one has yet complained much about the performance of the glossary_page code (other than allowing page-per-letter), I'm not looking at problems there yet. I'm trying to figure out exactly how to split it into a separate file to reduce code load times, which would help. Further, I am, hopefully, about to take over the Taxonomy List module too, and there is a suggestion there to make it more of an API, which the Glossary module could use to produce the overview page.

Another possibility is some sort "context" type of drill down on the hierarchy. I haven't done much thinking on that idea yet, but it is rolling around in all that empty space in my head.

The idea of an external link has been mentioned before. I'm not sure how to do that without introducing a Glossary-only table to contain that. One idea I have had is to prefix an external link with something like "#ref: " and then add code to check for that.

The term "permalink" is new to me and I don't really understand your description, can you please clarify it so a blonde can understand it?

#4

Marbux - March 27, 2008 - 05:51

Somehow I get the idea the problem is more with my explanation than with your blonde hair. :-)

"Permalink" is a term that was coined in the context of web apps that cycle content from e.g., a web site's front page to archives. I.e., if you link to the front page, the content you want readers to see won't be there later when you link to that page. So e.g., with Drupal, clicking on a heading of a blog entry on a front page will take you to the archive "permanent" link for the particular node.

Somewhat more loosely, a "permalink" can be just a named anchor link. For example, look at the comments on this Groklaw web page. Immediately under each comment there is a line that begins, "Reply to this," and ends with a number sign # hyperlink. Click on the number sign and you are taken to a new page that has the particular comment at the top and a unique URL. This allows linking to particular comments.

I had in mind something similar for the Glossary module so that people could link to a glossary term from external web sites. Whether you had Glossary set to advance to the term in the glossary or to display that term/definition alone, there would be a way to link to the particular term from external web sites.

I've got Glossary set to display a term on its own page when folks click on a linked term in content. The problem, however, is when someone wants to link to a term from an external web site. If the term has a "see also" cross-reference, folks can click on one of them and then click back to the original term to get a URL for the desired term in their location bar. But that's a cumbersome process. And not all of my terms have cross-references. Hence my desire to have a page that has nothing but the permalinks, so folks already familiar with the glossary can go to a single page and have a link to any term in the glossary accessible with one mouse click.

It sounds like Taxonomy List might get at least part of the way to the latter suggestion, if I'm understanding the documentation correctly. But I didn't see any mention of a wildcard to display all terms. Perhaps what I'm looking for here is the Taxonomy Browser module?

Best regards,

Paul

#5

NancyDru - March 27, 2008 - 13:40

Glossary entries can be linked from external sites already (assuming one knows the tid) and they should never "age" from the page, so I would say they are permanent already.

I think what you're saying is that you want a way to force the whole glossary to display (despite page-per-letter setting) and to have each term linked to itself?

Taxonomy Browser is for listing content by user selected terms, so I don't think that's what you want. In the context of this discussion, Taxonomy List is another way of displaying the Glossary overview page, but not with the full linking.

#6

NancyDru - April 25, 2008 - 11:19

Hmm, I think terms will link to themselves now since I am using check_markup now. So are we now down to forcing the whole glossary to display?

#7

NancyDru - April 28, 2008 - 14:22

@Marbux: I just had a "Duh" moment. The term_relations table has two tid values. Currently we look at both of them to build the relationships. I need to do some more checking, but I think we can add a setting to allow it to look at those values differently. This would then allow the option to have "one way" and "two way" related links. Currently, it is doing what I call "two way" but I don't think it has to.

#8

Summit - April 29, 2008 - 14:50

Subscribing, greetings, Martijn

#9

NancyDru - June 29, 2008 - 18:27
Status:postponed (maintainer needs more info)» fixed

Surprise! I finally got this done. There is a new setting for "one way" linking. Let me know how it works for you, please.

Fix committed to both -dev versions.

#10

Anonymous (not verified) - July 13, 2008 - 18:32
Status:fixed» closed

Automatically closed -- issue fixed for two weeks with no activity.

 
 

Drupal is a registered trademark of Dries Buytaert.