Jump to content

Wikipedia talk:WikiProject Stub sorting/Archive 11

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 5Archive 9Archive 10Archive 11Archive 12Archive 13Archive 15

Deprecation of {{Vocab-stub}}?

Hi all - I've just been in discussion with User:Uncle G about {{vocab-stub}}, which has apparently been deprecated because it is redundant to {{Move to Wiktionary}}. This came as a surprise to me for several reasons: (1) I don't recall this deprecation ever having been discussed here - as far as I was concerned it was still in regular use; (2) stub types are rarely deprecated - they are usually either in use or deleted through SFD; (3) the primary purpose of that stub type isn't to mark things for moving to wiktionary - it is to mark articles on vocabulary and usage which qualifty for wikipedia articles in their own right, as explained in the note at WP:STUB#Basic information. When was this deprecation decided, and why? Grutness...wha? 22:51, 5 May 2007 (UTC)

Hmm, yeah I can't see why that would be deprecated. The "move to Wiktionary" people sometimes go too far in my experience. — SMcCandlish [talk] [cont] ‹(-¿-)› 23:03, 5 May 2007 (UTC)
This probably stems from irritation at it sometimes being used as something of a "misc-stub". The note seems on the one hand worded rather too strongly worded, and on the other, pretty pointless: as it's noincluded, no-one'll notice it unless they're looking at the tenplate page itself. I'd rather see something on the category page (as usual), worded in less hyperbolic, clearer and more explicit terms. Alai 01:10, 6 May 2007 (UTC)
Note removed. Note on project page removed in a sec. Rich Farmbrough, 08:09 28 September 2007 (GMT).
Among certain other changes, I can't help but noting. Anyhoo, that seemed to last all of 20 minutes before being "re-deprecated". Some actual consensus on what the status of this would be handy, though. Alai 10:21, 28 September 2007 (UTC)
Items like Keywords: A Vocabulary of Culture and Society and pretentious language are not really candidates for transwiki. Rich Farmbrough, 11:56 28 September 2007 (GMT).
I agree, I think we have a confusion of purposes here, perhaps understandable in the light of the "dumping ground" phenomenom, but that's to be avoided if at all possible. We now seem to additionally have the issue of whether the template should populate the (non-stub, obviously) category. Category:Copy to Wiktionary (otherwise populated by its namespace-doppelganger {{copy to Wiktionary}}). This seems to be tied into previous categorisation of the Category:Vocabulary and usage stubs, which was via the self-same template (subsequently substed and decatted). Alai 16:42, 28 September 2007 (UTC)
It seems inappropriate. Make a mountain out of a molehill, for example, has a wikt entry in it, which may of course also refer back to WP. Rich Farmbrough, 09:13 29 September 2007 (GMT).
Indeed, I can think of several reasons why that particular proverb would refer back to Wikipedia. :) Alai 16:01, 29 September 2007 (UTC)

Double spacing

Please stop the double spacing between the text and the stub template. It is against MOS and it is NOT necessary. The stub templates are clear enough breaks from the articles. There is already enough space between the text of the article and the stub template.199.126.28.20 05:46, 22 June 2007 (UTC)

My own personal experience - and that of those I've asked - is that the single empty line makes the code a lot easier to read, and it makes stub sorting easier by reducing copy-paste accidents that are more prone to happen if you have both categories, stub template(s) and interwiki links following each other without any breaks at all. Valentinian T / C 09:25, 22 June 2007 (UTC)
No, I'm talking about two lines of space separating the preceding text and the stub template actual text, not the wikitext.70.74.35.53 06:37, 19 September 2007 (UTC)
Which is neither a distinction, nor a difference. Alai 19:48, 19 September 2007 (UTC)
Ditto, V. And I think the double spacing is the least of WP's formatting worries. It pales in comparison to all the misspellings, bad formatting, and horrendous grammar... Her Pegship (tis herself) 22:12, 22 June 2007 (UTC)
I can't think what the MOS has to do with this: this isn't formatting of article text, this is formatting of markup code. As stub templates often look horrendous when jammed right up against the preceding text, especially if it comes right after a paragraph of text, I'd suggest just the opposite: please always use two blank lines before the first stub template. (At least until such time as the CSS coding of the tags is changed to make this unnecessary, concerning which there was a flurry of discussion some time ago, but so far as I know, no action.) Alai 18:38, 1 July 2007 (UTC)
Indeed, the Manual of Style is neither relvant here nor does it address what 199.126.28.20 seems to think it does. In response to Valentinian, I find it hard to credit that anyone would genuinely feel that "Blah blah blah<return>{{stub-here}}" is somehow "easier to read", much less "much easier to read", than "Blah blah blah<return><return>{{stub-here}}", whether we are talking about the rendered view or the code view. I've heard of dyslexia, but not disblanklinea. — SMcCandlish [talk] [cont] ‹(-¿-)› 22:29, 19 September 2007 (UTC)
But we want consistency. If double spacing is not allowed anywhere, why do stub template formatting have an exception?70.74.35.53 02:00, 22 September 2007 (UTC)
So far as know, there's no such general "rule". Going from "not a good idea between paragraphs" to "mustn't be allowed anywhere" would be a case of false generalisation. Alai 02:14, 22 September 2007 (UTC)
I don't believe he said that. Alai 23:54, 19 September 2007 (UTC)
Right. For one thing, double spacing is generally avoided, as a guideline, which is not an official policy, and secondly virtual all rules of any kind in most contexts have exceptions, and in Wikipedia I would have to say that working around display problems so that pages look presentable would have to be one of them. :-) — SMcCandlish [talk] [cont] ‹(-¿-)› 02:09, 22 September 2007 (UTC)
The anon later commented on my talk page that he was referring to double spacing occurring between "the preceding text and the stub template actual text, not the wikitext." Valentinian T / C 05:38, 22 September 2007 (UTC)
In that case, I have no idea what the point is. Is there some offending example to look at? How would this even happen other than by a stray <br /> inside the stub template's code? — SMcCandlish [talk] [cont] ‹(-¿-)› 09:13, 23 September 2007 (UTC)


TFD debate on {{Expand}}

There's a long debate on whether {{Expand}} should be deleted, over at WP:TFD. Looks like the outcome will be "no consensus", but it's clear from the comments that a lot of people aren't sure when it should be used. I've put the case that it should never be used on the same article as a stub template (as mentioned here in the past), and also commented that it might be worth - once stubsense is back running properly - trying to seek out any articles that use both it and a stub template, in order to remove one or the other from those articles. Any thoughts on that? Grutness...wha? 02:21, 17 July 2007 (UTC)

I have done that in the past, with little objection. Rich Farmbrough, 08:43 27 September 2007 (GMT).

Actors-repertory theater companies-stubs?

Resolved
 – Wrong venue.

This is to propose the idea of stubs that deal with repertory theater companies and the actors affiliated therewith. It would be filed under Entertainment, Theater/Stage, Film, and Television, and would include lists of member actors of the repertory theater companies.

Parker Gabriel 21:36, 5 August 2007 (UTC)

This is not the proposals area; try WP:WSS/P. — SMcCandlish [talk] [cont] ‹(-¿-)› 23:03, 5 August 2007 (UTC)

UN geoscheme

In a number of cases, we do some "lumping" of countries in a way that often doesn't correspond to the structure of the permcats, due to size considerations. This is fine, but what could do with further examination is on what basis we define these "lumpings". In particular, we oculd do with a bit of 'democratic centralism' about whether we're using the UN geoscheme or not. (Or what point in between using and not-using.) Alai 18:08, 11 August 2007 (UTC)

