Extension talk:Glossary

From mediawiki.org

--Sorin Sbarnea 16:07, 27 May 2008 (UTC) Removed comments because the information is too old and all modifications were included in the last release.

preg_split Unknown modifier[edit]

Keep getting

Warning: preg_split() [function.preg-split]: Unknown modifier 'E' in /var/www/wiki/extensions/Glossary/Glossary.php on line 83

and

Warning: preg_split() [function.preg-split]: Unknown modifier 'O' in /var/www/wiki/extensions/Glossary/Glossary.php on line 83

please help --207.96.208.130 15:35, 28 July 2008 (UTC) Solution: some of my definitions had / in them example: I/O. Removed them and it works (although very very slow at parsing the page)Reply

Can't "shake" off the Glossary info from the mouse cursor !![edit]

I installed the 'latest' Glossary version '2008.05.27' - Works well on my Wiki 1.12 ..

When I place the mouse over a word, then move the mouse off the word, the information stays there forever and follows the mouse !!

It would also be nice if the Glossary words could be a 'green' colour - I'm sure at one time it was working that way  ?

Any help given will be much appreciated ...

--Dick 07:00, 28 May 2008 (UTC)Reply

Solution: Can't "shake" off the Glossary info from the mouse cursor !![edit]

Search for $span->setAttribute('onmouseover', "TagToTip('$term')"); in Glossary.php and add a new line after that.

The new line has to be: $span->setAttribute('onmouseout', "UnTip()");

After that you have to save the pages again because wiki is obviously caching the page content. (I'm new to mediawiki and had the same problem today. I have no idea (yet) on how to solve this cacheing problem otherwise.)

Christoph

...............

Thank You Christoph - your suggestion did the trick for me ... I didn't have to re-save pages either, just did a refresh on my browser and that was that .. I've used 'onmouseover' before but never thought about your solution - brain definitely getting too old ......

Now, if I can just get the 'green' colour back to the glossary words on the pages !!

--Dick 10:10, 28 May 2008 (UTC)Reply

...............

I asked about the green colour too and was given this response. I can't test it out because currently I can't get glossary to work at all (as noted below) but since you seem to have it up and running, maybe this will help:

(this is a piece of a larger email i sent to Benjamin Kahn)
> 2) it allows for the acronyms to show up highlighted or in a different
> colour from the rest of the text so users know to mouseover
>
>Yes. There is a line in the most recent version that looks like this:
>
>$wgOut->addHTML("<style text=\"text/css\"></style>");
>
>Simply change the style definition on that line to anything you want.
>
>.glossarydef {color: lightblue;}
>
>would work.

--Kay

...............

Kay,

I couldn't get your suggestion to work but did change this line in Glossary.php version '2008.05.27'

$span->setAttribute('style', 'cursor:help');

to read as:

$span->setAttribute('style', 'cursor:help; color:green');

which now gives me a green Glossary word ... Thanks for the idea ...

--Dick 14:42, 28 May 2008 (UTC)Reply

....................

Excellent! I honestly had no idea HOW to implement it, just wanted to pass on what i'd received in response, thought it might make more sense to someone who is more familiar with all of the code behind this than i am. I am glad it pointed you in the right direction. if i can ever get it back up and running again, i may try the suggestion you just made above.

--Kay

....................

Ok. i found the Glossary.php version '2008.05.27' and installed it and it is working. I tried changing the line as you stated above and it didn't work for me. I still get the little question mark but nothing at all shows up green. not the mark nor the text that the mark appears above when you mouseover.

--Kay

....................

Try clearing your cache - it may be the culprit..

As a matter of interest, a long time ago I placed the following at the end of my LocalSettings.php file

# When you make changes to this configuration file, this will make
# sure that cached pages are cleared.
$wgCacheEpoch = max( $wgCacheEpoch, gmdate( 'YmdHis', @filemtime( __FILE__ ) ) );

This does as it suggests and I can edit as I wish ...

--Dick 15:25, 28 May 2008 (UTC)Reply

....................

Ok i have that line in my LocalSettings.php it's actually been there but it isn't at the bottom. do you think that could be causing the problem?

--Kay

....................

Well I reckon that by having it at the end of the script would allow all the setting to be applied and then the cache flushed rather than some setting being set, cache being flushed and then other setting being set afterwards by LocalSettings.php ...

--Dick 08:54, 30 May 2008 (UTC)Reply


Having problems[edit]

