Talk:Glossary

From DIYWiki

Categories

I guess this one belongs in nearly all cats NT 17:29, 24 April 2007 (BST)

Yes I suppose we really need the ability to use a wildcard e.g. [[Category:*]] and have it appear automagically in every category listing. In the absence of such a facility it'd be a PITA to maintain it manually so maybe just 'Misc' or something? --John Stumbles 20:41, 24 April 2007 (BST)

I dont mind putting it in each category by hand some day. As and when.... NT 23:07, 24 April 2007 (BST)


Why is there a slightly-modified copy of the article here on the discussion page? --John Stumbles

Whoops - corrected :) NT 09:10, 28 April 2007 (BST)

Ah, so it wasn't part of the master plan then?!

more master ockup I think - NT

BTW what about using formatting it as a definition list like:

Round Tuit
source of energy and motivation for DIY jobs

I'm not suggesting changing it all hand - I reckon running it all through a cunningly-crafted Perl incantation should do it. (I'm happy to give it a shot if you think the result would be worthwhile.)

--John Stumbles 13:33, 28 April 2007 (BST)


That's easily done with the text editor, but is there an advantage I'm not seeing? NT 18:33, 28 April 2007 (BST)

I don't see any huge advantage but I think it'd look a bit nicer, be a a bit easier to maintain and look a bit more professional from the POV of anyone coming from another wiki (e.g. WP) since that's the formatting intended for this sort of list.

BTW how would you do it with the text editor (short of changing each one by hand)?

--John Stumbles 20:27, 28 April 2007 (BST)

OK I'll get it done next time I wiki. Sounds like you need a better text editor. NT 23:06, 28 April 2007 (BST)

I thought you meant the wiki editor. I could do it with vi but easier (for me) with perl. What editor do you use? --John Stumbles 23:34, 28 April 2007 (BST)

I see you've done it - nice one! What did you use BTW? --JDS
Mostly win32pad, fwiw. --NT


Split?

The article is quite big now. When I edit it I get a warning that some browsers may not be able to handle the size of it. I find it quite unwieldy to scroll through when reading, and even more so when editing. What do you think about splitting it? (If not into 27 separate alphabetical sections just yet, maybe just say, 0-L and M-Z?) --John Stumbles 18:31, 29 April 2007 (BST)

In all honesty I think that would ruin much of its usefulness. When I use a glossary I want to look up the words I need - having to go back and forth between different webpages is chaos, making a simple task unreasonably difficult.

Re the 32k warning, even the barely functional windows notepad can manage a pitiful 64k, and every PC owner has a WP even if not a txt-ed that can handle files way bigger. Even windows 3.1 Write can handle 100s of k. What wikimedia people were thinking when they wrote that I really don't know. I dont know how old wikimedia is, maybe they were trying to ensure 100% compatibility with some really old kit. NT 19:00, 29 April 2007 (BST)

I don't think it has anything to do with whatever editor you have on your PC but I'd guess it depends what size 'textarea' (or whatever the html form element is called) your browser can handle. --John Stumbles


Came across an explanation of this old rule:

"In the past, because of some now rarely used browsers, technical considerations prompted a strong recommendation that articles be limited to a maximum of precisely 32 KB in size, since editing any article longer than that would cause severe problems.[1] With the advent of the section editing feature and the availability of upgrades for the affected browsers, this once hard and fast rule has been softened and many articles now exist which are over 32 KB of total text size." NT 14:19, 18 May 2007 (BST)

As a matter of interest where did you find this, and what does the [1] refer to? --John Stumbles 23:13, 18 May 2007 (BST)


http://en.wikipedia.org/wiki/Wikipedia:Article_size

Theres a bunch more discussion about it, pros & cons. My take on it was that the important reason is now well & truly history, leaving only the q of article readability. And with a glossary, its not intended as an article to sit down and read all of. And even for dialuppers 32k is small. NT 23:54, 18 May 2007 (BST)

How about a glossary split by domain area?

So we could have an Electrical Glossary, a Plumbing / Heating one etc. That way you could still research a whole subject without getting loads of stuff from other unrelated areas of interest.

--John Rumm 02:24, 19 May 2007 (BST)


I'm sure those would be quite informative. I hope we also retain the all-in-one glossary though, as people need a place they can go to look up words they dont know, rather than clicking through 10 different pages trying to find one with their word on. NT 09:37, 19 May 2007 (BST)