Agree with the idea of implementing the UN geoscheme. Now that we've created geo- templates for most of the African nations and politician- templates for all of them, making the transition should be relatively simple. But it might be an idea to jot down a list of which country goes where in order to avoid inconsistencies, e.g. relating to Africa's minor island nations. Valentinian T / C 21:08, 11 August 2007 (UTC)
Sounds like a good idea to me, too, as long as we're consisten. FWIW, as far as the geo-stubs are concerned, I've been slowly making upmerged geo-stub templates for most countries - the only ones without them now either have naming or politics-related problems associated with them. In the case of Africa, everywhere has a geo-stub template except for Mayotte and Western Sahara (political concerns) and the British Indian Ocean Territory (naming problems). In any case, as I've suggested elsewhere (Wtalk:WSS/P), the usfulness of having five separate subcontinental categories for Africa's geo-stubs is becoming less and less all the time, and ditching them might yet be a reasonable option. Grutness...wha? 23:39, 11 August 2007 (UTC)
What tends to happen, though, is it just gets pushed down a level (or thereabouts), and we end up with similar issues with the Southern African politicians, Eastern European buildings and structures, or Latin America and the Caribbean schools (say). But if the "old" subcontinental categories are on the way out, much the better the time to implement new such on a more consistent basis. Alai 01:17, 12 August 2007 (UTC)
Good point, but see also my comment about potential problems at the SFD for Category:Central Asia geography stubs. Grutness...wha? 01:59, 12 August 2007 (UTC)
To generalise from the particular: the geoscheme in every case uses integral countries. (Unlike, say, using continents...) Alai 03:29, 12 August 2007 (UTC)
Btw, I generally don't think it will make sense to subdivide Europe into smaller segments (N, W, E, and S). On the other hand, Africa will remain a headache if we don't chop it down somehow, given the number of countries. I have the politicians in mind here. Africa was a major headache, and Asia will remain a bother, given that we still lack a lot of templates here, and due to the death of StubSense. Btw, it looks like StubSense's death is related to something relating to Interiot's counters. One of the two errors is due to a temporary fix in the code. [1] Valentinian T / C 06:46, 12 August 2007 (UTC)
I agree it'll be required less often, if at all, for Europe. I'm not necessarily saying we should be making any more of these than we are at present, just that when we do, we should follow the UN geoscheme (in cases where there's no suitable permcat parent). Alai 02:26, 13 August 2007 (UTC)
Agree completely. Valentinian T / C 09:26, 13 August 2007 (UTC)

Assessment bot

A bot request was posted at Wikipedia:Bot requests/Archive 51#Assessment bot which could be a great help to stub sorting. Give it a gander. ~ JohnnyMrNinja 05:29, 12 August 2007 (UTC)

JMN has also filed a request for a "stub sorting bot", which goes a bit further than the initial request. Should probably have some wider WPSS input on that. Alai 13:25, 17 August 2007 (UTC)

Upmerged templates for Asian politicans?

Some time ago, Thomas Macmillan sorted the entire material relating to African politicians by country, creating templates for next to all of these countries (if I remember correctly, Western Sahara is missing due to its status as a disputed territory and so are a few minor French islands near Africa). South and Central America are almost done as well, and I'm thinking about creating upmerged <country>-politician-stub templates for the Asian nations. Trouble is that I haven't done a proper count of this material for quite a while. Should I do a count for each of them and list them all on WP:WSS/P or is this too bureaucratic? My guess would be that {{Palestine-politician-stub}} would be only template that might cause problems, but on the other hand, we already have both {{Palestine-stub}} and {{Palestine-bio-stub}}, so I don't think we'll see any real problems here. Thoughts? Valentinian T / C 21:43, 13 August 2007 (UTC)

On second thought, moving this post to WP:WSS/P . Valentinian T / C 09:37, 14 August 2007 (UTC)

Speedy delete for a duplicate stub type

I have proposed a speedy delete criteria for a duplicate stub type. This will make things much easier for Grutness. ~ JohnnyMrNinja 06:34, 14 August 2007 (UTC)

Sortkeys for stub categories

As you can see on Category:Southern United States road stubs, the five subcategories use two different sortkey methods, when both should be using the same format. Which one, if any, is considered "canon", if you will, for WSS? --TMF Let's Go Mets - Stats 06:23, 19 August 2007 (UTC)

I don't know if we have an actual canon as such. I think "...stubs|*United States" was the original format, but most of the recent material omits the star (= "...stubs| United States" ). I think the latter format is the one mostly used on the generic categories, and I personally use the format without the star. Valentinian T / C 15:25, 19 August 2007 (UTC)
We don't have an established practice, for no better reason than we've failed to establish a practice. Either is OK, and certainly preferable to no "top-sorting" (or the rather bizarre "bottom-sorting" with \mu which I've seen on occasion, which seems to be just entirely confused). Obviously, it should be consistent within a given supercat. I'd vote for "*" across the board, on the basis that " " is typically reserved for the "main article" of a category, and is (I think) slightly less likely to be removed by some random editor who doesn't get what it's there for. But I'd be content with either, if it gets us towards a bit of democratic centralism (comrade stub-sorters). Alai 16:13, 19 August 2007 (UTC)
{{Stub Category}} uses µ, which I think is ridiculous, because you won't see the subcat till the last page. Also, * adds a separation that is not explained (and looks slightly odd). I personally feel that all subcats (not just stubs) should be given " " qualifiers so that they all show up on the first page of the category without separators. ~ JohnnyMrNinja 16:32, 19 August 2007 (UTC)
Yes, but the sorting of stub cats within permcats we're at least consistent about, whatever the merits of it as a strategy. If all subcats were top-sorted, I'd have no objections to making the stub cat the last of those (say with "*µ", " µ", or some such) but generally, they're not, and people would probably object if the stub cat "jumped the queue" ahead of all the other subcats. Top-sorting subcats in general would need to be discussed elsewhere. Using "*" doesn't add a separation, an inconsistency between "*" and " " introduces that. (I'd imagine more use "*", but I might be wrong and/or biased.) Some times that's desirable, though (say with a stub type that's split both by nationality and by occupation/genre/other). Often, it's just people rowing in opposite directions. Alai 18:20, 19 August 2007 (UTC)

Two types of stubs

Something was brought up at bot requests... There are currently two types of stub on Wikipedia, assessment-stubs and template-stubs. This is an odd double standard. I would think that either both should mean the same thing or there should be two different terms used. I have brought it up at the village pump, so please add any thoughts there. ~ JohnnyMrNinja 17:13, 19 August 2007 (UTC)

We've been arguing that here for ages. Having the assessmen-style templates called "Stub-Class" was a silly mistake from the beginning, since the stub system had already been in place for a considerable time. That's the reason why there's often a lot of confusion regarding what stub templates are among Wikiprojects. Grutness...wha? 00:18, 20 August 2007 (UTC)

Need a laugh?

Anybody in need of a laugh? Try checking out the topic of this deletion nom. Valentinian T / C 23:55, 28 August 2007 (UTC)

Expand and Sectstub templates

Hi all - there's rumblings over at Template talk:Expand about changes to {{Expand}}, {{Expand-section}} and {{Sectstub}} which may be worth commenting on by stub-sorteing regulars... Grutness...wha? 00:36, 29 August 2007 (UTC)

book-arts-stub

I proposed a stub July 17th (book-arts-stub) and I can't seem to find what happened to it. The link in my "contributions" page takes me to the July stub proposals [2], which have been archived. When I click that link[3] and search for book-arts I find nothing. I've also googled for it using site:en.wikipedia.org and didn't find anything. Where should I go to find out what happened with the proposal? You can reply here, I have this page Watched. Thanks! --Bookgrrl holler/lookee here 15:38, 1 September 2007 (UTC)

Looks like it was lost in the process of page archival. The concluded discussion was in this revision (it was closed as "create upmerge template"). Alai 18:11, 1 September 2007 (UTC)

Maribyrnong River /Victoria / Australia.

Hi there! I have noticed the Maribyrnong River on "Wikipedia" and I am very happy to have my local River included. However I can not find any entry's regarding "Canoeing/ Kayaking" on this River nor "Rowing" activeties. Thera are two Canoe Clubs and Rowing Clubs situatet on our River! Fred Jordan ( life member ) "Essendon Canoe Club est. 1925". <canoefrd@operamail.com.au> —Preceding unsigned comment added by 59.101.175.201 (talk) 01:02, 6 September 2007 (UTC)

Not sure why you posted this here, since it's not in any way connected to the stub-sorting wikiProject, but... if you have information on that article, fix it. Just click on the edit link at the top of the page and edit the article. Grutness...wha? 06:40, 6 September 2007 (UTC)

Full list of "nation-x-stub" names

Hi all - there is now a full list of nation-level (and nation-like, non-ontiguous or autonomous region-level) geo-stubs listed at User:Grutness/Geo-stub list. All of them are regular names, after NG fashion, at least, and there are now only a small handful of (mainly uninhabited) regions without such templates - all of which are currently awaiting naming suggestions on the proposals page (int, hint). Given that the geo-stubs are AFAIK the only near-complete by nation (and etc.) split of templates, these can perhaps be used as guides to the naming of similar splits for -bio- -politician- -hist- etc stubs. Grutness...wha? 00:07, 13 September 2007 (UTC)

Category:Sportspeople stubs

I recently added the missing "top-level" stub templates to the text of Category:Sportspeople stubs[4]. I noticed that there are lots of second- and third-level templates missing, e.g. {{Canada-lacrosse-bio-stub}}, {{collegefootball-coach-stub}}, etc. Do you think it's worth adding all the missing second- and third-level stub templates as well? DH85868993 16:11, 18 September 2007 (UTC)

Personally, I'd add them to the subcategories - mentioning {{Canada-lacrosse-bio-stub}} in Category:Canadian sportspeople stubs and Category:Lacrosse people stubs (or whatever it's called) rather than in the top level category.But we don't have a hard and fast rule on it one way or the other. Grutness...wha? 23:40, 18 September 2007 (UTC)

A template for a stub category which is being split off

Every so often, a new sub-category is created for a stub category, and the user who creates the sub-category doesn't have time to fully recategorize the stubs. I think we should have a template to place on such categories, which should look similar to the following:

Stub-sorting Wikiproject

This category is in the process of being split.
If you find any stub which seems to belong to Category:newtype stubs, please recategorize them.

What do you think about this? Od Mishehu 10:22, 19 September 2007 (UTC)

Sounds good to me. Grutness...wha? 23:41, 19 September 2007 (UTC)
That seems sensible, and indeed would correspond to one of the sections of the "to do" list. I wouldn't use that appearance, though, as it's too similar to {{WPSS-cat}}, and also bear in mind that very often multiple subcats are created at once, and such cases tend to be the ones where re-sorting is most strongly indicated, so the parameter should probably be free text to allow for a description of this, or a parameter list, or something along those lines. Alai 02:27, 20 September 2007 (UTC)
As to the look, I note that the various deletion templates recently got a new look, and it's possible the merge and split ones did as well. Something along the lines of the "split into two articles" template (whatever it's called) may be a reasonable look. Would it also be worthwhile adding a link to the WSS to do list, or is that too "self-referential"? Grutness...wha? 07:27, 20 September 2007 (UTC)
Stub categories are already self-refs, so I wouldn't see that as being a concern. — SMcCandlish [talk] [cont] ‹(-¿-)› 09:11, 23 September 2007 (UTC)
What I might be inclined to do is to have that template feed into a meta-category (or is that a meta-meta-category by this point?) of Category:Stub categories to be split, in a similar way as do {{popstub}} and {{verylargestub}}, and put the to-do link on that category page. But that's just a nicety. Alai 15:48, 23 September 2007 (UTC)
Sounds eminently reasonable. — SMcCandlish [talk] [cont] ‹(-¿-)› 16:22, 23 September 2007 (UTC)

Proposal

I just made a proposal concerning this project at the village pump. Go there and discuss it, if possible. --CrazyLegsKC 05:26, 21 September 2007 (UTC)

Misnamed? stub categories

I noticed that there are some categories misnamed. Instead of Category:Figure skating biography stubs, and Category:Speed skating biography stubs, the names are Category:Figure skater stubs and Category:Speed skater stubs. Should these be changed (and if so, how?) Also, the figure skating cat has a few subcats which are similarly misnamed. Neier 13:18, 21 September 2007 (UTC)

They probably should - categories like that are usually deliberately named so that they can include coaches and the like. The way to do it is to tag them with {{sfr-c}} and list them at Wikipedia:Stub types for deletion for discussion on the names. Grutness...wha? 23:20, 22 September 2007 (UTC)

Stub template photo

There's an illustration used in a stub template that's I like to suggest a change to. What do I do? Thank you. --24.211.242.80 00:17, 23 September 2007 (UTC)

Stub template standardisation

<pokes head above parapet> Over the years I have thought about the problems of stub templates, and have visited these pages from time to time, and while the stub sorting project is making great progress and is very sophisticated there are recurring problems with the templates themselves. So I created a template Template:Asbox - which deals with some of these problems, and allows for solutions to be developed for some others. Have a look.

Rich Farmbrough, 09:33 27 September 2007 (GMT).

(don't ask me how many of those I've converted by hand...), but on casual inspection OK otherwise. But what are these mysteriously-alluded-to problems this is intended to fix? Personally I generally settle for anything that doesn't screw up page layout, is reasonably brief, has a 40x30 or less icon, is free from meta-spam, and doesn't screw around with noinclude/includeonly more than my own personal indulgence of top-sorting the template, and "code" it by starting off some some obviously-related tag, fixing any of said issues with it, and basing the new one on that. But if I were so well-organised as to actually use {{metastub}}, like I'm currently supposed to, what would this do "better"? Alai 16:33, 27 September 2007 (UTC)

Basically it is designed to be easy to retrofit to existing stub templates. Given this (which I have tested) it will allow the following - and I am tentative about this because I don't want to open a zillion old arguments right now about which/whether these are good ideas -
  1. Topsort all templates - allow keys to be given within the topsort.
  2. Support multiple (currently 2) categories.
  3. Remove the oft heard wail "that's a good idea, but do you have any idea how many templates we'd need to change?"
  4. Allows stub templates to support a common simple sort order syntax (default parameter 1).
  5. Making stub templates line up with each other within variation imposed by the icon (if any).
  6. Putting all templates in a category of stub templates if required.
  7. Allowing simple tests to identify/overrule image size.
  8. Making future changes simpler, because they can be done to {{tl:Asbox}} or because the majority of stub templates will be well formed.

Erm... that's all for now. Rich Farmbrough, 18:08 27 September 2007 (GMT).

If Alai fixes the overlinking..
9. does away with overlinking.
Rich Farmbrough, 18:09 27 September 2007 (GMT).

Oh, you're proposing this as a transcludable meta-template, rather than as a substitutable one? Egads. Well firstly, there's the oft-heard "do you have any idea how many templates we'd need to change?" to implement that in the first place (I'm not sure that wail is actually oft-heard otherwise, at least not about anything there's actual general agreement that it really is a good idea), but of more concern to me would be the 'single point of failure' issues with that, and the consequent performance issues that, however obvious, it's apparently developer-mandated that we STFU about. That's been suggested before, and I remain very dubious about the idea (though given the already massive shenanigans in the template space, maybe that ship has largely sailed). That aside, sort order parameterisation (of the stub article) I've always been opposed to as largely-wasted effort (stub types are supposed to more of a set for editors, not a list for readers), and given DEFAULTSORT, seems highly unnecessary these days. And besides, they confuse my bot when it comes time to re-sort them. :) The category of stub templates in my estimation isn't required: a set of such were deleted a while back, revisited somewhat later, and again left non-existant. But those quibbles aside, I do very much agree with the general aim of standardisation (I hate to think how many I must have edited in that cause by now, and probably far from entirely consistently at that), so I'll try not to be too dogmatic about the means. Alai 18:55, 27 September 2007 (UTC)

Thanks for the comments, the documentation shows that I share your opinion on sort order being almost never necessary these days. Still it's cheap, as are the other benefits once it's in place. Rich Farmbrough, 20:07 27 September 2007 (GMT).
My opinion would be more on the lines that it's almost never of any conceivable application, and is most certainly never necessary, for the reasons stated. I also disagree that it's "cheap": it's yet more code clutter in the meta-template (which admittedly should be triply-fully-protected, and anyone spuriously editing it would be given electroshock therapy for putting a million articles on the job queue), and what's much worse it's an amount of code-complication in articles, for something that should be, can easily be, and by large has been, very, very simple. It would make sense to have it everywhere if you have it anywhere, as opposed to having in a minority and creating confused expections (and confused stub-sorters), but "nowhere" seems highly preferable to me. I'm not clear what you mean about the other benefits being "cheap"; they largely rely on editing the template, which is rather the main cost... Alai 22:22, 27 September 2007 (UTC)
It's already in there, some stub templates previously supported it. Yes, the cost of editing the template will eventually be larger, but at the moment it's similar to something like {{unreferenced}} or indeed {{tl}}. Rich Farmbrough, 11:50 28 September 2007 (GMT).

You will not believe me, but I was about to do the same. Good for me I went to look at this page first. I support the standartization and ready to join the effort in conversion, if one cannot do it by 'bot. Just drop me a note. At the same time I agree that a parameterized hypertemplate is kinda overkill here. I was thinking abut a single-param template for the text only. The rest of format is plain old cut'n'paste. Or am I missing some benefits of hypertemplates here? (besides the "single bottleneck" for screwing up) `'Míkka 07:21, 28 September 2007 (UTC)

Thanks for the offer - help always appreciated - it can't be fully automated. The trouble with cut and paste is that it diverges over time. Other possibilities of a common template are, for example, to put a link to WP:WSS in all the template pages (not that I'm espousing that), adding or changing CSS, reflecting style changes in WP as a whole etc. Rich Farmbrough, 11:50 28 September 2007 (GMT).
Pretty good summary, I think, especially on the latter point. The fact that this is now "pilot"-transcluded into about 45,000 stubs certainly makes me distinctly anxious about attempting to address the issues raised that having coding implications, lest I screw 45k articles up at once. Alai 10:58, 28 September 2007 (UTC)
45K items on the job queue later... Another coding niggle being, why is a conditional now being used to perform template top-sorting (or otherwise-sorting)? I've never seen anything so tortuous as that used on an actual stub template, at any rate. Alai 11:08, 28 September 2007 (UTC)
Yes, you're absolutely right. I wasn't sure to start with whether people might object, to top-sorting for particular categories or projects. I will give it a few days to see what other changes are required and remove that - sure will make things simpler. Rich Farmbrough, 11:50 28 September 2007 (GMT).
Personally I'd suggest something like <noinclude>| {{{templsort|}}}</noinclude> as being most consistent with current practice, but I'm probably massively biased, since the main practitioner of that that style is, well, me, and that's not itself precisely "per WP:STUB" (though no-one seems to have complained, and several people seem to be doing the same thing, so one could argue that guideline-lag is at work there). Well, actually, my actual bias would currently be towards "do-over from the ground up", but I should sleep on that to see to what degree that really is just correctable bias, and to what degree this is as bad an idea as it currently seems. Alai 12:07, 28 September 2007 (UTC)
One consequence of which is, for example, that due to the net combination of RF's change and dmcdevit's (repeated) change(s) to {{vocab-stub}}, the template's in no category, which it's not obvious was the intent of either editor, and seems like a Bad Thing in general. Doubtless simple enough to fix, say by giving those parameters a sensible default, but definitely getting further out into "field servicing", here. Alai 11:19, 28 September 2007 (UTC)

If anyone but Rich (if even?) and I are paying attention at this point, transclusion costs and benefits gives a reasonably "fair and balanced" take on the pros and cons of mass use of meta-templates. (I might nudge that talk page to see if anyone wants to chime in here, indeed.) BTW, if the aim of this is standardisation, why wouldn't we be standardising things like image sizes in the process? Just replacing idiosyncratic inline code with meta-templatised code with idiosyncratic parameter values seems to give all the downside, and none of the claimed upside -- or certainly much less: granted there might be some tidying of table code and the like involved, I dunno. (Though obviously personally, I think we could just do the standardisation without the meta-templatisation, and amn't at all convinced of the need to build in scope to change what the "standard" itself is.) BTW, given the, um, strongly-expressed opposition to stub template parameterisation in some quarters, I'd suggest getting rid of all remaining provision for that in the m-t (again, that's if we really must have it at all). Alai 05:15, 3 October 2007 (UTC)

  • The more I see of this template as it is being used on stub templates, the more it appears to me to be causing far more problems than it's worth - largely for the reasons Alai mentions above. As it was described to me, it does seem that it wopuld have benefits,. however, the side-effects of asbox seem to be very bad ones and pretty far-reaching. I'm also now against the whole idea of it. Grutness...wha? 00:14, 9 October 2007 (UTC)
    • If we keep the template, but subst: all the existing (and any future) transclusions (much as metastub is currently employed, but with different parameterisation), then we'd get the benefit of standardisation to the current guideline. We would of course not get "flexibility" to change that standard in the way described above, and equally, have no "single point of failure". Might be an enlightened compromise vs. hauling it off to TFD, which I must admit I've been fighting the impulse to for some time. Alai 01:32, 9 October 2007 (UTC)
  • I can't say I'm actually following this conversation, as I don't get the coding nuances. I came across {{Asbox}} while tweaking {{ya-novel-stub}} -- so now I'm confused. Do I still use the {{foo-stub}} template code? What does this all mean to the average stub drudge?? How does this change the user interface or indeed, the editor interface? help... Her Pegship (tis herself) 18:37, 11 October 2007 (UTC)
    • IMO the established practice is still that implied by WP:STUB, i.e. the {{foo-stub}} template code, in line with metastub and the majority of the existing template, Rich's rather extensive kite-flying exercise notwithstanding. I suggest if the new version makes you tense'n'nervous, or confounds what you're trying to do, change it back, but there's no global rush otherwise. The central coding issue is basically, do we on the one hand standardise by conforming to (more-or-less) the same "raw code", or do we do so so via parameters passed to a "meta-template" (that is, a template transcluded into all the others (well, several hundred of them, last time I looked, but by intent of the proposal, all)). Alai 05:23, 13 October 2007 (UTC)