Ok here is the information from my 'version' MediaWiki 1.12.0 PHP 5.2.4 (apache2handler) MySQL 5.0.44

I installed the glossary.php listed for PHP 5 and I also got the most recent copy of wz_tooltip.js. When i enable glossary.php via LocalSettings.php some of the pages look alright but for others, ( including special pages --> version) display: HTTP 500 Internal Server Error with the text The website cannot display the page

I have tried renaming the wz_tooltip.js so it doesn't get picked up at all and the problem remains. --Kay

...............

Interesting Kay - I also have one page on my wiki which won't display when i have the Glossary active.

If I look at my Apache error log it indicates that I had a 'timeout' ....

I have noticed a small delay on the loading of various wiki pages when Glossary was activated ... I assumed that this delay was due to the Glossary checking the page for 'keywords' and that my page that doesn't load and times out was because of the long time needed to do the check ?? .. Not sure if my theory is correct of course.

Possibly there is a setting in Apache that could alter the timing to load webpages ??

--Dick 11:00, 28 May 2008 (UTC)Reply

...............

While I was on a 'roll' I decided to try out my theory - it appeared to work !!

I edited my 'php.ini' file and modified the time of 30 seconds (default) to 60 seconds

max_execution_time = 30     ; Maximum execution time of each script, in seconds

to

max_execution_time = 60     ; Maximum execution time of each script, in seconds

The page on my wiki which wouldn't load and gave a blank screen when Glossary was activated now loads correctly ...

I suggest that you look at your Apache error log file and see if it indicates a timeout on the relevant 'problem' page and then edit the 'php.ini' file accordingly ..

--Dick 15:20, 28 May 2008 (UTC)Reply

...............

30 seconds seems like a VERY long time to display a page. A small delay? This sounds like you have another problem. What is your server doing that pages are taking so long?

--User:Xkahn 14:53, 29 May 2008 (EDT)

...............

It appeared ONLY on the one page as I mentioned earlier - all the other wiki pages load reasonably fast ... I do have other server daemons running doing other jobs on my Linux box ...

As I said earlier, when I activate Glossary, then I notice a small delay when loading pages compared to when Glossary is deactivated. My 'theory' was that Glossary was referencing the keywords on the relevant page.

My url is http://www.zs6ro.co.za ... (Most of the 'green' words' are from the Glossary) ... The 'problem' page is at http://www.zs6ro.co.za/wiki/index.php/Amateur_radio in case you want to do comparisons but the Internet route delays etc may cloud the issue ... (Of course I'm testing on my LAN without the Internet involved, except maybe on some embedded links on the page. The pictures on the page are all local (on the same box) but possibly each one takes some time to load, adding up to more that the default 30 seconds)

My worharound works but if I can get back to the 30 second default it would make me much happier ..

--Dick 08:42, 30 May 2008 (UTC)Reply


All I get is a Question Mark in the tooltip[edit]

Hi, I setup the extension as instructed, and created a few entries in the Glossary page, but when I hover the mouse over the words, all I get is a Question mark next to the cursor instead of the actual tooltip. Any clue what I should do from here? Thanks!

Simon (using MW 1.12)

...............

Make sure that you have 'wz_tooltip.js' installed and that Glossary.php knows which subdirectory its in !!

--Dick 17:23, 28 May 2008 (UTC)Reply

...............

Thanks for the tip.. But I'm still having trouble. It's weird. In glossary.php, I have <script type='text/javascript' src='$wgScriptPath/extensions/tooltip/wz_tooltip.js'>.

When I look at the Page Source, it resolves as: <script type='text/javascript' src='/wiki/extensions/tooltip/wz_tooltip.js'></script>

Everything should work, I don't understand. When loading the page, there is an error that says: "TagToTip is not defined"

...............

Check that the sub-directory 'tooltip' is 'tooltip' and not possibly 'Tooltip !! .. In Linux case is very important.

--Dick 08:42, 30 May 2008 (UTC)Reply

...............

SOLUTION: I found the problem. I was using an outdated version of wz_tooltip.js. (Version 3.45) I upgraded to version 5.12 and it works. Thanks to all,

Simon June 16h,2008

Formating in Glossary Page[edit]

Just a quick question. Can you include formating in the Glossary Page? e.g. can I have subheadings for each letter? Or will this impact the function of the solution? -George

Yes, the extension will ignore any lines without both a semicolon (;) and a colon (:). So, you can have headings and plain-text paragraphs -BarkerJr 20:01, 2 August 2008 (UTC)Reply