Some subject glossaries already exist though, so a page of glossary links could save a lot of writing. There are already some links at the bottom of the main glossary NT 09:41, 19 May 2007 (BST)

Is "Search" not a solution for the "word I don't know" problem though? Its quicker to let the machine look for the term for you than reading through a list yourself (even if it is alphabetised).

--John Rumm 12:53, 19 May 2007 (BST)

I think the main advantage to splitting up the glossary is that it would be easier to maintain. ATM it's a PITA:

  1. waiting for the page to download
  2. scrolling through to see if there's an entry for the term you're interested in
  3. waiting for the edit page to download
  4. scrolling through the edit page and making your changes
  5. waiting for the preview page to download
  6. scrolling through to see how your edit looks
  7. ... etc ...

The download times probably aren't such a problem if you've a decent connection rather than NTL^H^H^HVirgin :-(

The problem with splitting by subject is what to do with terms which have meanings for different subjects e.g. a meter can be gas, water, electrical etc. One could have a separate generic glossary for such terms but that seems inelegant and you'd probably have people adding terms which they think only have meaning in one category to that category's glossary when there's already an entry in the generic glossary. Alternatively you have an entry in each relevant glossary and rely on the Search function to show them all if someone doesn't know what the term means at all: OTOH if they know it's, say, an electrical term then they can go straight to the electrical glossary.

From the POV of maintenance I think not only does having smaller glossaries make it easier, but also people who have expertise in a particular field can concentrate better on that glossary when all terms are in their domain of competence, rather than being interspersed with lots of stuff they know nothing about.

--John Stumbles 15:19, 19 May 2007 (BST)


I dont see any problems with >32k of text, it dls on NTHell dialup without issue.

But surely the solution is as suggested, ie if you want some subject glossaries, great, go ahead and start them, write them. Also leave the universal glossary for those of us that want to use that.

I've visited glossary sites at times, and theyre usually split into multiple pages, which totally ruins their usability IME. If I'm reading about a subject with terms I dont know, I need to be able to just search-find each term on the glossary page, there isnt a cats chance that I'm going to want to waste time running back and forth between numerous pages trying to find each word. Its a crazy way to have a glossary.

Subject glossaries have their uses in that they are small enough to be readable, either in whole or part, and are a quick way to build up subject knowledge.

With subject glossaries, I dont see any problem with for example the word 'meter' being included in all of electricity, gas & woodwork glossaries. (overlooking sp for sake of example)

I'm all for you creating the pages you want, and keeping what we have now, in true wiki spirit. NT 15:52, 19 May 2007 (BST)

I don't think having an all-in-one glossary and subject-specific glossaries is a good idea at all. I think it will confuse readers and (potential) editors as to which is the canonical version. I think we need to agree (all 3 of us!) on which way to go and stick to it. Since you've done most of the work NT I've left it the way you've gone with it, apart from making suggestions. However since John Rumm suggested the subject-specific split I've weighed in with my €0.02'orth. However I think consistency and consensus are paramount here. --John Stumbles 17:45, 19 May 2007 (BST)


I guess we disagree then. I cant imagine how titles like 'Glossary of Woodwork' and 'Glossary of DIY terms' would be confusing.

As for canonical, wikis are never the last word, always contain errors, and one of the points about them is that more than one view can coexist - and inevitably will in practice - within a wiki. As is already the case in fact. I think youre being optimistic if you expect consistency and concensus on wikis.

Go for it, write your glossary(s), but please let the articles people have worked on and are continuing to work on stay.

Practically I dont think it would be at all a good thing to ban someone from starting another glossary article, and I'm wondering if the policy you suggest would head directly in that direction.

We already have a somewhat similar case further down the line, with 2 different articles covering the same thing, 'Cables' and 'cables for domestic...' and if moderators start to delete other peoples articles - assuming the info to be valid - and clearly a lot of work has gone into them - then we wont do the wiki any favours.

If I write an all in one glossary, I wouldnt consider saying you cant write subject glossaries, and I think the sensible principle behind that works both ways round. NT 22:33, 19 May 2007 (BST)

DHW

"DHW" is used in the name of a Wiki page; "DHW" should appear in the Glossary, and be explicitly explained in the article. I'll not edit it, since I'm only guessing that its intended use in the Wiki is "Domestic Hot Water". John Stockton (talk) 20:58, 10 January 2017 (UTC)

fair point. Added DHW. --John Rumm (talk) 10:02, 11 January 2017 (UTC)