What is the point of stubs and stub icons

This is just to register a debate had over at Wikipedia:Stub_types_for_deletion/Log/2007/October/1 with which others might share some sympathy. I appeared to have walked into an area of notably strong views and not as much understanding of what I was saying as I would have hoped. I was unable to find much debate in the archived talk pages to support the non-negotiable guidelines. But that's not what I want to talk about.

Most stub templates produce the sentence: "This blank-related article is a stub. You can help Wikipedia by expanding it", often including an icon, and with the word expanding linked to the edit this page button. This lead me to believe that the point of stubs was to increase the conversion rate on such articles, possibly by enticing new users into contributing there where it was almost impossible not to make an improvement. Ideally we want articles to leave the stub category, and not remain within it.

Unfortunately, no concept relating to conversion rate is listed under this project's goals. Instead, the goals appear focussed towards only making stubs technically tidy within a whole series of mandated categories. Double and triple stubbing is preferable to making parametrized stubs containing, for example, pointers to a Wikiproject where hints and encouragement can be invited from people with the expertise.

I have held people's hands while they made their first wikipedia edit, and there is often a big barrier to making that step. It is likely that the people most daunted by it could become the best editors -- if they got past it. It's easy for us to forget the barriers.

It seems to me that the more an article appears to be in someone else's territory, the less likely it will be edited by someone new. If this is true then it predicts that, since icons in stubs and multiple stubbing makes the article look more developed and official, the more you have of that the less the stub will achieve the desired result -- if the desire is to get it elevated out of the stub category, rather than just making something empty look kind of pretty. Here's a radical idea:

Consider getting rid of all stub icons.

The logic which people use on websites is unpredictable, and it can only be done experimentally, as I have found with my limited experience of tuning websites.

An experiment could be to hide the icons in half the stub templates, then come back in six months time to see whether more or fewer such articles remain in these stub categories than in the ones which do retain their attractive (and potentially discouraging) icons.

Such an experiment is unlikely to take place unless conversion rate was seen as one of the prime considerations of stub design. It would be nice if people thought it should be an important factor.

Goatchurch 20:08, 9 October 2007 (UTC)

We've considered it in the past, and actually tried working without icons on stub templates - and editors always put them back. If you hide the icons in 50% of stub templates, within a week, 80% of stub templates would have icons - in many cases ones far less approriate than those they had before. Other than protecting all stub templates, there's no way of stopping it happening, not with the limited number of stub-sorters there are, anyway.
Links to Wikiprojects within the templates have also been used in the past, but are derided by the "no self-reference" crowd, leading to edit battles between them and the individual wikiprojects concerned. edit wars in general are a bad thing - edit wars on templates are far wose, due to server cncerns. thus we use the compromise of linking to Wikiprojects in the stub categories rather than on the templates. In any case, if you are arguing that a stub template generates a feeling of one group staking a claim to an article, having a WP banner on the template would only make it far worse. By the way, as someone who has mentored new editors on and off for several years, I must say you are the only person I have ever heard suggest some form of ownership is implied. I'm not saying that perception doesn't occur, but I'm sure it is an extremely rare one - especially given the first credo of Wikipedia which is drummed into new users - anyone may edit any article. Does not the stub template say you can help by expanding the article?
As to conversion rate, yes, conversion rate is a very important thing, which is why we try to make the stub categories both precise and broad - a difficult tightrope to walk, but one that is necessary. We do what we can in that regard by keeping stub categories of a viable size so that editors are neither overwhelmed by the size of stub categories nor left picking among dozens of near-empty categories. Parameterised templates have been suggested prequently in the past, but always cause far too many problems to be effective - the size of the stubsorting wikiproject would need to be a magnitude larger at least before it can be handled from that end, and Wikipedia's servers would also have to be considerably stronger before it is worth the risk of crashing the system entirely (a real possibility given the high usage of stub templates). It also makes keeping the stub system manageable impossible without seriously prohibiting exactly what stub templates could be formed, which would require both policy changes and further limiting of editorial freedom.
In other words, while I understand your suggestions, there's nothing new in them. They've all been either tried or seriously considered in the past, and all of them have been rejected as doing more harm than good. Grutness...wha? 23:38, 9 October 2007 (UTC)
Not all stub templates have icons: if you really think this is a worthwhile exercise, feel free to reconstruct such statistics from historical data. Personally, I think your hypothesis is a considerable stretch of what's credible, and don't really think testing it in the manner you suggest is worth the significant effort (if not to say outright disruption) it would entail.
On the whole "non-negotiable guidelines" and lack of "understanding" assertions that appear to motivate this intervention: extrapolating from your contributions to that particular deletion debate, I gather that your feeling is that your goals would be best served by maximising exclusivity and project-ownership of various articles. I suspect most stub-sorters (among others) would strongly disagree. You've advanced no other argument against double-stubbing, at any rate, just an assortment of things you apparently prefer. (Recall that the removal of "location in North Yorkshire" stub tags from, well, locations in North Yorkshire, is what led to the SFD nomination in the first place, rather than just the existence of that type in question.)
If you want to start a discussion on parameterised stub types and wikiprojects links, by all means do so, but I don't think it's helpful to take sideswipes in the process of purportedly addressing some other issue. I don't think an explicit "mission statement" would be especially beneficial (and indeed, in those terms it could be seen as tantamount to credit-stealing, since it's not us, as a project, that's doing the actual expanding). To say the tagging and sorting stubs with 4000+ templates that ask explicitly for articles to be expanded, is being done in the hope that they will be expanded, would seem to come under the heading of re(*4000)-stating the obvious, and anything beyond a hope is outwith the project's scope (or subscribing to the analysis that the prevalence of stub articles is the fault of the stub-sorting project). Lastly, "de-stubbing" is itself a fairly fuzzy issue, so measuring progress strictly in those terms could itself have a somewhat distorting effect (if anyone cared enough to engage in such). Alai 23:53, 9 October 2007 (UTC)