Pages not displaying[edit]

Hi,

I've installed the extension as described and created the Terminology page. The tooltip function appears to work (at least on the Terminology page). However when I go to my other pages in the wiki they are not being displayed. I implemented the php.ini change described above, but it doesn't solve the issue. I had a look the log files and this is what is reported back.

[client 161.30.167.79] PHP Fatal error: Call to a member function on a non-object in /srv/mediawiki/extensions/terminology.php on line 58, referer: http://161.30.167.79/wiki/index.php/CB

The CB page, for example does not contain anything extraordinary other than text.

George .......... Did you check to make sure that your terminology.php is pointing to the correct directory for the location of wz_tooltip.js? i always forget to do that and things get really weird

=Kay

Doesn't work as expected...[edit]

Hi

I've been using the previous version of Glossary and was very happy with it... As I upgraded to MW 1.12 it seemed to stop working. I then moved to the new version, and have to say it doesn't do what I expected. Why now doesn't it take care of case ? I end with all 'it' hilighted in green where I would expect only "IT" (Information Technology) to be... Also, previous version had the ability to be turned off when editing, deleting... which was very convenient ! I enjoyed also the simple HTML return code that could easily modified by newby as I am. I changed it to add a link to the acronym page... Is there a way to bring that capability back ?

What is the difference between Glossary and Terminology ? Apart from the fact that Glossary worked straight on my MW 1.12 and I couldn't have Terminology to work :(

Is there a way for Glossary not to parse links (ie I would prefer not to get tooltips on acronyls that are part of a link on page) ?

Thanks in advance for all your help.

Doc Color

wz_tooltip 5.13 broken[edit]

Reportedly 5.12 was working. The problem might be 5.13. Here's the fix:

Comment out line 537 and change 538 of this file, so that they now look like this:

//      if(!tt_db || !location.href.match(/http\:\/\/(www\.)?(walterzorn|devira)\./))
        if(!tt_db)        return;

Basically, the author hooked it so it could only be used on his site. Maybe that was for testing. --Otheus 17:03, 9 July 2008 (UTC)Reply

exculde pages or tags from other extension[edit]

Currently i have a problem with, if i use the following extensions together.

glossary
hierarchy

If i save the hierarchy page, the glossary extension modifies the code, so that the hierarchy extension fails. To solve the problem it may be cool, to exclude pages/namespaces or even text between specific tags. The hierarchy extension uses the

<index>

tag.The whole text between this tags should not be modified by the extension.

--Ozz 12:08, 12 July 2008 (UTC)Reply

Examples in the wild?[edit]

Are there any publicly accessible examples of wikis using this plugin that I can see? It sounds good, but it would be nice to see it in action before I take things further. --155.136.80.162 13:34, 16 July 2008 (UTC)Reply

You can see it at http://wiki.synmod.org/wiki/Main_Page (hover over NPC or Server) -BarkerJr 16:33, 2 August 2008 (UTC)Reply

Possible perfomance issue[edit]

Hello all.

The Glossary extension was working great until I increased the number of entries in the Glossary page I have ~195 acronyms and the site is becoming increadibly slow. If I switch off the Glosary the speed of the site returns.

Anyone else noticed this and/or is there a way to remedy?

Side effects with FCK Editor[edit]

When editing a page with the FCK Editor, the tags inserted by the glossary were written into the wikitext source. Further edits add further tags around the glossary terms. Does anyone have a solution for this Problem? Perhaps disabling the Glossary while editing?

