This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.
Until recently, my impression was de-orphaning can sometimes be beneficial (I did a bit when I was starting to edit) but, in most cases, isn't hugely significant because decent search engines are widespread. Additionally, many orphans cover naturally obscure topics which just aren't going to get many readers or improvements even if they were linked elsewhere.
However, I've been coming across cases where de-orphaning has actually made things worse, generally by giving too much weight to a subject we might not even want to have an article on in the first place. For example, I recently cleaned out a large number of dubiously-notable companies whose establishments were listed as nationally prominent events on pages like 2000 in the United States because of systematic de-orphaning.
It's become increasingly unclear to me whether de-orphaning efforts, as currently practised, are doing more good than harm. But this is based on my impressions, not detailed analysis. So I'm interested to hear others' thoughts.
It probably depends on exactly what is meant by deorphaning. Adding links to relevant articles is good, in that it provides readers a path to find new information. Search cannot help someone find something they don't know they are looking for. The 2017 and 2019 discussions however make a good point that deorphaning as an end in itself is obsolete.Stepping back slightly, is there more information on what the de-orphaning efforts as currently practised are? The adding of links where they are not beneficial is not great, but how much of it is a problem, and is it a systemic issue or a relatively occasional occurrence? CMD (talk) 06:54, 5 August 2024 (UTC)[reply]
The issue with de-orphaning is that it tends to be rather black-and-white. WikiProject Orphanage has the singular objective of reducing the backlog of orphaned articles, which can result in articles that may not meet GNG being given undue weight. Something like the introduction of an 'Orphan-Notability' template, alongside the 'Orphan' template, might help. When de-orphaning a particular article, the option of replacing the 'Orphan' template with 'Orphan-Notability' would create two lists: one for orphaned articles and another for orphaned articles requiring a notability check before they are de-orphaned. Svampesky (talk) 09:15, 5 August 2024 (UTC)[reply]
I've seen good things happen from good links. If an article has no inbound article links it gets very few page views, and thus very few edits. With meaningful links from other articles it is now being seen by readers interested in related topics, and someone reading an article on one topic is probably just the person to make good edits to a related article they click through to. It's true that low-quality links, like linking to a dubiously notable company in a large city article because the company is based there, tend to lower the quality of the established article. Cluttering it up without adding useful information for readers.
I think if meaningful, good article links can't be created to an article, that's a strong sign that the article subject is not notable. It's not a criteria for deletion of course, just an indication that a topic might not be encyclopedic, if no other encyclopedia articles should even mention it. Here2rewrite (talk) 11:29, 5 August 2024 (UTC)[reply]
+1 for I think if meaningful, good article links can't be created to an article, that's a strong sign that the article subject is not notable.. CapitalSasha ~ talk11:33, 5 August 2024 (UTC)[reply]
As an "Orphanologist" working on oldest orphan articles (beginning with 2014 backlog articles), I have seen much progress. At one point the backlog was over 120,000 articles and now about 55,000. And millions more of non-orphan articles. Prior to my involvement, the consensus is to make orphan tag "invisible" after two months. My suggestion would be to show all orphan tags. Regards, JoeNMLC (talk) 13:11, 5 August 2024 (UTC)[reply]
It always seems odd to me if an article can't reasonably be linked to other articles. This could of course mean that those other articles are missing rather than that our orphan is not notable. As for whether we use visible or invisible tags, it rather depends on whether we think the task is something we want to invite our readers to do. In its early days, yes I assume most new orphans can easily be linked into the project. After some time it ceases to be a newbie task and it requires a bit more experience of the project - does this link improve the pedia or is it visual clutter? I'm not sure whether two months is the right time and if not whether it should be increased to three or more or reduced to one. But if we were going to change the interval I'd like it done with some data as to the relative ease of deorphaning articles after one, two or three months. Ideally the link should become invisible at the point where deorphaning becomes a task we don't want to promote to newbies. ϢereSpielChequers13:33, 5 August 2024 (UTC)[reply]
I don't find this odd at all, and being an orphan isn't the end of the world. Of course some articles are crying out to be linked to (creators of new articles are often very poor at looking for links to add). I'm strongly against WP:UNDUE adding the name and a link just for the sake of de-orphaning. Johnbod (talk) 15:08, 5 August 2024 (UTC)[reply]
When this was discussed in 2017, I left rather lengthy comment. Although I no longer de-orphan to the same extent that I once did, I still think the tag is valuable as a diagnostic that signals that an article should be looked at. As I said back then, I have found plenty of instances where investigating why something is tagged as orphaned has helped me improve Wikipedia - merging duplicate articles, upmerging stubs to parent articles, creating new articles in a taxonomic chain, fixing broken links, and initiating the deletion of junk that no one has laid eyes on in years. Issues can arise when people focus more on the idea of removing the tag at all costs rather than figuring out what to do with the article, but that can happen with any maintenance backlog. Think of someone who mass-redirects unsourced articles rather than improving sourcing. Is the problem the tag, or the behavior? Let's not throw the baby out with the bathwater if we can solve the crap-links problem by dealing with whoever is doing it. ♠PMC♠ (talk)08:00, 6 August 2024 (UTC)[reply]
I agree. Even if someone deorphans by mechanically adding a See also link to a more prominent article, the watchers of that more prominent article will then be alerted to the lesser article and it then has an opportunity to be improved. ~Kvng (talk) 14:20, 8 August 2024 (UTC)[reply]
As is often the case when editing WP, de-orphaning requires a degree of editorial judgement. The problems almost always occur when people edit without discernment - adding links just for the sake of linking. The reality is that some de-orphaning links are very beneficial, while others are not. Blueboar (talk) 14:44, 8 August 2024 (UTC)[reply]
The relevant policy/guideline is actually already there:
It may be the case that some articles currently just cannot be de-orphaned. If this is the case then please do not try to 'force-fit' by adding unrelated links to articles where they don't belong just for the sake of de-orphaning. Always keep in mind that our primary goal is to improve the reader's experience, not satisfy the editor's indulgence in statistical achievements. Your priority when adding links should be to maintain article quality by adding relevant and useful links wherever possible — WP:CANTDEORPHAN
So, unnecessary links can always be removed. But it's not always bad, and the inclusion or non-inclusion criteria of certain articles in general articles such as "X year" may not be straightforward; what "degree" of notability (if a person has an article on Wikipedia that person is already notable) a person has to have to be included in "Births"?
Companies can be included in some lists by location or something else. What to put in "See also" is also covered by a guideline.
But do some articles even need to exist? I somewhat agree with other users regarding the (probable) lack of notability (though it may require changes in some notability policies). The other important thing here is the size of the article. Members of the state legislatures are presumed notable, but what if the fact that a person was a member is almost the only thing we know about them? Example. Named natural features are often notable, provided information beyond statistics and coordinates is known to exist. But for some very small streams, this "information beyond" is the etymology and what bodies of water they flow into (sometimes another small stream). Example, Example. The same doubts arise regarding small unidentified villages (that may not even exist), very small neighbourhoods or just "areas".
Finally, there are some interesting guidelines about orphans: Editors may also remove the tag from any article if they believe that de-orphaning is unlikely to be successful, or if they have attempted to provide incoming links-//-However, if you are certain the article is unlikely to ever be de-orphaned then simply remove the tag. Can this also be the answer sometimes? It can also be elaborated. For example, after some time and/or a number of attempts an article may be declared "hopeless" and the tag may be removed.
The reality is that some de-orphaning links are very beneficial, while others are not. A lot of those that "are not" are not harmful either. Oloddin (talk) 05:53, 10 August 2024 (UTC)[reply]
Let's go a bit deeper here. So far, a fair few editors have said something along the lines of "well, sometimes de-orphaning is beneficial and sometimes not", with varying emphasis on "sometimes beneficial" and "sometimes not". But what proportion of de-orphaning, in practice, is beneficial? Is it 90% beneficial, 10% not so much? 70–30? 40–60? 20–80? And where is the threshold for "this benefits Wikipedia on net"? – Teratix₵02:59, 13 August 2024 (UTC)[reply]
To go a bit broader, I would estimate that 90% of good-faith edits are beneficial. The deorphaning edits I have reviewed have about the same level of quality as the other edits I review on my watchlist. ~Kvng (talk) 13:42, 13 August 2024 (UTC)[reply]
"De-orphaning" is not some special process; it's simply connecting an orphan with the other articles by creating links to the orphan. This is beneficial unless these links don't fit into the articles where an editor is trying to put them in. It's hard to estimate how often that happens (not least because, again, whether the link belongs or not is often subjective), but I would say not too often (I agree with Kvng on that). In general, the appropriateness of a link, of some text that includes a link, or of the element in the list (or list-type article) is not dependent on whether it was an attempt to de-orphan or not. Oloddin (talk) 22:36, 17 August 2024 (UTC)[reply]
@Teratix, I suspect that the benefit depends on the subject. De-orphaning a sports or film actor bio probably has a ≥90% benefit: the athlete should be named in some list of the people on their notable team(s), and the actor should be named in the articles about the films they appeared in. De-orphaning a business probably has a 10% benefit. You might occasionally want a sentence like "Bob's Big Business has been the biggest employer in Smallville since 2005", but there are currently about 15,000 places to eat in London, and even if only 0.5% of them are notable, London#Leisure and entertainment doesn't need 75 restaurants named in it. It doesn't even need all six of its Michelin 3-star restaurants listed. However, when something like List of award-winning pubs in London is available, then that's an opportunity to de-orphan these pubs without unbalancing London. WhatamIdoing (talk) 21:17, 23 August 2024 (UTC)[reply]
What is the policy for maintaining access to Wikipedia's library?
It took me six months of steady editing to gain access to the library and for months now, I haven't been able to clip articles at Newspapers.com because I access it through an Ancestry account. Needless to say, this has slowed my editing significantly. How many edits do I have to complete in what sort of timeframe to maintain access? Not being able to clip articles for citations for so long has really sapped my enthusiam but I don't want to lose access to the library after working to gain it in the first place. Oona Wikiwalker (talk) 01:27, 19 August 2024 (UTC)[reply]
Note that there are known issues with Newspapers.com through TWL right now, not sure what the status on fixing them is though. ― novov(tc)01:39, 19 August 2024 (UTC)[reply]
Thank you so much. I did try the steps, but Firefox was spitting up errors so I shut the window and walked away from it for a few days. Difficulties with Newspapers.com is really a pity because it's often a necessary source, but I'm so grateful to have it when it works! Oona Wikiwalker (talk) 06:12, 26 August 2024 (UTC)[reply]
Starting a compilation of Wikipedia policies
I took long hours to condense core content policies into one document. By my calculations, I can retain at least 95% of the meaning of the policies, including most of their intricacies and details, by using only about a third of space that the policies and guidelines, scattered among multiple pages, now take (I estimated from raw text that the policies and guidelines I summarised have about 530 KB of raw text but under the compilation have just 173 KB - still a lot but much better).
It was a hard task and appears about as hard as working in one person to recompile the Constitution of Alabama - a ridiculously long document running at 373K words - 420K words before 2022 (for comparison, War and Peace is 587K words, and there's a good reason they publish it in volumes), but I think it is more than worth it, as people will have a unified set of policies that will be easier to read for people because there's gonna be much less of that but reflecting the same meaning. The overabundance of policies is one reason we have few new editors - there are too many rules, and then folks just randomly throw WP or MOS shortcuts not immediately obvious to the bystander, and suddenly nobody wants to join a project with United States Code-long rules and obscure jargon.
I will appreciate all feedback from you - positive or negative - and preferably some help into condensing further policies and guidelines, such as those about conduct, legal, editing etc. into one page where everything belongs.
I wish you well in your endeavour, but am worried that it will fail in the end because everyone thinks that "their" sub-sub-clause is vitally important. I admit that I rarely look at policies or guidelines now, but find a few basic ideas, along with common sense, to work. Phil Bridger (talk) 12:14, 22 August 2024 (UTC)[reply]
That works for me as well (I normally look into the rules on an ad hoc basis), but then you wouldn't need all those volumes of tiny rules covering, like, 99% of cases, and yet here we are. Also, admins themselves need a clear set of rules for proper enforcement (even if you catch the gist that the persob is just NOTHERE - an essay btw - you still kinda need a more concrete reason that just "that's my hunch")
It's like with RL: pretty common-sense that you shouldn't kill or rob anyone, or what appears common-sense like not using the army or the government to finance/securre your own reelection campaign, and yet these are codified lest anyone have an idea to bend the rules. Szmenderowiecki (talk) 17:29, 22 August 2024 (UTC)[reply]
This exists WP:Nutshell and I think your effort is noble but better focused on improving accessible language and navigation of existing guidelines for newcomers. Twinkle has feature to welcome new users for example. WP:Mentor finds ways to automate assisting newbies. ~ 🦝 Shushugah (he/him • talk) 12:47, 22 August 2024 (UTC)[reply]
Just to pick one example. There's no policy that an article must have (any) sources, let alone one. Yet we consistently advise new users to create articles with multiple sources. Save the edge cases and careful readings of guidelines/policies for advanced users who want to push the margins or change consensus. ~ 🦝 Shushugah (he/him • talk) 12:49, 22 August 2024 (UTC)[reply]
Actually there very much are two policies that prohibit articles without sources:
Verifiability says that you should only add content that you can check against a reliable source, and that you can remove any unsourced content
No original research says you just can't make stuff up. The only way you can have some sort of content is if it can be supported by a reliable source. Technically just have to demonstrate that the source for the passage is somewhere but if you don't provide it in the article, you can totally expect it to be removed and it's gonna be your problem.
No, policy prohibits unverifiable articles, not unsourced articles. Sources are required for BLPs and anything that is likely to be challenged should include a source (but this doesn't have to be inline). An article List of uncontroversial statements of fact consisting of things like "The sky is blue", "Many people are Catholics", "The 1970s happened before the 1980s", etc could be completely fine (it would be deleted, but for reasons completely unrelated to not having sources). Thryduulf (talk) 17:28, 22 August 2024 (UTC)[reply]
Look, I'm not making this up:
Any material lacking an inline citation to a reliable source that directly supports[b] the material may be removed and should not be restored without an inline citation to a reliable source
Which de facto means that if you are adding unsourced content, you are wasting your time as any editor may come by and just remove what you wrote, tell you "lacks an inline citation, I don't care why, pics or it didn't happen" and you are gonna still default to having to add a source (and then again giving time to fix it is a courtesy you needn't, though probably should, extend; though if you have the means to fix it yourself, you should do it)
So there's no obligation to source an article only in the most literal reading of policies. Anyone can enforce this policy provision. WP:SKYISBLUE is just an essay, although one with a pretty large following (and which totally makes sense for me, which is why there is a footnote to that effect) Szmenderowiecki (talk) 17:47, 22 August 2024 (UTC)[reply]
... any editor may come by and just remove what you wrote ...: the operative word is may. The reality is there's loads of unsourced text on WP, much of which will take years for it to be challenged, if ever. —Bagumba (talk) 18:29, 22 August 2024 (UTC)[reply]
It has been tried before. Take a look at Wikipedia:Attribution, an attempt 18 years ago to consolidate some policies. Some very active and well regarded Wikipedians put a lot of time and effort into that proposal, but it was rejected by the community. Consensus can change, but I suspect the community remains just as resistant to change as it was then. Donald Albury20:07, 22 August 2024 (UTC)[reply]
So I did read the poll, and a lot of stuff that was probably relevant here doesn't apply:
Users were complaining about lack of participation/that proposal being forced down their throats as policy - not an issue here (yet)
Merger of NOR, V, RS didn't appeal to people - not abolishing them, just giving sections to these concepts, not a problem.
Users complained about one massive page, or that they preferred separate policies rather than a massive policy code - well that is an issue to discuss but again it's not something that should extinguish all debate before it even starts.
Disgusted that truth is deprioritised - kinda not applicable here, because I'm not changing the framing of policy, just condensing it.
Change is unnecessary - again, debatable but let's have that debate in the first place
WP-links - well, you will have them all you like. Again, something to be discussed.
Assessment of any changes and their impact on disputes - to be discussed, again. This is how rulemaking process should work.
"If it ain't broke, don't fix it" - my whole point is that it is, in fact, broke, so needs fixing.
And again, you can say "meh, we tried eons ago and it didn't work, why bother anymore" but that's gonna be a catch-22, because nothing will change without discussion, which you don't want to hold anyway.
I believe the attitude should be "OK, let's see what you did there and if it makes any sense". It would be another thing if you told me why what I did was bullshit, which is fine. Szmenderowiecki (talk) 18:45, 23 August 2024 (UTC)[reply]
I know, but that's not the point of the compilation. What you are pointing to has a different purpose.
Nutshell, WP:5P etc. is a post hoc summary of policies and guidelines that summarise the main goals in slogans. Just like a company saying "we want to increase the market share; we want good treatment of workers" but not saying how.
WP:SIMPLE is a very high-level summary of policies and guidelines. It's the company analogue of saying: Good treatment of workers means paying more than the minimum wage, giving them extra breaks, paid leave and some other perks, without telling much specifics.
The body of the policies and guidelines is like all internal company directives about pay grades, conditions of getting worker benefits, levels of compensation, powers of HR/executives etc. This page intends to clean up all this body of policies and codify them in a couple of places, grouped by category, so that we remove unnecessary bloat, as in too many redundancies and passages repeated across different policy pages, extraneous comments etc.
@Szmenderowiecki, I don't feel like you're hearing what people are telling you, so l'm going to try a completely different, un-Wikipedian way of explaining this, because the previous efforts haven't worked, and maybe this will get your attention. Here's my new way:
Hi, Szmenderowiecki, and welcome to Wikipedia! I see you've been editing for just four and a half years, and that you've made a few hundred edits at Wikipedia:Reliable sources/Noticeboard, which I really appreciate. I don't know if you knew this, but you're in the top half a percent of contributors for all time. I also notice that you've never edited a single policy, and you have only made one small, uncontroversial edit to a guideline.
Just so you know, most of the people who have responded to you in this discussion have been editing for 15 to 20 years, and have made between 50,000 and 170,000 edits. Also, relevantly, we've been much more active in developing Wikipedia's policy and guideline ecosystem. If you'd like to see an incomplete overview of my own policy-related work, then you can start at User:WhatamIdoing#Policies and guidelines you can ask me about.
Now that you understand who's at the table for this discussion, I want to point out that there is an English saying that fools rush in where angels fear to tread. Every person in this discussion has more experience than you, and every single one of them thinks that, even though your goal is laudable and praiseworthy and at least partially shared by everyone here, your approach is not likely to be successful. It is, of course, possible that you know better than any of us and that rushing ahead is a great idea, but I suggest to you that it is unlikely that all of us are wrong in urging caution and small steps.
If you think you could slow down and get some more experience, and if you're willing to consider doing this over the space of years, then I think we could help set you up for success. For example, if we implemented this idea, that would get about 300 words out of a policy. The next step is to write a good RFC question. If you're interested in this, you could get some practical experience by helping out. WhatamIdoing (talk) 22:26, 23 August 2024 (UTC)[reply]
I don't know if you realise it, and I guess you didn't mean it, but the comment has a very strong patronising "you are too young to understand" vibe which I have a hard time shaking off rn.
I asked you for specific input in opinion and help, and I just think the folks who suggested Nutshell etc. misunderstood my intentions. I apologise if I wasn't clear. My intent is to retain the same scope and level of detail but in fewer words.
If what you meant is to do it in increments, fine, that's an option, still I'd love some feedback if I fucked up with the text in the first place. That is valuable. I'm open to discuss it one-by-one. I will hear input from people who actually drafted policies. That was what I intended to do anyway. Szmenderowiecki (talk) 23:30, 24 August 2024 (UTC)[reply]
You've dropped things, rearranged things, and changed things, and I suspect you have done this without knowing what effects any of that will have.
For example, you've added the word secondary to the WP:GNG, and swapped in a description for the WP:SIGCOV language:
Original: "A topic is presumed to be suitable for a stand-alone article or list when it has received significant coverage in reliable sources that are independent of the subject."
Yours: A topic generally may have a stand-alone article or list when several reliablesecondary sources that are independent of the subject address the topic directly and in detail, so that editors do not have to resort to original research.
I've been trying to get a definition of SIGCOV for years (and years), and failing repeatedly because nobody wants to admit how long (or, perhaps more precisely, how low) "in detail" actually is, for fear that some "unworthy" subject might deliberately seek a qualifying level of independent media coverage. The NOR line in the GNG is basically worthless, and AFAICT removing it would have no effect whatsoever on AFD outcomes, but the fear of making changes to such a high-visibility sentence will likely prevent us from fixing that. Your [e] footnote requires a huge amount of work (e.g., primary sources aren't always about events, sources don't have to adhere to the neutral point of view, a smaller number of high-quality sources is not automatically less indicative of notability than a large number of worse sources).
At the time we started leaning on secondary sources (about 15 years ago), we had a lot of editors who thought that secondary was a fancy way to spell independent. You have added a requirement for secondary sources that does not actually appear in the GNG statement (though it is in the explanations). The GNG offers a conditional rebuttable presumption, which you have turned into a statement of permission (may/are allowed to have...). The GNG says that multiple sources are only "generally expected", rather than required, and you have changed that. Oh, and "several" is often interpreted, at least in American English, as meaning "four" (a=one, a couple=two, a few=three, several=four), whereas the GNG is usually looking for "two".
Among the things you haven't resolved is whether the sources for an article must be considered in isolation. For example:
If I have ten brief independent secondary sources, is that multiple+independent+secondary+SIGCOV, or just multiple+independent+secondary and no SIGCOV?
If I have SIGCOV in a very lengthy, extremely detailed independent primary source, and I have a non-SIGCOV secondary source, does that add up to multiple+independent+SIGCOV+secondary and therefore notability overall, or do I have to get all three key qualities (independent+secondary+SIGCOV) in each source separately?
@Szmenderowiecki, just so you know, I'm always going to be interested in this. If you want to talk about how to improve our written policies and guidelines, then feel free to drop by User talk:WhatamIdoing and tell me about your ideas. It doesn't matter to me if that's that's next month, or next year, or next decade – I'd be happy to hear your ideas whenever you want to share them. WhatamIdoing (talk) 23:19, 25 August 2024 (UTC)[reply]
If anything, the project would benefit from more "fresh eyes"—editors with enough experience to speak somewhat intelligently about these issues, but without so much experience that they are heavily invested in the status quo. There is a strong, almost indisputable case that current PAGs are far too convoluted and complex for the project's good. As a practical matter, the core problem is that the self-selected self-governance model, which created the problem, is incapable of addressing it. Resistance is futile; hence my semi-retirement after about ten years of futile resistance. ―Mandruss☎02:54, 25 August 2024 (UTC)[reply]
I would add that it's useful to hear from editors who still remember their first few edits, because a sentence that makes sense to the "old hands" isn't necessarily any good for the majority of editors. An actual majority of editors has made five or fewer edits, total, ever. WhatamIdoing (talk) 03:02, 25 August 2024 (UTC)[reply]
It might be "useful" in supporting the position that current PAGs are far too convoluted and complex for the project's good (but I think that's self-evident). As for fixing the problem, not so much. Incremental change is never going to be enough; what's needed is massive overhaul, and that's just not going to happen under the current model. Meanwhile, the current model is sacrosanct. ―Mandruss☎04:45, 25 August 2024 (UTC)[reply]
I'll confess that I rarely look at the written policies & guidelines, & mostly use them as a citation when I need to emphasize a point to another editor. I consider what they say is basic common sense, but I've been around so long that I've probably internalized all of the important points. (This is not to say that the original poster is wasting their time. The written policies & guidelines have been considered a mess for countless years.) -- llywrch (talk) 01:49, 26 August 2024 (UTC)[reply]
This is part of the reason why English Wikipedia's guidance is sprawling: a lot of additions get made because a situation arises, some people say "we should have a rule for that", it gets added with a shortcut used for jargon, and editors brandish it in future discussions. As I've written before, it would be better to address problems without creating new specialized rules. But in English Wikipedia's current decision-making environment, there is little appetite to delegate to a working group to more effectively rewrite any pages. Amongst those who like to discuss these matters, there are enough editors who want to be able to weigh in on each sentence that it's hard to modify existing guidance pages, and instead we accrete more. Writing well is hard; writing well in a group is even more so. The irony of a crowd-sourced web site is that crowd-sourcing works best for making incremental changes, but consumes a lot of editor time in discussion for larger-scale changes. Which is why the path of least resistance for modifying guidance pages (and articles too) is to add a few sentences, rather than rework the pages. isaacl (talk) 23:22, 26 August 2024 (UTC)[reply]
As a new editor, adopting this would help me contribute more effectively. I would cautiously suggest that it seems like people know too many abbreviations. Support ForksForks (talk) 22:08, 26 August 2024 (UTC)[reply]
And we use different WP:UPPERCASE for the same page/section, sometimes resulting in one editor claiming that "WP:PAGE" supports his view and the next saying that "WP:SAMEPAGE" requires the opposite, and neither of them realize that they're talking about the same page. WhatamIdoing (talk) 00:35, 31 August 2024 (UTC)[reply]
I don't see any substantive argument that our current P&G structure / the ability for users to peruse it is actually problematic. It should be telling that those editors generally seeing potential in this are relatively new, and those who don't are relatively experienced. That's not (just) survivorship bias, that's experience indicating that what is perceived by some newer editors as a pedagogical issue is (as stated above) actually just the inherent difficulties in learning how to do something conceptually multifaceted and difficult.
Editing is just hard intellectually and socially, and there's no shortcut to becoming familiar with it to be found in compiling one huge document people will not be able to digest immediately versus having several documents. Remsense ‥ 论22:18, 26 August 2024 (UTC)[reply]
I agree with the inherent difficulties in learning how to do something conceptually multifaceted and difficult, but I believe there are more effective and efficient ways to communicate the PAGs than our current structure. I also believe it is pretty much impossible to replace the current structure with a more effective one, having seen what it takes to add a sentence to a policy. Schazjmd(talk)23:32, 26 August 2024 (UTC)[reply]
I think there are substantial improvements that can be made throughout each policy, or even refactoring involving multiple policies, but I think on the broadest level the modular P&G structure has no actual downsides—this isn't Justinian's code. Remsense ‥ 论23:36, 26 August 2024 (UTC)[reply]
I'm all for condensing our guidance down where possible, but I have to agree with Remsense – I'm not sure the goal should be putting absolutely everything on a single page.
There are quite a few policies and guidelines which the average editor doesn't really need to understand in detail unless they're editing in the particular area where it applies. For example, you've included our guideline on reliable sources for medical topics in your compilation, but I'd say that's not a guideline every editor needs to know in detail. For the average editor, it's probably enough to know "medical topics have stricter standards on sourcing, and if medical topics ever come up in my editing there's a page out there I can consult for more information". I don't see the benefit in trying to squeeze the details of that guidance onto a single page together with every other policy.
Sometimes there's a good reason for guidance to be extremely detailed or unusually attentive to particular wording. Our notability guideline for companies comes to mind – it goes over what sourcing does and doesn't demonstrate notability in pretty exhaustive detail. But the details are there for good reason – there's a lot of bad actors out there who manipulate the system for commercial interests, so we need to be unusually strict and explicit about exactly how to determine notability.
Of course, there's still a lot of cases where these caveats don't apply and we really could condense things down without losing much. My advice would be a more targeted approach: rather than condensing everything at once, work out where the low-hanging fruit is and push for changes there. – Teratix₵13:11, 28 August 2024 (UTC)[reply]
I enjoy reading the news in the "in the news" section of the home page of Wikipedia. It has the kind of hard news I like: tornados, earthquakes, fires, hurricanes, etc. from around the world.
But new stories don't come out very often. The current "cycling" item is now 10 days old.
Can't we get a top story each day? Ifyoucrydon'tlose (talk) 20:06, 28 August 2024 (UTC)[reply]
There are some nominations in the queue (see WP:ITNC) but these haven't been posted as they either haven't found to be appropriate topics for ITN to feature, or the article lacks the quality needed to be featured on the main page. As WP is not a newspaper, ITN should not be considered as a news ticket and we don't have an obligation to keep fresh stories there. Of course, more nominations for stories that meet the criteria can always help, but it should be forewarned that there is usually a high bar related to significance of the stories to be posted. — Masem (t) 20:17, 28 August 2024 (UTC)[reply]
Discussions at In the news are largely composed of a group of regulars who have their own ideas about what is "significant" enough to be posted to the main page. I largely avoid ITN because my one experience attempting to nominate something there was extremely frustrating and I don't think it's worth wasting my time updating articles with breaking news stories that editors will randomly find "insignificant" for idiosyncratic reasons. voorts (talk/contributions) 21:42, 28 August 2024 (UTC)[reply]
Its primary purpose is to point readers to Wikipedia articles that discuss the people, places and events that are in the news. These articles will (ideally) give readers the background information to better contextualize and understand what they read/see in news media. Blueboar (talk) 12:30, 29 August 2024 (UTC)[reply]
That's a good description and I thank you for that.
One small note: If you hover over and click on "Ongoing", you can get a list of previous items.
It is highly subjective whether an event is considered significant enough, and ultimately each event should be discussed on its own merits. The consensus among those discussing the event is all that is necessary to decide if an event is significant enough for posting.
Anything else is subject to who shows up. If non-regulars chose to change the outcomes, there is no current guideline-based reason why present trends couldn't change. Until then, what you are seeing is the will of the "regulars". —Bagumba (talk) 10:29, 30 August 2024 (UTC)[reply]
Tags for this (fairly new) WikiProject are being mass-added to practically every article imaginable that is tangentially related to the 2010s — every sporting event in the 2010s; every film, TV show, and video game released in the 2010s; every Super Bowl, solar eclipse, election, notable death, and session of Congress during the 2010s, and so forth. Here's a sampling of the flood of edits that are flooding my watchlist (and likely others). Is this really necessary? To begin with, it's unclear whether a WikiProject should have a scope this large, or if this is attainable (if so, a bot should be assigned to handle mass-tagging). The WikiProject page explicitly states, The WikiProject is and will be involved in thousands of articles. There's no WikiProject equivalent for other decades or centuries, so we're in uncharted waters. InfiniteNexus (talk) 01:01, 1 September 2024 (UTC)[reply]
Apologies if my edits have been overbearing or troublesome, I'll make sure to stop with any further edits. To explain my reasoning, I found the concept of a WikiProject with goals like these to be interesting, so I thought it would help to participate by expanding its scope. I understand that there are countless articles that could qualify as relating to the 2010s, but it honestly made the challenge more enticing. Again I apologize for the flood of edits and clogging up your watchlists, I will make sure to end the expansion and mass edits and I wouldn't be opposed if the WikiProject ends up being removed. DukeOfDelTaco (talk) 01:31, 1 September 2024 (UTC)[reply]
To be clear, I am not targeting you specifically; you aren't the first and only person to mass-add these tags for WikiProject 2010s, but you are the most recent person to do so. InfiniteNexus (talk) 01:55, 1 September 2024 (UTC)[reply]
No worries. I think it's laudable to try to resurrect a WikiProject, but tagging random articles probably isn't the best way to do it. The best way to get the project up and running again would be to find some other editors (maybe @TrademarkedTWOrantula, who revamped the 2010s page a few months back) who are willing to help narrow the scope of the project and focus on crafting some initial tasks. voorts (talk/contributions) 02:03, 1 September 2024 (UTC)[reply]
Well, then ... if the project is inactive, then the tags should definitely not be mass-added to thousands of articles in a bot-like fashion. Even if the project weren't inactive, I still don't think a WikiProject should have a scope this broad. InfiniteNexus (talk) 19:08, 1 September 2024 (UTC)[reply]
I think given that it's inactive, and there's no prospect that participants in the project will come to a consensus regarding narrowing its scope, there would need to be some sort of higher level of consensus to deactivate it and avoid having people tag random articles with this WikiProject going forward. On the other hand, as long as mass tagging isn't occurring, I don't really see the harm with tagging this WikiProject inactive and moving on. voorts (talk/contributions) 19:11, 1 September 2024 (UTC)[reply]
Technical
Coming soon: A new sub-referencing feature – try it!
Hello. For many years, community members have requested an easy way to re-use references with different details. Now, a MediaWiki solution is coming: The new sub-referencing feature will work for wikitext and Visual Editor and will enhance the existing reference system. You can continue to use different ways of referencing, but you will probably encounter sub-references in articles written by other users. More information on the project page.
We want your feedback to make sure this feature works well for you:
Sign up here to get updates and/or invites to participate in user research activities.
We are aware that enwiki and other projects already use workarounds like {{sfn}} for referencing a source multiple times with different details. The new sub-referencing feature doesn’t change anything about existing approaches to referencing, so you can still use sfn. We have created sub-referencing, because existing workarounds don’t work well with Visual Editor and ReferencePreviews. We are looking forward to your feedback on how our solution compares to your existing methods of re-using references with different details.
Wikimedia Deutschland’s Technical Wishes team is planning to bring this feature to Wikimedia wikis later this year. We will reach out to creators/maintainers of tools and templates related to references beforehand.
This is a very important task to work on, but I am not sure how this proposal is an improvement for those of us who do not use the VisualEditor.
Compare:
<refname="Samer M. Ali">Samer M. Ali, 'Medieval Court Poetry', in ''The Oxford Encyclopedia of Islam and Women'', ed. by Natana J. Delong-Bas, 2 vols (Oxford: Oxford University Press, 2013), I 651-54.</ref>{{r|Samer M. Ali|p=653}}
or:
<refname="Samer M. Ali"/>{{rp|653}}
with:
<refname="Samer M. Ali">Samer M. Ali, 'Medieval Court Poetry', in ''The Oxford Encyclopedia of Islam and Women'', ed. by Natana J. Delong-Bas, 2 vols (Oxford: Oxford University Press, 2013), I 651-54.</ref><refextends="Samer M. Ali"name="Samer M. Ali, p. 653">p. 653</ref>
existing workarounds don’t work well with Visual Editor and ReferencePreviews OK, then VE and ReferencePreviews need to be fixed so that they work well with the existing ways of referencing.
Adding another competing standard (obligatory XKCD) is not very useful unless you want to disallow the others which will probably make people very mad (see WP:CITEVAR) and is not necessarily an improvement.
There is no reason why VE or RP would require a new standard, they could just as easily support one of the existing ones (and ideally all of em).
Sfn is routinely out of sync with its parent and requires the use of third party scripts to detect that it is so. Extended references do not i.e. the Cite extension will issue a warning when you have an extension without a parent.
And Rp is objectively subjectively ugly. Presenting it as a potential option is offensive. :)
In <refextends="Samer M. Ali"name="Samer M. Ali, p. 653">p. 653</ref>, a name for the subreference is not required (<refextends="Samer M. Ali">p. 653</ref> will be typical I suppose), and even when it is you can abbreviate since you know what the parent is (e.g. <refextends="Samer M. Ali"name="SMA653">p. 653</ref>).
Some other benefits:
Reference extensions work with reference previews to display the extension directly with the primary citation.
The extensions are grouped with the primary citation in the reference lists.
And the third, which you brushed aside: VE works well with reference extensions.
And as for OK, then VE and ReferencePreviews need to be fixed so that they work well with the existing ways of referencing., MediaWiki systems try to be agnostic about the specific things that wikis do around X or Y or Z. As a general design principle this helps to avoid maintaining systems that only some wikis use, and leaves the burden of localization and each wiki's design preferences to those wikis. Rp additionally has nothing to work with in regard to VE and ref previews. Izno (talk) 16:06, 19 August 2024 (UTC)[reply]
@Izno: Thank you. Gotta sell these things a bit, you know?
Is this style of referencing intended to replace all others? If its better, then lets just abandon all other variants.
The extends keyword is familiar to codemonkeys but perhaps not the most userfriendly for others. I am not sure why it would be harder to show an error when someone writes <refname="nonexistant"/>{{rp|653}} than when someone writes <refextends="nonexistant">p. 653</ref> but in theory this new system could auto-repair references (has that been considered?) Category:Pages_with_broken_reference_names contains 1300+ pages.
I agree with Izno—I'd rather have a syntax that integrates with the <ref>...</ref> syntax, rather than relying on templates, which mixes in a different syntax, and are wiki-specific. isaacl (talk) 16:28, 19 August 2024 (UTC)[reply]
If you control the parser you can make any string do anything you want so the currently chosen syntax is, in itself, no advantage or disadvantage. Polygnotus (talk) 16:31, 19 August 2024 (UTC)[reply]
You provided the wikitext for two examples and asked if one seemed to be an improvement, so I responded that in my opinion, the syntax of the sub-referencing feature under development is conceptually more cohesive to an editor than one where wikitext surrounded in braces follows the <ref.../> code, or uses solely wikitext surrounded by braces. Sure, any strings can be turned into any other strings, but there are still advantages of some input strings over others. I also prefer the resulting output of the reference list. isaacl (talk) 16:45, 19 August 2024 (UTC)[reply]
Agreed, but I assume that things are not set in stone yet. I don't mind the difference between [1]:635 and [1.1] or what exact wikicode is used. So I am trying to think about functionality (e.g. automatically repairing broken refs/automatically merging refs instead of how things get displayed/which wikicode is used). Polygnotus (talk) 16:47, 19 August 2024 (UTC)[reply]
I apologize as your first post seemed to be concerned about the wikitext markup being used by users of the wikitext editor. From a functionality perspective, I think as Izno alludes to, it will be easier to implement features such as detecting hanging references and merging them together with a syntax that is within the <ref> element, rather than relying on detecting templates and associating them with <ref> elements. That would require the MediaWiki software to treat some wikitext in double braces specially. (It would be easier if the extended information were flagged using triple braces, since it would avoid clashing with the extensible template system, but I don't see any advantages to that over extending the <ref> syntax.) isaacl (talk) 17:09, 19 August 2024 (UTC)[reply]
Please don't apologize to me (even if there would be a reason to do so, which there isn't), I am a very confused and confusing person and I understand myself roughly 4% of the time (and the world around me far less often than that). Polygnotus (talk) 17:14, 19 August 2024 (UTC)[reply]
Good to see this moving forward. My main interest was how it would look on the hover, rather than in the References section. I thought the ref extends might 'fill in' variable fields into the general ref, but it seems instead that it just created a new line below. How flexible is this below line, will it display any wikitext? Could we for example add chapters and quotes? (Which will need manual formatting I assume.) CMD (talk) 16:53, 19 August 2024 (UTC)[reply]
What parameters should be sub-referenced? It should be limited to page numbers, and quotes. Not, for example, multiple works, authors, volumes, issues, IDs, dates of publication, ISBN numbers, etc..
How is data in a sub-ref added? If it's free-form text, it's a step backwards from CS1|2's uniform |page=42 to a free-form text like "Page 42" or "(p) 42" or whatever free-form text people choose. Bots and tools need to be able to parse the page number(s). Free form text is not semantic. Templated text is semantic. Anything that moves from semantic to non-semnatic is bad design.
Before this is set loose, there must be consensus about how it should be used. It opens an entirely new dimension to citations that is going to impact every user, citation template, bot, bot library (PyWikiBot etc), tool, etc.. -- GreenC17:00, 19 August 2024 (UTC)[reply]
Yeah its also a bit weird to ask for feedback and then already have a proof of concept and say is planning to bring this feature to Wikimedia wikis later this year. You must ask for feedback before code is written and before any timeline exists. Polygnotus (talk) 17:05, 19 August 2024 (UTC)[reply]
At a minimum, it should not be added until there are clear guidelines for usage. More specifically, it should have a feature that issues a red error message if the sub-ref does not contain a special template for displaying page numbers and/or quotes ie. anything else in the sub-ref is disallowed. Then new parameters can be added once consensus is determined. We should have the ability to opt-in parameters, instead of retroactively playing cleanup removing disallowed parameters. -- GreenC17:18, 19 August 2024 (UTC)[reply]
@GreenC: So then you would get something like this, right?
<refextends="Samer M. Ali"page=""chapter=""quote=""anchor=""><refextends="Samer M. Ali">{{subref|page=""|chapter=""|quote=""|anchor=""}}</ref>
And then a form in VE where people can fill it in.
The former was deliberately not chosen during design work as being too inflexible for all the things one might want to make an extending reference. Izno (talk) 19:33, 19 August 2024 (UTC)[reply]
"All the things", which below you said was only page numbers, chapters and quotes. What else do you have in mind? -- GreenC20:04, 19 August 2024 (UTC)[reply]
There have been previous requests for support in CS1 for subsections of chapters of works. But that's beside the point: we don't need to lock this down out of some misbegotten idea of chaos. YAGNI. Izno (talk) 20:45, 19 August 2024 (UTC)[reply]
It will be chaos as currently proposed, though I never said "lock this down". Johannes asked for feedback. The two main issues I raised, Johannes already said, these are known issues. He said, make a guideline. So I suggested at a minimum, let's make a guideline. You and Johannes don't seem to be on the same page about that. You hinted that were part of the development team, is that correct? -- GreenC23:09, 19 August 2024 (UTC)[reply]
No, I am a volunteer interested in this work since when it was first discussed at WMDE Tech Wishes and/or the community wishlist and have been following it accordingly, working on a decade ago now.
Guidelines are descriptive also. "We usually use it for this, but there may be exceptions." is reasonable guideline text. "You are required to use it only for this." is another reason it's not going to fly. Izno (talk) 16:06, 20 August 2024 (UTC)[reply]
That's a shame, the former was precisely what I imagined and was excited for when I first read about the idea. CMD (talk) 02:36, 20 August 2024 (UTC)[reply]
@GreenC We don't do that with regular references. There's nothing in the software that produces a red error message if I do <ref>My cousin's roommate's friend told me</ref>, so why should subrefs be enforcing that? --Ahecht (TALK PAGE)19:37, 19 August 2024 (UTC)[reply]
@Polygnotus: This has been being discussed for many years now. m:WMDE Technical Wishes/Sub-referencing was created in 2018, and even then the idea had already been being discussed for a while. phab:T15127 was created in 2008. It's not odd that they're finally at the stage of having an implementation (or if it is, it's that it took so long to get here). Anomie⚔21:45, 19 August 2024 (UTC)[reply]
You should probably assume that's the situation for any MediaWiki change. A few years back, some user script authors were mad because a code change had been throwing error messages at them for "only" seven years(!), which was obviously too short a time frame for them to notice that anything needed to be adjusted. WhatamIdoing (talk) 23:06, 23 August 2024 (UTC)[reply]
I actually totally disagree and think you're making a mountain out of a molehill. My anticipation is that most people will use it for the obvious (page numbers). In some cases they may use chapters (a single long text with a single author or even for anthologies). Rarely do I anticipate them using anything else, but I think they should have the luxury of putting whatever they want in the reference.
As regards mandating some use like templates, that's not how it works, though I can imagine some sort of {{Cs1 subref}}... which is probably basically {{harvnb}} and some others.
One thing however that is sure not to occur is to have subreferences of subreferences. This should prevent the vast majority of pathological cases. Izno (talk) 19:32, 19 August 2024 (UTC)[reply]
Uh, yeah. People have successfully used our current mechanisms for extending a parent reference in many many ways which notably don't fit what you want. Izno (talk) 20:44, 19 August 2024 (UTC)[reply]
/me looks back 20+ years… sure is a good thing we wrote all those guidelines before making a wiki that was to become the most popular encyclopedia……. —TheDJ (talk • contribs) 07:20, 20 August 2024 (UTC)[reply]
No one's stopping you from writing some guidelines. There might not even be any opposition if you put sensible things in it. But as Izno says, the guidelines would be advisory rather than prescriptive. – SD0001 (talk) 14:03, 20 August 2024 (UTC)[reply]
When a document has a nested structure, e.g., chapters within sections, it is natural for an editor to want citations that match that structure. I would expect nested citations to include arbitrary combinations of author, editor, page, quote, title and URL, depending on the type of document. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:15, 19 August 2024 (UTC)[reply]
Does "will work for wikitext and Visual Editor" cover the list-defined references examples on the demo page? I'm testing right now and the Visual Editor still seems to have the same problems with list-defined references that have existed for some time.[1] Will this update fix any of those issues? Rjjiii (talk) 02:28, 20 August 2024 (UTC)[reply]
Hi, thanks for your feedback, questions and interest in sub-referencing! Given the large number of comments, I’ll try to provide answers to all of them at once:
replacing other referencing styles: We don’t intend to replace other citation styles. We are fulfilling an old community wish, creating a MediaWiki solution for citing a source multiple times with different details. Citation styles are a community matter and per WP:CITEVAR you can continue to use your preferred way of referencing. If the community wants certain referencing templates to be replaced by sub-referencing, they are of course free to do so, but that’s up to you.
Reference Previews are going to display both main- and sub-reference in one reference pop-up, showing the sub-reference’s details below the main information (example). There are still a couple of details going to be fixed in the next couple of months.
ReferenceTooltips (the gadget enabled by default at enwiki) will need an update. It currently only displays the sub-reference’s information (example), similar to the behavior with sfn (example). But different to sfn (example) it currently doesn’t show a pop-up on top of the first pop-up for the main information. Given that gadgets are community-owned, we won’t interfere with that, but we’ll try to assist communities in updating the gadget.
Yes it will be possible to display any wikitext in sub-references, just like it is possible to do so using normal references (without any templates). We’ve intentionally allowed this, because local communities prefer different citation styles (and even within communities users have different preferences), therefore our solution shouldn’t limit any of those. Citing sources with different book pages will probably be the main reason to use sub-referencing, but it’s also possible to use it for chapters, quotes or other details.
You’ll need to do the formatting (e.g. writing details in italic) yourself, except if the community creates a template for sub-references
List-defined references in VE: We are aware of the issues mentioned in phab:T356471, many of those also affect sub-references. As we are still defining some VE workflows (currently we’ve mostly worked on the citation dialog) we haven’t found a solution yet, but we might be able to resolve at least some of those issues while continuing our work on sub-referencing in Visual Editor.
As already mentioned on meta this should be up to local communities, given the many different referencing styles. It should also be up to them to decide if they want to use templates for sub-referencing or not. We’ve reached out to communities much in advance, so you should have enough time working out some guidelines if your community wants that.
But as Ahecht said: Users can already use references for all kinds of unintended stuff, sub-referencing is not different to that. It’s necessary to technically allow all kinds of details in sub-references, due to the many different citation styles within one community and across different communities.
From our user research we expect most people using sub-referencing for book pages. There will be a tracking category (example) which could be used to check if there is unintended usage of sub-referencing
Adding another referencing style isn’t really useful: We are fulfilling a wish which is more than 15 years old and has been requested many times in the past years. Existing template-based solutions for citing references with different details only work on those wikis who maintain such local templates – and most of those have issues with Visual Editor. That’s why a global MediaWiki solution was necessary. You can always continue to use your preferred citation style per WP:CITEVAR.
Doesn’t look like an improvement for Wikitext: If you compare it with template-based solutions like {{rp}} you are correct that those allow for simpler wikitext. But if you’re editing in multiple Wikimedia projects, your preferred template from one project might not exist on the other one. That’s why a MediaWiki solution will be beneficial to all users. And most current template-based solutions have the already mentioned disadvantages for Visual Editor users. Also readers will benefit from a more organized reference list by having all sub-references grouped below the main reference.
The attribute “extends” doesn’t seem user friendly for non-technical users: We’ve done several consultations with the global community and a lot of user testing in past years where we asked for feedback and ideas on the attribute name. One takeaway is that the name is less important for many users than we initially thought, as long as they can remember it. And our user tests showed a surprisingly large number of Wikitext users switching to VE in order to use the citation dialog (for referencing in general, not just for sub-referencing) – if you do that, you don’t need to deal with the attribute name at all. We didn’t see any major issues with “extends” for people exclusively using Wikitext in our user tests. But so far there is no final decision on the attribute name, so if you have any ideas let us know (we’ll make a final decision soon).
You should have asked for feedback earlier: We’ve been working on this feature (on and off) for almost 8 years and had a lot of community consultations (e.g. at Wikimania, WikiCite, discussions on metawiki where we invited communities via Mass Message) and many rounds of user testings – always with the involvement of enwiki users. And we are doing this big announcement now in order to make sure that really everyone knows in advance and can provide further feedback while we are finalizing our feature.
Perhaps it would be wise, in future, to make a list of predictable reactions/questions and incorporate the responses to those in the announcement. Highlighting the advantages of a change/addition, USPs if any, why decisions were made and perhaps even a short timeline can make the reception much warmer. Some people here (e.g. Polygnotus) don't know the 15 years worth of background information. The good news is that I think that it is an improvement (although it could be a bigger improvement). I assume others have also mentioned things like ensuring refs don't break and automatically merging refs (but I do not want to dig through 15 years of history to figure out why it wasn't implemented) and this is/was an opportunity to make something superior to the existing methods that could replace them. The OrphanReferenceFixer of AnomieBOT will need to be updated. Polygnotus (talk) 17:04, 20 August 2024 (UTC)[reply]
It's always difficult to write such announcements in a way that they answer the most important questions while also being short an concise so that people actually read the them ;) Some of the questions raised in this section have already been answered in meta:WMDE Technical Wishes/Sub-referencing#FAQ and we'll continue to add more frequently asked questions there, if we notice (e.g. in this village pump discussion) that certain questions come up again and again. Johannes Richter (WMDE) (talk) 17:16, 20 August 2024 (UTC)[reply]
Agreed, it is super difficult to strike the right balance. And even if you do, some will still be grumpy. But its also very important. Polygnotus (talk) 17:20, 20 August 2024 (UTC)[reply]
Thanks for the detailed response and the included screenshots. I was a bit glum following my comment above but I think I have a better grasp of the underlying concept now. If we are able to use citation templates in the sub-reference field, that may provide a way to fix at least some of the potential issues raised above. Is there a place to track changes to the reference pop-up (File:Sub-referencing refpreview.png)? My first impression is that's perhaps not a necessary large white space but I'm curious to read more discussion on the matter. CMD (talk) 17:25, 20 August 2024 (UTC)[reply]
@CMD depends on what you mean by "place to track changes"? There are several phabricator tags which might serve this purpose (although we've collected a lot of user feedback which is still under discussion and therefore not filed as a task yet). We want to use meta:WMDE Technical Wishes/Sub-referencing#Recent changes and next steps to document important changes on the current prototype and can certainly document further changes to Reference Previews for sub-referencing in this section as well, if that's what you imagined? Johannes Richter (WMDE) (talk) 15:43, 21 August 2024 (UTC)[reply]
Thanks for the lengthy reply! Can a template tell if it's being used in an extended reference?
If there is any probability of this all working in the Visual Editor, we should also aim to make templates that work in the Visual Editor. That would mean a template that slots inside of an extended reference, rather than a template that invokes one (the way that {{r}} or {{sfn}} work). There is already some discussion at Help talk:Citation Style 1 about building a template for consistency between the main named reference and the extended sub-references. I considered making a proof of concept template that would only handle pages, quotations, and so on, but folks have already mentioned citing named sections in a larger work and other broader ideas.
For a template to plug into this, I've checked the parameters currently available in major templates that cite locations within a longer work. If I've missed anything feel free to update this table:
In-source location parameters in existing templates
Also, regarding formatting, CS1 and sfn are based (to an extent) on APA and Harvard citation styles.
Also(B), regarding LDR, one of the issues with list-defined references in the Visual Editor is that removing all usage of a reference from an article's body text makes the reference become invisible in the VE and emits this error message on the rendered page, "Cite error: A list-defined reference named "Bloggs-1974" is not used in the content (see the help page)." To have an un-called reference isn't exactly an error, though. Editors move citations from the bibliography and standard references down to other sections (Further reading, External links, and so on); some articles still have general references at the bottom. Is there a way to push un-called references down to the bottom of the list and treat them as a maintenance issue rather than an outright error, like the below example with citations borrowed from Template:Cite book/doc(11-02-2024)
Can a template tell if it's being used in an extended reference? No, not currently. Lua experts feel free to correct me if I am wrong. Polygnotus (talk) 02:57, 21 August 2024 (UTC)[reply]
push un-called references down to the bottom of the list and treat them as a maintenance issue it isn't even a maintenance issue; it is useful if people name refs so that those names can be used later to refer to those refs. But if no one refers to em that is fine. Polygnotus (talk) 03:01, 21 August 2024 (UTC)[reply]
Indeed to best of our knowledge templates currently cannot tell if they are being used in a sub-reference. But it should be possible to make such changes. As templates are community-owned, we cannot do that ourselves, but we'll try to assist communities (e.g. by providing documentation or some examples) with the necessary changes to citation tools and templates. Johannes Richter (WMDE) (talk) 15:47, 21 August 2024 (UTC)[reply]
Yes, additional parameters might be needed on <ref>...</ref> and on citation templates to designate main and sub-references.
LDRs that are named but not cited are most definitley treated as errors; that doesn't mean that they should be treated as errors. There are other markup languages where uncited references are treated as legitimate. Admiitedly {{Refideas}} is a workaround, but it would be nice if {{Reflist}} could include incited references and if the LDRs were listed first. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:20, 21 August 2024 (UTC)[reply]
Strange short description - how to fix it?
I started typing "Space-Men" in the search bar and it suggested the Space-Men article with the strange short description of 1960 Italy?'"`UNIQ--ref-00000004-QINU`"'? film. It shows up in the page information page that way too, but not in the article's source/wikitext, so I'm not sure how to fix it. Any ideas? 28bytes (talk) 17:34, 26 August 2024 (UTC)[reply]
{{Infobox_film}} builds a shortdescription from the country. The country ends with a reference. A reference gets replaced by a strip marker, for technical reasons. But a short description doesn't have wikitext support, so the stripmarker is not automatically replaced/removed. The template that adds the automatic short description should be updated to strip the strip markers. —TheDJ (talk • contribs) 18:27, 26 August 2024 (UTC)[reply]
While my effort to fix it evidently didn't address the underlying issue, if you're going to slap my hand you could at least acknowledge that I made a good-faith effort to fix the most immediate problem that was presented in the OP, and that I made it clear in my own message that I wasn't sure that I'd really fixed it at all. I'm not sure what you're talking about with the second part of what you've said, unless you meant to say that I could have posted it there. Except that I couldn't have posted it there because I didn't know that the underlying issue was with the template, nor did the OP indicate that the issue lay with the template. DonIago (talk) 20:17, 26 August 2024 (UTC)[reply]
After thinking more on it, I agree. Fixing the broken case as a temporary measure seems fine, not different from CSS fixes people make. I do think VPT should try to find the root cause of problems, but I don't think DonIago's change should have been reverted while the problem is not fixed.
I'm unclear if the strip markers not being detected is a larger issue, or something that needs to be coded into Template:Infobox film/short description. Nthep and DJ's comments made it seem like an easy fix, so I restored Space-Men to using the auto-generated SD so it will be as it was prior to the issue and utilize that auto SD. But if it is not an easy fix, then yes, we can implement the workaround that Doniago did. - Favre1fan93 (talk) 16:10, 28 August 2024 (UTC)[reply]
The problem is fairly common where the infobox generates a short description from values found in the infobox. Often a country is expected, but the country name turns out to be a list of countries. Often (like here) a field is expected to be a simple piece of text, but has a reference appended or includes an extra formatting template. In this case, the reference should be moved into the article text – the infobox should be only a summary of details that are present in full in the article. Otherwise, just add a manual SD like DonIago did. The sandbox is well out of date, so I assume that nobody has signed up to fix the template? If not, can we please just fix the Space-Men article? It hurts — GhostInTheMachinetalk to me18:16, 30 August 2024 (UTC)[reply]
Ah. I would have first tried {{Strip tags}}. Is that too aggressive? However, us mortals make such changes. We need somebody with superpowers to fix the infobox template for us. So, for now, I just fix individual articles as I find them — GhostInTheMachinetalk to me21:41, 30 August 2024 (UTC)[reply]
Not via the WEBUI, you may get close with the API - but a quarry report is likely going to give you what you want assuming your filters are supported cheaply. — xaosfluxTalk18:26, 27 August 2024 (UTC)[reply]
Another possibility is old-school screen scraping. Just go to your contributions page in a browser and save the page as HTML (in Chrome, it's File/Save Page As..., and I'm sure similar in most other browsers). Then hack at the HTML with standard command-line tools. This did a pretty good job for me:
It's ugly and hackish, but for a one-off job where you can accept occasional errors, it's often the best way. If you're not into the command-line, google for "HTML to CSV conversion" and you'll find lots of other tools that do this. RoySmith(talk)15:22, 29 August 2024 (UTC)[reply]
I use Notepad++ + regex. I copy the list into Np++, use Alt to column-select all the text to the left of the page names & remove it, then Ctrl+H to remove diffhist [^\r\n]+, leaving only the page names. ~Tom.Reding (talk ⋅dgaf)16:23, 29 August 2024 (UTC)[reply]
Thank you, Tom.Reding (and all) that's an interesting approach. But the recent results for my contribution include:
12:02, 26 August 2024 diff hist +32 N De Cotiis #REDIRECT Vincenzo de Cotiis current Tags: New redirect Uncategorized redirect
18 August 2024
18:59, 18 August 2024 diff hist +32 N Taxa inquirenda Species inquirenda current Tags: New redirect Uncategorized redirect
7 August 2024
22:04, 7 August 2024 diff hist +31 N Jablochkoff electric candle #REDIRECT Yablochkov candle current Tags: New redirect Uncategorized
and not only does your regex not work for that (it removes the page titles as well as other stuff), but the "diff hist" columns do not align, as the dates are of differing lengths. Are we at cross purposes? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits14:14, 30 August 2024 (UTC)[reply]
The 2 apparently empty brackets [ ] actually contain 2 whitespace characters each, present in sample text, 1 of which is 0-width, so be careful when copy-pasting, since misplacing and/or losing the 0-width character is never good.
There are 3 whitespace characters in (?: ), which are also required.
The position & formatting of diff hist/diffhist probably differs based on skin, but the idea is to use some string that appears at the same relative position on each line.
Make sure there is a blank line before the first line, to match (\r?\n), which are the CRLF characters, or else the regex won't evaluate the first line.
What Izno said. Or, to save you the trip, here's a list going back to late June 2018 (when the create log began). I've removed creations in user talk, too, since I assumed that's what you meant; there were 585 in that namespace, compared to just 21 in User:. CSV available in the cyan "Download data" box. —Cryptic14:46, 30 August 2024 (UTC)[reply]
Onlyinclude allows for transclusion of hidden comments?
I was wondering, has it always been the case that <onlyinclude>...</onlyinclude> tags, if placed inside of a hidden HTML comment, will still transclude its contents when called from another page? (For example, see here and here in my sandbox.) This seems strange to me, if the code is hidden it seems like it should not be transcluded elsewhere. This doesn't seem to apply to includeonly though.
I assume it has always been like that and it seems logical to me. Comments <!-- ... --> are saved as part of the page and not stored somewhere else. If the page has onlyinclude tags inside then all other parts of the page are ignored on transclusion so the comment start and end tags are not seen. includeonly works different. A page with includeonly but no onlyinclude is processed from the beginning on transclusion so the comment tags are seen there. PrimeHunter (talk) 12:10, 28 August 2024 (UTC)[reply]
The most likely explanation is that, because of an AfD debate, the article was deleted and the pageblock then ended. And then the article was recreated, and the editor was then able to contribute to it. The current incarnation of the article was deleted by another administrator a few minutes ago, just as I was about to click the delete button. My explanation is an informed hunch and those with deeper understanding of the software may have a better explanation. Cullen328 (talk) 07:44, 28 August 2024 (UTC)[reply]
There's some edits after the page was moved. I think Cullen328 above might be on the right track. Maybe partial blocks are by page_id rather than page_title. Thank you both for the ideas. –Novem Linguae (talk) 07:48, 28 August 2024 (UTC)[reply]
Just a brief update here...
The previously blocked user is already arguing for undeletion at Requests for Undeletion, here [2].
Given that the article coudl as easily have been deleted under G5 as G4, would it not be possible for an admin to just site block the user, rather than for others to have their time wasted by his continual bad faith actions? Axad12 (talk) 08:29, 28 August 2024 (UTC)[reply]
No problem, I will open a thread at ANI and copy you in. (I will say for now however that I feel that the user's behaviour at Requests for Undeletion was quite unacceptable). Axad12 (talk) 08:57, 28 August 2024 (UTC)[reply]
@Novem Linguae Partial blocks apply to a specific incarnation of a page, not the page title (as you say, it works by page id). If you move a page to a new title the partial block should move with it.
You also cannot use a partial block to stop an editor creating a page.
Perhaps changed recently or I did not pay attention but Special:Watchlist has filter for namespace and refers to Article/Mainspace as "Content", the first I've seen it named as such anywhere. I like content but find it confusing when elsewhere e.g in Special:MovePage it's called (Article). I don't have a strong opinion on the correct name, but think we should minimize confusion. ~ 🦝 Shushugah (he/him • talk) 10:55, 28 August 2024 (UTC)[reply]
{{trout}} me 🎏 You are right! I did not read closely enough, despite bothering to report it here, because I would have expected it to select all content/talk pages then. Thank you for the informative links down MediaWiki rabbit hole! ~ 🦝 Shushugah (he/him • talk) 12:36, 28 August 2024 (UTC)[reply]
Invisible text on pending changes page histories with green on black gadget.
I use the green on black gadget available through preferences. When I go to the history of a page which has pending changes, the bytes and the user-entered edit summary for the top two entries are in black text on black. I struggle to read this. If I click-and-highlight then I can read it. I'm not sure how long ago it started. For example here. Can it be fixed? Thanks, DuncanHill (talk) 16:07, 29 August 2024 (UTC)[reply]
The other day, I had a notification I had already seen reappear a month later. Apparently this is something which is seen on occasion, but nobody knows how to reproduce it. If this happens to you, please leave comments on T373443 with whatever details you can figure out, or just email me if you don't have phab access and I can do it for you. RoySmith(talk)17:57, 29 August 2024 (UTC)[reply]
I have been experimenting with dark mode (&withgadget=dark-mode). While doing that, I received a "You have a new Talk page message" notification. In dark mode, I had no idea that the notification was there. The text is black on a dark brown background that visually disappears in the black window. I did not even see the light red badge on the bell. Looking at it now, the pink badge is kind of obvious but I only noticed it while looking for it after seeing the normal notification in another window with the original white background. It is essential that new editors receive an in-your-face talk notification because we block people who do not respond but continue with problematic editing. I know this should be requested elsewhere but there is not much point adding the opinion of one person so I'm looking for thoughts. Johnuniq (talk) 05:07, 30 August 2024 (UTC)[reply]
Problem of using "|show_designation=no" and "|show_type=no" on Template:Public art row
Hi
I am trying to use "|show_designation=no" and "|show_type=no" commands on Template:Public art row when I use the template on list of public art pages, but it keeps showing these colons.
The simple answer is that these parameters are not recognised or supported by Template:Public art header. Perhaps it was thought that every table should have these columns. Are you sure it is appropriate to omit them in the article you are working on? — Martin (MSGJ · talk) 06:36, 31 August 2024 (UTC)[reply]
@PrimeHunter Thanks. I'm afraid I am not sure how to add that to my global.js - or how to load the other one in my browser console. In fact, I'd never heard of my browser console until today. I use Chrome and have found it now, but am still pretty clueless. Sorry. Doug Wellertalk08:06, 1 September 2024 (UTC)[reply]
@Doug Weller: You already load it in your global.js. That's why you have the diff option in contributions and used to have it in your watchlist. safemode=1 omits user scripts and gadgets. The browser console is a way to run specific JavaScript on a page you are currently viewing. Right-click on an empty part of https://en.wikipedia.org/wiki/Special:Watchlist?safemode=1, click "Inspect", click the "Console" tab in the lower part of the right pane, copy-paste the above command and press enter. Does that give you "Inspect diff" links at the time (it won't last when you leave the page), and do they work? What happens if you do the same at https://en.wikipedia.org/wiki/Special:Watchlist? PrimeHunter (talk) 10:08, 1 September 2024 (UTC)[reply]
@PrimeHunter I copied mw.loader.load("//en.wikipedia.org/w/index.php?title=User:Writ Keeper/Scripts/commonHistory.js&action=raw&ctype=text/javascript"); into the console and hit return but got the message "undefined". Doug Wellertalk10:27, 1 September 2024 (UTC)[reply]
Not sure if it is relevant, but I've 3 watchlists, one for user and user talk pages, one for articles and their talk pages, the third for Wikipedia and Wikipedia talk, and that one has show and hide diffs. I'm not sure if that's always been the case, sorry. Doug Wellertalk10:32, 1 September 2024 (UTC)[reply]
When logged out, in dark mode, at {{Soulfly}}, the actual link for Soulfly is an extremely dark grey that is difficult to see on a black background. It was not this way before. Does anyone know how to fix this? --Jax 0677 (talk) 12:41, 31 August 2024 (UTC)[reply]
Xtools appears to be down
Here - it says 'Error' and then "This web service cannot be reached. Please contact a maintainer of this project. Maintainers can find troubleshooting instructions from our documentation on Wikitech." Any idea what's going on? GiantSnowman13:43, 31 August 2024 (UTC)[reply]
Adding an EventListener to avoid unwanted submit during type of "edit summary" textboxes
Hi, for example during type of "edit summary" after an edition or during writing "Other/additional reason" for moving a page, users may press enter button, but they may or may not tend to submit their form. In the case of not tending to submit their form, this behavior of Wikipedia may be considered ill-posed. For example consider this scenario:
During the third stage, casual pressing enter key may lead to ill-posed submit of this form. So, I propose adding this EventListener to avoid wrong submit:
Or somehow showing a confirmation message box, like this:
varinput=document.getElementById("myInput");input.addEventListener("keypress",function(event){if(event.key==="Enter"){lettext="Are you sure?";if(confirm(text)==true){document.getElementById("myForm").submit();}}});
I myself have had many problems with this «default behavior of forms on in HTML». This behavior is not the intended behavior for such important actions like "Edit" and "Move" of pages. I really think that other users of Wikipedia sometimes have had many problems with this default behavior.
This default behavior is good for other applications, like entering a password and then checking it on back-end code.
I really think that showing a confirmation before publishing an edit (only showing confirmation in the case of pressing Enter key in the textbox, otherwise not showing) would be helpful. Hooman Mallahzadeh (talk) 12:14, 1 September 2024 (UTC)[reply]
I just tried to fix a few examples and it's taking way too long. As a busy practicing attorney, I don't have two hours to spare to clean up someone else's mistakes. I have better things to do with the Labor Day holiday weekend, like going through more of my photography library to identify more photos for upload to Commons.
One of the longest running debates among lawyers for many centuries is whether a trial court should be organized as a nationwide or statewide entity that merely happens to sit in multiple counties, districts, or circuits—or whether each county, district or circuit should be regarded as having an entirely separate trial court. There are strong public policy arguments for and against each position, resulting in worldwide gridlock on this issue.
California is among the majority of American jurisdictions that adhere to the latter position. In other words, it has 58 superior courts, not one superior court that happens to sit in 58 counties. Section 1 of Article 6 of the California Constitution refers to "superior courts" (notice the plural) and Section 4 starts with the following words: "In each county there is a superior court of one or more judges."
Unfortunately, User:Mliu92 created many articles for superior courts that imply that California adheres to the former position. For example, the article for Santa Cruz County Superior Court incorrectly states that the "Superior Court of California, County of Santa Cruz, is the branch of the California superior court with jurisdiction over Santa Cruz County."
We need a bot to go through the English Wikipedia and replace every instance of the phrase "is the branch of the California superior court" with the phrase "is the California superior court". How do I go about initiating that request? Coolcaesar (talk) 19:11, 31 August 2024 (UTC)[reply]
A while ago, I asked about references. I put that aside for a while and now I'm picking it up again. It's obvious that my original strategy was not going to work, so I'm starting again. Before I dive into this too deeply, is there any actual documentation on how references are rendered in HTML? Some of it I can suss out. For example, the first citation in Special:Permalink/1233803324 gives:
in the reflist, with the backlink for citation 1a, and I should treat the "cite_ref..." and "cite_note" ids as opaque strings (as opposed to trying to parse them, as I was originally doing). Is that it, or are the more bits of magic that will only become apparent when this iteration of my code breaks on something I haven't seen yet? RoySmith(talk)19:26, 31 August 2024 (UTC)[reply]
There is no documentation on the current parser's format, but there is documentation for the new parser: https://www.mediawiki.org/wiki/Specs/HTML/Extensions/Cite. You will probably have a much more enjoyable time working with the new parser's output anyway, since it includes lots of extra output to make it more machine-readable (e.g. the values for refname in the data-mw attribute – no need to try to parse them out of the href/id).
I'm not familiar with Phabricator and I'm not sure it's the best place to point this out. I made this edit. It appeared on the page after I clicked on the button to publish. As I clicked back to where I was before, the edit disappeared. It was gone from the live page and also gone when I clicked the edit button to browse the page's text, this without any intervention via succeeding edits. This continued to be the case after I cleared the cache for the page. However, the edit was still there when I checked the page's edit history and my own contribution history. I thought this to be bizarre, as I don't recall anything like this ever happening before. RadioKAOS / Talk to me, Billy / Transmissions 20:14, 31 August 2024 (UTC)[reply]
I would like to request a tool that, given a revision number (or title) of a page and timestamps T1 and T2, would run down all the transcluded templates, {{excerpt}}s, and modules in that rev, and return a most-recent-first sorted list of transcluded/invoked items which have changes recorded in their history between T1 and T2, or since T1 (if T2 is empty). The tool should recursively expand templates (maybe only if |recurse=y?). Possible format: four columns, with 1) Item name, 2) last change timestamp, 3) rev. number, 4) userid; where item name could be template, module, or excerpted source pagename. Bonus: column five, containing the template traceback sequence, if the row item was not found at top level, i.e., the item was not directly transcluded by the given page rev., but further down.)
Here is my use case: I recently panicked when I noticed that Ships of ancient Rome, which has over one hundred {{sfn}} short citations and makes liberal use of {{excerpt}} had fifty harv errors of the type 'Harv error: link from CITEREFLastname-YYYY doesn't point to any citation'. (I am very familiar with sfn/Harv errors of this sort and how to fix them, and wrote part of the doc for it; ditto {{excerpt}} doc.) The offending edit was a very minor change to add a {{convert}} template to the body (diff) which resulted, very oddly, in the 50 errors. No one had changed {{convert}} or Module:Convert, so I first suspected PEIS issues or nonprinting characters, but that proved wrong, and the problem went away during the time I worked on it (see these 6 edits), so I presume an upstream problem had been fixed in the interim. It could have been an entirely different template, but my investigation was hampered, and then I abandoned it, because of the impracticality of tracking down every transclusion made by the article, possibly recursively if nothing changed in directly transcluded items.
Having a tool that would return a sorted list of most recently changed transcluded items would be a powerful aid in this situation. (O/T: we need a word that encompasses the meanings of transcluded, invoked, or excerpted; I vote for eval'ed unless somebody has a better idea.)
The way things turned out, the problem I observed (whatever the cause) was fixed while I looked into it, and that's great, but what if it hadn't been? Such a tool would be very useful to help someone track down a real problem and make it possible to find and advise the author of a recent change that broke something, whereas now, it is so impractical as to be near hopeless. Can anyone build this? (edit conflict) Mathglot (talk) 21:04, 31 August 2024 (UTC)[reply]
Sounds a lot like Special:RecentChangesLinked, except substituting the templatelinks table for pagelinks, only going in one direction, and without the unfeasible complication of looking at old revisions instead of the current one. I'm surprised it's not in MediaWiki already (and wouldn't be surprised if it was and I just didn't know where to find it). Twenty years ago I'd have suggested making a feature request. For now, something like quarry:query/85974 is probably the best you can hope for. —Cryptic21:43, 31 August 2024 (UTC)[reply]
Parser function for checking if a user is blocked
If possible, could someone assist me with a template which checks if a user is blocked?
The syntax would ideally go something like this:
{{ifblocked|Blocked User|foo|bar}} would return foo because Blocked User is blocked.
{{ifblocked|Magog the Ogre|foo|bar}} would return bar because Magog the Ogre is unblocked.
I'm happy to use Lua if necessary (I have never learned to use Lua, unfortunately).
template/technique request : insert wikitext between each character of string
i am looking for something that works like the following two examples ; between abc → a;b;c {{key| followed by }}{{key| between abc followed by }} → abc
thanks in advance akizettalk20:34, 1 September 2024 (UTC)[reply]
Does the community still want moved pages to be unreviewed
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Back in 2017, the community decided in this RfC that moved pages should be unpatrolled. The feature was stuck in Phabricator purgatory and was never actually implemented.
I'm really surprised so many people supported that: it would create a substantial added burden for patrollers in exchange for maybe making a very rare problem slightly easier to detect. (Redirects from page moves already go into the queue, and even if they're retargeted elsewhere, a good reviewer should notice the suspicious history.) Unless this is a much larger-scale issue than I'm aware of, I don't think that proposal should be implemented. Extraordinary Writ (talk) 08:00, 21 July 2024 (UTC)[reply]
I have seen cases (e.g. recently at AT CBS This Morning) where a long-standing patrolled page becomes unpatrolled because a non-autopatrolled user moved the page - like from vandalism being reverted like CBS This Morning, or from requested moves like (709487) 2013 BL76. There can be quite a lot of these cases. Is this scenario also part of this discussion? thanks. Aszx5000 (talk) 09:36, 21 July 2024 (UTC)[reply]
@Aszx5000 That specific behavior is part of a bug that started happening recently and will be probably reverted. It's being tracked in T370593. The default behaviour is to not unpatrol page that are moved. Sohom (talk) 10:00, 21 July 2024 (UTC)[reply]
I think the RfC should be respected. Yes, WP:CCC but we really shouldn't overturn an RfC without an new RfC. Besides, this will help with detecting move vandalism in some cases so it is a useful change. Nickps (talk) 12:32, 21 July 2024 (UTC)[reply]
Oppose: If the RfC hasn't been implemented in 7 years, and it was only recently implemented by accident, it makes sense to revisit the discussion instead of implementing it by surprise so much later on in time. As one of the more active patrollers, I absolutely hate the idea of adding to the workload / massive backlog by adding pages to the queue just for being renamed. Really we'd want to just mark it as patrolled 99% of the time anyways. Hey man im josh (talk) 14:49, 21 July 2024 (UTC)[reply]
FWIW, I attempted to figure out how much moving and patrolling actually goes on so I could see if making it necessary to re-patrol moves would indeed add a significant workload. I came up with 916 moves and 1225 patrols yesterday. My SQL is weak (and my understanding of the MediaWiki schema even weaker) so I don't know if these numbers are accurate or not. If they are, then it looks like this would almost double the patrolling workload. RoySmith(talk)15:33, 21 July 2024 (UTC)[reply]
Though, as usual, raw statistics are misleading. Neither of our queries, for instance, try not to count page moves by autopatrolled users, or pages moved out of the main namespace without leaving a redirect or where the redirect was later deleted. I can at least compensate for the small sample size by showing stats for all of July up to now, which are better: 7068 page moves starting in mainspace, 13519 mainspace page curations. —Cryptic16:55, 21 July 2024 (UTC)[reply]
Oppose. I don't see much of a point in implementing this as it would unnecessarily double the workload of the NPP team. Redirects left behind from moves are already placed in the redirect queue (except for users in the page mover, autopatrolled, and redirect autopatrolled groups, including administrators). DannyS712 bot then automatically reviews a portion of them if the changes fit certain criteria, and the rest are reviewed manually. I feel like this system works just fine; it's not like we have a runaway page-move vandalism issue on our hands. —TechnoSquirrel69 (sigh) 17:50, 21 July 2024 (UTC)[reply]
Oppose. To quote myself from 2017: Oppose pending more information. I'm concerned about rushing into something that will potentially hugely increase the load at the already hugely-backlogged WP:NPP. How many pages are moved per day? How many more reviewers would we need to handle the extra load? What's the scale of this problem? Are there other solutions we could explore (e.g. marking pages that have {{disambig}} removed as unpatrolled)? We have the answers to some of those questions above, and it's not looking good. Doing this would double the NPP workload in order to close a loophole that is apparently so small that nobody noticed it had been accidentally left open for the last seven years. Really bad idea. – Joe (talk) 21:35, 21 July 2024 (UTC)[reply]
Comment: the proposal as it developed in the 2017 RfC was not for all article moves but for those by non-EC users which I think was 40 a day at the time. Cenarium's comment is not clear to me but search for "40" (not pinging them because they have not edited since April). Pinging @Ivanvector: who initiated the proposal for their comments. We don't know if this is still a concern or if other mechanisms were put in place. S0091 (talk) 19:39, 22 July 2024 (UTC)[reply]
not for all article moves but for those by non-EC users which I think was 40 a day at the time. This somehow ended up not reflected in the 2017 RFC close and not reflected in the 2017 Phabricator ticket. We could go off on a tangent about whether that RFC was closed correctly or not, but I think it's a non-issue because we'll get a fresh consensus in this RFC that will override any lack of clarity about the previous close. –Novem Linguae (talk) 23:58, 28 July 2024 (UTC)[reply]
??? I don't know that area that well because that not normally where I do my NPP work but I thought this was already happening. For example Extracorporeal procedure was in the cue. The community really needs for fix some things to help with the disaster at NPP but worrying about easy stuff like this really isn't it. North8000 (talk) 20:28, 22 July 2024 (UTC)[reply]
Oppose: Unnecessary. They will almost always be marked as reviewed immediately, so this just adds a pointless burden to the NPP queue. CFA💬22:15, 28 July 2024 (UTC)[reply]
The discussion above 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.
Deploying Edit Check on this wiki
While attending Wikimania this year, Selena Deckelmann (User:SDeckelmann-WMF) demonstrated a new feature for Visual Editor, Edit Check in a session. Edit check introduces additional prompts in Visual Editor when an editor tries to insert a blacklisted URL as reference and also when they try to publish a revision without inserting a reference. This greatly helps with encouraging editors inserting references in their edits. If I recall correctly, the percentage of editors inserting references increased from 11% to 40% in their tests (do correct me if I am wrong as I am going off on my recollection).see #What's next? for corrected stats
There is certainly some benefits in enabling this, primarily on improving the verifiability and reliability of content that's on English Wikipedia. Most of the sister projects have already been deployed with this feature. English Wikipedia does not have this feature enabled yet. The only thing that is holding back this feature is that Visual Editor is not set as the default editor for anonymous and new editors.
Therefore, I would like to propose that:
Visual Editor be the default editor for anonymous and new editors.
The last time I checked, new editors are presented with a pop-up box that asks them to choose which editor they'd like to use, with the solid blue button pushing them a bit toward the VisualEditor.
This thread is rather underdeveloped. For a proposal of this magnitude, I think we should figure out relevant factual questions (like what the current default is) and then draw up a more formal survey that could be CENT-listed, etc. Sdkbtalk19:05, 9 August 2024 (UTC)[reply]
Another question is how does it work with edits that don't need references adding (e.g. creating redirects, adding links on disambiguation pages, fixing spellings, etc)? Thryduulf (talk) 19:08, 9 August 2024 (UTC)[reply]
In theory, this sounds like a great idea. I'm eager to try it out, but I think a first step would be to make it available as an opt-in on enwiki. Then after people have got some experience with it, let's come back and talk about making it the default. RoySmith(talk)20:09, 9 August 2024 (UTC)[reply]
There's a simpler option for userscripts that should work: window.MWVE_FORCE_EDIT_CHECK_ENABLED=true;
So long as that's there before VE loads, it should force you to have edit check. Either method also bypasses the account restrictions on edit check, so you're not quite getting the pure experience that people would if we just turned it on for enwiki. By default it only shows up for new users (defined as under 100 edits), and someone might want to edit the configuration on-wiki for that. DLynch (WMF) (talk) 21:26, 9 August 2024 (UTC)[reply]
The add-reference check is very conservative currently. You need to be a user with less than 100 edits who has added a whole new paragraph of at least 50 characters (configurable per-wiki) that contains no references before it'll pop up. This can all be loosened up in the future, whether by default or through community configuration, but we figured that those criteria had pretty low odds of being a false positive to start with.
It's quite interesting that this boosts the percentages so much, because I honestly thought that complete new-editors would be doing far more minor edits. But no, major new blocks of text are pretty popular.
It's actually turned on with the reference check everywhere but 8 of the wikipedias (bn, de, en, hi, id, nl, pl, ru), so it's pretty easy to try it out on another wiki if you don't want to jump through userscript hoops here. DLynch (WMF) (talk) 21:34, 9 August 2024 (UTC)[reply]
Not sure where ReplyTool will put this, but nothing I'm seeing in the documentation requires VE to be the default editing interface in order to deploy the new tool. So deployment doesn't seem contingent upon answering the larger question of whether VE should be default. Folly Mox (talk) 22:17, 9 August 2024 (UTC)[reply]
Unless things have changed in the last year, it doesn't need it to be the default, but editor does need to be in the visual editor, and that's somewhat more likely to happen (especially for the editor's first edit) when the visual editor is the default. WhatamIdoing (talk) 01:29, 10 August 2024 (UTC)[reply]
The functionality is targeted towards new editors and anonymous editors, therefore the need for Visual Editor to be the default before the deployment of the functionality is considered complete. Also there are on wiki configuration options that we may want to adjust. As stated by Dlynch (WMF) above, the tool is configured by default for an user with less than 100 edits and making revisions of more than 50 characters. – robertsky (talk) 04:15, 10 August 2024 (UTC)[reply]
Minor quibble: enwiki has already got the prompts about blacklisted URLs for references/links. We rolled those out everywhere on the logic that any edits involving them were going to get blocked-on-save anyway so it wasn't going to disrupt any workflows. :D
It's a bit fuzzy because we called the project "Edit check", and we're developing a specific system called edit check (of which the "add reference" check is the first example), but we're also doing smaller edit-enhancement features along the way that colloquially get called checks just because of the project.
Conduct a thorough analysis of the potential consequences of setting Visual Editor as the default for anonymous and new users. Consider factors such as user experience, editor retention, and overall editing patterns. If making Visual Editor the default is not feasible, investigate other strategies to increase Edit Check adoption. This could include targeted outreach to experienced editors, promoting the feature through in-editor messages, or developing incentives for reference usage. Regardless of the chosen approach, it's essential to closely monitor the impact of Edit Check on reference usage and article quality. This data will be crucial for refining the feature and measuring its overall effectiveness.
I'd support making Visual Editor the default, as long as they also leave wikitext editing as an option (which I'm sure they will). VE is much better nowadays than when it was first released. As a WYSIWYG editor, I suspect it is much more new editor friendly. It is unarguably better at things such as automatic citation generation and table editing (adding and removing columns and rows, moving columns and rows around). And for the few things it is bad at (such as complicated template syntax), power users can just switch to wikitext editing. Any logged in user can select their default at Special:Preferences (under "Editing mode"). –Novem Linguae (talk) 10:47, 10 August 2024 (UTC)[reply]
I totally agree that VE should be the default for new users. I use VE every day, and it's just fine for most stuff, and getting better incrementally. Folks who think VE should not be the default should go to edit-a-thons and try teaching new users. 20 years ago, wiki-markup was the new hotness and was miles ahead of editing raw HTML. Today it's just a barrier to entry for potential new editors. RoySmith(talk)12:24, 10 August 2024 (UTC)[reply]
When I first edited English Wikipedia as an IP editor, I found WikiText editing very difficult to understand. I’m sure that most new IP editors face this issue. I strongly support making the Visual Editor the default. New IP editors are often unfamiliar with Wikipedia and may not know how to cite a reference using the WikiText editor. They may also not know how to switch to Visual Editing. Frankly, I still have to check the preview before publishing edits using the WikiText editor because I sometimes make mistakes. GrabUp - Talk11:08, 10 August 2024 (UTC)[reply]
Potentially minor bugbear alert: The visual editor reference creator still hasn't figured out the basic functionality of allowing for an easily accessed and obvious use of an |author= field, instead forcing all authors into |last and |first. It's not a groundbreaking issue, but it's really disappointing that it's still around after so long, especially given the many words given over the years about attracting more diverse perspectives etc. The default reference tool that we are going to create a pop up asking all new editors to use should allow for sources from authors whose names don't fit into the common European name format. It may be hidden behind an additional field button, but at least the wikitext reference creator has the option. CMD (talk) 12:10, 10 August 2024 (UTC)[reply]
My biggest bugbear is the lack of ability to set a reference name. For example in this edit I switched from visual to source editing so I could reuse citations between prose and infobox. Although admittedly this is not something a brand new editor wants to do, being able to set a name other than ":0", ":1", etc would be rather handy. Thryduulf (talk) 12:28, 10 August 2024 (UTC)[reply]
Is naming references a policy? Or is it something you consider useful? I don't edit the code. I just reuse citations when I need them, directly from the citation insertion menu. Very convinient. 37.169.50.102 (talk) 12:52, 11 August 2024 (UTC)[reply]
I mostly work in VE; I'm not personally bothered by the opaque names (i.e. ":0") that VE invents because I never see them. But many people work in wikitext, where having human-friendly names is important. So, I agree that improving support for reference naming should be a high priority. RoySmith(talk)12:57, 11 August 2024 (UTC)[reply]
I just went looking, and I don't see a Phab ticket for this. I was a bit surprised there was no ticket, but then I thought about it a bit more. It's probably hard to come up with a wiki-agnostic way to generate good citation names. You'd have to program it with something very enwiki specific to get it to read our unique citation templates then extract the author last name and year from them. User:Nardog/RefRenamer is a good workaround though. –Novem Linguae (talk) 13:14, 11 August 2024 (UTC)[reply]
I thought we were talking about auto-generating good names. Those tickets are for something else. Maybe I am misreading this subsection though. Apologies if we are not actually talking about auto-generating good reference names. –Novem Linguae (talk) 13:20, 11 August 2024 (UTC)[reply]
When copy pasting named references to another page, you get false matches that are not obvious. If automatic named references were more unique (slugified title) this false collision would happen less often. I am all for hiding/abstract workflows where needed. ~ 🦝 Shushugah (he/him • talk) 13:03, 11 August 2024 (UTC)[reply]
All programmers should read Falsehoods Programmers Believe About Names, and then re-read it every few years to refresh their memory. People who design database schemas should re-read it every time they start a new project. I agree that it's not a showstopper for our purposes, but it is a surprising lack of cultural sensitivity from an organization which is so into i18n.
For me, the biggest bugbear is that there's no good way to convert a {{cite web}} into another template without basically starting from scratch. It really should be smart enough to figure out that if {{cite web}} has a "first=" field, it can safely map that into {{cite news}}'s "first=" and so on. It won't be perfect, but it'll get you most of the way there. RoySmith(talk)12:57, 10 August 2024 (UTC)[reply]
@Chipmunkdavis @RoySmith Visual editor follows the definition of the template parameters at Template:Cite web#TemplateData (and so on for other cite templates). I think the developers would also wish that you didn't require the name to be split into two fields; it's a chore to fill it out this way. If you think this can be changed, please edit it there. Matma Rextalk13:58, 10 August 2024 (UTC)[reply]
@Matma Rex you are entirely correct that VE gets its field definitions from the templates. The first part of my comment about first_name/last_name ethnocentricity applies equally well to template writers.
But, the part about being able to convert one type of citation to another really is a VE issue. The "automatic" feature of the VE template editor is very handy, but it often can't intuit the proper type of template (that's not VE's fault) and falls back to using {{cite web}}. It would be really handy if you could say, "Please make that into {{cite news}}, and do the best job you can converting the fields". RoySmith(talk)14:38, 10 August 2024 (UTC)[reply]
|author= is already present in the existing template parameters, even if just as an alias of |last. Not presenting the alias in VE is a choice of VE, the buck should not just be passed to blindly following a particular table. CMD (talk) 14:56, 10 August 2024 (UTC)[reply]
It might be controlled by the WP:TEMPLATEDATA in something like Template:Cite/doc. I think VE reads the template data to determine the parameters it displays. If a parameter is omitted or set as hidden, perhaps it is not displayed. Not 100% sure but that is probably worth checking. –Novem Linguae (talk) 15:08, 10 August 2024 (UTC)[reply]
Assuming it is, then it would be really useful to have some statistics of how often VE (I know, I should really be saying Citoid or Zotero, or something else, but I'll just keep saying VE because that's what the end user sees) gets it wrong. I'm not entirely sure how we would define "gets it wrong", but a first pass might be "VE initially calls it {{cite web}} which is later corrected to a different {{cite xxx}} variant". Some of that might require instrumentation inside VE to detect when the user abandons a constructed citation before saving it. Some of it might require analyzing revisions to the page to see when template types are corrected after the fact. But let's assume one way or another, we could build a log of incorrect categorizations.
Then what we would do is take the full log of these reports, group them by top-level domain, and sort by frequency. If it came out that "bxtimes.com" was the most frequently domain which got mis-categorized, then it would be the highest priority for a human to go figure out how to fix and add that knowledge to the VE (Citoid? zotero?) database. After enough iterations of fixing the highest priority ones, we'd end up with a better system. If (total SWAG here) we could find the 100 top problems that accounted for 50% of the total errors, with a very small amount of human work to fix them, we could have a major win.
It sounds like a reasonable stab at the misassignment-of-citation-templates issue.
Caveat up front: I'm a developer, but I've never actually touched the internals of Citoid+Zotero, so I might be wrong about details here. That said, I believe you're right that the classification part happens entirely in Zotero, and further that if you want to teach Zotero about how to classify a new site there's some guidelines we have for that over on mediawiki.org. This coming from Zotero is also why we have vastly more classifications than we actually use on-wiki -- check out the mapping for that.
It's possible that some of the incorrect template-usage you see could be at the level of those mappings, as well -- I note that the `statute` type is just hooked up to the generic `Citation` rather than to {{Cite_act}}, for instance, though that's probably far from the most common one to need.
As for the specifics of working that list-of-sources out...
We do have some instrumentation inside VE already that could probably be looked at to work out how often someone gets all the way to the "presented with a citation-template" step and then abandons it, which would give us an okay up-front guess at the rate where something is wrong with the generated citation. Ignoring the question of other types of failure for now, the next problem is that our VE usage-instrumentation is carefully ignorant of content for privacy reasons, so it doesn't know anything about what URL was looked up when that happened. Looking for revisions which consist of just a citation template being replaced with a different citation template sounds doable, albeit slow.
I wonder if we could approach it another way. Assuming that Zotero has some internal logging of the translator it used when we make a request to it, or that it can be persuaded to tell Citoid this, we could perhaps add some logging for requests that fall back to the default-translator for unknown pages. That's not a perfect match for the misclassifications, but it's much easier to find. It does leave out cases where the translator exists but is getting it wrong, of course. DLynch (WMF) (talk) 01:46, 11 August 2024 (UTC)[reply]
it doesn't know anything about what URL was looked up when that happened does it know/track what type of template it chose? If so we can possibly work out what proportion of e.g. cite-news vs cite-web generations were abandoned? I don't think, ottomh, there would be any privacy issues with that? Thryduulf (talk) 01:53, 11 August 2024 (UTC)[reply]
Unfortunately not. All it tracks is that a citoid request happened, and then either that the "insert" button was chosen or that something was done to move away from the citoid results list. It doesn't even track what type was chosen if you go to the "manual" tab and explicitly pick one of the templates listed there.
I do agree it seems very unlikely to be a privacy issue. I mostly mentioned that was the guiding principle to explain why the case for so many questions like this turns out to be "we never needed this actually-very-innocuous content-related data before, so we weren't collecting it". DLynch (WMF) (talk) 02:09, 11 August 2024 (UTC)[reply]
Superb Owl has been maintaining a table of domain names where mw:Citoid has trouble producing a correct citation at User:Superb Owl/Community Wishlist § Automatic Citation Tool. As I understand it, Citoid's problems are partially due to how it scrapes target pages, and if domains are not putting all the information we need in <meta> tags then our only recourse is to improve Zotero translators directly.However, Citoid is understandably geared towards internationalisation and extension to all Wikimedia projects. En.wp has a considerably more complicated / sophisticated / mature citation framework than probably anywhere else. Little things like an automated citation using {{cite web}} instead of {{cite news}} or {{cite periodical}} don't bother me: User:Citation bot converts these, and the only template type it really struggles with is conversion to {{cite book}}, which has a pretty different parameter set.What does bother me about the automated citations output by the Visual Editor (apart from all the <ref name=":0">) is how often it just dumps out obviously incorrect information with no message to the user. Things like |last=B.C. |first=Sima, Qian, approximately 145 B.C.-approximately 86 (1); |last=Company |first=Rand McNally and (2); |last=Feb. 1 |first=the Office of Communications on |last2=2019 |last3=P.m |first3=3:06 (3); |last=à 00h00 |first=Par Le 2 avril 2008 (4); |first=Government of Canada National Research Council|last=Canada (5), etc, etc, etc, bonus consequence.A few days ago, I floated the idea to add a layer of error-checking into the VE citation generation interface. That's really all we need, I think. It shouldn't be the responsibility of WMF staff to ensure that every citation generated by their tools somehow makes sense for our project. But if there could just be one extra step for editors using the interface, where they could see the errors their automated citations are causing our community-maintained modules to throw, maybe they'd take the steps necessary to compare the output against the source and correct the problems before publishing.This won't fix every problem, obviously: algorithmically generated citations are only perfect when they draw on structured metadata that maps properly and completely onto our template parameters. But being able to get feedback during the edit should help editors in the VE environment clean up some of their own messes before they hit mainspace, unreviewed at the bottom of the article. Folly Mox (talk) 12:37, 11 August 2024 (UTC)[reply]
@RoySmith, @DLynch (WMF), @Folly Mox, speaking from experience from creating Zotero translators for a couple websites that I frequently use for citations, errors like this are more often than not a byproduct of missing specific Zotero translator rather than anything else. The default translator will interpret og:type = article as itemType = 'webpage', therefore citiod will use {{Cite web}}. This is unfortunate as even in the default translator's own test cases, vox.com is expected to return as 'webpage' for itemType. However, I would agree with this output, as in Open Graph Protocol, the last object type specified is 'article', and I am assuming that that's the fallback for Facebook as Facebook would use the embedded preview for articles if there's no og:type in the header (i.e. Facebook debugger on wikimedia.sg).
Therefore, what's needed to be done is to either have another translation layer on citiod to map generated citations from identified websites to use {{Cite news}} instead of {{Cite web}}, or write a specific translator for bxmedia.com, or investigate if the default translator in Zotero can be extended further so that the rework for specific websites can be minimal. – robertsky (talk) 18:16, 11 August 2024 (UTC)[reply]
Actually, passing Citoid's output directly to Citation bot before returning it to the editing interface – one specific implementation of another translation layer – sounds like a minimally effortful solution using tools already deployed and currently maintained. Citation bot doesn't fix everything (and breaks some things) but it usually does a good job in selecting which template type to apply to a citation, and in mapping data to appropriate parameters. Folly Mox (talk) 18:35, 11 August 2024 (UTC)[reply]
Yes. I have it enabled as an user script. It just won the Coolest Tool Award for improving the quality of edits. While I appreciate the work there, I also wish there is an easy way to translate the JSON files to Zotero translator format so that the work can be enjoyed by those who cannot use it out of the box on Wikipedia and everyone else who is using Zotero in general. – robertsky (talk) 08:36, 12 August 2024 (UTC)[reply]
65, I had heard of that tool, but wasn't previously aware of its functionality. It looks like a great idea, but for the fact that it is presented as an option to Citoid's output rather than a replacement of it (community generated translators for domains Citoid struggles with should – by definition – always be superior).I'm not interested in apportioning blame for Citoid's output: generalised parsing of html meta elements across the entire set of domains is a hard problem and a big task, with a lot of people involved in every step. But it remains true that for a significant portion of domains lacking structured metadata, Citoid's output ranges from suboptimal to unusable.Any additional translation layer that can be configured by the community would be superior to none, and that functionality should exist in Visual Editor so as to improve the quality of citations generated and reduce the maintenance burden shouldered by script maintainers and experienced editors on this project. Folly Mox (talk) 11:29, 13 August 2024 (UTC)[reply]
Please post corresponding Phabricator tickets for all mentioned "bugbears". 1) Having tickets for these things and 2) making noise in them is the best way to move these fixes forward. –Novem Linguae (talk) 14:31, 10 August 2024 (UTC)[reply]
Thanks all who have participated in the discussion above. I wil admit that this is my first time opening a proposal. Apologies if it is lacking in some details. While early, it seems that at this juncture, there a large support among the participants to have Edit Check deployed and/or Visual Editor be set as the default editor, keeping in mind that there are still some bugbears, or wishes to have some citations related issues resolved (honestly, I think belongs to another thread, but I appreciate the discussion nonetheless). I would like help in bringing this proposal to the next step of having it as a CENT discussion, be it by opening another thread/discussion here or elseswhere, or reformating the current one.
Impact report
In the opening, I presented a wrong statistics from the test that the product team conducted. Upon further check, I found the impact report on reference checks. Short of reproducing the whole report, these are the key numbers:
The number of constructive edits from newcomers increased from 19% to 42% (2.2 times more. As defined by newcomers with less than 100 edits and not reverted within 48 hours).
Breaking down the above number, this is consistent across all wikis with the test on. And on mobile, the increase was 4.2 times more.
Contributors that are shown Reference Check and successfully save a non-reverted edit are 16 percent more likely to return to make a non-reverted edit in their second month (31-60 days after).
10% decrease in edit completion rate for edits where Reference Check was shown
1.8% false nagative
6.6% false positive
From the report, we can see that Edit Check, in particular the Reference Check functionality, helps with improving the content contribution of newcomers and helps to improve the retention of newcomers as well. The 6.6% false postive rate may be a concern, but in my opinion, a minor one. Details from the report indicates that some of the dismissal is essentially WP:SKYISBLUE. Additionally, further finetuning of the configuration for the Reference Check may be made as well to attempt to reduce the false postive rate.
Questions asked
The following are some questions and answers summarised from above (feel free to add more):
Qn: Is Visual Editor is the default editor for newcomers on enwiki?
No. Newcomers are presented with an option to use Visual Editor upon first edit. Declining it will let editors to use source editors instead.
Qn: how does it work with edits that don't need references adding (e.g. creating redirects, adding links on disambiguation pages, fixing spellings, etc)?
The default configuration of needing 50 characters or more before the Reference Check kicks in means that most of the edits asked in the question will not have the Reference Check triggered. Further more, it is for newcomers with <100 edits, therefore it won't be presented to a majority of registered editors.
Qn: Must Visual Editor be the default editor for this to be deployed?
While the functionality is available through a JavaScript switch or through a query parameter, Edit Check is meant for newcomers. If it is not set as default editor, the effacies of Edit Check will definitely be reduced.
Having the user pick whether they want to use visual editor or wikitext editor their first time editing a page (the status quo) seems reasonable and it wouldn't hurt to leave that alone. Perhaps we should just RFC deploying edit check, and leave the visual editor issue alone? The two issues don't seem as strongly linked as I first thought. –Novem Linguae (talk) 06:16, 12 August 2024 (UTC)[reply]
If Edit Check can be deployed without changing the default or not status of VE, it would probably sail through any approval process. If it works, then later someone will be able to pull up stats saying "New editors using VE put references in 80% of their edits but those using wikitext only put them in 15%" or similar to inform that second issue. CMD (talk) 06:45, 12 August 2024 (UTC)[reply]
I should also add that the other target audience is anonymous editors. Right now the experience is as screenshot. This may be a subpar outcome for Edit Check if the primary CTA button is 'Start editing', and the anon/new editors continue to edit in source editor.
As for the statistics of how many new editors are using Visual Editor now, this is one which Foundation staff can help to answer since we do not have the access to user data. – robertsky (talk) 09:54, 12 August 2024 (UTC)[reply]
That information could be gleaned from an appropriate query, since Visual Editor tags its edits. quarry:query/84486 has the first edit for accounts registered in the first half of 2024; something similar and significantly less complicated could probably check for the "Visual Edit" tag. It would be a bit more difficult to include unregistered editors, but a basic usage ratio should be possible to estimate using public data. Folly Mox (talk) 10:32, 12 August 2024 (UTC)[reply]
@DLynch (WMF), I believe these stats are on a Superset dashboard. Can you pull them? If memory serves, there's one query for the first five edits and another for the first 100, but I don't know if one is set up for the first edit alone. WhatamIdoing (talk) 22:40, 13 August 2024 (UTC)[reply]
Edit check will work the same way for VE editors whether or not VE is default. Either way, any usage stats will be within VE users. The message given to anonymous editors who click edit, and the default or not use of VE, do not affect Edit check outside of absolute usage numbers. Generally for new features we have adopted small trials rather than immediate maximal pushses, so in that respect the current VE setup is more a benefit than an issue. CMD (talk) 11:42, 12 August 2024 (UTC)[reply]
@Chipmunkdavis, if the community thinks that an intermediate step to trial out this among the newcomers who enable Visual Editor first is required, we should explore the idea. This may simply mean that window.MWVE_FORCE_EDIT_CHECK_ENABLED=true; or the query parameter should be set in MediaWiki:Common.js (and maybe MediaWiki:Mobile.js as well), of course with account restriction criteria being set to limit the force enablement to newcomers of <100 edits.
letuserEC=mw.config.values.wgUserEditCount// wgUserEditCount: null for anon editors and non null value for registered editorsif(userEC===null||(userEC!==null&&userEC<100){window.MWVE_FORCE_EDIT_CHECK_ENABLED=true;}
I don't see how enabling edit check is an intermediate step, unless the plan is to later expand it to <500 or <1000 edits? CMD (talk) 03:42, 15 August 2024 (UTC)[reply]
It is intermediate step to see if Edit Check on enwiki does encourage an uplift in new/anon editors who are using VE adding content with references. Dependent on the result, we then can determine if it is beneficial to have VE to be the default editor with respect to Edit Check. – robertsky (talk) 05:30, 15 August 2024 (UTC)[reply]
@Robertsky: respectfully, I understand you've personally operationalized Edit Check deployment as involving making VE the default (which it may be recalled I thought was already the case), but these are two separate things. Linking them muddies the proposal and gives the impression of an agenda.I'd love for Edit Check to be enabled on this project, not necessarily for the initial check of adding a reference to a chunk of sufficiently long text (which sounds like a fuzzy test), but for all the stretch goals we could add to it for giving immediate feedback about identified categories of problem edits.Very little opposition should be expected if you disentangle all the Visual Editor stuff from this proposal, and if you wait until more kinds of checks are implemented – the kinds that save experienced editors from making the same kinds of corrections to newbie mistakes over and over – I think you'll see strong support for making Visual Editor the default when that separate question is revisited sometime down the line. Folly Mox (talk) 10:47, 16 August 2024 (UTC)[reply]
@Folly Mox you are mistaken that I am involved in the operationalizing of Edit Check with VE. I simply come across the feature and think that it is a good idea to have it enabled. Of course, there is also a strong desire to set VE as the default, but I am pragmatic. The immediate personal aim is to have Edit Check enabled and then we see if it is really beneficial for the English community. – robertsky (talk) 14:21, 16 August 2024 (UTC)[reply]
I must not know how to use the word operationalized correctly, which is actually something of a relief 🙃 I was trying to describe a comment of yours above where you explained the need for Visual Editor to be the default before the deployment of the functionality is considered complete. Anyway, glad you're embracing the stepwise pragmatism. Should be an easy pass for the simpler "enable Edit Check" proposal. Often mistaken, Folly Mox (talk) 17:58, 16 August 2024 (UTC)[reply]
The likelihood that newcomers will include a reference the next time they add new content
And while we are confident that enabling the visual editor by default for people who are new will have a net positive impact on volunteers across experience levels, the idea @RoySmith, @FollyMox, and @Whatamidoing raised about decoupling the decisions to enable the Reference Check and VE for newcomers and people who are logged out seems wise. [i][ii]
Reason being: doing so, as I think @CMDput well, seems like a relatively lightweight and low-risk way for us to work together to:
Further, as @CMD, @Thryduulf, @RoySmith, @Novem Linguae, @Shushugah, @Folly Mox have mentioned [iv][v][vi][vii][viii][ix], it sounds like there are some facets of the reference experience that would be worth us talking together in more detail about.
The Link Check evaluates all external domains people attempt to link to against the globally-defined meta:Spam_blacklist and the locally defined, en:MediaWiki:BlockedExternalDomains.json and MediaWiki:Spam-blacklist lists.
The Reference Reliability Checks evaluates the references people attempt to cite against the same local and global lists mentioned above.
Zooming out, I think you all are in the best position to decide what you think the most effective deployment sequence here is. And please know: the Editing Team is ready to support you in what you decide.
Alright, I think this is a good place for me to pause.
Please ping me as new questions about Edit Check and/or VE emerge so that I, or another member of the Editing Team, can try to help.
In the meantime, we're going to continue following this conversation and will chime in when we think there is helpful information we can offer.
iii. We'll be able to filter Special:RecentChanges for edits made with Reference Check. You can see this in action at wikis like fr.wiki, es.wiki, and ar.wiki where Edit Check is already enabled.
x. Please boldly add tickets/issues as you see fit
xi. There is an open task the Editing Team will soon address to ensure each time the Link and Reference Reliability Checks are activated, a log entry is recorded in Special:Log/spamblacklistPPelberg (WMF) (talk) 21:11, 16 August 2024 (UTC)[reply]
@Robertsky, hi – would it be accurate for me to understand you as asking the following questions?
What steps would we (volunteers) need to take to activate the Reference Check at en.wiki?
How might we (volunteers) go about configuring the Reference Check? E.g. whose edits has the potential to activate Edit Check, where references are placed (before/after periods), the sections Reference Check should ignore edits to, etc.
Assuming the above are accurate, to activate reference check at en.wiki you all would need to:
Ask us to turn it on
Adjust the configuration on-wiki to reflect your preferences (e.g. example of frwiki’s ignoreSections)
And the Editing Team would need to then deploy a configuration-change patch to enable Reference Check on en.wiki.
Call me wary for a number of reasons. First off is the false claim (also posted at the linked Mediawiki page) that Visual Editor must be the default to deploy this, or the later made implication that it makes no sense to deploy this without making VE the default. If these are coupled in this way, with the bigger change used as a prerequisite for the smaller one, then it is a hard no.
Then there is my last (in a long line) experience with a tool that had been tested or even deployed elsewhere, and worked oh so well (makes me thing of Flow, may it rest in peace). A year ago, we were asked to help with a new tool for the Android App[5]. We were told that "During initial evaluation of the model, it was preferred more than 50% of the time over human generated article descriptions. Additionally, Descartes held a 91.3% accuracy rate in testing." and that it had been succesfully been tested in 15 languages already. When we actually tested, it turned out to be very, very buggy and not usable at all. The result was that in August they posted "We’ve officially received grades for all languages and are now finalizing analysis. We will share the outcomes in next month’s update as well as our recommendations for next steps based on the experiment." and then crickets. So from an A/B tested in 15 languages, successful tool with 91.3% accuracy rate to an abandoned project after one short test by enwiki.
And then I tried to test this new tool here. I added a paragraph of text without a source, published, and got the "add reference" pop-up. Choose "yes", got presented with the automatic reference option by adding a title, typed "Lord of the Rings", no luck, so tried "manual". Click on "Book", and get "thank you for adding a citation!" even though no citation is added. Same result if I manually try to add a website or anything. Perhaps it works in real life, perhaps not, but this certainly doesn't give much confidence. Fram (talk) 13:39, 13 August 2024 (UTC)[reply]
@Fram You may see it as a false claim, but it may simply that for the end goal of Edit Check to encourage better content submissions among all anon and newly registered editors can be met by having VE be the default editor.
Your experience in testing out new tools certainly tempers one's expectations on the viability of tools on the platform. With respect to using AI to generated short description, I would also have similar reservations (my cautious approach to/use of AI is known), and still I have to say that it is an unfair comparison given that we are not expecting 91.3% of the new editors to give references. The A/B test in the impact report shows a more modest uplift of ~x2 inputs. Of course, further detailed analysis on a roll-out (in whatever form) on a trial basis can be made if we can tap on the existing tags (i.e. possible unreferenced addition to BLP) or edit filters or even sorting through the raw data.
With respect to the patchdemo wiki, maybe a more updated wiki mirrors better the current real world setup? The demo was generated back in June 2023, more than a year ago. I would have expected bugs and issues between then and now. Furthermore, it might be a patchdemo for limited use? i.e. to show partially the progress of the work? When testing directly on here in enwiki (until before publishing the edit), the reference are being added as a citation be it automatic or manual mode. – robertsky (talk) 19:05, 14 August 2024 (UTC)[reply]
If you insist that statements that VE must be made the default for this isn't a false claim, then I think we're done discussing this. And I see no reason to trust the WMF on any test results, considering that coincidentally just now they posted the results of that other software thing I mentioned above:
" By the time most of you provided feedback the experiment was already completed, and we already received support from some of your fellow experienced editors of English Wikipedia ". Yeah, right, like you posted in the "January update" which you posted in, er, August. And which is completely unverifiable, is based on a very small number of edits apparently by unknown "experienced" editors. They claim on that page that "If users that see the treatment do not select a suggestion more than 50% of the time after viewing the suggestions, we will not expand the feature". Let's see:
How often were Machine Suggestions Accepted, Modified or Rejected?
Edit type
% of Total Machine Edits
Machine suggestion accepted
23.49%
Machine suggestion modified
14.49%
Machine suggestion rejected
62.02%
So why do they plan to continue with the feature anyway? Same as always, I guess, features aren't abandonded no matter how bad, no matter which promises were made, until after (usually) enwiki or dewiki find out how bad they really are, and even then only after an unnecessary, unwanted clash with WMF has been had and mutual distrust gets cemented for another 10 years. So yes, I don't trust WMF test results, I don't trust WMF promises, I don't trust WMF false claims and those defending them, and I don't support a rollout of such features without much better, verifiable (by us) testing or with added "requirements" which aren't needed but pushed by the WMF anyway. Fram (talk) 08:41, 16 August 2024 (UTC)[reply]
I don't support a rollout of such features without much better, verifiable (by us) testing sure. let's test Edit Check out, as what I have said in my previous replies to others. – robertsky (talk) 16:43, 16 August 2024 (UTC)[reply]
Let's test it by first providing us with a correct test environment. Sending editors to a test environment which doesn't reflect the actual environment is useless. Step 1: test if it is technically working. This should happen on a testwiki, not a live wiki. This is not an unnecessary step, there have been too many rollouts of supposedly ready new software addons which turned out to be very, very buggy and were not at the beta-stage but at some pre-alpha stage. Step 2: after approval from enwiki, do a limited test on enwiki completely reviewable by editors here, not a test where we just have to believe the results in good faith, and automatically shut down the test afterwards. Step 3: after approval, do a further rollout (larger test or full rollout). For this, we are not at step 1 yet. Fram (talk) 11:13, 19 August 2024 (UTC)[reply]
It wasn't until about five minutes ago. Beta was left with an extremely-restrictive configuration since about April as a result of some validation testing our QA was doing for that configuration process. Specifically, it would only activate the edit check if your account had less than three edits made -- though you could have tested it as an anonymous user to get around that.
I just reset the config file to the defaults, so right now it'd be fair to test it there. I can also adjust any of the values if you want to see what the experience is like.
One thing that's not obvious from the config if you want to test it is that the "add a reference" check will only trigger when you add a completely-unreferenced new paragraph. DLynch (WMF) (talk) 03:51, 29 August 2024 (UTC)[reply]
Besides Beta Wikipedia, if anyone prefers an English-based example can have a look at simple.wikipedia.org. It is already deployed there and anyone can monitor the changes made when References check is shown to the user, as all edits are tagged (including rejections).
Reference check is deployed at all Wikipedias but 8. It is not deployed at these wikis because we haven't yet informed them that it is an available option. Trizek_(WMF) (talk) 15:37, 29 August 2024 (UTC)[reply]
For an example at greater scale, I believe French Wikipedia is the biggest wiki with it enabled (#3 in edits). It's a bit trickier for native English speakers to judge the quality of the edits produced there, admittedly, but looking at the revert rates should be easy enough. DLynch (WMF) (talk) 06:05, 30 August 2024 (UTC)[reply]
Thanks. So, looking at the most recent 50 edits at Simple where editcheck was activated, it was declined 39 times, 4 times it was used but the edit reverted, and among the other edits where it was supposedly used we find cases without any reference either[6] or referencing Wikipedia[7], or of course a copyright violation from a Wordpress blog[8]. That's not really an impressive result... Fram (talk) 07:10, 30 August 2024 (UTC)[reply]
And at the French Wikipedia, 34 out of 50 were rejected, some others reverted (again e.g. for using Wikipedia as a source), others supposedly used the tool but didn't add a reference anyway[9][10]. This seems close to the results at Simple, and again shows no improvement over the baseline you gave at Mediawiki[11]: "Of all the new content edits newcomers make across Wikipedias, 12% of these edits include a reference." When this tool gives the same results, but also means that many more people are now confronted with a popup they don't want, it doesn't seem like a welcome change. Fram (talk) 07:22, 30 August 2024 (UTC)[reply]
Thank you for highlighting that 12% of users add a citation spontaneously, with no prompt to add one. When Edit Check is shown, you observed at Simple Wikipedia that 39 edits over 50 are declined. It means that 11 edits lead to a citation being added. If I'm not wrong, this sample shows that 22% of users now add a citation because we provide a reminder. I think +10 qualifies as an improvement.
Using recent changes and the current flows of edits, I took a larger sample set than the 50 last edits to find the number of Edit check declined edits. I also looked at more wikis. This gives me 309 declines over 500 edits at Simple, 267/500 at French, 197/500 at Spanish, 192/500 at Portuguese, 170/500 at Chinese, 175/500 at Arabic Wikipedia. The percentage of declines decreases, leading to more citations be added, respectively 38.2% (+26.2 points compared to the number given previous paragraph), 46.6%, 60.6%, 61.6%, 66% and 65%. What would be the percentage for English Wikipedia? Let's test it for a given period of time and figure out.
Regarding reverts, let's not forget that References check is an encouragement to add citations. We assume it is for good faith users. Users who have no intention of adding one will not add one. But we now have a good number of users who now add a citation, something never considered firsthand. References check will be improved and some minor issues identified will be fixed. I'm glad that you mention a copyright violation, because the Editing team is working on this as a new check.
Please read what I wrote. "When Edit Check is shown, you observed at Simple Wikipedia that 39 edits over 50 are declined. It means that 11 edits lead to a citation being added." No, as there were cases which weren't tagged as "declined" but didn't include a reference anyway. Of the 50 edits, I think 4 were actually acceptable additions of a reference (without checking in detail). That's 8% of acceptable reference additions with this tool, while 78% of edits confronted the editors with this popup and were declined, and the other 14% were either unacceptable edits or references, or people who didn't decline the popup but didn't add a reference anyway. Please, you can't simply look at the number of declines and think that the remainder is references being added, it's easy to check some of those to see that this isn't true[12][13][14]... Fram (talk) 11:17, 30 August 2024 (UTC)[reply]
Proposal: Create quizzes on Wikipedia
I’ve always been disappointed that Wikipedia doesn’t offer this feature and would love for it to be put in to Wikipedia. Since we have AI around, we can easily create quiz questions on a larger scale for the most popular articles. We could start by implementing quizzes on the main page and going from there. I understand that Wikipedia is an encyclopedia, but the question I came here to answer is that is it just an encyclopedia or is it more than an encyclopedia that includes features that are not just for encyclopedias as a general learning site. Britannica has something similar and I think it would be great not to copy everything it does, but have it as inspiration for creating quizzes. I would like to discuss if Wikipedia should have extra features that make the website more enjoyable rather than just reading and editing. I hope you will consider this suggestion. Interstellarity (talk) 21:33, 10 August 2024 (UTC)[reply]
The NY Times runs a weekly quiz, with questions about the previous week's news stories. It's kind of fun (even if I rarely score above 50%). My guess is if you pitched this to WP:SIGNPOST they'd be happy to run it. On the other hand, there's absolutely nothing stopping you from doing it in your own userspace and announcing it on WP:VP. If people like it, they'll vote with their mouse clicks.
I'm not too on board with including quizzes and other gadgets like this, that are a pretty heavy weight to maintain (especially with having to review all the AI-generated quiz questions), while not really being encyclopedic and probably being an uncomfortable distraction for a lot of readers (including me). However, having them on the Signpost would be cool, although I don't think them being AI-generated is a good thing. On a larger scale, I'm afraid of "feature bloat" where the core thing (here, the encyclopedia) gets buried under layers of gimmicks, ultimately making it much less convenient and not necessarily more enjoyable. Adding more for the sake of adding more isn't necessarily a good thing. Chaotic Enby (talk · contribs) 22:43, 10 August 2024 (UTC)[reply]
The idea of quizzes was discussed in June 2022 and by you in March 2022. As I said in those discussions, anyone should feel free to start quizzes on a project page to establish a track record of being able to produce them regularly, and to figure out what audience exists for this feature. isaacl (talk) 04:03, 11 August 2024 (UTC)[reply]
Heh, I just looked up the March 2022 discussion (which I had long since forgotten about) and discovered that I said almost exactly what I said here :-) RoySmith(talk)14:45, 11 August 2024 (UTC)[reply]
I don't get why we need things like extensions and AI to run quizzes. Quizzes existed long before Mediawiki and AI. Just take a couple of minutes to ask a few questions each day/week/month in your user space and advertise it on one of the village pumps and/or Signpost. If the feature is popular then it can be formalised to the main page etc. Nothing will happen unless someone (most likely you) volunteers to do it. Phil Bridger (talk) 08:40, 11 August 2024 (UTC)[reply]
Wikipedia already has loads of extra features that make it more enjoyable, most of which are dramaboards 😉 The true "extra feature" that makes Wikipedia so great is how lightweight and on-mission it is. Even on a bad connection, on a slow device with an old browser, I can navigate to a Wikipedia article, and it will load the whole thing for me to read (certain restrictions apply).I don't have to stop the page loading before stylesheets are applied because it can't reach an advertising partner, I don't have to leave the tab open two minutes and go do something else while my phone wearily executes javascript routines, I just open the page and read the page, like how the internet used to be before it became total capitalism garbage.Any extra interactive features added to the default experience reduce our availability and usability for people on the lower end of computing resource / network infrastructure privilege. It feels important to preserve that equity.So I guess my position is: no, Wikipedia isn't just an encyclopaedia— it's also an online community; but also no, Wikipedia isn't a general pedagogical resource— it's pretty much just an encyclopaedia with an active editing community. Folly Mox (talk) 13:27, 11 August 2024 (UTC)[reply]
For sure! I probably could have done a better job in selecting a qualifier than the term "general" in general pedagogical resource, or maybe should have chosen different words altogether. I was attempting to communicate my personal opinion on the OP's question on whether Wikipedia is just an encyclopedia or is it more than an encyclopedia that includes features that are not just for encyclopedias as a general learning site.Folly Mox (talk) 09:47, 13 August 2024 (UTC)[reply]
Sure, why not! It's an education website. This is something many loose track of, we are in the business of a non-profit education resource. The best way to do this is start a Project and run the quizzes in project space. Once it has a following and support, which might take years and press exposure, then consider something on the front page. -- GreenC20:37, 12 August 2024 (UTC)[reply]
Oppose - this is an encyclopedia, not Facebook or TikTok. We do not need to degrade ourselves by turning ourselves into a host for social media games. --Orange Mike | Talk20:58, 20 August 2024 (UTC)[reply]
Hi everyone, sorry for responding so late. I don't check Wikipedia as often as I used to. Unfortunately, I don't have all the time in the world to be dedicating to making the quizzes all by myself. I'd be open to suggesting ideas that will help make the quizzes better. I feel that if I had help with the quizzes rather than alone (not saying I won't contribute, but I don't to put a heavy load on my editing and my personal life), I think it would be helpful to increase the chances of it being a successful feature on the site. Interstellarity (talk) 22:50, 20 August 2024 (UTC)[reply]
It's not necessary for you to do all the work, if there are other interested contributors. As the one who seems most interested in the idea, though, you are a good candidate to co-ordinate the work, or even to just create some quizzes on whatever schedule is convenient for you to try to figure out what might be a sustainable way of working. isaacl (talk) 17:32, 21 August 2024 (UTC)[reply]
...and the best way to find out who could be involved is for you to start with a few questions. I'm sure you will get people saying "I wouldn't have asked that" so you can ask them what they would have asked instead, and the second quiz will already be written. Phil Bridger (talk) 19:23, 21 August 2024 (UTC)[reply]
I think you (and Mike) are being a bit bah-humbugish here. Of course this shouldn't be an official™ part of Wikipedia, but there's no reason why someone shouldn't ask a few questions in their user space if that's what floats their boat. It will probably fail anyway. Phil Bridger (talk) 19:24, 26 August 2024 (UTC)[reply]
The proposal was to put it on the main page, so it merits being discussed (and, in this case I guess, opposed) as a serious proposal, not assumed to be automatically relegated to a userspace project (which can be done without a village pump proposal). Honestly, having it on the main page or articles directly would be bloat, but I'm down for having quizzes on the Signpost, and it would definitely be fun! Chaotic Enby (talk · contribs) 19:54, 26 August 2024 (UTC)[reply]
Improve readability of hyperlinks in Dark Mode
The current dark blue color of hyperlinks in Wikipedia's Dark Mode can be difficult to read, especially for users with visual impairments. I propose changing the color of hyperlinks in Dark Mode to a brighter, more readable color, such as yellow.
This change would improve the overall usability and accessibility of Wikipedia for users who prefer Dark Mode. A brighter hyperlink color would provide sufficient contrast with the dark background, making it easier for users to navigate and read articles both on the website and the app.
Rationale:
Improved readability and accessibility for users with visual impairments
Enhanced user experience for Dark Mode users
Consistency with web accessibility guidelines, which recommend sufficient contrast between text and background colors
Implementation:
Change the color of hyperlinks in Dark Mode to a brighter color, such as yellow (#FFFF00)
Ensure the new color is consistent across all devices and browsers
Discussion:
I welcome feedback and discussion on this proposal. Please share your thoughts on the proposed change and suggest alternative solutions if you have any. Galilean-moons (talk) 14:53, 19 August 2024 (UTC)[reply]
If there is a standard colour for links in website dark modes we should use that (for the same reason we use blue as the standard link colour on light mode). I'm not a regular user of dark mode meaning I have little direct experience, so I looked for examples. Of about 20 websites with dark modes that were highlighted as good by various discussion forum contributors, only 3 were primarily text-based, had links of a different colour to the body text when not mousing over the link and had a dark mode that I could easily find and activate. Two of them used a pale blue (#3ebcf4 and #9eb1ff) and 1 used purple (#a667e4). A couple of git hub results were people commenting/complaining that yellow is not an intuitive colour for hyperlinks. Thryduulf (talk) 19:19, 19 August 2024 (UTC)[reply]
Further, it would probably be best if the color is set in same place where the light-mode link colors are set rather than us overriding them locally. That would likely be in the skin. Anomie⚔21:31, 19 August 2024 (UTC)[reply]
Light blue is good, although cyan could also be an option. It is visually brighter than blue at similar HSL lightness levels, while a light blue (higher lightness level, i.e. adding white) isn't visually as sharp, especially if we want to make it visually distinct from purple. Chaotic Enby (talk · contribs) 23:03, 20 August 2024 (UTC)[reply]
I use dark mode and am (slightly) vision impaired. The difficulty for me is less the blue hyperlinks and more the difference between blue and purple (non-visited/visited). Gnomingstuff (talk) 18:47, 20 August 2024 (UTC)[reply]
@Gnomingstuff Yeah, unfortunately I don't expect much improvement there, especially considering how many websites style away visited link coloring entirely, forcing them to the same color as unvisited links. (Something that will always earn them a UserStyle in my browser, restoring the difference, because WTH is it with site authors just deciding that a useful browser feature isn't necessary on their site?) So I guess we should be happy there's any color difference at all.
I know at least for the light-mode skin, in the last round of design updates not too long ago, the decision was made to slightly lighten the unvisited blue, and massively lighten the visited purple. The focus was on increasing their contrast relative to the black body text (for some reason), though I pointed out that it came at the cost of decreasing their contrast with the background color, particularly in infoboxes and other non-white sections of the page, but the whole contrast-with-unlinked-text thing was a big priority for some reason. It was an unfortunate additional side effect that the change also brought the two colors much closer to each other, but I suppose contrast in particular is always a balancing act. FeRDNYC (talk) 15:00, 23 August 2024 (UTC)[reply]
A new color might be useful, but yellow seems to me to be a pretty poor choice, as it's quite an aggressive color. I think another shade of blue would be optimal, as up to now people have made things with yellow backgrounds but not with blue ones, and yellow-on-yellow situations would violate MOS:CONTRAST. — Alien333 ( what I did why I did it wrong ) 20:20, 24 August 2024 (UTC)[reply]
@Alien333 I can see the point of yellow, in that it's the complementary color to blue in many color models, and yellow links inline with white text (remember, we're talking about dark mode here) wouldn't really be that "aggressive", I don't think. I'm not entirely sure how easy it would be to detect yellow links in white text, particularly for users with color-vision impairments. Though IIUC, both the yellow/white and yellow/blue pairings would be good choices because the difference would remain completely visible to those with the most common form, deuteranomaly ("red-green color blindness").
Also, just for the record, there are a ton of blue-background elements on Wikipedia, particularly in the article space — including all of the standard infobox, navbox, and table styles. (Heck, even the standard background for inline <code>...</code> elements used to be a subtle blue, though it seems it's been changed to a neutral gray.) Yellow may reign in Talk page headers, but blue is very common elsewhere.
The prevalence of blue backgrounds on article pages is why I tried to point out that lightening the blue link text in the light mode palette was an especially poor choice, because links often appear inside those boxes, and quickly become combinations that fail the WCAG's thresholds for text contrast against background color. In dark mode, those background colors either get erased entirely, become a shade of dark gray, or (least commonly) become a much darker blue, so it isn't as much of an issue there. FeRDNYC (talk) 21:18, 26 August 2024 (UTC)[reply]
After some CSS tinkering:
Actual yellow would be nearly invisible, and certainly not legible. Some kind of inverted yellow, such as this one, could do the trick, but as long as we're going to do that we might as well just take a cyan of the same level, like that one. Also this green, maybe. I'd prefer the cyan or green because that is more logically linked to the light blue of unvisited links. — Alien333 ( what I did why I did it wrong ) 22:57, 26 August 2024 (UTC)[reply]
In the case of this ABC News, there are hundreds of articles with broken links, such as LGBT rights in Afghanistan.
It is even more common for it to omit a link to the "work", either displaying it in plain Wikitext or not at all. This excludes important contextual information, and goes against MOS:UL which says that proper names that are likely to be unfamiliar to readers, which would include news sources as few have global recognition, should be linked.
In the case of this ABC News, there are thousands of articles with missing links, such as Joel Reddy.
Following a discussion with Robertsky, I proposed a bot that would be able to rectify one or both of these issues, as well as add additional information to the citation template that can be determined from the URL or other content already in the template, such as the publisher or publication location.
To minimize impact on watchlists, it can be configured so that only some errors or omissions will trigger an edit, with the rest being done only if the article is already being edited.
I am raising this in the community now to determine whether the community believes that this task is worth completing.
In addition, the bot uses a configuration file that I would need the communities help to expand. Currently, it addresses issues with the following sources:
Please provide details for the other sources that you wish to see corrected by leaving a comment on the configuration talk page, or if you are sufficiently familiar with JSON to understand the configuration file by editing it directly. BilledMammal (talk) 09:02, 25 August 2024 (UTC)[reply]
Overall, I support more frequently linking publication names. For an article that doesn't use them, though, it should be kept consistent. Sdkbtalk22:41, 25 August 2024 (UTC)[reply]
I’ve already touched on this, with the above reference to WP:UL, but to address it in a little more depth in regards to consistency:
First, I don’t think we want to follow the pattern of the majority of the article, as in most cases they will be unlinked solely because RefToolbar doesn’t add links rather than because of any deliberate editor choice.
Second, a sufficiently expansive configuration file will be able to switch from unlinked majority to linked majority.
However, I would be able to alter the program to not include links under certain circumstances if that is what the community would prefer. BilledMammal (talk) 23:19, 25 August 2024 (UTC)[reply]
add additional information [...] such as the publisher or publication location. If that's done, it should be VERY selective, erring on the side of omission. Cites for The New York Times do NOT need to show that the publisher is A. G. Sulzberger or that the publication location is New York City. Et cetera. Bots should reduce work for human editors, not create work for them; we have too much of the latter already. ―Mandruss☎22:44, 25 August 2024 (UTC)[reply]
New York Times is actually a very convenient example, as it is already in the configuration file.
Not only will it not add the publisher or publisher location, it will actually remove them if it is already editing a page, in accordance with the specifications at {{cite news}}BilledMammal (talk) 23:09, 25 August 2024 (UTC)[reply]
People keep becoming confused because they think clicking "Publish" means "Move my changes to article space". But they should think that! – that IS what "Publish" must mean to any reasonable person in their situation, and there's no good reason for them to think it might have the meaning it currently does. "Publish" means to make something generally available and accessible, to put it on public display – it doesn't mean "commit changes to upstream server" (or whatever is actually happening), and it certainly can't mean that to the average person editing Wikipedia.
The only potential good reason I can see to keep it as it is would be "We deliberately keep this process confusing" – and I don't agree with that kind of policy. TooManyFingers (talk) 17:09, 27 August 2024 (UTC)[reply]
I can see your point, but as far as editing Wikipedia goes, anything you 'publish' is both available and accessible by other people. Relabelling as 'save' could likewise be easily misunderstood. AndyTheGrump (talk) 17:17, 27 August 2024 (UTC)[reply]
Wikipedia's lawyers wanted the button changed to say "publish changes" to emphasize that all edits to any type of page are public. "Save" does not do that. 331dot (talk) 17:22, 27 August 2024 (UTC)[reply]
I think this is a case of 'fixing the wrong thing'. What is wrong is Drafts. It is an incomplete feature because it's just a public page in a public thing that isn't really 'public'. It could be fixed by making these particular cases "Publish draft" or something the like however, making every single control in MediaWiki super context specific is a bit difficult (it is designed on purpose to be a generic system after all). —TheDJ (talk • contribs) 19:00, 27 August 2024 (UTC)[reply]
Someone creating a draft has to grapple with several things...
Writing some text in their draft
Saving (which is published publicly; which means both legally it can be reused/edited/scrutinized)
Even with all that, they need to transclude {{subst:submit}} which is when it is really submitted for review...and still then it's not published in sense of being visible in Mainspace (not to be confused with Wikipedia namespace)
Every control being context specific, sure. But having the text for a few select UI elements being namespace-specific (or namespace-overridable) may not be the worst idea for a future WMF developer project. ― novov(tc)12:36, 28 August 2024 (UTC)[reply]
Just a general comment: even very common words do not mean the same thing to everybody. A change you think makes things clearer may make things more confusing for someone else. It's one of the areas where we have to find a rough consensus, using language that makes general sense to most users without leading too many astray. Discussions like this are how we figure it out. Donald Albury21:03, 27 August 2024 (UTC)[reply]
We're unlikely to find a word that can't be misinterpreted. "Save" is more ambiguous than "Publish", in my opinion. Perhaps "Commit". The absence of anything else that might mean "put this in the page" might be a clue. But, ultimately, any uncertainty lasts as long as it takes to try it and see what happens. Are we getting a lot of complaints from newbies who can't figure out what to do? If not, it's the proverbial solution in search of a problem. People keep becoming confused - Show me, please. Operative phrase is "a lot". A few is not enough. ―Mandruss☎23:07, 27 August 2024 (UTC)[reply]
But what you write is public, even in draft space. That's the whole thing. The only potential good reason I can see to keep it as it is would be "We deliberately keep this process confusing" – and I don't agree with that kind of policy. Come on, that's an obvious strawman. The fact that the WMF already weighed on it, and that people gave it many thoughts before making this choice, should tell you there is probably a less dishonest reason for it. Chaotic Enby (talk · contribs) 23:09, 27 August 2024 (UTC)[reply]
We do cause confusion when we say (accurately) that every edit is 'published' but also use the verb 'publish' to refer to moving drafts to mainspace. But as others have said, the problem lies with the drafts, which is a poor choice of words to begin with (people don't usually publish 'drafts'). I've never heard or been able to come up with a better phrase, though. – Joe (talk) 08:39, 28 August 2024 (UTC)[reply]
@Joe Roe A simpler change would be to change verb for move from Draft to Article as "Promote" to indicate it's a positive thing, without touching the thorny legal/technical side of publish. It's celebratory and fits other descriptions of being declined/rejected. The namespace bit is an implementation detail. ~ 🦝 Shushugah (he/him • talk) 11:55, 28 August 2024 (UTC)[reply]
I think it important that editors understand that when they click the button, they are “publishing” whatever they have written. Where it is published does not matter. It may be published in Mainspace, in Draftspace, in Talkspace, in P&G space, etc. … but it is all a form of “publication”. Blueboar (talk) 12:16, 28 August 2024 (UTC)[reply]
Long story short, it's gonna stay "Publish" - lots and lots and lots of prior arguments about this were already made, and the WMF is going to enforce that. The OP thesis is that editors are confused when editing in draft space. We could add additional guidance to Template:Editnotices/Namespace/Draft - which appears in the edit window for all pages in the Draft namespace if there is special guidance needed. — xaosfluxTalk13:33, 28 August 2024 (UTC)[reply]
And additionally... complicated processes will always cause confusion, not matter how much text you throw at the user. The whole process only exists because we didn't want Pending Changes/Flagged revisions in main space. Flagged revisions would have probably been simpler to understand for the users, even if it would have been more annoying to us editors. Its always a balance. —TheDJ (talk • contribs) 16:03, 29 August 2024 (UTC)[reply]
The Foundation has developed a new tool at Meta:CampaignEvents which is used by other editions of Wikipedia. Anyone who organizes an Edit-a-thon knows the event management tooling is quite limited and requires lot of behind-the-scene knowledge for promotion of events.
If you believe English Wikipedia should try this feature out, please support this proposal. It does not remove any existing options or require people to use this over other forms of event management. In order to set this up, we need to establish consensus to try it out and then file a Phabricator ticket request, which I am happy to do. See the recent talk from 2024 Wikimania about it here on Youtube and notes from the same session. Here are the slides.
In the past I organized edit-a-thons using the Outreach Dashboard which helped with tracking contributions, but not collaboration between editors (see here). I am also happy for English Wikipedia to try tooling that is used by other language editions of Wikipedia and contribute insightful feedback in order to make these tools useful. ~ 🦝 Shushugah (he/him • talk) 22:24, 29 August 2024 (UTC)[reply]
Has the support team been looped in on this? There are 3 projects using so far, and it would be useful to know any outstanding issues. Also note, this requires a permission group (c.f. meta:Meta:Event_organizers) that we'd have to determine how to deal with. (some options: WP:PERM, autopromote). — xaosfluxTalk22:44, 29 August 2024 (UTC)[reply]
The description says "enhance the management and visibility/discoverability of events within Wikimedia". That certainly sounds like a good thing.
But going off on a tangent, as a checkuser, one thing I'd love to see is some way for an event coordinator to register the IP address(s) which are going to be used at the event, and having that be visible in the checkuser tool (@Dreamy Jazz). One of my suckiest CU experiences was blocking a whole pile of socks only to discover after the fact that what I really did was stomp on a perfectly legitimate "Learn to use Wikipedia" event for 13 year olds. There would be much awesomeness if a notification about that could come up in the tool. RoySmith(talk)23:06, 29 August 2024 (UTC)[reply]
Thanks for bringing this up. Regarding this tool, what are the specific implications for en.wiki? Based on Meta:CampaignEvents, it currently has two tools, Registration and Event list. I would assume we would not want Registration here, as that seems to involve the creation of a new namespace (Event:) and is a task better suited for Meta. Conversely, the Event List seems like something people may want to casually have access to, and thus locking it behind the Wikipedia:Event coordinator perm (ie. at the same level as being able to generate unlimited new accounts on a single IP) feels limiting. CMD (talk) 06:28, 30 August 2024 (UTC)[reply]
You can directly edit as a user this event: Meta:Event:Sandbox/Shushugah/Testing without any special permissions on Meta. And same would be true for English Wikipedia if approved here
We should have the Event namespace in English Wikipedia. While only users with event creator can "register" the event, any editor can still edit the content and description with project updates. To-do lists etc..
Meta:Main might be better suited for multi-wiki events it also requires advanced knowledge of Help:Interwiki syntax and is not very new user friendly. Copying and pasting a list from enwp project page to Meta wouldn’t simply work and would require juggling two different accounts. ~ 🦝 Shushugah (he/him • talk) 15:00, 30 August 2024 (UTC)[reply]
Is there an advantage to adding the new namespace on en.wiki in the days of unified accounts when new users can post on meta too? CMD (talk) 13:57, 31 August 2024 (UTC)[reply]
I mentioned a few cons, namely that wikilink templates would break, templates are not usable across different Wikis, the watchlist is separate for each. For advanced users this might be acceptable but for new users explaining difference between Meta and enWP would be a very high hurdle and counterproductive. ~ 🦝 Shushugah (he/him • talk) 14:01, 31 August 2024 (UTC)[reply]
Hello, everyone! My name is Ilana, and I’m the product manager for the Campaigns team, which developed the CampaignEvents extension. Thanks for bringing up this topic, @Shushugah, and thank you for your responses and feedback, @Xaosflux, @Pppery, @RoySmith, and @Chipmunkdavis. I’ll respond to the questions and comments so far below, and I’m happy to respond to any other questions that come up:
Event Registration was first released to Meta-Wiki in November 2022. It has been used in 600+ events with over 10k participants. The Event List was released in April 2024, and we’re now expanding it to feature WikiProjects as well (see T368115). Invitation Lists is our newest feature. It is testable on the beta cluster (see video demo), and we’re planning to release to Igbo Wikipedia & Swahili Wikipedia soon.
The extension has two sides: an organizer side and participant side. The participant side requires no special rights for access. The organizer side requires the Event organizer right for access. Wiki admins set the criteria for and manage the right. We are open to comments on how the right can be configured or expanded. We love the idea of bundling it with the Event coordinator right.
The extension comes with two new namespaces: event and event talk. You can read our rationale for why the namespaces were created. Overall, we think that there are many advantages to keeping the two namespaces, but we’re open to other ways that communities may want to define event pages. So, we are curious to hear what others think on the topic!
In the near future, we are hoping to integrate Community Configuration (T370829). This way, wiki communities can choose to turn on the extension, and they can choose which tools to turn on and how they should be configured.
I have a question for you all: How do you feel about my team inviting some organizers and/or users of the CampaignEvents extension into the conversation? Perhaps they can provide some more context. Since the extension is enabled on Meta-Wiki, we already have users from many different wiki communities.
Is there a reason the invitation list is not listed as one of the features alongside the Event Registration and the Event list on the main meta page? Anyway, if the features are separately toggleable, it sounds like enabling the overall extension is only beneficial and separate discussions can be had on the existing and upcoming features. CMD (talk) 07:50, 1 September 2024 (UTC)[reply]
Temporary override of existing protection, falling back after expiration
I have often wished that there was a feature in the page protection options to assign a different protection to an already-protected article for a short duration, and when that different protection expires, it falls back to the original protection level. Whatever the current protection level is, it resumes when the temporary override protection level (which could even be "none") expires.
Use cases:
Content dispute between editors on a semiprotected article: I'd like to override that for a week and apply a higher protection (ECP or full as appropriate), and when it expires, the semiprotection resumes and runs it course as usual.
The current behavior is for the article to become completely unprotected at expiration.
Experimental unprotection: RFPP requests to unprotect could have the new protection level (none) override the current protection on a trial basis for a finite duration, after which the original protection resumes. This might be related to a past discussion Wikipedia:Village pump (proposals)/Archive 38#Temporary lifting long-term semi-protection of featured articles, but I would like to see just a general temporary override feature available for any article.
We currently have a pseudo-situation like this with PCP. Any protection other than "none" overrides PCP and when that protection expires, PCP goes back into effect. I am asking for temporary overrides to any protection level regardless of what it is. ~Anachronist (talk) 05:49, 31 August 2024 (UTC)[reply]
Not sure how technically feasible this is, but the first use case definitely happens all the time, and often leads to articles becoming unprotected that really ought not to be. So this is at minimum seeking to address a real problem. Sdkbtalk05:53, 31 August 2024 (UTC)[reply]
That would work too, except for the case of experimentally unprotecting, but that is low-priority compared to the first use case I described. I wasn't aware of that bot. I hope it can be approved. ~Anachronist (talk) 17:06, 31 August 2024 (UTC)[reply]
This appears to be a software feature request, mostly covered by phab:T41038. As such, it is not something that we can implement directly here on the English Wikipedia. Workarounds with a bot as described above are the most we can try in the absence of new software. You are welcome to follow, comment, or provide patches related to T41038. — xaosfluxTalk12:29, 1 September 2024 (UTC)[reply]
I don't know where to ask this, but why is it when I logged into Phabricator as my username "Anachronist" to make a comment, the username appears as "Amatulic", which was my username many years ago? ~Anachronist (talk) 16:49, 1 September 2024 (UTC)[reply]
@Anachronist, Phabricator accounts are separate from Wikimedia accounts, although the login process is now unified with Wikimedia accounts. So you likely made a Phabricator account under your old username many years ago, and attached it to your Wikimedia account, but while you updated your Wikimedia username, the Phabricator username has stayed the same. You can probably update it there too to keep it in sync. Sdkbtalk19:37, 1 September 2024 (UTC)[reply]
I don't recall ever making a Phabricator account. Did Phabricator even exist in 2006? It isn't a problem, I just thought it was strange. My VRT account doesn't do that. ~Anachronist (talk) 19:44, 1 September 2024 (UTC)[reply]
Idea lab
Merging mass-created village stubs into district articles
Initial ideas, village stubs
There are a lot of mostly formulaic (though that's not necessarily bad) stubs of villages with 60-100 people that will probably never be significantly expanded, at least beyond one or two events happening there. I know that under the the guideline on geographical features all inhabited places are considered to be notable, but what if very small villages were by default merged into district articles? I'm thinking of a section "Villages" or something similar with a subheading for each village and a few sentences with the population/location (what's already in the leads). Villages that had enough coverage to need their own article would be split; it could be done based on the categories "Rural localities in X district" that already exist.
For example, Basovo and Timonovo in Valuysky District, Russia. The second has 1 event happening there, and the 1st none listed; both are very small towns with a couple hundred people. It's possible Timonovo could be expanded with a description of the event, but that would be rather WP:1E-style and deserve its own article.
I'm posting this here because I don't know the history & policy details sufficiently to put it into proposals (or the 300-vote discussions), but I wanted to see what people thought and if this had been proposed before. Mrfoogles (talk) 04:00, 15 August 2024 (UTC)[reply]
It depends on what the guidelines are agreed to. I'd say if a location only cites census tables and maps (gonna use Hashemabad, Kerman as an example), they should be merged with the above-class subdivision. All these location articles only have maps and census tables, could possibly violate geographic feature Notability. Roasted (talk) 04:22, 15 August 2024 (UTC)[reply]
I would cautiously support this as long as it was done carefully so no information was lost, was explicitly without prejudice to later expansion and excluded places with significantly more extensive articles on another language wiki. Of the three places here, only Timonovo has more information elsewhere (ru:Тимоново (Белгородская область)) but that is borderline. My ballpark suggestion would be that any article with circa two paragraphs of prose of non-census information excluding a description of it's geographical location on any language edition of Wikipedia should not be merged in without an individual discussion. I'd also say that before any merge takes place there needs to be a list of all the merges proposed laid out in a fashion easy for humans to check (separate lists or separate sections for each destination article would probably work well). Thryduulf (talk) 10:25, 15 August 2024 (UTC)[reply]
Section break 1, village stubs
I support the concept… Wikipedia should continue to cover all noteworthy geo locations, but we can be more flexible in how we cover them. Not all locations require a stand alone article to be included. Blueboar (talk) 11:49, 15 August 2024 (UTC)[reply]
The ru.wiki versions of the villages are not much longer unfortunately, and the length of the longer one comes from quite generic information that would likely apply to the district. Your method of merging to the district article sounds like one in which no information would be lost, although I would leave room for a bit more than what is currently in the leads. CMD (talk) 12:00, 15 August 2024 (UTC)[reply]
I doubt anyone will stop you but I think it's a waste of time. For some reason some editors have strong feelings about the existence of stubs vs. redirects to entries in lists but, from the reader's perspective, they're pretty much the same. I can't tell anyone how to use their time but if all the collective hours we've wasted on merging or talking about merging stubs were instead put into expanding them, the encyclopaedia would certainly be better off. – Joe (talk) 07:13, 16 August 2024 (UTC)[reply]
There's the rest of what I wrote, and if your counter-proposal is to treat the nav boxes as great article content then I don't think that's very helpful to the reader either. CMD (talk) 12:31, 17 August 2024 (UTC)[reply]
I might come to the same conclusion ("As a reader, they are not the same") but in the opposite direction: Hunting through a merged-up page to try to glean which info is relevant and which is about other villages takes up time. With a stub like Timonovo (five sentences, 75 words, five sources, plus the infobox), you know that all the information is what you're looking for, and you know that's all there is. WhatamIdoing (talk) 22:19, 18 August 2024 (UTC)[reply]
List articles don't have to be tabular data with no prose, nor do they have to be internally consistent as to whether or not the list items they contain are bluelinks or not. The GA Infrastructure of the Brill Tramway is basically a list article that contextualises borderline notable information beautifully.I should disclose that I'm strongly in favour of contextualising stubs into their container topics wherever possible. Folly Mox (talk) 16:18, 16 August 2024 (UTC)[reply]
Somehow I doubt the result it this will be a load of GA-level lists. It'll be the existing stubs, pasted in one after the other. – Joe (talk) 05:49, 17 August 2024 (UTC)[reply]
I agree that the implementation of contextualisation is likely to resemble pure concatenation, and would prefer that outcome to the status quo. JMO. Folly Mox (talk) 15:59, 17 August 2024 (UTC)[reply]
I was more thinking of a policy allowing people to merge such things if they felt like it: because there are so many village articles it's never worth it for any one person to start a discussion about merging the villages of one district, because who cares about this one random district in particular. And no one has the hours and hours you refer to to just go do it for all of them. With a pre-consensus it could ideally happen piece by piece? If there was a policy on this I might merge the villages of that district just because I ran across them, but I wasn't planning to spend 900 hrs on trying to do all of them.
As for expanding them: 60 people live in most of these village, and it's unlikely someone's written a book about most of them. Not going to say it's not a little bit of a waste of time, but having a list of villages in a district in its article seems useful: it was helpful to me finding some village list in district articles on the German Wikipedia I think when I was trying to figure something out. I think name+whatever small details exist could be somewhat helpful, if not the most important task. Mrfoogles (talk) 18:54, 16 August 2024 (UTC)[reply]
@BilledMammal put together a sample of 10,000 articles so we could try to find out some basic information about what the community's actual practices are – the revealed preference, if you would like to use that language, rather than the aspirational goals. So far, we're finding facts like these:
90% of articles have between 2 and 95 sentences, heavily skewed towards shorter articles. The most common number of sentences in an article is two. Half of articles have 13 or fewer sentences. A quarter of them have 5 or fewer.
If you define a stub as having ≤10 sentences, then 43% of Wikipedia's articles are stubs. If you define is as ≤250 words, then 41% of articles are stubs.
Half of all articles have 4 or fewer (detectable) inline citations. A quarter have 2 or fewer. Only 21% have more than 10. Having more than 20 (about 10% of them) is a statistical outlier.
Compared to longer articles, stubs tend to have about twice as many citations per sentence.
The reason I bring this up is because when we compare articles against our ideals, it's very easy to think "What garbage. It 'only' has five sentences. It 'only' has five sources. It 'only' has 75 words." We ought to be thinking "Huh, that has more sentences than 25% of our articles. It has more refs than 60% of our articles. It has more words than 16% of our articles. Maybe it's not too different from normal, actually." WhatamIdoing (talk) 22:40, 18 August 2024 (UTC)[reply]
I recently ran a new scan, of 100,000 pages, where the talk page categories are also provided. I’m not sure how to upload it yet - it’s a far larger dataset than all the others I’ve uploaded put together - but it should be helpful as it will allow us to determine which topic areas have abnormal articles.
I suspect that the size of places will vary by location. Most US census places have longer than median articles (e.g., Mulberry, Kansas has 25 refs and almost 1,000 words) but were largely written by bot/script.
I totally support the idea to reduce village stubs. here is one possible way to do so; make articles consistently named "villages in ___ County", or "Villages in ___ Oblast," or "Villages in ____ Arrodinsement," and so on, and make these into list articles.
I think that the fact that these articles are close to the status quo doesn't necessarily mean they wouldn't be improved by merging them, though. The point is that they have very low potential (only have 50-200 people or so), which is not true of all stubs. Mrfoogles (talk) 17:20, 20 August 2024 (UTC)[reply]
Some time back (we're talking at least 15 years), I wanted to have an article on every inhabited place in Ethiopia. This aspiration was foiled by the fact that information on even sizable towns in that country can be hard to get ahold of -- at least at that time. In many cases all the information I had about the village was the population statistics. Moreover, at the time I was not interested in adding to the large number of stubs on Wikipedia; this is why you'll find a lot of red links in those articles.I considered addressing this problem exactly as proposed above: create a section in the article that provided the stats on those towns/villages. However by that point I was tired of working on Ethiopian topics & decided to move on. -- llywrch (talk) 18:18, 27 August 2024 (UTC)[reply]
Rename and/or Combine Content Assessment classes
Currently Content Assessment is named arbitrarily at Featured, A, Good, B, C, Start, Stub. Looking for ideas as to what A, B, and C classes should be renamed? And if B and C classes were combined into one, what would that be named?
I would merge B, C and Start together and call them all "start". Anything checking criteria of article like DYK would not solely rely on WikiProject content assessment anyways. ~ 🦝 Shushugah (he/him • talk) 21:51, 18 August 2024 (UTC)[reply]
I’d definitely be opposed to lumping B and Start into the same bucket, the resulting rating would cover a really wide range in quality. There is a difference between “often not used and superfluous in many cases” and “totally unnecessary”. ― novov(tc)01:57, 19 August 2024 (UTC)[reply]
The names aren't really arbitrary. They're basically American letter grades, plus two existing review processes (FA and GA), the separate {{stub}} system, and a squeamishness about rating anything with a "bad grade". C is a relatively recent innovation; back in the day, it was realistically Stub–Start–B, and anything else required extra effort. In 2008, editors basically decided to divide the Start class into two groups (C and Start).
As a first approximation, we started with:
Stub: Less than ~10 sentences.
Start: More than 10 sentences but not yet B-class.
B class: Meets all six specified criteria.
and we decided to have:
Stub: Less than ~10 sentences.
Start: More than 10 sentences but still kind of short and not B-class.
I would consider using something other than the A-B-C convention. I noticed that an inordinate number of editors were adding A class to India articles. Apparently people think it's like self-grading a homework assignment. I think A-class should either become a universal process like GAR or FAR, or go away entirely. That I know about, only WP:MILHIST, WP:USROADS and WP:HIGHWAYS have a process to review A-class articles. WP:WikiProject Biography and Wikiproject Cyclones had a process, but the latter turned out articles that in no way represented the best of Wikipedia. Schierbecker (talk) 02:40, 19 August 2024 (UTC)[reply]
Yeah I agree. Given how few WikiProjects actually have a process for reviewing A-Class articles and how difficult it would be to create them given how many of them are small and/or semi-inactive. Standardising it to a universal process or eliminating it would probably be better. Although there is always the idea that "it's there if people need it" DimensionalFusion(talk)09:04, 19 August 2024 (UTC)[reply]
What's A class? Why does it even exist? I always thought there's B class, better than that is Good Article, and the very best is Featured Article. A class seems to have no good place in this scheme of things. Gawaon (talk) 11:23, 19 August 2024 (UTC)[reply]
A class exists because there is a broad gap between GA (B class with a review by a single editor - a low grade) and FA (A class with a comprehensive review by at least three editors - a high grade). B class is the minimum acceptable standard, which is why it would be destructive to merge with lower classes. Starts and stubs are unacceptable quality. FA is not generally available. Our very best is A class (comprehensive review by at least three editors from the project). Hawkeye7(discuss)11:16, 21 August 2024 (UTC)[reply]
A class (comprehensive review by at least three editors from the project) isn't necessarily correct. The majority of WikiProjects don't have any specific assessment criteria for A-Class articles, and WP:Content assessment just lists some generic criteria. In contrast, GA gives much more solid criteria.
It may be because GA is a site-wide standard but A-Class criteria is handled by WikiProjects, though this is a bit confusing given the majority of articles have multiple WikiProjects. Am I missing something here? DimensionalFusion(talk)21:49, 22 August 2024 (UTC)[reply]
The majority of WikiProjects don't use A-class at all, so of course they haven't wasted their time setting up a process and criteria for using it. WhatamIdoing (talk) 04:19, 23 August 2024 (UTC)[reply]
Under the rubric suggested by Wikipedia:Content assessment/A-Class criteria, A-class reviews closed as successful by WikiProjects without a formal A-class review system should be supported by two uninvolved editors, with no significant opposes. The number of articles that were made A class using the informal process is basically zero. For a while WP:Cyclones was promoting subpar articles based on discussions held on IRC, but they were the rare exception. Schierbecker (talk) 21:38, 26 August 2024 (UTC)[reply]
Because as someone not involved with MILHIST, I am not familiar with A-review. I cannot name a single other WikiProject off top of my head that does A-reviews though they exist. On other hand, most editors understand what GA standard is, which isn't custom to any Wiki projects. If there was a proposal to introduce A-class as a universal standard, I would reconsider my position, but as it stands, it adds more confusion than anything else to rest of the project. This is why project banner shell has been simplified to rate class of an article on behalf of all WikiProjects. ~ 🦝 Shushugah (he/him • talk) 14:42, 31 August 2024 (UTC)[reply]
The problem here is that making A-Class a universal review like FA or GA is that GA already has a big backlog, but as A-Class is above GA it would make reviews take longer due to the higher quality requirements. Potentially leading to an even longer backlog.
@DimensionalFusion, do you mean why do WikiProjects generally prefer FA and GA? It's because they don't want to bother with A-class. Think about it: Either you can do a whole bunch of extra optional work for very little value, or you can just... not. WhatamIdoing (talk) 01:36, 1 September 2024 (UTC)[reply]
There definitely isn't a pressing problem here, but I do agree that we're being overly precise with content assessments, both in terms of the capacity of WikiProjects to review and re-review them (way, way down from 2008) and what they're actually used for (does the difference between C and start and B actually change anything, anywhere?) That the current situation works okay shouldn't stop us trying to refine it.
I like the simplicity of Stub > Start > GA > FA. A stub is a potential article, that might still end up being merged or redirected. GA and FA are well-defined standards with dedicated review processes. The GA criteria in particular are way lower than most people think: we could aim for most articles being GAs one day, and a lot of things that are being rated B or A are already there. I don't see the point in differentiating the mass in the middle---articles that have established themselves but that nobody has really whipped into shape---perhaps just call them something like "satisfactory" or "average" instead of "start" (which implies some deficiency). – Joe (talk) 07:29, 21 August 2024 (UTC)[reply]
I see a big difference between articles like for example Mode conversion (start) and Atom (B). Start class articles are short articles that probably cover the basics but there is a lot more they could say and improvements to writing style, referencing, etc are almost certainly possible. B class articles are (mostly) comprehensive and generally well written but haven't been through any formal processes. Whether there is a need to differentiate B and C is the only question in my mind, but retaining the distinction between them and start is useful.
When looking for examples though I did find MXenes which is tagged as start class but is clearly higher quality than that, especially if someone who understands the subject expands the lead. Thryduulf (talk) 10:28, 21 August 2024 (UTC)[reply]
There is absolutely a difference between Start articles and B-rated articles in the abstract, but the goal remains the same with either article; keep improving them. And at the same time, there are a ton of improperly classified articles, because editors are either too stringent or self conscious and either way, the energy should be focused on improving them. Heck, editors are reluctant to downgrade a B article to a Start article and prefer to fix issues (which is probably the right spirit), but makes the ratings exaggerated in their helpfulness across our 6 million articles here. ~ 🦝 Shushugah (he/him • talk) 00:36, 23 August 2024 (UTC)[reply]
The goal remains the same but the implied method is different. A Start article implies great adding work is needed, a B-class article implies curating and refinement is needed. This difference is why you don't really go from a B to a Start, as it's rare that much content leaves articles. CMD (talk) 04:19, 23 August 2024 (UTC)[reply]
> does the difference between C and start and B actually change anything, anywhere?
Is it possible to have links offered when any page is created in mainspace (or moved from say draftspace). So if Grand Poobah Association is created, as part of the creation in mainspace, it brings up a list of article (and clips of the article) containing the phrase "Grand Poobah Association" unlinked. Basically, I am trying to somehow staple https://edwardbetts.com/find_link/ to the end of the creation/move to mainspace process. Absolutely fine if this is optional.Naraht (talk) 18:55, 20 August 2024 (UTC)[reply]
If someone's computer crashes or for some another reason they close the tab, their changes while editing will be lost. I think we can have a 'save changes' button so that the changes can be saved without finishing the edit halfway. Please provide your inputs. Anonymous1261 (talk) 14:36, 21 August 2024 (UTC)[reply]
Articles on computers and software frequently display fields labeled by bit number in, e.g. instructions, registers. Tables are a convenient means to do this, but involve a good deal of manual editing to consistently align field descriptions with bit labels. It would be helpful to have tools that automated the creation of such tables.
As an example, the IBM 7094 registers table might be generated from the templates
Pardon my pragmatism, but it doesn't seem viable unless you can do it yourself. Even with community consensus, you're not likely to find a template-qualified editor willing to spend the necessary time without a personal interest in the product. Many far smaller proposals have failed for that reason.If such an editor exists, they can Just Do It™ as normal bold editing; prior community consensus is not required.Re "personal interest in the product", it doesn't get much more arcane. I say this as a retired system software developer very familiar with the S/370 PSW and its descendants. Sadly, I'm not template-qualified. ―Mandruss☎01:55, 24 August 2024 (UTC)[reply]
Easier-to-read Article Font when Editing
When editing a page in Wikipedia it can be difficult to read the actual article because of the code, i.e. brackets, urls, citations, references etc. My suggestion is for all code to be in either a different font colour, theme (e.g. Times Roman) or style (e.g. bold), with the published words, numbers etc., clearly legible and distinct from the code, such that what the reader will see on the published page will be seen on the editing page. Protestnt (talk) 08:34, 25 August 2024 (UTC)[reply]
VisualEditor's primary design characteristic is not displaying wikicode, so it's not an ideal solution for this user story. As mentioned, the Syntax highlighter gadget at Special:Preferences#mw-prefsection-gadgets under "Editing" is probably a good start, or the 2017 wikitext editor. Those will handle the colour changes (well, not in Minerva, but it looks like Protestnt edits in desktop view). Font family changes could likely be handled with custom CSS.I feel like User:Alexis Jazz/Factotum might have rich enough and configurable enough syntax highlighting to be a one-stop option here, but I only used it for a brief time around a year ago (too much javascript for my phone) and I can't remember all the options in that package. Courtesy ping Alexis Jazz. Folly Mox (talk) 16:32, 25 August 2024 (UTC)[reply]
I think it might be a great answer to this User story. If the problem is "it can be difficult to read the actual article because of the code, i.e. brackets, urls, citations, references etc.", then "get that visual clutter out of sight" is a great solution. A lot of FAs get copyedited in the visual editor precisely because it's easier to "read the actual article" without brackets and templates in the way.
Is there a better way of assessing an editor's experience? This is something one might (should?) do before interacting with another editor. (And also something to apply to oneself, now and again.) At present we have (1) edit counts and (2) number of articles created (3) date of first edit (have I missed one?). It seems hard to get an opinion on how much of an editor's work is in writing new encyclopaedia content of articles – which is the job we are here to do (yes, just like, e.g., a car manufacturer being all about building cars, we do need a lot of support functions to achieve that job).
The problem with edit counts is that this includes:
lots of short edits because the editor does not prepare a considered piece, check it with a preview, and then add it.
interminable discussions/arguments on talk pages.
a focus on page curation (example:[15]) or other "maintenance" activity.
The problem with number of articles created is that an editor may be working in an area where most subjects have an article on them already. Some of these may need improvement (sometimes radical improvement), updating or simply expanding from a stub. So this measure favours those who edit in rapidly changing subjects where new topics arise frequently.
Date of first edit has some use, but there are still editors who started years ago who seem to be unaware of some of the basics, and quite new editors who seem to have got a real good grip of how everything works and produce quality article content.
In searching for a useful set of measures, I suggest something that looks at activity in main namespace (i.e. encyclopaedia content). This could be, as a single group of information:
the total number of characters added
the number of edits
the number of edits grouped in size bands
I feel this would give a more useful view of an editor's activity. What is important is that this should be easily visible to anyone (without needing knowledge of some little used method of getting this data).
My first thought is to back up a step and ask why you think we need a measure of editor "experience" in the first place? Anomie⚔11:19, 27 August 2024 (UTC)[reply]
Agree with Anomie, especially since "experience" doesn't really translate linearly, someone could be very experienced at writing content but not familiar with "backend" or administrative tasks. Or someone could be very good at writing templates and maintaining code. Or doing mostly WikiGnoming. Etc. Yes, one could say that only the first one is "pure" editing, but this doesn't mean they're inherently the only one doing valuable work, or that they should be higher in some kind of hierarchy of experience. Chaotic Enby (talk · contribs) 11:43, 27 August 2024 (UTC)[reply]
In addition to the points made by Anomie and Chaotic Enby (with which I agree), your proposed metrics are not reliable indicators of anything relevant: a highly skilled copyeditor will have fewer character additions to their name than someone who writes long, terrible prose. Which of these two edits of mine is the greater addition of encyclopaedic content +220,030 bytes or +759 bytes? Is making the same improvement in one edit better or worse than making it in twoedits? My recent gnoming contributions have ranged in size from -167 bytes to +220,030 bytes, almost entirely overlapping with my non-gnoming edits (other than deprodding and BLARing). The number of edits in each band tell you nothing about the sort of editor I am. Thryduulf (talk) 12:04, 27 August 2024 (UTC)[reply]
I thought the brief analogy (above) with a car factory was clear – sticking with that analogy, yes the main task may be building cars, but you still need accountants, cleaners, a marketing department, etc., etc. So I am well aware that Wikipedia would not function without lots of tasks other than "pure" editing. What I find a problem is that in the example I gave above, [16] the edit count (as the only readily available metric) does not make clear that the editor has done very little writing of encyclopaedia content, yet they are welcoming new editors, have offered themselves (on 11 July) for multiple feedback services and are active on approval of draft articles. There is very little editing of actual article content and even less of finding some sourced material and adding it to an article. So from this I conclude that the measure of edit count is misleading and that the editor in question does not really have the experience to be judging other editors' efforts. Hence the need for more better quality information. With that information available to all, it might make an editor ask themselves "am I the right person for this job?", so providing a self-policing element. ThoughtIdRetiredTIR12:42, 27 August 2024 (UTC)[reply]
On Wikipedia:Page Curation, we find Page Curation is a suite of tools developed between March and September 2012 by the Wikimedia Foundation, and greatly improved in 2018 in collaboration with the Wikipedia community, to help experienced editors review new pages on the English Wikipedia.[bold added] The thoughts here are all about determining what is an "experienced editor" – hopefully with that largely being self-policing if the right info is available. ThoughtIdRetiredTIR12:48, 27 August 2024 (UTC)[reply]
What is it about extensive writing of article content that makes someone uniquely qualified to welcome other editors, offer feedback on articles or determine the quality of a draft? In the passage you quote, "experienced" means "is familiar with Wikipedia's policies, guidelines and norms", someone who spends most of their time on Wikipedia reading a broad range of existing articles and discussions is very likely going to have a much better grasp of what page curation entails than someone who has spent twice that amount of time adding sourced content to a narrow topic area. Two people who spend the same amount of time making the same number, size and type of edits to the same type of articles can be very differently suited to page curation - for example if editor A's edits are almost all accepted as good by others while editor B's are reverted and/or require extensive fixing by others. Editor B is arguably more experienced because they will likely have been directed to read more policies and guidelines and had more talk page interaction regarding their editing than editor A (whose talk page may consist only of a welcome message). There is no simple metric that can capture this. Thryduulf (talk) 13:03, 27 August 2024 (UTC)[reply]
Large numbers of edits that welcome new users make a correspondingly large increase in the edit count of a user. These are not edits that increase an editor's knowledge of Wikipedia. This is something that devalues edit count as a useful measure of experience. ThoughtIdRetiredTIR16:25, 27 August 2024 (UTC)[reply]
Respectfully, I don't think we need more metrics and ratings and hierarchies of editors. I'll also note that the Wikipedia:New page reviewer user right (which gives access to the Page Curation tools) is only granted by administrators, most often at first for a short trial, so there is already every opportunity to check if the user has the experience needed.One does not simply walk in and start patrolling new pages. (Although NPP always needs more people!) Chaotic Enby (talk · contribs) 14:27, 27 August 2024 (UTC)[reply]
I think it’s helpful to know whether someone is a [[WP:Young editor]] when giving them feedback on potentially problematic edits. But when people are able to communicate adequately, none of the metrics about previous edit count, areas of expertise concern me. I can be convinced that having certain about edit count, user permissions can be helpful when looking at someone’s diff and to ascertain what kind of question to ask someone; but again with emphasis on being kind and effective communicators. In the past, I’ve been chided as a “new editor” when I had 500 edits by someone who was abusing their seniority status. Needless to say, they were also blocked frequently for problematic behaviours. ~ 🦝 Shushugah (he/him • talk) 14:46, 27 August 2024 (UTC)[reply]
From my experience (and I am talking about positive experiences) the most helpful of editors are those who have added a lot of encyclopaedia content. I attribute that to their understanding of some of the problems in sourcing and explaining an article, and also in how to interact with some of the more difficult people in this community. I suspect that many editors, whether they know it or not, have learnt most of their knowledge on Wikipedia from other editors with a substantial track record behind them. What worries me in this case is: who will a new editor go to for assistance/guidance? If they go to someone who was their new page reviewer, but that person does not have any depth of experience, that new editor is being short changed. In the example given, the editor in question apparently does not read the articles too closely – I have no idea what they are doing, but tagging a short article that says when some died (20 years ago, at a good age) with a BLP warning suggests a superficial approach, as does immediately sticking an orphan tag on everything that comes out of draft, which will obviously be the case on making that transition. To answer I don't think we need more metrics and ratings and hierarchies of editors: I think I am trying to make a closely related point, that the metrics we do have can mislead. Perhaps we just need a warning that the existing measures can mislead. ThoughtIdRetiredTIR16:14, 27 August 2024 (UTC)[reply]
Angela (enslaved woman)
On June 4, 2024, I moved the article Angela (enslaved woman) to Angela (slave), for homogenization. It was reverted by @CaroleHenson on July 3, in which they cite Slavery#Terminology. I attempted to reach them 6 days ago (as of August 30), but they are currently inactive.
The terminology section itself describes the naming as "dispute". I thought the (slave) disambiguator would be a better choice due to WP:NOTCENSORED, similarly to changing "passed away" to "died".
Also, I suggest reading WP:OTHERSTUFFEXISTS before writing your explanation for the requested move process. You will want to write something that doesn't sound like "It's more important for this article to match the others than to avoid language that I've been told is potentially offensive".
Wikipedia should generally avoid needlessly offending people. We want people who read that article to be thinking about the historical subject. We don't want them thinking about whether Wikipedia uses outdated or offensive language. WhatamIdoing (talk) 22:52, 30 August 2024 (UTC)[reply]
There was a recent discussion that, while not formally closed, basically came to the conclusion that both "slave" and "enslaved person" are acceptable ("slave" is not "outdated language") but that one might be preferable to the other depending on the specific context. In such situations it is almost always a bad idea to change from one to the other without consensus. Thryduulf (talk) 23:03, 30 August 2024 (UTC)[reply]
I don't think that (non-RFC) discussion needs a formal closing statement. We probably need to have multiple conversations like that, until more editors become familiar with the subject matter. A formal summary tends to discourage future discussions.
In particular, "both are acceptable" summaries tend to get misused this way: "The rules say that both are acceptable, so my preference is acceptable, and so the rules say we have to do it my way (and never, ever your way)".
As linguistic practices in scholarly and other high-quality sources have just started changing enough for editors to be noticing this, this is probably an area where we need people to keep their brains turned on instead of just trying to find a simplistic rule. I think the best approach will be more obvious in, say, five years. For now, we just need to avoid carving a rule in stone. WhatamIdoing (talk) 01:44, 1 September 2024 (UTC)[reply]
The policy requires Neutrality in article titles, so if editors decide that they have to match, they might need to make them match on the one that won't create an opportunity for complaints about offensiveness.
NB that I'm not saying anyone should be offended; I'm just saying that we already do get complaints about "slave" being offensive, so we can reasonably predict that we will get complaints about offensiveness if we choose the (slave) convention. Similarly, we currently don't get complaints about "enslaved person" being offensive, so I think we can reasonable predict that we won't get complaints about offensiveness if we choose the (enslaved person) convention. WhatamIdoing (talk) 01:50, 1 September 2024 (UTC)[reply]
But I do find substituting "enslaved person" for "slave" grating. Now, I was trained as a linguist and fully understand that a spoken language is a living thing and constantly evolving, but I am also an old fogey and have grown weary of euphemism churning. I have lived through several cases of a term being recognized as offensive, so we switched to some euphemism, which in a few years become offensive to some, so we switched again. In truth, we are just avoiding how the term is used offensively, and replacing one term with another that will also come to be used offensively. That said, I do not choose this as the "great wrong" to right. I will speak up, though, against the trend I've recently seen of changing "plantation" to "forced-labor cotton farm" and similar monstrosities. Saying that slaves were just "forced laborers" is hiding or dimishing the horrors of chattel slavery. Donald Albury17:05, 1 September 2024 (UTC)[reply]
These aren't exactly euphemisms, but I wonder sometimes whether the idea is to grab attention, in the way that an annoying advertisement for used cars is grating but effective at communicating the basic content. WhatamIdoing (talk) 19:47, 1 September 2024 (UTC)[reply]
Proposed temporary solution to the "remember me" function bug
Here is the thread on the bug -> Wikipedia:Village pump (technical)#"Remember me" not working as intended for me
Basically, "remember me" would forget about you sometimes, for whatever reason.
Now, I have no idea how wikipedia works under the hood, so this idea may be absurd or even stupid. I would like to suggest that a check is done every time an IP edits wikipedia to see if it is associated with an account, and a banner be displayed if the check returns a positive result, promoting to user to log back in before publishing their edit. —Mint Keyphase (Did I mess up?What have I done?) 02:57, 31 August 2024 (UTC)[reply]
A warning is displayed every time you edit with IP address about editing under an IP address. I would say that's already a warning enough if one has been editing while logging in. – robertsky (talk) 01:55, 1 September 2024 (UTC)[reply]
@Mint Keyphase, Wikipedia runs MediaWiki software under the hood, and if you are interested in that, please go to mw:How to contribute on our sister site (same username/password; it'll usually log you in automagically).
Robertsky is correct that we already post a warning for every IP. It's in a yellow box at the top of the page and says:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to a username, among other benefits.
Additionally, there are privacy problems around doing things with detecting logged-out editors. Here be dragons, or at least lawyers. This might be solvable, but it's not likely to be quick.
The practical problem is bigger. Imagine what would happen if we did this, and you were using a shared internet connection, e.g., at school. Everyone in the school building would get 'warned' because one person logged out. This is probably not solvable. WhatamIdoing (talk) 01:59, 1 September 2024 (UTC)[reply]
WMF
Wikimedia Foundation Bulletin July Issue 2
Here is a quick overview of highlights from the Wikimedia Foundation over the second half of July 2024. Please help translate.
Feature updates from the Tech News: Stewards can now globally block accounts; Wikimedia site users can now submit account vanishing requests via GlobalVanishRequest; and interface of FlaggedRevs (also known as “Pending Changes”) is improved.
This month’s Wikimedia Research Showcase highlighted the impact machine translation has on both content and readers of Wikipedia and provided interesting insights on how to overcome related challenges. Watch the recording.
The Charts project officially kicked off. The goal of this new initiative is to restore basic data visualization capabilities to the wikis. Check out the project page and follow our progress on Phabricator.
The CampaignEvents extension is now available on Meta-wiki, Arabic Wikipedia, Igbo Wikipedia, and Swahili Wikipedia, and can be requested on other wikis. This extension helps manage and make events more visible. Learn about how to request this extension.
The Campaigns Product & Programs teams have launched a consultation on WikiProjects and other forms of collaboration on the wikis. They want to understand why they work (or don’t work) for some Wikimedia communities, and they want to learn what can be done to improve the experience. Everyone is encouraged to share their feedback.
The Board of Trustees selection pre-onboarding and campaign period is open from July 25 to August 26.
Foundation Trustee Dariusz Jemelniak was appointed to the Governing Board of the European Institute of Innovation and Technology, established as part of the EU’s key funding program for research and innovation.
I am an occasional user of SWViewer, a vandalism patrolling tool that is (in my understanding) partly maintained by the Wikimedia Foundation. I generall like its interface and design, and I have found it to be a useful tool.
I do have one item that I would like to discuss though: I think it would be wise to add a checkbox for whether or not to mark an edit as minor. Currently, the interface allows users to tick a box for "Use undo" when rolling back an edit with a summary. This is good, but it only allows users to revert edits in a way that is marked as minor. I understand that certain wikis, such as the English Wikipedia, have a very narrow understanding of what constitutes a minor edit, and there are times when I want to undo an edit but it is not technically a minor edit. This makes me have to manually go to the English Wikipedia and click the "undo" button there rather than keeping all of this in the SWViewer interface.
Is there a way that the WMF could either:
Not automatically mark edits made while "Use undo" is ticked as minor (i.e. submit them to non-minor edits); or
Allow users to select whether or not their actions are considered to be minor edits (via a tick box)?
Hi, I'm not WMF staff (although I am the Wikimedian of the Year) but I noticed something I thought should have wider community input. Please keep in mind that as far as I'm aware this is in very early stages and there is no guarantee that it will actually be implemented. Also, please be nice. I anticipate that some people will be surprised by what it was being proposed here so I felt like this was an important reminder. Anyways: mw:Wikimedia Apps/Team/iOS/Fundraising Experiment in the iOS App. There is a feedback section towards the end of you wish to give it. I have already commented there. Clovermoss🍀(talk)17:47, 10 August 2024 (UTC)[reply]
This is an example of what is being proposed. Essentially, there would be a donation button near the top right of an article and these would kind of be like Reddit trophies. I think this needs way more visibility than being buried in the depths of mediawiki which is why I'm posting here. Clovermoss🍀(talk)18:52, 10 August 2024 (UTC)[reply]
Hi @Clovermoss, it’s Haley from the Mobile Apps team! You’re correct that the project is in very early stages. We just recently published the project page and had planned to start outreach after Wikimania—that’s why folks might not have heard about it yet. In short, the idea is that we want to try out other ways of fundraising beyond just banners – hopefully ways that make readers and editors feel more connected to each other. But we know that fundraising ideas have to be considered carefully, which is why our goal right now is just to be in conversation with the community on high level concepts. We hope people will join the discussion on the project page. P.S. Congratulations on Wikimedian of the Year! HNordeen (WMF) (talk) 16:01, 14 August 2024 (UTC)[reply]
This should have been mentioned at the fundraising brainstorming page as soon as it was published. I object to the "gamification" aspect of giving money to people. I'm not sure how "donating from an article" is an improvement over just having a discrete "donate" button, which we already have. In conclusion: I think this is unnecessary.
Also here – is it THAT HARD to say "introduce", which is a long-standing, universally recognized word, rather than "onboarding" which is today's #1 corporatese-jargon? These things always make the WMF look bad, bureaucratic, corporate, and out of touch. Cremastra (talk) 17:06, 14 August 2024 (UTC)[reply]
@HNordeen (WMF): This is what I meant when I said at the page itself that this is likely to cause a public relations disaster. Imagine a thousand comments like this. Please understand that I really don't think this is a good idea and I don't say this because I wish you to fail but I wish to see everyone suceed. Clovermoss🍀(talk)17:13, 14 August 2024 (UTC)[reply]
I'll also note that the phrase "Microinteraction and confirmation snackbar." was used without apparent embarrassment to mean "a notification/confirmation box". The thing is, phrases like this are inaccessible, and make these pages harder to understand. Cremastra (talk) 17:17, 14 August 2024 (UTC)[reply]
While "microinteraction" definitely should've been left out, that's not a "box". "Confirmation box" sounds like a dialog for you to confirm. A snackbar can only be a small message that pops up from the bottom to tell you that the operation has been a success (sometimes with an ündo" button to the right). Aaron Liu (talk) 18:17, 14 August 2024 (UTC)[reply]
Sorry, what I meant by confirmation box was a box confirming that the operation worked. That is, it's sending you a confirmation, not the other way around. Cremastra (talk) 18:19, 14 August 2024 (UTC)[reply]
That's an important distinction for developers, but I think if the page is targeted to the general public, "notification bar" should suffice. Cremastra (talk) 18:46, 14 August 2024 (UTC)[reply]
I don't mean to sound like a complete crank, but this is, I think, part of the reason some or many editors react badly to WMF pages like this: they're sometimes hard to understand and come off as a bit condescending. I've WP:BOLDly toned down the language so that it's easier to understand for non-developers. Cremastra (talk) 18:12, 14 August 2024 (UTC)[reply]
I appreciate that my comment prompted you to reflect and tone things down a little. [17] I also know that your heart is in the right place too and that a lot of the time these comments are caused by a series of frustrating events and not feeling like one has been listened to. Feel free to tell me if I'm putting words in your mouth, Cremastra. I just know that HNordeen (WMF) is relatively new to the foundation and I don't want her to feel like all of this was directed at her personally. Clovermoss🍀(talk)18:19, 14 August 2024 (UTC)[reply]
I guess I can put this here: I feel like calling this "mobile fundraising" is a little bit misleading. Do not misunderstand me: I sincerely appreciate Clovermoss bringing this here, regardless of the title. But this is not really about fundraising on mobile. That always has happened, and I doubt anyone will have feedback on that. This is about allowing people to donate to "support"/"champion"/"appreciate" a particular article. Would "allowing people to donate in appreciation of a particular article" be a neutral way to phrase what is being suggested? Best, HouseBlaster (talk · he/they) 18:32, 14 August 2024 (UTC)[reply]
I said mobile fundraising because I wasn't sure what else I could put without making it sound like I was canvassing and steering the discussion a certain way. Between here and CENT, I'm sure this will get enough eyes instead of being buried at mediawiki. If someone does change the title, I'd suggest that it's as clear and concise as possible. Clovermoss🍀(talk)18:42, 14 August 2024 (UTC)[reply]
@HouseBlaster: What would you think if we added "experiment" to the end of the current text? It'd make it more clear that what is being proposed is a bit different compared to a normal mobile fundraising. Clovermoss🍀(talk)21:01, 14 August 2024 (UTC)[reply]
I'm largely indifferent to the idea of mobile fundraising in general, and was surprised it wasn't already well established. I'm also mostly indifferent to the idea of donations tied to articles. What I have a quite strong opinion about is what happens when someone donates "to" an article. To the point: there should be no direct connection between donations and the appearance of a Wikipedia article for anyone other than the donor. No matter how it's framed (badges, stickers, sponsors, endorsements, pictures, text, etc.), if there's any way to affect the appearance of the article with money, there will emerge metacommunicative/signalling strategies to manipulate the system in unacceptable ways. On some level, I like the idea of audiences being better able to communicate appreciation to contributors, but it has to be divorced from money. — Rhododendritestalk \\ 18:59, 14 August 2024 (UTC)[reply]
To the point: there should be no direct connection between donations and the appearance of a Wikipedia article for anyone other than the donor.
Agreed. I also see that the WMF recognises at least some of issues this could cause, saying Safeguards should be added to prevent inappropriate usage of the feature on sensitive articles, but I don’t think they’ve thought through the complexity of accurately classifying articles as sensitive.
Alternatively, if they have already succeeded in doing so in a robust manner, can they please release the tool, as it will be very helpful in general? BilledMammal (talk) 00:23, 15 August 2024 (UTC)[reply]
I think the safeguards comment was in regards to the concerns that I and other people expressed at the page itself on why you wouldn't want something like this on controversial articles. As far as I'm aware, this is just an idea and nothing has actually been implemented. That would mean that there isn't a way to filter this content out yet either. Clovermoss🍀(talk)00:41, 15 August 2024 (UTC)[reply]
I encourage people to leave their feedback on the mediawiki page itself (see my initial comments at the top of the thread) so it isn't scattered across pages and projects. Clovermoss🍀(talk)00:45, 15 August 2024 (UTC)[reply]
Thank you to everyone who has spoken up here - I'll echo @Clovermoss's request to please leave thoughts and ideas on the mediawiki project page. The mediawiki page has been edited to make it more clear (thank you for suggestions on how to do that!) and in hopes to communicate that this is at an early stage, and we are not limited to this first idea that is on the page. I've also expanded the page to include risks that have been brought up so far. Thanks to everyone who has contributed, we have the capacity to try a new format of fundraising within the iOS app this year, and we're excited to work together with you to identify what form it could take. HNordeen (WMF) (talk) 21:04, 16 August 2024 (UTC)[reply]
Hi @Clovermoss, it's meant to communicate that we want to change direction to pursue alternate ideas in response to feedback and suggestions we receive. We want to work together with you to figure out ways of recognizing existing donors and creating pathways for potential donors, and we only want to proceed with ideas that we can all feel good about experimenting with. HNordeen (WMF) (talk) 16:16, 23 August 2024 (UTC)[reply]
Wikimedia Foundation banner fundraising campaign in India postponed to start on the 27th of August
Dear all,
As mentioned previously, the WMF is running its annual banner fundraising campaign for non logged in users in India. Initially, we planned the campaign to start tomorrow and run until the 10th of September. We have had some issues with our local payment provider in India and due to this we are postponing the campaign by a couple of weeks. Our new campaign dates are the 27th of August to the 24th of September.
You can find more information around the campaign, see example banners, and leave any questions or suggestions you might have, on the community collaboration page.
Generally, before and during the campaign, you can contact us:
The Open Conversation with the Trustees at Wikimania hosted breakout discussions about the Movement Charter, affiliate strategy and hubs, the proposal for a Global Resource Distribution Committee (hybrid table--had streaming and is available to watch back online), the Product/Tech Advisory Council & Product/Tech priorities, building a sustainable revenue strategy for the movement: online fundraising, Wikimedia Enterprise and the Wikimedia Endowment, and responding to emerging threats to free knowledge: litigation, censorship, disinformation, and trust in an election year.
Editor tools related to references & categories and more tech updates on the latest Tech News.
Outreachy (a paid, remote three-month internship to support underrepresented groups in tech) is open. Mentors should submit projects before September 11 at 16:00 UTC (more info).
The Campaign Events extension is now available on Meta-Wiki, Arabic Wikipedia, Igbo Wikipedia, and Swahili Wikipedia, and can be requested in other language wikis.
Editors using the iOS Wikipedia app who have more than 50 edits can now use the Add an Image feature. This feature presents opportunities for small but useful contributions to Wikipedia.
Some next steps on a movement charter: A message from Wikimedia Foundation CEO, Maryana Iskander, Chair of Board of Trustees, Nataliia Tymkiv, and Chair of Governance Committee, Dariusz Jemielniak.
Elections for four community-and-affiliate elected seats on the Board of Trustees of the Wikimedia Foundation will be held from September 3 to September 17. To learn more about the candidates, watch this short "Meet the Candidates" presentations.
Why are less images being uploaded today? It wasn't like that from 2006 to 2009, many images were uploaded at that time period. Is there a reason why the image uploads declined after that period of time? MJGTMKME123 (talk) 21:49, 25 August 2024 (UTC)[reply]
There is nothing preventing appropriate and policy-compliant images from being uploaded. As to when it is appropriate to replace an existing image with a new one, that will depend on the specifics: newer isn't necessarily better. AndyTheGrump (talk) 21:57, 25 August 2024 (UTC)[reply]
If someone finds it worth uploading in each particular instance? I have very little clue what sort of general rule you'd expect there to be. Remsense ‥ 论22:03, 25 August 2024 (UTC)[reply]
There is no general answer to this line of questioning. Improved media are uploaded if editors discover or create them; what constitutes an improvement depends entirely on the media in question. Remsense ‥ 论22:18, 25 August 2024 (UTC)[reply]
@MJGTMKME123, what do you mean by "less images being uploaded today"?
Do you mean specifically what's being uploaded today, as in Sunday, the 25th of August? (If so, please go to Wikipedia:Village pump (technical) and sound the alarm, because a sudden downturn is probably technical in nature.) Or do you mean "in recent years"?
How much less? Is this like a long-term leveling off? Are you talking about uploads directly to the English Wikipedia, or at Commons? How are you counting the number of uploads? WhatamIdoing (talk) 22:20, 25 August 2024 (UTC)[reply]
We have made efforts to direct uploaders Wikimedia Commons whenever appropriate, so having less uploads here could be a good thing. — xaosfluxTalk22:32, 25 August 2024 (UTC)[reply]
Are you thinking about any images in particular? Again, we can't really answer your question because it's way too broad. Remsense ‥ 论22:38, 25 August 2024 (UTC)[reply]
I'm just asking about the trend of fewer image uploads in the recent years, but I understand if it's too broad. I was wondering if there are any topics where image uploads have noticeably declined. MJGTMKME123 (talk) 22:43, 25 August 2024 (UTC)[reply]
I didn't actually use a tool. I just noticed that most images were made around that time period by just analyzing the date of random images. MJGTMKME123 (talk) 22:59, 25 August 2024 (UTC)[reply]
@MJGTMKME123, I suggest looking at c:Commons:Statistics of uploads vs deletions, which gives the number of annual uploads from 2003 through 2022, and which does not support your hypothesis that there has been a multi-year decline in uploads.
If you know anything about SQL, you can run queries like this and get whatever numbers you want. I use the "check 10 pages in Special:Random" method a lot, but you've got to remember that it's really quite a crude estimate, and if your random images weren't actually random (e.g., they were images used in Wikipedia articles), then you'd be looking at a crude estimate of a biased sample, which is basically worthless. WhatamIdoing (talk) 23:07, 25 August 2024 (UTC)[reply]
That's way more useful data than what I found just below. So uploads to Commons have risen steadily if non-monotonically, and there is no year for which the number of files uploaded was less than any all of the three previous years. Folly Mox (talk) 23:19, 25 August 2024 (UTC)edited 10:16, 26 August 2024 (UTC)[reply]
This wouldn't account for which images are actually being used in articles (plenty of Commons images aren't), but I'd be very surprised if those are mostly pre-2009. ― novov(tc)10:10, 26 August 2024 (UTC)[reply]
What do you base that on? The number of articles in the English Wikipedia has more than doubled since 2009 (3,144,000 on 1 Jan 2010, 6,764,355 on 1 Jan 2024), and images in older articles are often replaced, so I suspect a large majority of images in articles have been added since 2009. For your claim to be valid, editors would have had to be preferencially using images uploaded before 2009 to add to articles. However, an analysis of the upload dates of a large enough sample of images currently in use in articles would be needed to support your claim. Frankly, I don't think that is worth pursuing, as I don't see its relevance to building a quality encyclopedia. Donald Albury13:49, 26 August 2024 (UTC)[reply]
On a related point, please consider looking through the popular articles for a favorite subject area – most WikiProjects have a page like Wikipedia:WikiProject Medicine/Popular pages – and seeing what new images could/should be added. Not having an adequate number of images in each article is a constant complaint from readers, and it even has benefits beyond the obvious value of the image itself (e.g., helping people with dyslexia keep their eyes on the right part of the article). WhatamIdoing (talk) 17:08, 26 August 2024 (UTC)[reply]
Another source for images (which I suspect has been under utilized) are family photos. For example, over his lifetime my Dad took approximately 4,000 photos which are in slide format. While some will be of little interest to Wikimedia in general -- I doubt anyone is eager to see photos of llywrch's first birthday -- there are a number of images that I know will be of interest, such as photos of his business trips to Sudan & Nigeria, photos Oregon from as far back as 1960, & so forth. (I have some of a railway train that ran between Banks & Vernonia back in the 1960s that no longer exists. The trackway has since then been converted to the Banks–Vernonia State Trail. I've already uploaded a few of these to Commons. I'd be far more along with sharing these on Commons except that for many I'm missing information. For example, he visited an agricultural station in a town in Western Sudan -- for which I'd be surprised if we had any photos -- however I don't remember/know the name of that town.I expect there are countless Wikipedians with older family members who were hobbyist photographers, so this is a resource begging to be exploited. (PS, I had discussed doing this with my father before he passed, so I definitely have permission to do this.) -- llywrch (talk) 22:43, 30 August 2024 (UTC)[reply]
Candidate for the Board of the Wikimedia Foundation – Maciej Nadzikiewicz / User:Nadzik
Hello everyone! I am coming here to get feedback from you and ask for your support.
I am a candidate in the upcoming elections for the Wikimedia Foundation Board of Trustees (a volunteer body that oversees the Wikimedia Foundation) and I want to make sure that I represent the voices of as many contributors as possible on the Board.
My candidate video
I am an active Wikimedia contributor (140,000+ edits on 462 projects & 3,000+ administrator actions) with advanced global permissions. I have experience as a Board Member of Wikimedia Europe, representing 29 Wikimedia affiliates from Europe. I have presented the Wikimedia movement values multiple times as an expert in the Polish Parliament. I was one of the organizers of Wikimania 2024. I generally understand the challenges the editors face, but I want to learn about particular issues that are relevant to your wiki that you’d want to bring to the attention of the Wikimedia Foundation.
I am willing to address any questions you may have. Please contact me here: (wiki-mail, meta-talkpage). See my candidate video; I prepared captions in 12 languages, including English.
Wikimedia Foundation Board of Trustees Election - Introduction
Farah Jack Mustaklem - Board of Trustees candidates lightning talk at Wikimania 2024
Dear colleagues,
In a week's time, polls open for the community to vote on the selection of four trustees to the Wikimedia Foundation Board. More information about the process and timeline is outlined here.
I am one of twelve candidates running to fill these seats, and ask for your support in this process.
My name is Farah Jack Mustaklem (Fjmustak), and I am a long-time Wikimedian with extensive on- and off-wiki experience. I seek to bring about change and reinforcement to the Board in the following areas:
Bring more diversity into the Board
Build a Charter
Combat misinformation/disinformation
Focus on human rights
For more about my candidacy, I invite you to visit my user page (including my answers to the community questions) as well as my candidate page. The short video to the right is a brief summary of my Board candidacy.
If you feel passionately about any of the issues outlined above, I urge you to consider voting for me and to spread the word. Please feel free to reach out to learn more or share your concerns.
There's a reasonably sized subcommunity who decide which news stories are linked at "In the news". The conversations are held at WP:ITN/C. You should be able to participate without an account, assuming some knowledge of Wikipedia policy. Folly Mox (talk) 11:53, 28 August 2024 (UTC)[reply]
I think you have a common misunderstanding of what this section actually is. It is not meant to be a continuously updated news ticker, it is a way of showcasing articles that have been updated to reflect recent events. --User:Khajidha (talk) (contributions) 12:42, 29 August 2024 (UTC)[reply]
We don't updated ITN particularly quickly compared to a normal news website. I think the normal cadence is a new news item in the ITN box every few days. And there's only around 4 bullets so not that many total news items either. I'm not sure the reasoning for this... maybe limited space, and the editor time it would take to do more voluminous or more frequent updates? –Novem Linguae (talk) 14:15, 29 August 2024 (UTC)[reply]
No, ITN does not have a formal overseer, unlike other mainpage sections which are either driven by a single key volunteer or elected coordinator. But it has plenty of editors who hang around and vote on nominations. Very little gets through this gauntlet and so the section often gets stale, as you have noticed. Most recently, ITN ran the same picture of a cyclist for ten straight days. There were plenty of other pictures that might have been run but no-one was accountable or responsible for making this happen.
The good news is that this doesn't much matter because our readers just go straight to topics which are in the news. For example, the top read article on Wikipedia yesterday was WWE Bash in Berlin. But you'd never see that at ITN because, for some reason, such combat sports get no love at ITN – InedibleHulk can perhaps explain why that is.
If you want to browse what's happening in the world, then the best place to look is Portal:Current_events, which seems to work much better because there's a crew of editors more focussed on posting items than arguing about them. For example, today it reports that "NASA announces discovery of Earth's subtle electric field, which contributes to the polar wind phenomenon." Such interesting science gets little love at ITN too.
What should be done to overhaul the {{dubious}} template? Literally every time I've seen it on an article, there is zero discussion on the talk page about what may be dubious in the article. I discussed this on the talk page a while back, but the discussion just went around in circles and fizzled out. Should a drive be done to remove drive-by instances of this tag where no discernible discussion exists? Ten Pound Hammer • (What did I screw up now?)19:40, 28 August 2024 (UTC)[reply]
I see that you have asked this exact same question at three different locations (here, and at the WP:V and WP:RS talk pages). That is not helpful, as the discussions may end up working at cross purposes. Please choose one location for us to discuss this, and close the other threads. Thanks. Blueboar (talk) 20:34, 28 August 2024 (UTC)[reply]
The position taken by Jason Quinn (pinging) in the discussion you linked, especially So rather than a red link for "discuss" appearing if the parameter is not used, the "discuss" link should only appear if it is used and emphasis on the tag as a marker of dubious content seems rather reasonable. Ifly6 (talk) 16:33, 30 August 2024 (UTC)[reply]
Nothing, users should at least fill out the reason =, and if that's not sufficiently obvious, start a discussion on talk like one would for any other tag. If not, some enterprising soul will likely revert the tag.Selfstudier (talk) 16:52, 30 August 2024 (UTC)[reply]
I think sometimes the |reason= is obvious enough that it doesn't need to be explained, too. I think that sometimes {{dubious}} gets used when the material really ought to have been removed instead, but the editor doesn't feel like it's okay to do that. WhatamIdoing (talk) 17:09, 30 August 2024 (UTC)[reply]
I thought after reading your first sentence, "if it's that obvious then surely the dubious claim should be removed", but then I read and agreed with your second sentence. Too many people are too diffident about removing things. I must say that I think I have used this template a few times, but, as far as I can remember, I have always started a discussion. Phil Bridger (talk) 19:57, 30 August 2024 (UTC)[reply]
Agree with this too. Re Should a drive be done to remove drive-by instances of this tag where no discernible discussion exists? – I don't think there's much of a need to remove dubious without parameters. There are a lot of cases where editors are fearful of stepping on others' toes by just removing it. Ifly6 (talk) 22:14, 30 August 2024 (UTC)[reply]
The {{POV}} templates generally require an active discussion. It's one of our defenses against using then as a badge of shame, since we've had problems with people adding that template as a sort of public protest for not getting their way. I've occasionally cleaned out some old undiscussed ones, but even in an anti-tag-bombing mood, there have been a few never-discussed tags that I thought were very obviously deserved. I expect that some of the {{dubious}} tags are the same: there's no discussion, but you don't need an explanation to know why that's doubted.
@WhatamIdoing: what do you suggest then? Seems every time I bring this up, it just turns into an endless cycle of "We should do something." "Should we do something?" "We should do something." "Should we do something?" and nothing ever gets done. Ten Pound Hammer • (What did I screw up now?)16:22, 1 September 2024 (UTC)[reply]
If you see such tag, it's not obvious why it's there and there is no talk page discussion, just remove it. Also can remove it if it's dated. Selfstudier (talk) 16:44, 1 September 2024 (UTC)[reply]
TPH, I don't think we should particularly worry about this. It's being used in about 0.1% of articles, which isn't much. The problem is sometimes obvious, so no discussion or reason needs to be given. In other cases, a discussion or reason has been given.
I decided to use the edit suggestion tool and focus on adding missing references on women's biographies, but the edit suggestion tool presents me with pages that have nothing to do with the topic even tho I only ticked "Biography (women)" and "Find references (sources for existing articles)"
The tool suggests biographies of men. Example : Jeff Schweitzer
I edited David A. Louton yesterday, and it's no longer appearing in articletopic:women search results. I suspect that in some cases, especially when the page is short, the software makes the wrong guess about the subject. WhatamIdoing (talk) 16:46, 30 August 2024 (UTC)[reply]
Template:Permanent dead link
{{Permanent dead link}}, currently a redirect to {{Dead link}}, needs to be modified so that it transcludes {{Dead link}} with the |fix-attempted=yes template parameter already specified. Because then it would be a convenient shortcut to transcluding that template with that parameter, as right now it's a deceptive and rather useless redirect which doesn't do that. How can this be accomplished?
While I was writing this, I just thought of block notice templates like {{Uw-blocknotalk}}. However, I don't have a strong knowledge of template code, and so I don't know what a "safesubst:" is. I'm not sure if the includeonly and safesubst bits would be necessary in this 'Permanent dead link' template conversion, especially since it isn't going to be substituted when being used.
Update: using the code from the blocking templates as said above, I wrote Special:PermaLink/1242911547 in Template:X1 sandbox, and tested out transcluding it in another sandbox, comparing it to a plain old transclusion of 'Dead link' with the parameter manually specified. All looks identical and normal to me. So can someone confirm with me that the code is all valid? — AP 499D25(talk)12:06, 29 August 2024 (UTC) updated 12:27, 29 August 2024 (UTC)[reply]
AP 499D25, looks good to me. The safesubst: is necessary for allowing it to be both transcluded and subst:ed. |bot= is probably unnecessary, because bots should be using the normal template directly. — Qwerfjkltalk09:21, 30 August 2024 (UTC)[reply]
Alright thanks! I'll be going ahead with publishing the redirect to template conversion now, and per your suggestion I'll take out the 'bot' parameter bit. — AP 499D25(talk)11:15, 30 August 2024 (UTC)[reply]
?` for each symbol of string ` template ?
does such a template exist and/or is there some other way to achieve the effect of calling a template with the every symbol of a given string as the argument
also i apologize if this is the incorrect place to ask- if so please point me to the correct one so that i can ask any further questions about templates there
thanks in advance akizettalk20:41, 31 August 2024 (UTC)[reply]
not moving the discussion as it would result in the same question beïng in two places which seems undesirable what i meant was a {{for loop}}-like template such that e.g {{template name|key press|abc}} results in ` abc `
howëver i have since reälized i might not need it for what i'm doïng after all · still would be helpful though