How to write a script

From the functional spec we generate good script.

this is comes from devlopers.

writiing script is testers work for good quality script see below points

1. give brief information about the tool 2. give environment req to test 3. any kind of data testing and limited data testing to be mentioned in description. 4. any types users should be mentioned. —Preceding unsigned comment added by 193.195.187.198 (talk) 12:03, 19 October 2007 (UTC)

Colour scheme for {{WPSS-cat}}

You may have noticed that the background colour for the stub category page boilerplate has changed; apparently it's been using markup intended for talk page templates all this while. I can't say I'm much taken with the new scheme, but that might just be the imprinting of having stared at thousands of 'em over time. There's a discussion at Wikipedia:Category message boxes about some sort of standardisation, but the current level seems to be approximately 'none'. We should probably given this some thought, at any rate. Alai 17:42, 5 November 2007 (UTC)

I've restored the former colour. I personally found the old look much easier to read and the recent edit seems to have been motivated by a an editor trying to give the template two different looks depending on whether it is used on talk pages or other page types. I don't follow the logic in this modification since the template isn't intended to be used on talk pages at all. Valentinian T / C 17:49, 5 November 2007 (UTC)
And User:PEJL has already reverted it again citing that the colour is inappropriate for non-talk pages. It would be nice to see input from other editors regarding how which template they prefer, but for my sake it could be spotted green if people fancied such a look. Valentinian T / C 17:59, 5 November 2007 (UTC)
(ec) I made the original edit. The motivation was that I saw the template used on a non-talk page. I assumed the template was at least sometimes supposed to be used on talk pages, because it used talk colors, so that's why I used the conditional. If it's never to be used on talk pages it theoretically doesn't need a conditional. (It is used on quite a few talk pages, and on those pages, the talk colors blend in well with other templates.) Either way, the template shouldn't use talk colors on non-talk pages. Any other color scheme would be fine. --PEJL 18:02, 5 November 2007 (UTC)