Ok, I tried to disable the glossary by adding three lines at the beginning of the function glossaryParser:

  function glossaryParser(&$parser, &$text) { 
  global $wgRequest;
  $action = $wgRequest->getVal( 'action', 'view' );
  if ($action=="edit" || $action=="ajax") return false;
  ...

The action "ajax" needed to be disabled, too, because switching in FCK Editor from WikiText to WYSIWYG renders the glossary entries again. Kai Woska 14:18, 12 September 2008 (UTC)Reply

Glossary keywords in headings and corresponing edit links[edit]

Some strange effect: When a glossary keyword is located in one of the pages headings, the corresponing edit link first comes up with the right title popup (from the normal html title attribute). When moving the cursor over the heading, the glossary entry pops up correctly, but when moving back to the edit button, the title attribute has been emptied. This occurs in the moment the onmouseover event of the glossary keyword fires (without delay from the glossary popup).

Nice html entries ?[edit]

Before I install it... Can the extension nice display formatted text: bold, italic ; multiline tips ; complete tips, with images and tables, including links...

In fact, I was thinking about defining a special "glossary" namespace, and creating all extended glossary definition there - one page per definition... With also would allow to include these pieces of text in a regular text.

Any plan to extend such a way ?

...Otherwise, I probably could do this on my own, but I won't have time to engage into a public release here. IF a finally came out with this, could anybody here take time to package it on a page, write the doc and submit it to the Extensions place - so others can benefit ??

--FredT34 05:38, 28 September 2008 (UTC)Reply

Dots do not work[edit]

When I use dots in an abbreviation, no glossary tooltips are created. Example:

q.q.
Qualitate Qua

This does not work. Is there a workaround for this?

This is due to the regular expression used to find text matching the glossary term. Within the function glossaryParseThisNode{} you will see the following line of code:
$texts = preg_split('/\b('.preg_quote($term).'s?)\b/iu', $node->textContent, -1, PREG_SPLIT_DELIM_CAPTURE);
Within that, the regular expression used to search for the glossary term is:
'/\b('.preg_quote($term).'s?)\b/iu'
Noting that the apostrophes delimit strings and that the periods perform string concatenation, this breaks down to mean:
Part of expression Meaning
/ start the search expression
\b a word boundary
( start of string expression
preg_quote($term) the glossary term
s? 0 to 1 occurrences of the letter s
) end of string expression
\b a word boundary
/ end the search expression
i use PCRE_CASELESS option (ignore the difference between upper and lower case when comparing text)
u use PCRE_UTF8 option (treat text as though it is encoded in UTF-8)
So the string expression sought is the glossary term (followed by an optional 's') as a distinct word, ignoring case.
Your issue is with the word boundaries. The periods in the term 'q.q.' are treated as word boundaries and so this glossary term is never matched by the regular expression above.
You probably want to replace the word boundaries in the regular expression with a term denoting any character that is not alphanumeric or a period. (Depending on your glossary terms, there may be other characters that you want to add to the list of characters that form a word.) This should allow correct matching of your glossary terms.
I haven't tested it (this is just from my understanding) but I believe that the following term should work for that part of the regular expression:
[^.0-9a-z]
(The square brackets denote a character class. The circumflex is a NOT symbol, here. So this expression matches any character that is not a period, not a digit, and not a letter. The PCRE_CASELESS option still applies here.)
This bit of the expression should replace both of the word boundaries, and I believe should be inside of the round brackets. This would give the final full regular expression as:
'/([^.0-9a-z]'.preg_quote($term).'s?[^.0-9a-z])/iu'
And so you should replace the complete line of code with:
$texts = preg_split('/([^.0-9a-z]'.preg_quote($term).'s?[^.0-9a-z])/iu', $node->textContent, -1, PREG_SPLIT_DELIM_CAPTURE);
As I say, I haven't tested this. Give it a go and tweak as necessary taking the documentation on regular expressions into account.
-Stelio 03:09, 27 February 2009 (UTC)Reply

Major revisions to allow disabling and fix multi word issues[edit]

I found that this extension conflicts with other extensions (like Hierarchy) as it changes the actual text. I added a function and another parser hook to allow for disabling the extension via a comment or a parser option.

$wgHooks['ParserAfterStrip'][] = 'glossaryCheck';
function glossaryCheck(&$parser, &$text){
	global $glossaryEnabledOnPage;
	
	// This allows for other extensions to disable the glossary if they need to.  Example: Hierarchy.
	// You can force disable the extension by setting the parser options variable "glossaryEnabledOnPage" to 0
	// You can force enable the extension by setting it to 1
	$options = $parser->mOptions;
	$enabled = $options->glossaryEnabledOnPage;
	if (is_int($enabled)){
		if ($enabled == 0){
			$glossaryEnabledOnPage = false;
			return;
		} elseif ($enabled == 1) {
			$glossaryEnabledOnPage = true;
			return;
		}
	}
	
	// If not forced, check to see if the wiki text has a __NOGLOSSARY__ command
	$pos = stripos($text, '__NOGLOSSARY__');
	if ( $pos != null and is_int($pos) and $pos > 0) {
		$glossaryEnabledOnPage = false;
	} else {
		$glossaryEnabledOnPage = true;
	}
}

Example of a comment:

<!-- __NOGLOSSARY__ -->

You can also disable the extension from another extension by setting the "glossaryEnabledOnPage" variable on the parser options:

// Other Extension Code
function Render($input, $title, $options) {
	$options->glossaryEnabledOnPage = 0;
	// parse text
	$localParser = new Parser();
	$output = $localParser->parse($input, $title, $options);
	$html_text = $output->getText();


This should allow for better compatibility and flexibility of the extension.


After this I also fixed a bug that I found where multiple words were not being taken into account. So if you had two terms:

  1. Location
  2. Location Group

Then Location Group would never be parsed because it now has spans around it. I created a few classes and functions to handle this and changed the whole parsing and replacing code. I now create a glossaryDefinitions class that parses the multiple glossaryDefinition objects. It then uses the glossarySortByAttribute function to reverse sort by word length. It doesn't yet take into account the word length so theoretically, terms like:

  1. Gloss
  2. Glossary

might still conflict... maybe. Haven't tested it.

Anyways, the extension now works as expected for me and is compatible with other extensions that we are using. Future things I will probably do to the extension are:

  • Allow for multi-page glossaries (A page per letter - Glossary/A, Glossary/B, ...) As this is the standard convention for large glossaries.
  • Sort by Word length as well ( I still need to test around this to see if it is needed)

Below is the full revision of the Glossary. I believe it is stable and I have done MANY tests to make sure it works as designed:

<?php
/*
 * Copyright (C) 2007  BarkerJr
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * as published by the Free Software Foundation; either version 2
 * of the License, or (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
 */

/*
 * Download http://www.walterzorn.com/tooltip/tooltip_e.htm and extract it to $wgScriptPath/extensions/tooltip/
 *
 * Use definition-lists in the Glossary page.  Place one definition on each line.  For example:
 * ;CS-S:CounterStrike Source, a game by Valve
 * ;HTML:HyperText Markup Language
 */
 
 $glossaryEnabledOnPage = true;
 
$wgExtensionCredits['parserhook'][] = array(
	'name' => 'Glossary',
	'description' => 'Provides tooltips from the [[glossary]] defined for all instances of the given term',
	'version' => '2008.05.27',
	'author' => 'BarkerJr, Sorin Sbarnea, Greg Doermann'
);

$wgExtensionFunctions[] = 'glossarySetup';
function glossarySetup() {
	global $wgOut, $wgScriptPath;
	$wgOut->addHTML("<script type='text/javascript' src='$wgScriptPath/extensions/tooltip/wz_tooltip.js'></script>");
}

$wgHooks['ParserAfterStrip'][] = 'glossaryCheck';
function glossaryCheck(&$parser, &$text){
	global $glossaryEnabledOnPage;
	
	// This allows for other extensions to disable the glossary if they need to.  Example: Hierarchy.
	// You can force disable the extension by setting the parser options variable "glossaryEnabledOnPage" to 0
	// You can force enable the extension by setting it to 1
	$options = $parser->mOptions;
	$enabled = $options->glossaryEnabledOnPage;
	if (is_int($enabled)){
		if ($enabled == 0){
			$glossaryEnabledOnPage = false;
			return;
		} elseif ($enabled == 1) {
			$glossaryEnabledOnPage = true;
			return;
		}
	}
	
	// If not forced, check to see if the wiki text has a __NOGLOSSARY__ command
	$pos = stripos($text, '__NOGLOSSARY__');
	if ( $pos != null and is_int($pos) and $pos > 0) {
		$glossaryEnabledOnPage = false;
	} else {
		$glossaryEnabledOnPage = true;
	}
}

$wgHooks['ParserBeforeTidy'][] = 'glossaryParser';
function glossaryParser(&$parser, &$text) {
	global $glossaryEnabledOnPage;
	$rev = Revision::newFromTitle(Title::makeTitle(8, 'Glossary'));
	if ($glossaryEnabledOnPage == false){
		return false;
	}
	if ($rev) {
		$content = $rev->getText();
		if ($content != "") {
			$changed = false;
			$doc = new DOMDocument();
@			$doc->loadHTML('<meta http-equiv="content-type" content="charset=utf-8"/>' . $text);
			
			// makes glossary definitions to be on only one row, not two
			$content = str_replace("\n:",":",$content);
			
			$definitions = new glossaryDefinitions($content);
			
			$def_array = $definitions->getSorted(true);
			foreach ($def_array as $def){
				$term = $def->term;
				$definition = $def->definition;
				if (glossaryParseThisNode($doc, $doc->documentElement, $term)) {
					$span = $doc->createElement('span');
					$span->setAttribute('id', $term);
					$span->setAttribute('style', 'display:none');
					$span->appendChild($doc->createElement('b', $term));
					$span->appendChild($doc->createTextNode(": $definition"));
					$doc->documentElement->appendChild($span);
					$changed = true;
				}
			}
			if ($changed) {
				$text = $doc->saveHTML();
			}
		}
	}
	return true;
}

class glossaryDefinitions {
	public function __construct( $content ) {
		$has_definitions = preg_match_all("/;(.*)\:(.*)/", $content, $definitions);
		$this->definitions = array();
		
		if ($has_definitions) {
			for ($counter = 0; $counter < count($definitions[0]); $counter += 1){
				$this->definitions[] = new glossaryDefinition($definitions[1][$counter], $definitions[2][$counter], $definitions[0][$counter]);
			}
		}
	}
	
	public function getSorted($reverse = false){
		return glossarySortByAttribute($this->definitions, 'length', $reverse);
	}
}

class glossaryDefinition {
	public function __construct( $term, $definition, $wikitext = null ) {
		$this->term = $term;
		$this->definition = $definition;
		$this->text = $wikitext;
		preg_match_all('/ /', $term, $spaces);
		$this->length = count($spaces[0]) + 1;
	}
}

function glossaryParseThisNode($doc, $node, $term) {
	$changed = false;
	if ($node->nodeType == XML_TEXT_NODE) {
		$texts = preg_split('/\b('.preg_quote($term).'s?)\b/iu', $node->textContent, -1, PREG_SPLIT_DELIM_CAPTURE);
		if (count($texts) > 1) {
			$container = $doc->createElement('span');
			for ($x = 0; $x < count($texts); $x++) {
				if ($x % 2) {
					$span = $doc->createElement('span', $texts[$x]);
					$span->setAttribute('onmouseover', "TagToTip('$term')");
					$span->setAttribute('onmouseout', "UnTip()");
					$span->setAttribute('style', 'cursor:help');
					$container->appendChild($span);
				} else {
					$container->appendChild($doc->createTextNode($texts[$x]));
				}
			}
			$node->parentNode->replaceChild($container, $node);
			$changed = true;
		}
	} elseif ($node->hasChildNodes()) {
		// We have to do this because foreach gets confused by changing data
		$nodes = $node->childNodes;
		$previousLength = $nodes->length;
		for ($x = 0; $x < $nodes->length; $x++) {
			if ($nodes->length <> $previousLength) {
				$x += $nodes->length - $previousLength;
			}
			$previousLength = $nodes->length;
			$child = $nodes->item($x);
			if (glossaryParseThisNode($doc, $child, $term)) {
				$changed = true;
			}
		}
	}
	return $changed;
}

function glossarySortByAttribute($array, $attribute, $reverse = false){
	$att_array = array();
	foreach ($array as $item){
		$att_array[$item->$attribute][] = $item;
	}
	
	$sorted_array = array();
	foreach ($att_array as $items){
		foreach ($items as $item){
			if (!$reverse){
				$sorted_array[] = $item;
			} else {
				array_unshift($sorted_array, $item);
			}
		}
	}
	return $sorted_array;
}

?>

If you want to see this in action you can visit our wiki. The glossary is disabled on the actual glossary page, the main page, and the book index pages, but enabled everywhere else.

Hope this helps,

--Greg 22:01, 29 April 2009 (UTC)Reply

--->> MediaWiki internal error. Marc

wz_tooltip.js must be included INSIDE the body section, immediately after the opening <body> tag[edit]

I'm getting this error after installing glossary extension, the error appears after submit or preview on a Special:CreateForm SWM page. Does any of you know how to solve this issue? Is there a conflict between SMW and the Glossary Extension?

I am getting this error message, too. I am using MW 1.16beta2 and monobook. --kgh 11:46, 9 May 2010 (UTC)Reply
I addressed this problem on Extension talk:Terminology since this is the new extension providing Glossary's features. Cheers --kgh 21:43, 11 May 2010 (UTC)Reply

Glossary and semantic forms[edit]

Are these extensions incompatible with each other? Semantic Forms gives error messages related to wz_tooltip.js. Anyone knows how to solve that?

I presume this is the same problem as described [[Extension talk:Glossary#wz_tooltip.js must be included INSIDE the body section, immediately after the opening <body> tag|here]]. --kgh 11:47, 9 May 2010 (UTC)Reply