Extension talk:Glossary

the code you said to find in the in glossary.php, is not there ,i.e. begins with $title.

see the bit here

// Get the list of emoticons from the "MediaWiki:Glossary" article. $title = Title::makeTitle( null, 'Glossary' ); $emoticonListArticle = new Article( $title ); $emoticonListArticle->getContent;

Tarlachmoorhouse 10:13, 13 June 2007 (UTC)

It Stops links working
The tool tip is great but I'd like to take it a bit further (but don't know enough about how to do it), I want to be able to make the entries automatic links to pages that would contain more information on the TLA.

I tried putting wikilinks around the TLA e.g. do it manually FTP or even List of FTP Clients but it just displays the brackets rather than making it a link.

I know that the system already does a tool tip with wiki links, this would saving having to create a link such as FTP to get the tooltip to display the full name

FTP//File Transfer Protocol


 * 1) this would display as:- FTP (but in blue)
 * 2) it would show a tool tip of:- File Transfer Protocol
 * 3) would be a link to:- File Transfer Protocol (FTP) e.g. File Transfer Protocol (FTP)

I could then create a page on FTP with more details, also possibly putting the page into a category 'Glossary' etc.

Tarlachmoorhouse 08:35, 13 June 2007 (UTC)


 * -I would also like this kind of feature --193.167.195.60 11:47, 8 November 2007 (UTC)

Make the Glossary page readable
The following simple adjustments make the glossary a readable page.

lines 63-69 // If the content successfully loaded, do the replacement if( $emoticonListArticle->mContentLoaded ) {                       $emoticonList = explode( "\n;", $emoticonListArticle->mContent ); foreach( $emoticonList as $index => $emoticon ) {                               $currEmoticon = explode( ":", $emoticon, 2 );

then you can do your glossary as a list using the ;Item:explanation wiki markup, so that it looks like this:


 * Item:Explanation
 * Item:Explanation.

also - this needs to be updated to work w/ firefox and to ignore template calls, and work inside headings and items that land in the TOC. I think in order to work w/ Firefox AND to allow for the ability to link mentioned above, It'll have to be modified to create a floating DIV that will pop up on mouseover...It'd take some JavaScript, i think, but probably could be Inline and not require anything in the heading...

Made the Glossary page readable
I made a few changes to get this to work more effectively. I changed the target glossary word color to green so it is more obvious that it is special and I implemented the above suggestion to make the glossary more readable (explode on : and take out leading ;). Working in 1.10.1 and with Firefox. Cheers, Wade.

Here is the revised php extension file:

Does the extension work with MediaWiki version 1.10.1?

I didn't manage to make it work.

--Jperl 09:30, 3 August 2007 (UTC)

Can't make it work with 1.10.1
This extension is really usefull, and the last adding to make it more "readable" great, but I can't make it work on the current version of MediaWiki which is 1.10.1, does anyone have a solution ?

Knowing that the extension it is based on (emoticons) works perfectly. Did you mean this error... Warning: preg_replace [function.preg-replace]: Compilation failed: nothing to repeat at offset 5 in ....extensions\Glossary\Glossary.php on line 91

Just made it work with 1.10.1
just made it work with mw version 1.10.1. --Jperl 17:16, 5 August 2007 (UTC)


 * You going to tell everyone how you did that? Will make life a whole lot easier for those who encounter the same issue ;) --Dr DBW 08:04, 21 August 2007 (UTC)


 * Well I simply used the above code. But now the problem I have is that on permanent link pages, not the glossary is read, but the page itself. And so there a preg replace error occurs, because of the mediawiki links Jperl 08:12, 23 August 2007 (UTC)

Bug in MediaWiki or simply wrong use of a function?
the following lines should read the glossary page. and the simply do.

but if an oldid isset, they aren't reading the glossary, but the text of the actual article. and if there a wikilink Link:Text isset, this is producing a preg_replace error (since i exploded with : (see above code)).

is this a normal behaviour of mediawiki? can anyone tell my why this happens?

for all of those having the same problem (glossary works for normal articles but not with permanent links), I have made an ugly bugfix (glossary will unfortunately not work with permanent links).