I suggest that by way of a placeholder, by the logic of "least surprising result", we for the time being use a colour similar to the long-standing one; but not identical, and not via the "talk page coding". Let's especially try not to get into needless revert wars on templates with thousands of transclusions. Alai 18:15, 5 November 2007 (UTC)

I've not heard about a "talk colour" before, and I don't see the point in trying to impose one. In any case, the current white is simply way too anonymous. This template's purpose is to be a visible warning against the creation of odd templates and categories that will merely make our work harder, but in its current shape, this template is as visible as a hole in space. Valentinian T / C 23:18, 5 November 2007 (UTC)
See Wikipedia:Talk page templates for info on "talk colors" for templates, and Talk:Pinkerton (album) for an example of a talk page with such templates. Perhaps a style similar to {{warning}} (compared to the current style which is similar to {{notice}}) would work for you? --PEJL 23:35, 5 November 2007 (UTC)
I originally made the box that colour IIRC. At that time, the colour was used for all such templates on talk pages and non-talk pages such as categories. Hence its use/ I've no objection to a change of colour, though it should be something else that is both unobtrusive and noticeable (if that isn't an oxymoron). Perhaps apple green or something similar? Grutness...wha? 23:37, 5 November 2007 (UTC)

Might work. Here are a few experiments (warrenty or guarantee of usefulness does *not* apply) :)

Stub-sorting Wikiproject

This category is maintained by WikiProject: Stub sorting.
Please propose new stub categories here before creating fresh categories and templates.

(original look)

Stub-sorting Wikiproject

This category is maintained by WikiProject: Stub sorting.
Please propose new stub categories here before creating fresh categories and templates.

(orange)

Stub-sorting Wikiproject

This category is maintained by WikiProject Stub sorting.
Please propose new stub categories here before creating fresh categories and templates.

(pale blue)

Stub-sorting Wikiproject

This category is maintained by WikiProject Stub sorting.
Please propose new stub categories here before creating fresh categories and templates.

(silver)

Stub-sorting Wikiproject

This category is maintained by WikiProject Stub sorting.
Please propose new stub categories here before creating fresh categories and templates.

(grey)

Stub-sorting Wikiproject

This category is maintained by WikiProject Stub sorting.
Please propose new stub categories here before creating fresh categories and templates.

(shamrock green)

Stub-sorting Wikiproject

This category is maintained by WikiProject Stub sorting.
Please propose new stub categories here before creating fresh categories and templates.

(lime)

Stub-sorting Wikiproject

This category is maintained by WikiProject Stub sorting.
Please propose new stub categories here before creating fresh categories and templates.

(olive)

Stub-sorting Wikiproject

This category is maintained by WikiProject Stub sorting.
Please propose new stub categories here before creating fresh categories and templates.

(jade)

Stub-sorting Wikiproject

This category is maintained by WikiProject Stub sorting.
Please propose new stub categories here before creating fresh categories and templates.

(moss green)

Thoughts? Valentinian T / C 00:19, 6 November 2007 (UTC)

I like the silver or the moss green. I was thinking of something part-way between moss green and lime green when I mentioned apple - sort of the tones of the lime but the softness of the moss. Grutness...wha? 01:57, 6 November 2007 (UTC)

If we were working by "type", the closest I can find seems like {{consensus}}... which is the original, "talk page" colour. Oh well. I suggest an orange that's midway between that and "you have messages" orange used above, for the sake of making a minimal perturbation. If cat-page standardisation gets anywhere, after all, it may end up being changed significantly, so I'd prefer to avoid a series of rapid jumps in potentially opposite directions. Alai 02:20, 6 November 2007 (UTC)

I'm fine with both green, silver and orange. The main issue is to avoid a template that is too anonymous. Valentinian T / C 16:29, 10 November 2007 (UTC)
I'd certainly also prefer any of the above to the status quo. Alai 16:28, 14 November 2007 (UTC)
The current white colour is too anonymous. How about we try with a nice green and see what happens? Valentinian T / C 20:36, 26 November 2007 (UTC)
The moss green above, perhaps? The text isn't as obvious in the other two, and text boxes like this are usually a pastel-ish shade. Grutness...wha? 22:40, 26 November 2007 (UTC)
The moss green one was the one I had in mind. I've been bold and updated the template. It might benefit from a thin outline, though. Valentinian T / C 08:18, 27 November 2007 (UTC)

Ordering the School stubs for United States

There has been very little feed back regarding the Ordering the School stubs for United States as found on Wikipedia talk:WikiProject Stub sorting/Stub types with the discussion question asked at Wikipedia talk:WikiProject Stub sorting/Stub types#Ordering the School stubs for United States Before being bold and just doing it, I would like a bit of feed back first. Maybe I was asking in the work place, so I am added a request here as well, Thank you in advance for your consideration of this subjectDbiel (Talk) 12:19, 8 November 2007 (UTC)

I agree with the suggestion you made on WP talk:WSS/ST. Sounds sensible. BTW, not too many people probably monitor that talk page - especially since the stub type list has been split into subpages, which is probably why you didn't get many responses. I've added one of those "consider commenting here instead" banners to the top. Grutness...wha? 23:15, 8 November 2007 (UTC)

Protection warranted?

Are stub templates sufficiently high-risk to be protected/semi-protected as high-risk templates? I just reverted an anon editors devious little work on {{euro-school-stub}} that added the schools to a category German national socialist ....yadda yadda. Consider whether these templates are high risk and whether you want anons to have free rein on adding different categories to them. Carlossuarez46 05:53, 15 November 2007 (UTC)

mmm. It's never been much of a problem in the past except on some which are obvious contention-magnets (e.g., {{Palestine-stub}}), though understandably high use ones like {{stub}} are protected. I think there'd be a loud complaint if all stub types were protected (we're accused often enough of being - ironically given the current case - "stub nazis" as it is). Certainly worth watching, though... perhaps we each need to put a few more templates and categories on our watch lists... Grutness...wha? 07:44, 15 November 2007 (UTC)
I think that mass-protecting, or even mass-semi-protecting, stub templates is a bad idea. However, given the widespread use of the templates, any template which is vandalized - should be semi-protected. Od Mishehu 08:05, 15 November 2007 (UTC)
Personally, I'd be inclined to semi-protect the lot, and full-protect the ones with the highest use (and the ones with most scope for POV grief), but I think there's some truth to the "backlash" concern, so I'm inclined to be cautious about doing so without some sort of "coup excuse". Honestly, though, what new editor wants to start editing stub templates? And what's our incentive to facilitate non-new editors editing them from IP addresses?
The "high risk" aspect isn't really that bad, on a template-by-template basis: none has more than a couple of thousand transclusions, and most are in the range of a few hundred, which the WP:PERF mob would scoff at. (Mind you, they do do a lot of scoffing.) It's somewhat disheartening to find a template that's had its category removed, or made useless by a botched sort key, and then realize that it's been that way unnoticed (or at least, unfixed) for months, but I suppose that's just further evidence that sadly, the contents of many stub types are basically just left to languish en masse. Alai 17:14, 15 November 2007 (UTC)
Not trying to be overly pesky or policy-bound, I should note that many templates are transcluded into BLP's so while the various BLP patrollers look at changes to the bios, there could be all sorts of mischief added through transclusion: imagine some varmint replacing the current text at {{US-actor-stub}} or any of the hundreds of others meant to be added to bios, with something about pedophilia or drug use etc.... Newbies probably shouldn't be messing about with templates; most newbies don't even know how they work or how to mess them up. But vandals with brand new accounts can and do mess with them from time to time. It's just a matter of when we find the problem and fix it. The euro-schools took 30 hours, some more used one probably shorter, but not necessarily. Carlossuarez46 19:26, 15 November 2007 (UTC)
It's a valid point. I must admit that's more obviously malicious than most template-tampering that I've seen, which tends to be either out and out newbie cluelessness, or semi-informed tinkering that goes wrong -- at least that I've noticed. If I were GodKing for a day, I'd pitch the ideal ease of editing these someplace between "autoconfirmed" and "admin" -- "manuallyconfirmed", as it were. As, however, I'm not, I suspect there might be some more persuading to do on this... Alai 03:00, 16 November 2007 (UTC)

Hi all - I've nominated this for deletion at tfd - it was created by someone unaware that expand and stub templates aren't used together, and I'm having difficulty finding the actual documentation relating to it (several places which say "the documentation needs changing to show this", but no evidence that it's actually been done). Any input would be welcome. Grutness...wha? 23:06, 16 November 2007 (UTC)

