This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
In late March - early April 2017, Wikipedia:Village pump (proposals)/Archive 138#Rfc: Remove description taken from Wikidata from mobile view of en-WP ended with the WMF declaring[1] "we have decided to turn the wikidata descriptions feature off for enwiki for the time being."
In September 2017, it was found that through misunderstanding or miscommunication, this feature was only turned off for one subset of cases, but remained on enwiki for other things (in some apps, search results, ...) The effect of this description is that e.g. for 2 hours this week, everyone who searched for Henry VIII of England or saw it through those apps or in "related pages" or some such got the description "obey hitler"[2] (no idea how many people actually saw this, this Good Article is viewed some 13,000 times a day and is indefinitely semi-protected here to protect against such vandalism).
The discussion about this started in Wikipedia:Village pump (policy)/Archive 137#Wikidata descriptions still used on enwiki and continued mainly on Wikipedia talk:Wikidata/2017 State of affairs (you can find the discussions in Archive 5 up to Archive 12!). In the end, the WMF agreed to create a new magic word (name to be decided), to be implemented if all goes well near the end of February 2018, which will replace the use of the Wikidata descriptions on enwiki in all cases.
We now need to decide two things. Fram (talk) 09:58, 8 December 2017 (UTC)
What should we do when there is no magic word, or the magic word has no value?
an interim measure, to get things moving more quickly, I see some value in initially displaying the Wikidata description as a default for a blank magic word parameter, as it is no worse than what WMF are already doingtoo. Galobtter (pingó mió) 11:58, 19 December 2017 (UTC) Addendum, #5 is basically it, yeah. What matters is in the long-run it's there here. Galobtter (pingó mió) 07:21, 10 January 2018 (UTC)
Pinging everyone who !voted in the What to do with blanks discussion: Francis Schonken, Peter (Southwood), TheDJ, Fram, DannyH (WMF), Mike Peel, Sandstein , James, Dank, Carwil, TomT0m,ChristianKl, Jheald, Galobtter, Davey2010, Doc James.
If the debate is viewed as a simple option #1 vs option #2 outcome, the situation is rather unpleasant. By my count there is currently a majority for #2, however it's not exactly overwhelming. On the other hand #1 has substantial minority support, and the WMF is strongly averse to the possibility that descriptions get mass-blanked before we can repopulate with new descriptions.
There has been substantial discussion of an alternative that was not presented in the original RFC choices: a transition from #1 to #2. In the initial stage, any article that lacks a local description will continue to draw a description from Wikidata. We deploy the new description keyword and start filling in local descriptions which override Wikidata descriptions. Once we have built a sufficient base of local descriptions, we finalize the transition by switching-off Wikidata descriptions completely.
I believe multiple people above have expressed support above for this kind of compromise. People on opposing sides may consider this less-than-ideal for opposing reasons, however I hope everyone will consider this plan in an effort to build a collaborative compromise-consensus. Alsee (talk) 16:24, 6 January 2018 (UTC)
We've been talking for a long time about how to give Wikipedia contributors editorial control over the short descriptions. I've got a new approach to a solution here, and I'd like to know what you think.
First up, to establish where this approach is coming from:
That last point is the one we've been wrestling with for a while. I was asking for examples of article pages that shouldn't have a description, and several people brought up examples where the article had a disambiguation phrase, and the short description was only repeating information from that disambig phrase. Here's some examples:
I said above that I didn't think the redundancy was harmful, but some folks pointed out that I was moving the goalposts -- asking for examples, and then saying they didn't matter. I was trying to make content decisions about the format, and I'm not one of the people who are doing the actual work of writing and moderating them. Fair point.
So I wanted to estimate how many useful descriptions there currently are -- taking out "Wikimedia list page" and "Wikimedia disambiguation page", and also taking out pages where the description is just repeating a disambiguation phrase.
Last week, Mike Peel generated a list of 1,000 random articles and descriptions, which helped us to survey the quality of descriptions on a decent cross-section of pages. I wanted a bigger sample, so we generated a list of 10,000 articles and descriptions.
Here's the breakdown from that larger sample of 10,000 random articles. This is my current definition of "not useful" descriptions:
Putting those together, that makes 48.75% blank/not useful descriptions, and 51.25% useful descriptions.
Extrapolating that out to 5.5 million articles, it suggests that about 2.82 million Wikipedia articles have useful descriptions. (I'm open to continuing to iterate on the definition of useful vs not useful, if people have thoughts about that.)
Now, from the WMF side, the thing that we want to avoid is switching suddenly from 2.8 million useful descriptions to a much lower number, which is what would happen if we built a magic word that's blank by default. That would hurt the experience of the readers and editors who rely on the descriptions.
So, the solution that I'm proposing is: WMF builds a magic word that Wikipedia editors can populate with descriptions.
The decisions about how to generate ~2.8 million descriptions will be made by Wikipedia editors, and the timeline is up to you. I'll be interested to see how that process develops, but it's not our process. Our role is to switch to full Wikipedia-hosted descriptions when there are enough descriptions that the folks who use them won't notice a meaningful degredation. So that's the idea.
One final thing that I want to say is that there are a lot of people in the movement, including the WMF, who believe that more integration and interdependence between Wikidata and Wikipedia is going to be key to the movement's growth and success in the future. We're going to keep working on helping Wikidata to build features that make that integration realistic and practical.
Right now, Wikidata doesn't have the working features that would make short descriptions easy to see and moderate from Wikipedia. In the future, as the Wikidata team builds those kinds of features, we'll want to keep talking to folks about how to encourage productive interdependence between the two projects. I'm hoping that a positive resolution on this short descriptions question helps to keep the door open for those future conversations. What do you think? -- DannyH (WMF) (talk) 00:32, 22 December 2017 (UTC)
This is the key bit:
English Wikipedia editors need to be able to see, edit and effectively moderate the short descriptions on desktop and mobile web, without becoming active Wikidata editors. That requires meaningful integration in Wikipedia watchlists and page history. Those are features that the Wikidata team is working on, but they don't currently exist, and they don't have a timeline for it.
Integration is not possible until this capability is created. The current situation exposes us to prolonged vandalism and thus harms our reputation. Doc James (talk · contribs · email) 06:12, 30 December 2017 (UTC)
It would be a good idea if {{nobots}} is placed on the talkpages of users who havent edited in more than 13 months. or maybe 12.
Currently there are many many users who fit this criteria. And they have subscribed to many newsletters, and whatnot. These things get delivered by bots. And if the user has set-up a bot for archiving then it means a lot of resources are being wasted, which can be saved.
If we are going to place {{nobots}}, then I think we should include {{not around}} as well. —usernamekiran(talk) 05:25, 7 February 2018 (UTC)
Over half of the pages in my watchlist are redirects, and I'm tired of them crowding up the top whenever I create a new batch, then 15% or so are changed by a bot because they're double redirects. I've stopped adding redirects to my watchlist when I create them, but that doesn't do anything to fix the redirects that are already on my watchlist. Care to differ or discuss with me? The Nth User 03:01, 30 January 2018 (UTC)
.watchlistredir { font-style: italic; }
to your CSS. Then go to Special:EditWatchlist. You will be able to pick out the redirects by their italics. --Izno (talk) 04:05, 30 January 2018 (UTC)
please creating categorys for birth by day example november 15 birth — Preceding unsigned comment added by 5.219.149.1 (talk • contribs)
In a sense, we already have this tool. If you type a date in the year into the box in the top right-hand corner, you will get to a list of people born on that date in the year. Vorbee (talk) 19:37, 7 February 2018 (UTC)
Hi, I'm proposing a bot that moves from having the standard inline references to using List Defined References. Now, this is a change that has no effect on the wikitext. Instead, it moves all references to their own section, for those unfamiliar. Clearly, the usage (or not) thereof is purely stylistic. Hence, the bot would only operate this process on request by a user. I believe this to be a valuable process, due to the ease with which large articles otherwise become unmanageable. For example, I had to make this change to fix the removal of a reference in another part of the article. The result was that a second usage of the reference became orphaned. It is on a large article like this, the very articles that pose most problems, that making the change manually is tedious. I therefore propose my bot. ∰Bellezzasolo✡ Discuss 22:49, 6 February 2018 (UTC)
The proposal is inconsistent with the following passage from WP:CITE [emphasis added]:
<ref name="ABC" />
tags.So you would have to gain consensus to change WP:CITE. I think it would a bad idea because there are several possible approaches to avoiding clutter in any particular article, so the alternatives should be discussed on the article's talk page rather than employing a bot. Jc3s5h (talk) 02:43, 7 February 2018 (UTC)
OK, perhaps a less contentious area that AnomieBOT doesn't cover then:
A bot to fix unused LDRs that result in big red errors in the references section. This would work by detecting the errors, then commenting out the offending reference. By commenting out the reference, it is still available for review (and, if the article is being copy-edited, it doesn't dissapear on somebody). It would then post to their talk page notifiying them of its action. ∰Bellezzasolo✡ Discuss 04:09, 7 February 2018 (UTC)
just fix the referencemean in the context of an unused reference? In the majority of cases the LDR became unused when the content that used it was removed. How is this an "error" as to verifiability? You do understand that we are not talking about undefined refnames in citations, right? ―Mandruss ☎ 20:09, 7 February 2018 (UTC)
(copied from Wikipedia talk:Non-free content/Archive 68#Suggestion for new bot as there are not many contributors]]
I would like to propose a new bot to tag all new oversized non-free images with {{non-free reduce}}. I would like to explain a little history to this idea, and how many images it's likely to affect.
Pinging a few editors I know are interested in this area @BU Rob13, Stefan2, and Diannaa:
Time for some discussion...
most common pictorial needs can be met with an image containing no more than about 100,000 pixels(and Masem, who added that to the guideline, has said that it was never intended to be a hard limit). However, the determination if the needs can be met by an image of that size need to be made by a human, not a bot, and unleashing the bot as you've described it is going to result in the needless lossy resizing of images that arguably meet the "minimal use" criterion. If you're going to do this, I would say that Fbot 9's threshold of 164,025 should be an absolute minimum, and frankly I'd be more comfortable with a number closer to 307,200. Anything less than that could get tagged with a "needs human review" tag, but not with something that's going to cause DatBot to come along and automatically resize the image without human intervention. --Ahecht (TALK
{{Anchor|Suggestion for new bot}}
can be placed for continuity. ~ Tom.Reding (talk ⋅dgaf) 20:51, 9 February 2018 (UTC)Hi
I have found several articles over the years where the Controveries or Criticisms sections of articles (mainly companies and politicians) has been deleted by IP editors (most probably who have very direct COI) with innocuous editing summaries like 'copyediting' or 'grammar fixes' and it hasn't been caught by people watching the pages (or no one is watching the pages).
I wonder if there is some way to flag this? Perhaps there can be a bot that checks for where section headings or large chunks of text related to controversies and criticisms have been wiped and flags them somewhere for review?
Thanks
John Cummings (talk) 13:10, 11 February 2018 (UTC)
Not a good idea Such sections are generally a bad idea anyway. North8000 (talk) 18:54, 11 February 2018 (UTC)
Comment: Perhaps an alternative proposal to try and address the same problem would be to look at edits with a large number of characters removed where certain words appear, e.g criticism, scandal, illegal, conviction etc. John Cummings (talk) 09:42, 12 February 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Following a series of vandal edits to the template space (here and here, and the ANI about it), MusikAnimal template-protected (without opposition) templates with 5k+ transclusions and semi-protect all those with 1000+ transclusions.
Earlier today a template with 956 transclusions was vandalised.
Due to the fact that the template space isn't widely patrolled, and the potential for great harm to be done in a very short amount of time, I am proposing that all templates be semi-protected. This would likely involve a software change, but I think it's the only way to ensure that major vandalism on a relatively-unused template doesn't sit around for ages, to be seen by the unsuspecting public who might not know how to let us know to fix it.
I briefly discussed this off-wiki with Cyberpower678, who said they would support if there was a minimum transclusion count (10+ was discussed) so I am amenable to that option, but from an administrative standpoint I think it's easier to just batch-protect everything (unless we can get a protect-bot that can autoprotect templates with 10+ transclusions). Primefac (talk) 18:18, 21 December 2017 (UTC)
the free encyclopedia that anyone can edit.Protection of so many templates runs contrary with Wikipedia's principles. AdA&D 19:28, 8 January 2018 (UTC)
Atleast can we have semi-protection for 100+ transclusions? Another incident occured today that shows why it really is needed. {{Sidebar person}} is transcluded on 564 pages, including Donald Trump. Yet it was completely unprotected, and was vandalized by someone so that a huge "fuck donald trump" showed for at least 40 minutes (probably more) at-least 2 hours (based on a reddit post), 2 hours after the vandalism was reverted (only for logged-out users, because apparently they get a cached version of the page - so regular editors did not see it) I'm thinking that after that automatic semi-protection, at admin discretion, maintenance templates that shouldn't be changed much can be preemptively template/semi protected. Galobtter (pingó mió) 11:25, 1 January 2018 (UTC)
I'm wondering if there's a smarter way to do it. Templates that are transcluded onto other templates (like that one was) should be protected at a lower count. I'm sure there are reasonable ways so that sports stat templates etc are not protected while ones like these are. Galobtter (pingó mió) 11:52, 1 January 2018 (UTC)
If we want to lower the impact of vandalism, we would be far better off enabling as many users as possible to respond to vandalism rather than restricting both vandalism and any response to vandalism to ever smaller groups of users. Vandals by definition are a small set of users and as such can always be thwarted by a larger populace. Adding restrictions just means vandals will have to become more determined to bypass the restrictions. As such, restrictions are not a sustainable practice. Currently anti-vandalism tools are difficult if not impossible to access and use by anonymous IP users which are in fact the largest set of users and editors within WikiMedia projects. 50.53.21.2 (talk) 06:08, 28 January 2018 (UTC)
It looks like about half of the "oppose" votes are opposing the "blanket" semiprot, which I sorta get. That half also mentioned that an alternate option was an "X+ transclusions" option. Seeing as how the % of !votes who would be amenable to that is more than the "hard oppose", I think it's time to flesh out a number. The numbers that were thrown around the most were 10+, 100+, and 250+. So, despite my personal concern that we'll never agree on anything, I'd like to see if we can try. Primefac (talk) 02:21, 4 January 2018 (UTC)
I am interested in adding about 17,000 new stub articles for arthropod species. These can be added over a period of a several weeks or a few months with a bot. The article content is significantly better than the minimal stub frequently seen on these and similar Wikipedia topics.
In my mind, these stubs will serve three primary purposes:
I have requested and received positive input from the Arthropods and Tree of Life projects. I have been manually posting new stub articles generated for a variety of arthopods, primarily insects and spiders, over the past few weeks at the recommendation and encouragement of project members and interested editors. I have received positive feedback, and the stub quality has evolved and improved significantly. Several of the stubs have already been expanded by various editors.
Today I applied for approval for bot operation, and was directed to the Village Pump for more discussion.
Operation Details
VB source code is available at User:Qbugbot/source.
Species selection
The ITIS has most long-established arthropod species in its database, although it does not have many of the newer species and may not reflect recent reorganization of genera and higher taxa. The species in Bugguide generally reflect the latest research, and are limited primarily to species photographed or collected in North America by its users. By selecting the species that appear both in ITIS and Bugguide, we end up with a set of non-controversial species (from a taxonomic standpoint) that are not overly rare or obscure.
Article creation
Articles are created in the following steps:
Article upload
Articles are created on demand for upload. An article will be uploaded only if no article exists for that title. If one does exist, the article will be skipped. No existing articles will be altered. If the taxonomic parent of an uploaded article does not exist, it will be generated and uploaded. If a list of more than 100 "children" is included in the article, it will be split off as a separate list article. A talk page with the proper stub template is created for each article.
Manual verification
During the test period, every article created will be viewed on Wikipedia to verify that it exists, it is the correct article, and the information is proper. Later on, the text of all the day's articles will be downloaded and verified manually or automatically. At least one article daily will be manually viewed on Wikipedia.
Sample articles
Here is a list of some random test articles generated and manually posted on February 1.
Bob Webster (talk) 05:27, 3 February 2018 (UTC)
bot
it will have autopatrol
, so the articles would not show up in the NPP queue. — JJMC89 (T·C) 20:12, 3 February 2018 (UTC){{taxonbar|from=Q10417852}}
;
{{taxonbar}}
will suffice, as shown here. It's a pity that {{Taxobox}} doesn't yet pull its data from Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:28, 3 February 2018 (UTC)
|from=
/|from1=
parameter is not required for {{Taxonbar}}, it is desired from a tracking perspective. |from=
/|from1=
should only be removed if the Wikidata entity (Q code) has no relation to the page (i.e. it was erroneously added to {{Taxonbar}}). ~ Tom.Reding (talk ⋅dgaf) 06:14, 4 February 2018 (UTC)
|from1=
. Also, no duplicate entities are ever displayed. Discrepancies are shunted to one or more tracking categories (though not yet live). There is no tracking category for duplicate |from#=
values, and it should probably be added in the future (though it's not a priority now since this is a very fringe case). For more info I encourage you to read through the discussions at Template talk:Taxonbar. ~ Tom.Reding (talk ⋅dgaf) 15:56, 4 February 2018 (UTC)I've added a new list of sample articles below. The latest source code is available at User:Qbugbot/source. Thanks for the suggestions! Please let me know if you run across anything else. Bob Webster (talk) 19:32, 12 February 2018 (UTC)
Here is a list of some random test articles generated with qbugbot and manually posted on February 12. They now include changes recommended below by Trappist the monk, Tom.Reding, and Elmidae. These are the latest of about 2,000 arthropod stub articles that have been generated by qbugbot and posted manually since the first of the year. Bob Webster (talk) 19:29, 12 February 2018 (UTC)
|date=2008-2009
, which should simply use an en dash instead of a dash. Use of volume & number params too (tho I'm not sure whether or not an en dash was needed for |number=
since "No." was used previously).|pages=475
/|pages=1016
the # of pages in the books? (they shouldn't be! should be the location of the supporting material only; otherwise it doesn't belong; I left it alone for now)|pages=323 + 22 plates
looks odd, but I have no suggestions for anything more appropriate. Can anyone else comment on this? (|id=
exists, but doesn't look appropriate)|publisher=Houghton Mifflin Company.
) aren't needed in CS1 templates (other than for abbreviations), as the template takes care of all otherwise-superfluous punctuation. No errors found regarding this, just fyi to help avoid potential future errors.{{cite journal}}
for that is inappropriate. Because it comes in five volumes, mixing book's volume designation with the publisher's series issue number seems non-nonsensical: 1–5 (76-80) implies that we mean issues 75–80 from each of the five volumes. cs1|2 does not support the notion of series numbers. Pensoft is the publisher; series, if it is necessary, is Faunistica. Similarly, Nelson, et al. is also a book, not a journal; The Coleopterists' Society is the publisher.|url=
when there is |doi=
because that constitutes overlinking and because most most dois are behind paywalls (|url=
is generally considered free-to-read). When the doi is free to read, the citation should be marked with |doi-access=free
|pages=323 + 22 plates
looks like the total-number-of-pages-issue that was mentioned so should not be doneI have a request on improving taxobox. On a taxobox for a taxa; it should be explicitely mentioned; which system of classification has been used. If a mixture of system has been done (although that is highly unrecommended). It is important because classification systems change; where not only the taxa fusion and splits; but ranks of the taxa sometimes changes; and although quite rarely; rank names too changed. So whenever publish a taxobox; please mention which system of classification is followed. Best if a taxobox contain 2 or 3 columns for the hierarchies according to separate classification systems. This not only improve correctness of the articles; but also will work as better reference and would help literature search.
RIT RAJARSHI (talk) 16:55, 13 February 2018 (UTC)
I noticed that the article about the German language has a spoken audio sample, but many other language-related articles (like Spanish) don't. Would it be good to add audio samples to other articles describing languages (including English dialects)? I find them useful since they help to form a picture of how the target language sounds. --Sir Beluga 16:26, 9 February 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This topic has seen a lot of debate, but I think we might want to consider turning off the function that leaves messages on talk pages.
See user:InternetArchiveBot for context. This talk page shows a typical instance of the bot's messaging process, which it does after redirecting a dead link to an archived copy of a dead web page hosted at the Internet Archive. The bot has posted hundreds of thousands of these messages on various Wikipedia article talk pages since 2016.
Why?
Question for you guys, should I turn off the bot's messaging feature? — Preceding unsigned comment added by Cyberpower678 (talk • contribs) 19:51, 11 February 2018 (UTC)
I am pinging people who have engaged in previous conversation about the bot messages.
Blue Rasberry (talk) 20:07, 11 February 2018 (UTC)
A discussion is taking place at:
Interested editors are invited to participate. --K.e.coffman (talk) 20:29, 18 February 2018 (UTC)
Following up on the discussion at Wikipedia talk:Arbitration Committee/Noticeboard/Archive 36#Community feedback: Proposal on case naming, I created a proof-of-concept template to create aliases for the cases opened in 2017 and 2018. Please see Wikipedia talk:Arbitration/Requests#Aliases for arbitration cases for more details. isaacl (talk) 02:28, 21 February 2018 (UTC)
Hi everyone, I have two suggestions. Should we show budget in the wikis for computer games? This is already done in the film wikis.
Also, should have a special entry for marketing costs when talking about a film budget? For example it might say that a film budget is 25 mil. The box office might be 30 mil. A reader of this wiki might then believe that the made a profit of 5 mil. However, with film the marketing might very often be double of the budget. So, if a film budget is 25 mil + 25 mil marketing then you would have a loss of 30 mill. Not 5 mil. profit. Same could be done with computer games
Hi all thanks for replies suggestions. Is there an easy way to give for example all computer games a budget template? And yes I of course agree that the sources for these numbers should be reliable. Also, would eventualism be ok. I'm pretty confident that I can get reliable sources on the newer and bigger games for the older or smaller ones that might be a bit more difficult.
Editors support this proposal to change Category:Infobox templates to a {{all included}}/{{tracking category}}.
Cunard (talk) 01:39, 12 March 2018 (UTC)
tl;dr version: I propose that we change Category:Infobox templates to a {{all included}}/{{tracking category}}, and get all the benefits this would entail.
Currently Category:Infobox templates is setup as a {{container category}} [with a handful of infoboxes which are mistakenly in the category], which is pretty much completely useless. Infoboxes are sub-categorized in an extremely incomplete way, so finding anything is almost impossible simply because this scheme is pretty much ignored, on top of just badly designed in general. Try to find something like {{Infobox journal}} from the main category, and you'll be spending a long time browsing things before realizing it's located in
or
And that's when it's categorized in the first place. You can't get to {{Infobox ABL team}}, because it's not categorized.
So to fix/improve this situation, I propose that we change Category:Infobox templates to a {{all included}}/{{tracking category}}. This would have several benefits, such as (non-exhaustive list):
:incategory
call in Special:Search. If you're looking for a retail-related infobox, you could just search for 'retail', and you'd find {{Infobox retail market}} quite easily.The category could be automatically populated and correctly sorted by the {{Infobox}} template itself (and other similar templates) in the vast majority of cases (at the very least anything that starts with Template:Infobox foobar can be), with the rest being manually categorized. This wouldn't change the subcategory system, so editors could still find {{Infobox element}} via
if they prefer browsing that way. Headbomb {t · c · p · b} 12:43, 21 February 2018 (UTC)
class=infobox
", or otherwise). There is no provision to add/remove "cornercases" *, which could best be handled beforehand at definition stage (that is: here & now). Also, the category will change its definition without providing any process of cleaning up/adjusting the subcategories; these are left to die without care (for this too, starting a new category would be a better solution, evading conflicting definitions).class=infobox
in them somewhere. As for your cornercases, this has also been explained above. Those can be handled by adding [[Category:Infobox templates]]
manually to the templates (or subpages) when appropriate. Headbomb {t · c · p · b} 23:09, 25 February 2018 (UTC)
people know what infoboxes are- apparently that knowledge differs. For example, it differs between you and me, and between template forms. In general, "people know" is not a strong base for a definition (category redefinition in this case). Also, I mentioned eight non-standard situations, about none of which have been answered wrt category definition. - DePiep (talk) 11:12, 27 February 2018 (UTC)
RFC here, please join -> MediaWiki_talk:Wdsearch.js#Add_link_to_search. --Superchilum(talk to me!) 10:50, 28 February 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
As many people here know, there are ocassional April 1st items posted on English Wikipedia,
However, this year I was wanting to ask if there would be any interest in doing something a little unusual.
During the 1980's in the United Kingdom there was a viewdata system called Prestel, which used a presentation
format not dissimilar to the Teletext system used by the BBC's "over the air" CEEFAX.
I'd be interested for April 1st to see what English Wikipedia might have looked like as a viewdata based system c. 1988.
I've posted a similar proposal on French Wikipedia (although for obvious reasons the basis system would be the french TeleTel/Minitel)
It would need a moderate amount of technical effort, as currently Commons doesn't necessarily support a view for the Teletext frame formats the GPL frame editor I found supports.
ShakespeareFan00 (talk) 10:59, 27 February 2018 (UTC)