simply put this line below the above three lines. this will cause the function stop if there a [ is in the glossary (or article whatever is read).

it might be, that also other syntaxes cause problems. so then simply include another strpos or make a preg_match out of it.

but I'd like to come to the root of this problem. so please tell me wheter getting the content of an article was already made wrong.

--Jperl 08:45, 23 August 2007 (UTC)

I changed the explode code to ":-" so that it won't explode errant colons or double slashes and still get the benefit of the ;Word:Definition formatting. I also added right before for obvious reasons (it was crashing my page). However, right now, (I'm on 1.6, php4) it's not adding the tooltip to the page, which it was doing before I used the modified code on this page, hmm --Benjo4u 23:28, 7 September 2007 (UTC)

code should be revised
the code of this extension should be revised.

Johannes Perl wrote: > I've some sort of problem with the glossary extension. > The following lines should read the glossary page and they simply do in a > normal case. > > $title = Title::makeTitle( null, 'Glossary' ); > $emoticonListArticle = new Article( $title ); > $content = $emoticonListArticle->getContent; > > But if an oldid is set (permanent link on article), they aren't reading the > glossary, but the text of the actual article. > Is this a normal behaviour of mediawiki? Can anyone tell my why this > happens?

Because Article::getContent is horrible and should never be used by anybody outside of internal code that does article views. :)

For clean behavior, use the Revision class:

$rev = Revision::newFromTitle( $rev ); if( $rev ) { $content = $rev->getText; } else { // Maybe do a nice error message here? $content = ''; }

- -- brion vibber (brion @ wikimedia.org) --Jperl 16:24, 9 September 2007 (UTC)

Example Sites?
Any sites using this that we can have a look at? Thanks --Dr DBW 05:26, 10 September 2007 (UTC)

working code
hi,

i revised the code, since the I don't think the author will do it.

This is my working code using the one already edited by wvanbusk. So the glossary should be entered in the way


 * HTTP:Hypertext Transfer Protocol
 * FTP:File Transfer Protocol

It also shouldn't destroy links, as it is the case (for me) with the other code. And since I used the Revision class it also works with permanent links.

--Jperl 12:50, 10 September 2007 (UTC)

I've added  at the end to make it work with MW 1.11.0.

--Flavien 09:26, 20 September 2007 (UTC)

Problem with using glossary words for explanation in other glossary entries
I'm using the original extension code with entries seperated by // If I do an explanation for one entry and use another entry-word in this explanation the extension doesn't work, because of recursive use of the -tags. Example: LAN// LocalAreaNetwork WAN// WideAreaNetwork,connection between different LAN s.

This doesn't work. Has anybody a suggestion how to solve this problem? --Luna2504 09:58, 12 September 2007 (UTC)


 * Well in this case you should extend the regulary expression so that it doesn't replace it within already existing tags. --Jperl 12:56, 13 September 2007 (UTC)


 * And how can I do this? I'm a newbie in php :( I actually changed my version of the extension to the last version publicated here. Where do I have to add/change something in the code? Thanks for every helping advice. --Luna2504 10:33, 17 September 2007 (UTC)

Category problem
If i use a term that has been defined in the glossary as a category name, the category is not beeing recognized. Instead the text is shown:

anybody experiencing the same problem?

Problem with links and glossary phrases containing same words
Revised code brokes links when glossary term is part of link. It does not break links when the whole glossary term is used as link: TERM works just fine some text TERM breaks This only breaks when name of the link contains some text before TERM and some text and TERM is separated with space. Links does not break if some text is added after TERM.

I am also having problems with terms containing part of other terms: TERM1 = Some term TERM2 = TERM1 + some text In this case TERM1 works ok, but in TERM2 only the TERM1 part is rendered and rest is treated as normal text

Any ideas?

Thanks --193.167.195.60 11:45, 8 November 2007 (UTC)

This works for tags whose definitions might include tags. It also includes the beginnings of an attempt to ajax (using sessions) it so it's not built into the page.

This is the tooltip library I like using, wz_tooltip tooltip. I've edited the js to accept all my defaults.

Here's my ajax code GlossTipAjax.js

Tooltips are too short
Tooltips are too short, is there any way to change that?

--JuhaV 11:37, 14 November 2007 (UTC)

A Complete Rewrite
Here's a rewrite I did, because I couldn't get the other code to work the way I wanted. This extension only modifies text, so it doesn't break things. It uses the ;: definition list (be sure the term and definition are on the same line).

This requires PHP 5.

Please let me know what you think.

Whew! This version appears to be a lot better. Thanks for fixing many of the problems that my original version had. (I didn't see the discussion page to this extension until today -- sorry everyone.) On the other hand, lack of updates from me got the much improved version above.

I modified your version:


 * Handle the lack of the javascript tooltip library dynamically. (If it doesn't exist, fall back to browser tooltips.)  I also documented that in the source code.
 * Made the javascript tooltips sticky (nothing should EVER follow my mouse)
 * Fixed a bug where the tooltip could get "stuck" on

I'm putting this version up on the main page, and changing the author to be you with patches from me. (Same as the source says now.) I'd have checked with you first, but don't see contact information for you.

- Benjamin Kahn ( User:Xkahn ) Mar 19, 2008

Doesn't work for me!
The above code doesn't seem to work for me. I get a cursor with a question mark next to it when I hover the mouse over a piece of text that has a glossary item defined, but nothing else. I've tried editing and saving both the article and the glossary page. I'm running mediawiki 1.11, PHP 5.25, Apache 2.2 and browsing using Mozilla 2.0.0.11 Sorry! Should have read the whole page more carefully. Had not installed the javascript. All working now - very nice. Great job.

Hmm. There seems to be a clash with Semantic Forms v0.9.3. If you have a form with a property that is also a term in the glossary then that field is busted in the form. For example: EC ID: gets displayed like: EM]" type="text" value="" size="35" /> on the page. EM is a term in the glossary and EM is also a Sematic Forms property. This code clashes horribly with the Semantic Forms extension.

Breaks Google Maps Extension
I used the code in A Complete Rewrite above, which worked quite well. I'd like to get multiline tooltips and embed HTML as described in ws_tooltip.js, but other than it it works great.

The only problem I have is that it breaks any maps generated by the Google Maps extension if there are any glossary keywords on the same page.

For example, one of my pages used the word NOS, which I had previously defined as a glossary entry. When I navigate to that page, the I get the tooltip for NOS, but the map is completely missing from the page.

I found that if I removed the word NOS from the page, the map displayed as expected. It is important to note that the NOS text was not in the Google Maps code block, but rather is in the main body of the page as normal text. I can only conclude that the parser is somehow affecting the Google Maps extension's code in some way.

If you need any more details just let me know and I'll see what I can do. - Jangell 16:02, 3 March 2008 (UTC)

Not working with Chinese Glossary
It'll not work for Chinese like following: The line 3 will not work.--Roc michael 02:29, 26 March 2008 (UTC)
 * AFAIK:As Far As I Know
 * AWGTHTGTATA:Are We Going To Have To Go Through All This Again
 * 預覽:預先瀏覽

Error after editing file
I succesfully installed the extension as described.

Then, I wanted to add a class property to the  tag used by the extension (to use in combination with common.css), so I added the line: $span->setAttribute('class', 'glossary');

After that, I got the error:

Warning: Cannot modify header information - headers already sent by (output started at /usr/home/****/public_html/wiki/extensions/glossary.php:1) in /usr/home/****/public_html/wiki/includes/WebResponse.php on line 10

I removed the line, put the old glossary.php file back, but still got the error. If I remove the require_once line, the error disappears, when i again put in the require_once line the error reappears.

Does the extension store the glossary entries somewhere else? Could this be causing the error and if so, can this data be purged?

Folkert Roscam Abbing 23:50, 3 April 2008 (UTC)
 * (btw, I experienced the same problem with another extension (Lockdown), also after adding 1 line of text to the extension source, very strange)
 * I triend including the contents of the file (between the  tags) directly into localsettings.ini. The error disappears, but ofcourse, this is not really a nice solution. If I insert a newline before the  and copied the code between these tags to the new file. Then I compared the files on byte level, and there turned out to be some nonprinting characters in beginning of the first (faulty) file. - Folkert Roscam Abbing

Also breaks HeaderTabs extension
I really like this extension, but as well as the problems with Semantic Forms (and other extensions) mentioned above, if there are any glossary entries on a page that uses the  tag, the   tag has no effect. I haven't yet been able to work out why. --Snuck 00:28, 7 April 2008 (UTC)