What about trying this on the stub types list? I used it on the category page for Category:Computer stubs and it's really handy. Her Pegship (tis herself) 20:31, 27 November 2007 (UTC)

They'd be really handy - if they worked in Safari, which they don't. I can't get at any of the information in the table in Category:Computer stubs, unfortunately, and anyone else using an older form of Safari will be in the same situation (I've complained about similar tables in articles on the help desk in the past with no success :( All that appears there for me is a thin unclickable line. Grutness...wha? 23:04, 27 November 2007 (UTC)
No joy. :( I have reverted it. Her Pegship (tis herself) 23:48, 27 November 2007 (UTC)

Diplomats quandry

Should we categorize Diplomats under a pure bio-stub or should the politician-stub do the trick? I am having this discussion here. We should come to a consensus on this issue.--Thomas.macmillan 15:02, 3 December 2007 (UTC)

Problem with category changes in templates

Hi all - I've just been looking through Special:Wanted categories toi see if there were any stub-related concerns there, and I discovered three cqategories which had been renamed or upmerged but which didn't have their articles move when the templates were changed. I've tried null edits on the templates, b ut there still seem to be a lot of articles in Category:Music producer stubs (which should be in Category:Record producer stubs), Category:Chess biographical stubs (which should be in Category:Chess biography stubs), and Category:Cricket history stubs (which were upmerged somewhere). The music producer one has over 100 unmoved stubs. Can't see what the problem is... any ideas? Grutness...wha? 10:46, 8 December 2007 (UTC)

Fixed (with copious null 'bot edits to the articles, and a handful of ones by hand). This sort of thing seems to happen from time to time: I'm assuming it's caused by some sort of flakiness in the job queue, with some things "falling off" of it. (It can't only be the size of same, since it's hardly a month behind.) In order to avoid this happening, the best thing would be to make the template changes, then re-check later and delete only when it's actually empty. I realize that's not very convenient, since it basically involves multiple handling for the same task, and doing the job at a machine pace, and is frequently going to involve a significant delay due to job queue size. (But just try telling anyone that over at WP:TALKTOTHEDEVHAND.) However if this is not done, these sorts of job queue problems will show up from time to time, as will some article that turn out not to be template-populated at all. Alai (talk) 21:06, 9 December 2007 (UTC)

Brevity being the soul of wit...

The list of "to be created"s is getting big. Should I delete anything from 2006? From the last 6 months? Last rolling year? Your thoughts, please. Her Pegship (tis herself) 21:21, 13 December 2007 (UTC)

  • If possible, prioritise by (lack of) need. If something would help re-sort an oversized parent, or is there to "complete a set" on an existing pattern, keep it on /T. If it's something that would be reasonable, but there's no pressing reason to have it, give it the shove... Alai (talk) 05:59, 17 December 2007 (UTC)
    • I'd suggest moving things to a subpage, rather than ditching them entirely - especially anything on the "to be created" list. We don't want to lose too much info about what has been proposed and approved but not yet created. In fact, perhaps splitting that info out to a separate "to be created" page is a good way of thinning the list down... Grutness...wha? 09:43, 17 December 2007 (UTC)
  • The main difficulty with judging need is having to go back to the discussions and track down how many items could use the stub type. It was enough of a pain just finding the dates...Thus I have taken G's suggestion and created a subpage. Cheers, Her Pegship (tis herself) 19:12, 17 December 2007 (UTC)
    • Isn't it essentially the same effort in each case, i.e. looking back at the old discussion, which (one presumes) holds both? But the subpage plan seems basically sensible. Alai (talk) 20:36, 17 December 2007 (UTC)
      • Noting the date of the discussion is (thank God) a no-brainer...interpreting the discussion about how necessary a type is takes more time and, alas, more concentration that I can dredge up. Pathetic, but true. Her Pegship (tis herself) 00:11, 18 December 2007 (UTC)
        • I may be showing my biases here, but I was thinking in terms of the parent type being humungous. Generally with my proposals (many of which I'm sure are languishing unactioned), I try to signify this in some subtle way, such as saying "oversized parent". Some of these have probably just been overlooked, other require more careful or extensive action than others, so may well languish longer. Alai (talk) 02:56, 18 December 2007 (UTC)
  • I think I'd also misunderstood what it was being proposed to do here, exactly. It looks fine as-is. Alai (talk) 06:03, 18 December 2007 (UTC)

Stub articles not appearing in new stub category

Excuse me if this is a common problem. However, Category:Video game gameplay stubs is a new stub category. Stub articles are not appearing in it, for instance Action point. Why is this? Thanks for your help! SharkD (talk) 09:43, 15 December 2007 (UTC)

Two reasons: firstly, see above (the section "Problem with category changes in templates"), second, for some reason it was marked with a stub redirect which should have been deleted ("Video-game-gameplay-stub" - the template is at {{Videogame-gameplay-stub}}). There shouldn't be anything using that old template name. Grutness...wha? 11:13, 15 December 2007 (UTC)
Make that three reasons. That f**king Asbox rubbish was involved yet again. I removed it and replaced the template's text with the older standard stub template format, and all the articles appeared in the category. The sooner we get rid of Asbox, the better. Grutness...wha? 11:26, 15 December 2007 (UTC)
Part of that was my fault. I deleted the category and moved the template, but didn't have enough time to change all transclusions to use the correct template. Sorry about that! ~ Amalas rawr =^_^= 23:32, 16 December 2007 (UTC)
S'alright - it's the sort of thing I would have expected you would have used a bot for, given the number of them. Sadly, it seems to be a fairly common occurrence lately that old names aren't being orphaned and deleted as p[er normal (have a look at my recent additions to WP:SFD. Grutness...wha? 23:59, 16 December 2007 (UTC)
If there's something that requires a "touch" or a "template replace" bot as a result of an SFD, please let me know, since even in a "lull" I should be able to do it relatively promptly, and with minimal effort compared to doing it by hand (or indeed, semi-auto with AWB). Anything more complex I'll also have a stab at, but with less of a "performance prediction". If you want to run your own for the same purpose, feel free to pick my brains, and I'll certainly support an BRFA to that effect. (These days the bot approvals group seems to reacted to earlier criticism of "process" and "delay" by becoming an exercice in racing each other to speedy-approve, so that's hardly needed.) On asbox, what Grutness say. Time to declare the absurdly-large "pilot" over, and start systematically reverting them? (Maybe just subst'ing would suffice, but I'd have to double-check that.) Alai (talk) 21:06, 17 December 2007 (UTC)

Village pump

There's a proposal over at the village pump to simply ban stubs. Caerwine Caer’s whines 00:08, 27 December 2007 (UTC)

Repurposing {{stub}}

Most maintenance projects use a date parameter to indicate articles that have needed attention the longest, but not this one. How about repurposing {{stub}} as follows: 1. With no parameters {{stub}} serves to mark newly located stubs for us to sort. 2. When that stub is first sorted, then in addition to the subject specific templates, it keeps adds a parameter, i.e., {{stub|date=January 2008}} that would place stubs in categories such as Category:Stubs needing expansion from January 2008. 3. When the date parameter is present, the article would not be placed in Category:Stubs nor would it add the blurb text unless another parameter such as sorted=no were present.

This would enable editors to focus on stubs that have remained stubs for a long while. An alternative would be to add code to every stub template to do this, but I doubt that we'd want to or be able to ensure every stub template has the necessary code. Caerwine Caer’s whines 00:18, 27 December 2007 (UTC)

  • Mmmmmm. I can understand why this suggestion makes sense, but I can't really see how to go about it while continuing the split of stubs unless a parametered stub template is added at the same time as sorting into a subject-specific stub type. Which would make things pretty messy, since you can guarantee that very soon people will be adding dated stub templates directly, meaning lots of stub articles would bypass the sorting process and go directly into the date-specific categories. The only way I could really see round that happening is adding the date-sorting parameter directly to the individual by-subject stub types, so that, for instance {{Art-stub|date=January 2008}} would automatically add articles directly to both Category:Art stubs and Category:Stubs needing expansion from January 2008. And adding the parameter to all stub types would be a very very long and daunting task. Grutness...wha? 03:34, 27 December 2007 (UTC)
  • Hm, yeah - that might work. Still not entirely convinced of the idea overall, but that does seem like a possible solution to that particular problem. Grutness...wha? 04:05, 27 December 2007 (UTC)
  • Maybe we should consider introducing a different template name for this: {{datedstub}}, or something? Alai (talk) 16:42, 28 December 2007 (UTC)
    • I don't see where it would address Grutness' concern, since casual sorters will prove just as likely to add {{datedstub|January 2008}} as they would {{stub|date=January 2008}}. It would make the template a little easier to code as it wouldn't need to use if's, but I can't see where that would be a major problem. Caerwine Caer’s whines 18:11, 28 December 2007 (UTC)
      • I was speaking only to my own concerns, which are that if a template populates one category by default, and a quite different set of categories if given a parameter, it doesn't exactly comply with "least surprising behaviour", and is indeed bordering on "bizarrely obscure and confusing". An alternative solution to same objection would of course be, "let's not bother doing this at all". Alai (talk) 23:41, 28 December 2007 (UTC)
        • This is exactly the same behavior as most other maintenance templates have had for quite some time, of having the date parameter work in exactly the manner proposed, so having {{stub}} follow the general rule would indeed be "least surprising behavior". Caerwine Caer’s whines 02:23, 29 December 2007 (UTC)
          • No, it's not. You're not suggesting we split the existing articles tagged with {{stub}} by month (which would be consistent, both with its current behaviour, and with that general pattern), but that we have it do its existing job with no parameter, and a totally different one if given a parameter. If there's any other "maintenance template" that behaves in such a manner, please let me know what it is, so I can drag it off to TFD, or better yet, shoot it on sight. Alai (talk) 03:49, 29 December 2007 (UTC)
            Now that I've addressed the secondary issues, let me at last proceed to your concern. Let's change what I proposed the "sorted" parameter to do and make the default be that without it or if "sorted=n" then the blurb text appears and the stub appears in Category:Stubs to be sorted by subject. Only if "sorted=y" and a positive assertion were made that the subject had been sorted would the blurb text not be added. Does that address your concerns, or have I hit a target other than the one you thought you were presenting? Caerwine Caer’s whines 18:15, 29 December 2007 (UTC)

What is Betacommandbot up to?

I've noticed a handful of these edits lately. Any idea what's going on? Grutness...wha? 05:16, 29 December 2007 (UTC)

Betacommand has also been removing the edit action links himself with AWB. A number of editors have suggested on his talk page that he stop and get a consensus first. Should this go to the Village Pump? — Swpbtalk.edits 22:38, 29 December 2007 (UTC)
It's already been brought up at the Admins noticeboard. Hopefully something will be done about it soon! Grutness...wha? 22:57, 29 December 2007 (UTC)

As people have noticed, I started removing the external link in stub templates. They do not anything that is not already available on the page. But they also cause a problem. When you search for improper external links, that link back to wikipedia, IE self refering links in the mainspace, Special:LinkSearch is flooded with extra links from every transclusion of a stub template. There is only one method of checking these and that is to manually load every single page and check the actual edit text. That is why I started removing the external edit links in templates. Are there any proof that the extra edit links actually do anything beneficial. βcommand 16:06, 30 December 2007 (UTC)

Since your concern is that there is no way to determine that these references are due to stub templates without loading the page, that is easy to fix without resorting to eliminating such links. Instead of using [{{fullurl:{{FULLPAGENAME}}|action=edit}} expanding it] for the link in stub templates, if a dummy parameter were added, say stub to make it [{{fullurl:{{FULLPAGENAME}}|action=edit&stub}} expanding it] then there would be a easy way to determine which external links are presumably coming from stub templates without having to check on the link. Such a dummy parameter has no effect on the action of the link but does serve to flag the link. Of course that presumes that the good people who provide the MediaWiki software don't start using stub as a real parameter, so it would be wise to check with them to see if we could reserve a nonsense parameter for such a purpose before making use of it. Caerwine Caer’s whines 18:07, 30 December 2007 (UTC)
that will not address the issue, as the main method that I use, and many other users use is WP:AWB and that does not see the actual links, it just gives a list of pages. βcommand 18:23, 30 December 2007 (UTC)
And where does this list come from? I don't use AWB myself, but I would think that if it is detecting external links transcluded from a template that are in an article that point back into Wikipedia that it would be powerful enough to discern which links have particular parameters in their URL. At worst it might require alteration of the wikicode above to put the stub parameter as the first parameter instead of the last parameter if AWB is only capable of parsing initial substrings. Caerwine Caer’s whines 19:03, 30 December 2007 (UTC)
If you look at this you will see URL linked from page. AWB does not parse the link it just gets the page name. βcommand 21:10, 31 December 2007 (UTC)
I see from its user manual that AWB is able to filter its lists in several ways, including removing all entries from a list that occur in a second list. So if the expanding it link were changed to [{{SERVER}}/w/index.php?stub&title={{FULLPAGENAMEE}}&action=edit expanding it] then this should generate an exclusion list that could be used to make a filter. Caerwine Caer’s whines 21:51, 31 December 2007 (UTC)
for now that will work, at least until I can get the devs to make a better solution. βcommand 21:25, 1 January 2008 (UTC)
It probably would have been better to have gone a little more slowly, as to be certain of consensus before you went ahead and started implementing this. For one thing, the devs might well have preferred a different link parameter be used. Caerwine Caer’s whines 23:29, 1 January 2008 (UTC)