Wikipedia:Categories for deletion/Log/2005 September 1#Category:Scandium compounds

= September 1 =

==[[:Category:Gold Rush]]==

==[[:Category:Directors of Los Alamos National Laboratory]]==

==[[:Category:Greek demons]]==

==[[:Category:Scandium compounds]]==

==Subnational Entites==

==[[Mladen Savovich]]==

==[[:Category:Shopping in Hawaii]]==

==[[:Category:Shark taxonomy]]==

==[[:Category:Small business]]==

==[[:Category:Wikipedians in Chechnya]]==

==[[:Category:Mountains by Elevation (km)]] and its subcategories==

===Enhancement table example and toolbar===

Here is an example of a generated table. it can be generated at the [http://planetarynames.wr.usgs.gov/jsp/FeatureTypesData2.jsp?systemID=5&bodyID=7&typeID=27&system=Jupiter&body=Io&type=Mons,%20montes&sort=AName&show=All USGS] web site, the mountains are sorted by Latitude. Heights are currently unavailable.

border="1" style="border-collapse: collapse;"

!bgcolor=#cccccc| Name↑↓

!bgcolor=#cccccc| LAT↑↓

!bgcolor=#cccccc| LONG↑↓

!bgcolor=#cccccc| DIAM↑↓

!bgcolor=#cccccc| ET↑↓

!bgcolor=#cccccc| AD↑↓

!bgcolor=#cccccc| Origin↑↓

Nile Montes

| 52.0

| 253.0

| 450.0

| Greek

| 1997

| Where Zeus restored Io to her human form.

Zal Montes

| 37.5

| 76.3

| 422.0

| Iran

| 2000

| Iranian sun god.

Euxine Mons

| 27.0

| 126.0

| 200.0

| Greek

| 1997

| Io passed by here in her wanderings.

Skythia Mons

| 26.0

| 98.0

| 200.0

| Greek

| 1997

| Io passed by here in her wanderings.

Mongibello Mons

| 22.3

| 66.6

| 180.0

| Italy

| 2000

| Name for Mt. Etna, site of Vulcan's forge in Dante's "The Inferno." Thunderbolts from here killed Capaneus, the great blasphemer.

Gish Bar Mons

| 18.5

| 87.0

| 87.8

| Babylon

| 0

| Babylonian sun god.

etc ...

|

|

|

|

|

|

Note that the table heading becomes a tool bar that can be clicked on to sort the table anyway the end-user prefers.

border="1" style="border-collapse: collapse;"

!bgcolor=#cccccc| Name↑↓

!bgcolor=#cccccc| LAT↑↓

!bgcolor=#cccccc| LONG↑↓

!bgcolor=#cccccc| DIAM↑↓

!bgcolor=#cccccc| ET↑↓

!bgcolor=#cccccc| AD↑↓

!bgcolor=#cccccc| Origin↑↓

  • In the absence of the USGS table heading toolbar↑↓, the sorting the Mountain Elevations using an elevation index on the category is a useful tool.
  • Indexing by that immediately updates a mountain height category when the mountain article is created with an appropriate infobox.
  • Each mountain in a manually created list has its own double entry error problem, but however lists have their own benefits, eg the editor can elect to manually add as many columns/feilds as desired.

In the absence of sorted heights lists for almost all countries, or even globally for the top 100 mountains, AND for lists that are evolving, I recommend we keep the current height sorted categorys.

¢ NevilleDNZ 16:35, 4 September 2005 (UTC) ¢

:I agree that this features are quite rewarding, but having categories as properties is a clear abuse of the technology. Though I am not in favor to delete these right away, however they should be replaced by something more flexible and much more powerful. In the mid term ugly categories that are abused to sort a list definitely should go away, therefore I suggest to channel the efforts for the [http://bugzilla.wikipedia.org/show_bug.cgi?id=1911|next technological step]. --BoP 20:39:55, 2005-09-04 (UTC)

These technical changes sound like a good thing, but until they appear, we have to use what we've got. A list is one possibility, but a bad one. Every time someone makes a new hill article, they have to remember to add it to the list as well (perhaps several lists, sorted by different fields: geography, elevation, geology, and so on). That is much more work than having templates include categories that achieve the same end. Certainly it's a work-around that the developers hadn't intended, but that doesn't make it "abuse", but rather ingenious. Until there's a better solution, leave this category here. We gain nothing by deleting it. --Stemonitis 07:55, 5 September 2005 (UTC)

: Well, I understand the intentions and the need, however let's state that it is a workaround and an improper use of a category. Ther obviously is a lack of possibilities in tables and categories. And I do not like the idea of tables that are hand drawn and make up more then half the code of a page. It just makes the whole thing extremely unreadable and generates problems as you have pointed out. I am not in favor to delete it, I would rather like to see a substitute in the mid term and would keep it until a better replacement is found! --BoP 07:27:27, 2005-09-07 (UTC)

  • Hear hear. --Mark J 18:11, 6 September 2005 (UTC)

===Post(?) vote close / pre vote count discussion===

Image:Hollerith_card.jpg in manually tabulating and manually sorting data that was already [http://en.wikipedia.org/w/index.php?title=User_talk%3AGrutness&diff=22394447&oldid=22393566 wikified], I award you this Hollerith punch card - ¢ NevilleDNZ 03:56, 7 September 2005 (UTC) ¢ ]]Image:Wheel Iran.jpg in creating a system already handled more effectively in other, simpler ways, I award you the Reinvention of the wheel award - Grutness...wha?]]

  • Is it over yet?: In honor of this occasion I have created a new award. To be honest now I feel a bit guilty unilaterly awarding this to 2 deserving recipients. But, then again... what the hell. ¢ NevilleDNZ 03:56, 7 September 2005 (UTC) ¢

Please, don't feel disobliged, if you feel that this award is appropriate and deserved then you can put this on your user page.

I was posthumosly awarded the Reinvention of the wheel award.

¢ NevilleDNZ 03:56, 7 September 2005 (UTC) ¢

: This is quite some fun to read, especially since this page was lacking images until now! P-) - but it might be the right time to sort yourself into "Category:Comedians" if you do not want to end in "Category:War" ... or to calm down. This dispute will not be resolved this way. - Still wondering if there might be a solution that suits both of you --BoP 07:27:27, 2005-09-07 (UTC)

  • I'm not changing my original vote, but if some are hard pressed to use categories, I would much rather prefer seeing :Category:7000 metre peaks, :Category:6000 metre peaks, etc. than one massive category which will eventually become unwieldy and somewhat useless IMHO. Of course though, this will probably lead to :Category:27,000 foot peaks, :Category:26,000 foot peaks, etc. Even if the current category survives, it still needs to be renamed due to capitalization at least. Besides, I find the current wording very awkward. I really cannot stand the "km" notation at all. There are currently over 700 pages on mountains/peaks already with thousands more to go. Do you really want a single category containing thousands of articles? RedWolf 02:56, September 8, 2005 (UTC)

:I think the vote has closed, so this discussion is somewhat academic, but for what it is worth...

:*I am prepared to scale/weight my keep vote based on how many actual hill/mountain pages I have contributed (rather then just categorised). In other words make mine a null vote. After all you are the guys who did all the hard work. I am still coming to terms with a wiki admin calling the idea a [http://en.wikipedia.org/w/index.php?title=User_talk%3AGrutness&diff=22394447&oldid=22393566 pig's ear].

:*But on the technical topic of 700 mountains in one category, that make 75 mountains to a page, about 10-15 page, this sounds feasible. However unfortunately the highest would appear on the last page... It is questionable if this is desirable. (BTW: Using existing wiki technology a 6100+|6200+|6300+|6400+|6500+|6600+|6700+|6800+|6900+ tool bar can be crafted for the top of the actual category and this tool bar would help vastly!)

:*Breaking these into country categories can be automated via the template, even adding the full/prefered country name. (And so the "inconsistency between nouns and adjectives" problem could be fixed here also by inserting standard nouns and/or adjectives from a lookup template)

:*I see (km) is unnatural for mountain height, this (km) can be dropped from the cat name, just as was done with the original :Cat: British Hills by Height (1000 ft) now it was called just :Category: British Hills by Height.

:*The capitalisation of "Elevation" to "elevation" wont receive any objections from my null vote, I see this is the norm elsewhere.

:*wrt to your idea of :Category:7000 metre peaks, :Category:6000 metre peaks etc. I see that some templates do actually employ a trick where they split the century from the year. In the case of elevation of the highest 1000 mountains globally you could have a custom infobox which these mountains use. eg {{infobox_mnts_6000m+ |elevation_m=6123 |elevation_6000m+=123 |region=NP}}. This could easily be used to autogenerate the sorted category you want. But the page would need to be named something like Category:6000 metre peaks, and the index on the category page would still be only one digit, 0,1,2,3,4,5,6,7,8,9 being hundreds of meters above the 6000m mark. (I am suspecting that there are a lot (100s) of "uncharted" 6000m peaks in Asia yet to be marked on a map.)

:BTW: I was impressed with 27,000m Olympus Mons on Mars. It has virtually (almost) no atmosphere at the top. If at the end of this we must use lists, I will manually create a manual list of the 10 highest known mountains and manually include both Everest and Olympus Mons and some other vital stats (manually), hopefully this list wont grow so fast :-).

:The whole infobox/category/sort strategy would be based on having a few standard info boxes, when contributors can add basic raw data. All the associated sorted categorys would happen automatically, (except for off scale exceptions, such as mountains on mars etc)

:Cheers - ¢ NevilleDNZ 08:19, 8 September 2005 (UTC) ¢ (ps. it is very hard to brain storm new ideas when the CfD gun is being held to your head :-( )

Given that I am going to have the entire book thrown at me anyhow, here is another workaround for sorting height higher then 10,000ft, (or 1,000m in Britian). The issue is the first character is the only one listed in the sorted index,... so

⒑ for 1000+ m,

⒒ for 1100+ m,

⒓ for 1200+ m,

⒔ for 1300+ m,

⒕ for 1400+ m,

⒖ for 1500+ m,

⒗ for 1600+ m,

⒘ for 1700+ m,

⒙ for 1800+ m,

⒚ for 1900+ m,

⒛ for 2000+ m

These will sort perfectly, and the index will only ever show the first character. (Which happens to be 2 digits that we need). Ironically some cultures actually have a special word for these numbers. eg Ethopian. But I think using Ethopian script would be a tad confusing, even though their numbers do sort perfectly well.

This is more effective then using a ">" for heights that go off scale.

¢ NevilleDNZ 14:02, 8 September 2005 (UTC) ¢

:The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the category's talk page (if any). No further edits should be made to this page.

==[[:Category:Wikipedian perl programmers]]==

==[[:category:Reservoirs in the UK]]==

==[[:Category:Fictional Celts]]==

==[[:Category:Ashkenazi Jews]]==