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.
(to see recent changes on Village pump subpages)
I want... | Then go to... |
---|---|
...help using or editing Wikipedia | Teahouse (for newer users) or Help desk (for experienced users) |
...to find my way around Wikipedia | Department directory |
...specific facts (e.g. Who was the first pope?) | Reference desk |
...constructive criticism from others for a specific article | Peer review |
...help resolving a specific article edit dispute | Requests for comment |
...to comment on a specific article | Article's talk page |
...to view and discuss other Wikimedia projects | Wikimedia Meta-Wiki |
...to learn about citing Wikipedia in a bibliography | Citing Wikipedia |
...to report sites that copy Wikipedia content | Mirrors and forks |
...to ask questions or make comments | Questions |
Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).
Policy
Preference of using OpenStreetMaps
Dear @User:Shannon1 before reverting my edits please discuss here.These maps are preferred because they are zoomable and rich of metadata. If you disagree please discuss. Hooman Mallahzadeh (talk) 15:19, 29 March 2024 (UTC)
- @Hooman Mallahzadeh: Hi, can you link me to the Wikipedia documentation or discussion that indicates the OSM maps are "preferred"? The watershed maps are valuable to river articles because they show key information like drainage basin extent, tributaries and topography. I wouldn't be opposed to including both in the infobox, but there appears to be no way currently to display two maps. Shannon [ Talk ] 15:22, 29 March 2024 (UTC)
- I should note that in French Wikipedia it is used correctly for Seine, In Japanese used for Arakawa River (Kantō). This is correct use of maps in the year 2024. Hooman Mallahzadeh (talk) 15:24, 29 March 2024 (UTC)
@Shannon1 Policies doesn't say anything. But I can discuss and defend about their preference. Just compare these images:
Traditional map | New Maps |
---|---|
Which of these maps is more clear? The new or the old? Hooman Mallahzadeh (talk) 15:38, 29 March 2024 (UTC)
- I really think that we should create a policy for the preference of OpenStreetMaps over traditional ones. Hooman Mallahzadeh (talk) 15:40, 29 March 2024 (UTC)
- I think they serve different purposes, and it would be ideal to have both in the infobox - but there appears to be no way to do this at the moment. The OSM map would be a fantastic replacement for pushpin locator maps like on Walla Walla River. However, it deletes a ton of important information that is displayed in the older watershed map. Can we hold off on any kind of mass replacement until this can be resolved? Shannon [ Talk ] 15:43, 29 March 2024 (UTC)
- OpenStreetMaps presents the least but most important metadata at each level of zoom.
- The ability of zooming is only provided by OpenStreetMaps
- If any change occurs for the river, for example the path changes, this is rapidly applied for OpenStreetMaps
- language of metadata changes automatically for each Wikipedia
- and many others. Just let me some time to write them.
- font-size of text of metadata is automatically adjusted
- Hooman Mallahzadeh (talk) 15:44, 29 March 2024 (UTC)
- You should have tried to get agreement for that policy before attempting to impose your preference across a large number of river articles. Kanguole 16:09, 29 March 2024 (UTC)
- @Kanguole Ok, we are here for agreement about that. Hooman Mallahzadeh (talk) 16:14, 29 March 2024 (UTC)
- @Hooman Mallahzadeh: Please revert the map changes you have made, since they have been challenged and there is so far no agreement for them. Kanguole 21:04, 29 March 2024 (UTC)
- @Kanguole Ok, we are here for agreement about that. Hooman Mallahzadeh (talk) 16:14, 29 March 2024 (UTC)
- If it's an article about a river, the traditional map is more informative. 🌺 Cremastra (talk) 21:01, 29 March 2024 (UTC)
@Shannon1 See, we can have both maps by using "Hidden version of maps in infoboxes"
{{hidden begin|title=OpenStreetMap|ta1=center}}{{Infobox mapframe |wikidata=yes |zoom=6 |frame-height=300 | stroke-width=2 |coord={{WikidataCoord|display=i}}|point = none|stroke-color=#0000FF |id=Q1471 }}{{hidden end}}
that is rendered as:
which yields: (here we hide topological and show OpenStreetMap, but the reverse can be applied)
Seine | |
---|---|
Topographical map | |
Native name | la Seine (French) |
Location | |
Country | France |
Physical characteristics | |
Source | |
• location | Source-Seine |
Mouth | English Channel (French: la Manche) |
• location | Le Havre/Honfleur |
• elevation | 0 m (0 ft) |
Length | 777 km (483 mi) |
Basin size | 79,000 km2 (31,000 sq mi) |
Discharge | |
• location | Le Havre |
• average | 560 m3/s (20,000 cu ft/s) |
Basin features | |
River system | Seine basin |
Tributaries | |
• left | Yonne, Loing, Eure, Risle |
• right | Ource, Aube, Marne, Oise, Epte |
We can have both maps, one is hidden by default, and the other is shown by default. But I really think that we should show OpenStreetMap and hide others. But in many rare cases that the revert is true, we show topographic map and hide OpenStreetMap. Hooman Mallahzadeh (talk) 15:54, 29 March 2024 (UTC)
- We want an edit for Template:Infobox river and use parameters hidddenMap1 and probably hiddenMap2 for implementing this idea. Hooman Mallahzadeh (talk) 16:07, 29 March 2024 (UTC)
- I opened a thread on Template talk:Infobox river regarding this. Also pinging @Remsense: who has been separately reverting my edits. Shannon [ Talk ] 16:09, 29 March 2024 (UTC)
- I'm merely concerned specifically with the articles I've reverted, I have no opinion on the issue at-large. Remsense诉 16:16, 29 March 2024 (UTC)
- @Remsense: I've been on Wikipedia 15+ years and river articles have always used these watershed maps. I'm aware that policies can change but there has been no such discussion at WP:RIVERS or elsewhere. In my view, the watershed map on Yangtze for example is far more informative than the OSM map, which is essentially a better locator map. The Yangtze basin is immense, with dozens of major tributaries, and in this case the OSM map also leaves out the Jinsha that continues for more than 2000 km upstream of Sichuan. (Not because I made the watershed map, necessarily – I just noticed the reversions because of my watchlist.) Shannon [ Talk ] 16:25, 29 March 2024 (UTC)
- I'm merely concerned specifically with the articles I've reverted, I have no opinion on the issue at-large. Remsense诉 16:16, 29 March 2024 (UTC)
- I opened a thread on Template talk:Infobox river regarding this. Also pinging @Remsense: who has been separately reverting my edits. Shannon [ Talk ] 16:09, 29 March 2024 (UTC)
- If you really want consistent guidelines (after working out technical issues), put them on WikiProject Geography. A global policy would just be MOS:BLOAT. SamuelRiv (talk) 16:39, 29 March 2024 (UTC)
- @SamuelRiv I made a discussion for that here. Thanks, Hooman Mallahzadeh (talk) 16:51, 29 March 2024 (UTC)
- @Shannon1:For my final word, I really cann't read the metadata of this map, because text on it is too small:
unless opening it. So its metadata is useless at the first glance, unlike OpenStreetMap.
- Not sure where to put this comment, because this section is broken with huge amounts of whitespace making it almost unreadable. I just want to mention that i have reverted three or four river map changes by Hooman Mallahzadeh, the summary of the diff indicated that the rather ugly and not as useful Open Street Map was preferable; my summary is "By whom is it "preferred"? Don't think there's a policy on this; until any discussion is finished the better map shouldn't be removed." I see now that a discussion (not a vote at all) has been started here. I'd like to suggest that Hooman Mallahsadeh reverts all the changes they have made of this type until this discussion comes to some conclusion. Happy days, ~ LindsayHello 20:26, 29 March 2024 (UTC)
Proposal 1: Render both; prefer OSM; hide others
Ok, please vote for this scenario.
"Both topographic and OpenStreetMaps will be rendered in Infobox, but it is preferred to show OpenStreetMap and hide others by using "Template:Hidden begin" and "Hidden end".
- For "vote", I asssume you mean "discuss"? 🌺 Cremastra (talk) 21:04, 29 March 2024 (UTC)
Agree with proposal 1 re OSM
- Agree Hooman Mallahzadeh (talk) 16:23, 29 March 2024 (UTC)
- Agree OSM is the option that is automated, scales, is multilingual, matches a partner open data / open media project, and which has a community of editors comparable to our own who actively seek to collaborate with us as Wikipedians. We should prefer OSM by default. It is okay for anyone to argue for exceptions, but also, no one should have to argue in favor of including OSM because it is normative. Bluerasberry (talk) 14:46, 30 April 2024 (UTC)
- You've posted what amounts to a non-sequitur: listing some nice things, and then skipping ahead to "we should prefer it by default" without actually having made an argument why we should that references or even acknowledges existing cite norms and policy, never mind any opposing arguments that have been made in this thread. Remsense诉 14:53, 30 April 2024 (UTC)
- Agree The OSM provides a good, legible summary for the size of the infobox, without the need to click onto it. The watershed maps look great, but only at a larger magnification. They should appear somewhere else prominent in the article at an appropriate scale. I believe that a map could be produced that does the job in the infobox better than either of these alternatives (e.g. a map like the OSM, but with the tributaries also marked). JMCHutchinson (talk) 15:36, 10 May 2024 (UTC)
Disagree with proposal 1 re OSM
- Disagree The OS map (in the way it is implemented here; don't know if layers in OS can be switched off for this kind of view) shows too much information that is not relevant for river articles (like roads, for example), and not enough information about what these articles are about - rivers. Plus, the watershed maps are just prettier IMO. Zoeperkoe (talk) 18:08, 29 March 2024 (UTC)
- Disagree Some maps are better for some things. For example in river or lake articles, the watershed maps are more helpful, but for city maps OSM is probably better. 🌺 Cremastra (talk) 21:03, 29 March 2024 (UTC)
- @Cremastra@Zoeperkoe Why OSM is preferred? Because it is more abstract, and for solving our problems, it is preferred to move from reality into concept. Please read the article Concept. In fact, we want to solve our problems by concepts that only includes main data and lacks redundant data. So certainly OSM maps are appropriately more abstract and finer concept.
- For example, in this image:
- The abstracted version of tree is preferred for many applications (question answering) like addressing and others over Cypress tree.
- So. in river Infoboxes, I even propose to use wider lines to remove elaboration of rivers and make a simpler map for its Infobox at the first glance. Hooman Mallahzadeh (talk) 05:22, 30 March 2024 (UTC)
- As someone who also likes the OSM maps in general cases: "read the Concept article" is not a very compelling argument.
- My argument would be that they are more flexible and more immediately maintainable by editors. We can theoretically better control the level of abstraction or detail we need for a given article. I don't mind cracking open the text editor to edit an SVG, but not everyone wants to do that. I've seen enough infobox crimes to know that dogmatism either for maximum abstraction or concretion is counterproductive. Remsense诉 05:28, 30 March 2024 (UTC)
- Disagree For users with Javascript disabled (either by choice or by force), OSM maps are useless. No movement, no zoom, and nothing drawn on top of the base tiles. Also no ability to swap between tiles. Please ensure that whatever choice you make fails safely without scripts. 216.80.78.194 (talk) 11:10, 31 March 2024 (UTC)
- OSM map is much less informative for the topic of rivers. CMD (talk) 06:17, 7 April 2024 (UTC)
- @Chipmunkdavis Being less informative is an advantage. The purpose of an Infobox is providing some general information, not detailed information. In an Infobox, only the most important and most readable data should be shown. Other maps can contain details, not the Infobox map. Hooman Mallahzadeh (talk) 06:52, 7 April 2024 (UTC)
- While I think this position is preferable to the other extreme which is far more common in infobox disputes, I think it's a perspective being wielded too dogmatically here. While it's fun when I say things like "being less informative is an advantage" and there's a real sense where that's true, it also misses the point here that no one size fits all when it comes to presenting key information, and a watershed is important information one would like to know at a glance. It's being mischaracterized in my opinion as a detail, what others are arguing is that it is not so. Remsense诉 07:05, 7 April 2024 (UTC)
- @Chipmunkdavis@Remsense Yes. But the most abstract data version is in the first zoom, if you want more abstract version do "zoom out" and if you need more detailed version, do "zoom in",
- But at the first glance, if is not enough informative, then for example for "watershed", we can use "point locators" on the map. Or for areas we can use area locators. They are added very fast by using new items of Template:Maplink. The same as Shinano_River. Hooman Mallahzadeh (talk) 07:20, 7 April 2024 (UTC)
- An in this particular case, the watershed and to an extent tributaries is important and immediately visually readable. CMD (talk) 12:29, 7 April 2024 (UTC)
- While I think this position is preferable to the other extreme which is far more common in infobox disputes, I think it's a perspective being wielded too dogmatically here. While it's fun when I say things like "being less informative is an advantage" and there's a real sense where that's true, it also misses the point here that no one size fits all when it comes to presenting key information, and a watershed is important information one would like to know at a glance. It's being mischaracterized in my opinion as a detail, what others are arguing is that it is not so. Remsense诉 07:05, 7 April 2024 (UTC)
- @Chipmunkdavis Being less informative is an advantage. The purpose of an Infobox is providing some general information, not detailed information. In an Infobox, only the most important and most readable data should be shown. Other maps can contain details, not the Infobox map. Hooman Mallahzadeh (talk) 06:52, 7 April 2024 (UTC)
- Disagree. I have just been reading a river article i happened to come across (River Wyre) which has made me feel so strongly that i have had to return here and protest these OSM maps, though i had planned not to. The map in that particular article, as well as other river articles i have looked at recently, is not sufficient: It gives no idea of the area drained by the river, there are unexplained dotted and faint grey lines all over it which apparently give no information, and (in this particular case) it is huge compared to the other images in the article. I am rather worried by Hooman Mallahzadeh's statement above,
[b]eing less informative is an advantage
, which i strongly disagree with; we should be giving our readers an abundance of information and allowing them, if they so desire, to choose what they wish to take away. Happy days, ~ LindsayHello 07:42, 7 April 2024 (UTC)- In the context of an infobox it is understandable what they mean. However, the point here is I think it's perfectly reasonable to display a river's watershed in the infobox. Remsense诉 07:54, 7 April 2024 (UTC)
- @Remsense See French Wikipedia at this page https://www.search.com.vn/wiki/fr/Seine . It displays both start and end with pointer and then in the continuum of Infobox, it discusses start and end of the river. I think this convention of French Wikipedia describes rivers (and also Seine river) fantastic. Hooman Mallahzadeh (talk) 09:02, 7 April 2024 (UTC)
- Remsense, i agree that the infobox should contain the watershed ~ the thing is, if it doesn't, the information (presumably in the form of a map) would need to be elsewhere in the article. The infobox is indeed the logical place to look. Happy days, ~ LindsayHello 13:19, 7 April 2024 (UTC)
- @LindsayH Please do not be surprised about my statement! Just see the Occam's razor article, ending line of the first paragraph:
"The simplest explanation is usually the best one."
- And this sentence:
In philosophy, Occam's razor (also spelled Ockham's razor or Ocham's razor; Latin: novacula Occami) is the problem-solving principle that recommends searching for explanations constructed with the smallest possible set of elements.
- And this sentence:
Entities must not be multiplied beyond necessity.
- I don't know what is your major, but this principle is applied to all theories in science. Hooman Mallahzadeh (talk) 08:07, 7 April 2024 (UTC)
- Hooman Mallahzadeh, i think you're possibly misunderstanding Ockham's razor: It says nothing about withholding information to make things simpler, what it means is that given a certain number of observations or facts the simplest explanation which covers them all is to be preferred. So i am still concerned (maybe even more so now) about your desire to give our readers less information. Happy days, ~ LindsayHello 13:19, 7 April 2024 (UTC)
- @LindsayH «Least information» but «most important information», in addition, it should be readable at the first glance, topological maps are usually unreadable at the first glance. Hooman Mallahzadeh (talk) 13:24, 7 April 2024 (UTC)
- Occam's razor has to do with problem-solving. If we apply to everything, then we get rid of everything as being too complicated. Cremastra (talk) 01:34, 11 April 2024 (UTC)
- It's always puzzling to me when people bring up Occam's razor as if it lends any credence to a particular philosophical argument, where it universally translates to "the right answer is probably the one that seems right to me". Remsense诉 01:38, 11 April 2024 (UTC)
- I think it's a useful metric when evaluating if an idea has a lot of edge cases or exceptions. If you can find a different idea that covers the topic without edge cases, it suggests that the "edge cases" aren't actually edge cases but rather refutations.
- That being said, I don't see how Occam's rasor applies to the question at hand. 104.247.227.199 (talk) 10:13, 20 April 2024 (UTC)
- It's always puzzling to me when people bring up Occam's razor as if it lends any credence to a particular philosophical argument, where it universally translates to "the right answer is probably the one that seems right to me". Remsense诉 01:38, 11 April 2024 (UTC)
- Hooman Mallahzadeh, i think you're possibly misunderstanding Ockham's razor: It says nothing about withholding information to make things simpler, what it means is that given a certain number of observations or facts the simplest explanation which covers them all is to be preferred. So i am still concerned (maybe even more so now) about your desire to give our readers less information. Happy days, ~ LindsayHello 13:19, 7 April 2024 (UTC)
- In the context of an infobox it is understandable what they mean. However, the point here is I think it's perfectly reasonable to display a river's watershed in the infobox. Remsense诉 07:54, 7 April 2024 (UTC)
- OSM clearly doesn't include the relevant topographic information. Aaron Liu (talk) 15:57, 29 April 2024 (UTC)
- Disagree OSM is user generated and in my experience has false information on it, I even tried to sign up to remove it but it's not obvious at all of how to remove place names. A topographical map can't be vandalised unlike OSM. Traumnovelle (talk) 09:04, 12 May 2024 (UTC)
- Agreed the input could be less abstruse, but that sword cuts both ways: can't be vandalized, can't be improved or fixed. Remsense诉 09:08, 12 May 2024 (UTC)
- Well it has been vandalised and it seems not possible to fix. Traumnovelle (talk) 15:43, 12 May 2024 (UTC)
- No, Wikipedia is not like a printed book, and all its information is unreliable. So even "topographical map" may be vandalised. In this aspect "topographical map" is the same as OSM, but a little harder to vandalised. Hooman Mallahzadeh (talk) 11:58, 12 May 2024 (UTC)
- We can control what appears on Wikipedia and on Commons - what appears on OSM is out of our control, and what does appear in my experience has been a bunch of names that are completely bogus. Traumnovelle (talk) 15:44, 12 May 2024 (UTC)
- Agreed the input could be less abstruse, but that sword cuts both ways: can't be vandalized, can't be improved or fixed. Remsense诉 09:08, 12 May 2024 (UTC)
Neutral
- I support the inclusion of both, but there is no need to hide one or the other. See the current documentation of Template:Infobox river. The OSM implementation would be a good replacement for the dot locator map, but it does not at all adequately replace a topographical map showing basin-level details. I am aware of the limits of image maps particularly regarding language, but 1) this is the English Wikipedia and this primarily concerns pages in English; 2) replacing existing .jpg and .png maps with SVG maps would enable maps to be easily edited for translation; and 3) if a map isn't available in a certain language, then just using the OSM version is fine. Shannon [ Talk ] 19:00, 29 March 2024 (UTC)
- Please see WP:NOTVOTE. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:26, 29 March 2024 (UTC)
- Yeah, that isn't how policy decisions are made. AndyTheGrump (talk) 21:32, 29 March 2024 (UTC)
- Im a huge OSM map fan, but to say that a it is preferred OVER a topographical map goes way too far. editorial discretion as always should apply, and blanket 'rules' for things like this almos always backfire. —TheDJ (talk • contribs) 10:19, 20 April 2024 (UTC)
Proposal 2: Include both (OSM and topographic maps) when appropriate
This seems like it best approaches existing consensus:
When appropriate, both a topographic map and OpenStreetMaps should be included in infoboxes.
Remsense诉 01:07, 30 March 2024 (UTC)
@Remsense Just see how beautiful Japanese Wikipedia introduced the river Shinano_River by this code:
{{Maplink2|zoom=8|frame=yes|plain=no|frame-align=right|frame-width=400|frame-height=600|frame-latitude=36.93|frame-longitude=138.48|type=line|stroke-color=#0000ff|stroke-width=3|id=Q734455|title=信濃川|type2=line|stroke-color2=#4444ff|stroke-width2=2|id2=Q11655711|title2=関屋分水|type3=line|stroke-color3=#4444ff|stroke-width3=2|id3=Q11362788|title3=中ノ口川|type4=line|stroke-color4=#4444ff|stroke-width4=2|id4=Q11372110|title4=五十嵐川|type5=line|stroke-color5=#4444ff|stroke-width5=2|id5=Q11561641|title5=渋海川|type6=line|stroke-color6=#4444ff|stroke-width6=2|id6=Q11437096|title6=大河津分水|type7=line|stroke-color7=#4444ff|stroke-width7=2|id7=Q3304165|title7=魚野川|type8=line|stroke-color8=#4444ff|stroke-width8=2|id8=Q11587633|title8=破間川|type9=line|stroke-color9=#4444ff|stroke-width9=2|id9=Q11561259|title9=清津川|type10=line|stroke-color10=#4444ff|stroke-width10=2|id10=Q11366441|title10=中津川|type11=line|stroke-color11=#4444ff|stroke-width11=2|id11=Q11674896|title11=鳥居川|type12=line|stroke-color12=#4444ff|stroke-width12=2|id12=Q11530256|title12=松川|type13=line|stroke-color13=#4444ff|stroke-width13=2|id13=Q11571106|title13=犀川|type14=line|stroke-color14=#4444ff|stroke-width14=2|id14=Q11626952|title14=裾花川|type15=line|stroke-color15=#4444ff|stroke-width15=2|id15=Q11671931|title15=高瀬川|type16=line|stroke-color16=#4444ff|stroke-width16=2|id16=Q11444998|title16=奈良井川|type17=line|stroke-color17=#4444ff|stroke-width17=2|id17=Q11563522|title17=湯川|type18=line|stroke-color18=#4444ff|stroke-width18=2|id18=Q59404662|title18=依田川|type19=line|stroke-color19=#4444ff|stroke-width19=2|id19=Q59490451|title19=西川|type20=line|stroke-color20=#4444ff|stroke-width20=2|id20=Q59537584|title20=黒又川}}
This includes all sub-rivers. I think this type of maps should be a good sample for all other Wikipedia to introduce rivers. Hooman Mallahzadeh (talk) 13:18, 30 March 2024 (UTC)
- I personally quite like this, yes. I'm sure if there's some argument against this, we will be hearing it—I like when other editors hone my aesthetic senses. Remsense诉 13:21, 30 March 2024 (UTC)
- It looks very useful. I also stumbled across the Syr Darya page which manages to use both types of map in the infobox using the |extra= field. I would say that's a good, clean way to approach it going forward. Again, I think both types of maps are useful in different ways, and I see no reason to take an absolutist stance and say one or the other should be favored in all cases.
- To add, I was kind of rubbed the wrong way at the start of this debate by OP's attitude that new and high tech is always better regardless of the context or usage (not to mention inventing an imaginary consensus which totally threw me for a loop), and as others have commented, this isn't how policy decisions on Wikipedia are made. Finally, as someone passionate about river topics, the auto generated maps just don't tell the full "story". It's nuance and individual approach versus cold standardization. Yes, there are a lot of poorly drawn and inaccurate user-made maps out there (including many of my older maps) which could do well with being replaced, but then there are beautiful ones like Rhine, which provide a value much harder to replace.Shannon [ Talk ] 16:53, 30 March 2024 (UTC)
- @Shannon1 Even in the article of Rhine and in the selected map of Infobox, the font is too small and we can't read anything. So aside from choosing OSM or not, between existing maps, the second map i.e., File:Rhein-Karte2.png is more appropriate for Infobox map of this article. I think we should make a policy for selecting between maps, the one that is more abstract, i.e. we apply this policy:
Hooman Mallahzadeh (talk) 17:56, 30 March 2024 (UTC)The simplest and most abstract map is the preferred one for Infobox of articles
- I have already made my point, so I'll excuse myself from further argument on this thread. As I've stated, I support applying both maps where possible as I believe that provides the best value for the reader. I don't particularly mind if the OSM or topographic map is placed first or second in the infobox. However, I cannot agree with the assessment that "the simplest and most abstract map is preferred" in the context of rivers, which are complex systems that are much more than a simple blue line. Unless a broader consensus can be reached, I maintain to oppose any removal of useful content that have been considered standard on river articles for years. Shannon [ Talk ] 19:56, 30 March 2024 (UTC)
- To add, I was kind of rubbed the wrong way at the start of this debate by OP's attitude that new and high tech is always better regardless of the context or usage (not to mention inventing an imaginary consensus which totally threw me for a loop), and as others have commented, this isn't how policy decisions on Wikipedia are made. Finally, as someone passionate about river topics, the auto generated maps just don't tell the full "story". It's nuance and individual approach versus cold standardization. Yes, there are a lot of poorly drawn and inaccurate user-made maps out there (including many of my older maps) which could do well with being replaced, but then there are beautiful ones like Rhine, which provide a value much harder to replace.Shannon [ Talk ] 16:53, 30 March 2024 (UTC)
- This seems to be the best of both worlds, clear, readable map, with some information about the watershed. - Enos733 (talk) 19:00, 29 April 2024 (UTC)
Proposal 3: Selection of varous types of "topographical maps" as background for OSM
I think this "alignment scenario" would be perfect:
OSM maps of rivers remains unchanged, but OSM white background could be changed to various topographical backgrounds by users.
Implementing this idea has challenges about setting correct size and challenges of alignment of two maps, but its implementation is not hard. Hooman Mallahzadeh (talk) 10:39, 20 April 2024 (UTC)
- I'm sure it can work fine, but I still am not quite understanding why we would need to codify it as policy. Everyone has pretty much re-reiterated their preference for "just figure out what works on a per article basis", and you haven't really articulated why there's anything wrong with that. Remsense诉 10:41, 20 April 2024 (UTC)
- @Remsense We should apply a policy is for "the selection of a map between various maps" for Infoboxes, which is for "First Glance Data". Wrong selection could give no data at the first glance. Hooman Mallahzadeh (talk) 10:45, 20 April 2024 (UTC)
- I'm not sure I understand. Editors are currently free to decide what is best for each article, as per usual. Unfortunately, I don't think the type of arguments you've made are going to convince other editors that we should restrict editors' flexibility like that. If you want to improve the site, I think working on individual articles and discussing how to improve their maps for each would be more helpful to the site, because I still don't see a need to change sitewide policy. Remsense诉 10:51, 20 April 2024 (UTC)
- You said
Editors are currently free to decide what is best for each article, as per usual.
- Editors should select what type of map for infobox? In the most cases (over 90%), the «simplest map» is the best for infobox. Do you agree? But in very special cases other maps should be used for Infoboxes. Isn't it better to be a «policy»? Hooman Mallahzadeh (talk) 11:00, 20 April 2024 (UTC)
- I don't think so, no. Let editors make their own choices per article. You are working in generally correct principles, but this would be applying them too dogmatically, as mentioned above. Remsense诉 11:02, 20 April 2024 (UTC)
- @Remsense But I really think that the selection of File:Bassin Seine.png for Seine river happened in English Wikipedia is wrong. Selection of French Wikipedia for this river is more appropriate, because it provides more data at the first glance. If we apply a «selection policy», such bad selections would not happen anymore. Hooman Mallahzadeh (talk) 11:18, 20 April 2024 (UTC)
- ...then discuss the merits for that particular map on that particular talk page, like I've suggested several times! That's how Wikipedia generally works. I don't know how else to illustrate that your suggestion seems overly restrictive, and the flexibility seems more worthwhile here, but please try to understand what I'm saying with that, I guess? Remsense诉 12:42, 20 April 2024 (UTC)
- @Remsense But I really think that the selection of File:Bassin Seine.png for Seine river happened in English Wikipedia is wrong. Selection of French Wikipedia for this river is more appropriate, because it provides more data at the first glance. If we apply a «selection policy», such bad selections would not happen anymore. Hooman Mallahzadeh (talk) 11:18, 20 April 2024 (UTC)
- I don't think so, no. Let editors make their own choices per article. You are working in generally correct principles, but this would be applying them too dogmatically, as mentioned above. Remsense诉 11:02, 20 April 2024 (UTC)
- I'm not sure I understand. Editors are currently free to decide what is best for each article, as per usual. Unfortunately, I don't think the type of arguments you've made are going to convince other editors that we should restrict editors' flexibility like that. If you want to improve the site, I think working on individual articles and discussing how to improve their maps for each would be more helpful to the site, because I still don't see a need to change sitewide policy. Remsense诉 10:51, 20 April 2024 (UTC)
- @Remsense We should apply a policy is for "the selection of a map between various maps" for Infoboxes, which is for "First Glance Data". Wrong selection could give no data at the first glance. Hooman Mallahzadeh (talk) 10:45, 20 April 2024 (UTC)
Closing time
We've had a good time chatting about maps, but it's pretty clear we're not coming to any sort of consensus to change site policy or guidelines. Does anyone object to me sewing this one up? Remsense诉 12:02, 12 May 2024 (UTC)
- As a finial word, I propose to provide a "Infobox map selection policy" that selecets a map between OSM and topological maps that satisfies these properties:
- Readable for texts
- Less detail with most important data
- and some other aspects. Hooman Mallahzadeh (talk) 12:08, 12 May 2024 (UTC)
- If (as you admit) there is no clear consensus, then you can't "sew it up" to your personal preferences. In particular "I propose to provide" sounds just like you have a fixed idea that you are trying to impose. Martin of Sheffield (talk) 14:51, 12 May 2024 (UTC)
- For clarity, was any of that intended for me? Remsense诉 15:00, 12 May 2024 (UTC)
- For clarity, I'd read both yours and Hooman Mallahzadeh's contributions together, for that mix-up I apologise. However it does apply to both unless your sewing up is a finding of no consensus. Martin of Sheffield (talk) 15:19, 12 May 2024 (UTC)
- More like a consensus to not to change anything, but the effect is the same. Remsense诉 15:21, 12 May 2024 (UTC)
- No, we should avoid choosing File:Bassin Seine.png for Seine river Infobox as happened in English Wikipedia. We can do that by a general policy. Hooman Mallahzadeh (talk) 15:24, 12 May 2024 (UTC)
- Consensus contradicts you. Cremastra (talk) 15:26, 12 May 2024 (UTC)
- @Cremastra Do you think that selection of File:Bassin Seine.png for Seine Infobox is correct? Hooman Mallahzadeh (talk) 15:27, 12 May 2024 (UTC)
- Yes, I do, but that's beside the point. The point is that consensus is against your proposal and you need to accept that. Cremastra (talk) 15:28, 12 May 2024 (UTC)
- I accept or not, this selection may harm Wikipedia. My opinion is not important at all. What is important is that
Are we providing information for readers in the best scientific way?
- If the answer is no, and some better way exists, then we are in a wrong way. My opinion is not important at all. Hooman Mallahzadeh (talk) 15:34, 12 May 2024 (UTC)
- And your opinion is that some better way exists, other have disagreed with that opinion. -- LCU ActivelyDisinterested «@» °∆t° 17:14, 12 May 2024 (UTC)
- I completely described advantages of OSM over topological maps above. I really think that we define "better" with advantages and disadvantages. Hooman Mallahzadeh (talk) 17:29, 12 May 2024 (UTC)
- Hooman Mallahzadeh, it's not mine intention to be rude, but i am going to be blunt: Do you understand the concept of consensus, the idea that through discussion it is usually possible to discern the community's will? Because throughout this discussion you appear to be ignoring it or pretending that consensus doesn't exist ~ your statement that
we should avoid choosing File:Bassin Seine.png for [the] Seine river...[w]e can do that by a general policy
ignores both the previous consensus and that developed in this discussion. Please don't take offense at my bluntness, but do take a moment to think that perhaps the will of the community is not with you on this one. Happy days, ~ LindsayHello 17:42, 12 May 2024 (UTC) - Yes you described what you believe the advantages are, and you may consider them to be fact but you failed to convince other editors of that. -- LCU ActivelyDisinterested «@» °∆t° 20:17, 12 May 2024 (UTC)
- You cannot assert that consensus should exist from the strength of argument alone, that's why we use consensus as a decision-making mechanism. Sometimes people do not value the same things you do or have the same priorities. It is healthy at least to acknowledge that everyone else that has considered them has found your arguments unconvincing. I would move on. Remsense诉 06:13, 13 May 2024 (UTC)
- Hooman Mallahzadeh, it's not mine intention to be rude, but i am going to be blunt: Do you understand the concept of consensus, the idea that through discussion it is usually possible to discern the community's will? Because throughout this discussion you appear to be ignoring it or pretending that consensus doesn't exist ~ your statement that
- I completely described advantages of OSM over topological maps above. I really think that we define "better" with advantages and disadvantages. Hooman Mallahzadeh (talk) 17:29, 12 May 2024 (UTC)
- And your opinion is that some better way exists, other have disagreed with that opinion. -- LCU ActivelyDisinterested «@» °∆t° 17:14, 12 May 2024 (UTC)
- Yes, I do, but that's beside the point. The point is that consensus is against your proposal and you need to accept that. Cremastra (talk) 15:28, 12 May 2024 (UTC)
- @Cremastra Do you think that selection of File:Bassin Seine.png for Seine Infobox is correct? Hooman Mallahzadeh (talk) 15:27, 12 May 2024 (UTC)
- Consensus contradicts you. Cremastra (talk) 15:26, 12 May 2024 (UTC)
- No, we should avoid choosing File:Bassin Seine.png for Seine river Infobox as happened in English Wikipedia. We can do that by a general policy. Hooman Mallahzadeh (talk) 15:24, 12 May 2024 (UTC)
- OSM has the ability of zooming in and out. But for "topological maps" we cann't zoom out but do zooming in with lowering quality. This is one of the worst drawbacks of topological maps. Hooman Mallahzadeh (talk) 15:21, 12 May 2024 (UTC)
- More like a consensus to not to change anything, but the effect is the same. Remsense诉 15:21, 12 May 2024 (UTC)
- For clarity, I'd read both yours and Hooman Mallahzadeh's contributions together, for that mix-up I apologise. However it does apply to both unless your sewing up is a finding of no consensus. Martin of Sheffield (talk) 15:19, 12 May 2024 (UTC)
- For clarity, was any of that intended for me? Remsense诉 15:00, 12 May 2024 (UTC)
- If (as you admit) there is no clear consensus, then you can't "sew it up" to your personal preferences. In particular "I propose to provide" sounds just like you have a fixed idea that you are trying to impose. Martin of Sheffield (talk) 14:51, 12 May 2024 (UTC)
Problem of vandalism
@Traumnovelle: Vandalism is problem of all texts inside Wikipedia and outside it in cyberspace and Internet. Unless we have some printed or signed version of data, vandalism happens in cyberspace. I really think that vandalism for OSM can be tolerated, as for other data of cyberspace.Hooman Mallahzadeh (talk) 15:50, 12 May 2024 (UTC)
- I've figured out how to remove vandalism from OSM, I still don't like the idea of relying on a third party with different policies and rules, there seems to be no active editors/watchers for this. Traumnovelle (talk) 15:55, 12 May 2024 (UTC)
- I think advoiding vandalism in OSM and Wikipedia be the same, but I'm not sure. I should do some research about vandalism in OSM. Hooman Mallahzadeh (talk) 15:59, 12 May 2024 (UTC)
- If someone adds a false piece of information in an article and I come across it I can click edit, search for the text with ctrl + f and remove it. If someone does the same with openstreetmaps I have to click dozens of tiny boxes and hope I've found the one that has been vandalised. It's like finding a needle in a haystack. Traumnovelle (talk) 16:04, 12 May 2024 (UTC)
- Well even now it's still tedious given you have to select dozens of areas and hope you've found the one the vandal has added a name to. I've given up on removing it and I still am opposed given how easy it is to vandalise and how tedious it is to deal with. Traumnovelle (talk) 16:02, 12 May 2024 (UTC)
- I think advoiding vandalism in OSM and Wikipedia be the same, but I'm not sure. I should do some research about vandalism in OSM. Hooman Mallahzadeh (talk) 15:59, 12 May 2024 (UTC)
- Hooman Mallahzadeh, do you have a conflict of interest with Open Street Maps? Cremastra (talk) 17:46, 12 May 2024 (UTC)
How to describe past events on the main page
Currently, the status quo for events listed on the main page is to use the present tense, even if the event in question has definitively ended. I didn't really notice this was an issue until yesterday when I noticed that the main page said that the Solar eclipse of April 8, 2024 is visible through parts of North America. Knowing that it was not currently visible and double checking that the article referred to the event in the past tense, I changed this to was visible. [1] I did not realize that this is against the current consensus at WP:ITNBLURB which says that these events must always be described in the present tense. If one is interested in further background, I encourage them to read this discussion here (scroll down to errors).
I think that this status quo is misleading to readers because it cases like this, we are deliberately giving inaccurate and outdated information. I believe this is a disservice to our readers. The eclipse is not visible anymore, yet we must insist that it is indeed visible. I think that we should also be consistent... If the article for a blurb is using the past tense, we should use the past tense on the main page. Therefore, I propose that events listed on ITN that have definitively ended should be described in the past tense if it would otherwise mislead readers into thinking an event is ongoing. Clovermoss🍀 (talk) 11:33, 10 April 2024 (UTC), edited 17:00, 10 April 2024 (UTC)
- Note: Notification of this discussion was left at Wikipedia talk:In the news.—Bagumba (talk) 12:00, 10 April 2024 (UTC)
I propose that events listed on ITN that have definitively ended should be described in the past tense
: But any blurb can be written in the past tense, e.g., a country was invaded, an election was won, a state of emergency was declared, etc. So if we did go to past tense, I don't understand why there is a distinction with needing to have "definitively ended".—Bagumba (talk) 12:07, 10 April 2024 (UTC)- I made the distinction because I felt our current approach was the most jarring in situations where we're literally misleading the reader. I don't really have any strong preferences either way on other situations and felt like it'd be for the best to make sure my RfC was clear and not vague. I'm not trying to change every blurb at ITN right now, hence the "definitive end date" emphasis. If someone wants more broader changes to verb tense at the main page, I'd say that warrants its own separate discussion. Clovermoss🍀 (talk) 12:16, 10 April 2024 (UTC)
- Note The blurb currently reads
A total solar eclipse appears across parts of North America
[2]—Bagumba (talk) 12:33, 10 April 2024 (UTC)- I was about to suggest a rewording along these lines… so that the blurb is accurate while maintaining present tense. Blueboar (talk) 12:45, 10 April 2024 (UTC)
- It's better than flat out saying visible, but this phrasing still implies that it is visible? Present tense when an event has ended implies that an event is still ongoing. Clovermoss🍀 (talk) 16:22, 10 April 2024 (UTC)
- Appear means
to start to be seen or to be present
.[3] It doesn't say that it continues to be seen. Perhaps the previous blurb's problem was that it resorted to using is, incorrectly implying a continuing state, not that a present-tense alternative was not possble(??)—Bagumba (talk) 06:34, 11 April 2024 (UTC)- To be present is to continue to be seen (by those looking, at least). I think you're misreading that as
to start to be seen or present
. That second to be matters here (and so it appears bold). InedibleHulk (talk) 22:30, 11 April 2024 (UTC)
- To be present is to continue to be seen (by those looking, at least). I think you're misreading that as
- Appear means
- It's better than flat out saying visible, but this phrasing still implies that it is visible? Present tense when an event has ended implies that an event is still ongoing. Clovermoss🍀 (talk) 16:22, 10 April 2024 (UTC)
- I was about to suggest a rewording along these lines… so that the blurb is accurate while maintaining present tense. Blueboar (talk) 12:45, 10 April 2024 (UTC)
Support per nom, see no reason to oppose. Aaron Liu (talk) 13:19, 10 April 2024 (UTC)- Per below, there isn'ta clear way forward for this one. On one hand, "Liechtenstein wins the FIFA World Cup" should definitely remain that way, but this also causes situations like these. Maybe something like
unless this wording directly encourages a misleading interpretation that the event is still ongoing.
, using an earthquake in present tense and this event in past tense as examples. Or maybe we should just IAR such cases. Aaron Liu (talk) 16:30, 10 April 2024 (UTC)- I don't think IAR is going to work as long as we don't have an explicit exemption because it'd be causing someone to explicitly go against consensus for their own ends. I switched the wording to "was visible" out of ignorance in regards to current standards, not because I was deliberately ignoring them. I think there might have been much more ado made about my actions if I had done this with a justification of IAR. I don't have issues with your proposed wording, because again, my biggest issue with all of this is intentionally misleading readers. Clovermoss🍀 (talk) 16:39, 10 April 2024 (UTC)
- @Aaron Liu: I've changed the proposal to have "if it would otherwise mislead readers into thinking an event is ongoing". Does that address your concerns? Clovermoss🍀 (talk) 17:03, 10 April 2024 (UTC)
- I don't think IAR is going to work as long as we don't have an explicit exemption because it'd be causing someone to explicitly go against consensus for their own ends. I switched the wording to "was visible" out of ignorance in regards to current standards, not because I was deliberately ignoring them. I think there might have been much more ado made about my actions if I had done this with a justification of IAR. I don't have issues with your proposed wording, because again, my biggest issue with all of this is intentionally misleading readers. Clovermoss🍀 (talk) 16:39, 10 April 2024 (UTC)
- Per below, there isn'ta clear way forward for this one. On one hand, "Liechtenstein wins the FIFA World Cup" should definitely remain that way, but this also causes situations like these. Maybe something like
- Comment for a lot of blurbs, the present tense is fine, as it continues to be true. e.g. elections, "X is elected leader of Y" is correct and better than past tense, and same with sports matches that end up on ITN. A blanket change to past tense is disingenuous therefore, although swapping to past tense for events that happened (and aren't ongoing) seems somewhat reasonable. Joseph2302 (talk) 13:55, 10 April 2024 (UTC)
- Isn't "Is elected" past tense? Though I agree that for situations where we can use the active voice, "Z legislature elects X as leader of Y" sounds better. Aaron Liu (talk) 14:05, 10 April 2024 (UTC)
- "Is elected" is present tense, specifically present perfect. "Elects" is also present tense, simple present. Levivich (talk) 18:14, 10 April 2024 (UTC)
- I thought "is elected" is passive voice. Voters are doing the electing, the elected person is passive in this situation. In passive voice "elected" is a past participle (
also sometimes called the passive or perfect participle
). (Side note: present perfect in English usually takes "have/has" as an auxiliary verb) —andrybak (talk) 23:00, 23 April 2024 (UTC)
- I thought "is elected" is passive voice. Voters are doing the electing, the elected person is passive in this situation. In passive voice "elected" is a past participle (
- "Is elected" is present tense, specifically present perfect. "Elects" is also present tense, simple present. Levivich (talk) 18:14, 10 April 2024 (UTC)
- Isn't "Is elected" past tense? Though I agree that for situations where we can use the active voice, "Z legislature elects X as leader of Y" sounds better. Aaron Liu (talk) 14:05, 10 April 2024 (UTC)
- I think for time-bound events such as the eclipse, including a time frame would be the best approach to avoid confusion. Additionally, I think using past tense is fine. isaacl (talk) 17:09, 10 April 2024 (UTC)
- I am in favor of past tense for everything. "Won the election," or "landslide killed 200" or "eclipse appeared" all read as fine to me. Newspapers using present tense makes sense because they publish every day (or more often). It doesn't make sense for ITN where items stay posted for days or weeks. Levivich (talk) 18:10, 10 April 2024 (UTC)
- Something about ITN mostly using present tense just feels... righter. Regardless of staying posted for weeks, they are all quite recent compared to most other stuff we have on the main page. Also see historical present. Aaron Liu (talk) 20:30, 10 April 2024 (UTC)
- I'll have what you're having. InedibleHulk (talk) 22:30, 11 April 2024 (UTC)
- Decide case-by-case: we can safely IAR in most cases. Cremastra (talk) 19:43, 10 April 2024 (UTC)
- No special rules for the main page: use the same tense we would in articles. We are an encyclopedia not a newspaper. (t · c) buidhe 20:37, 10 April 2024 (UTC)
- Object The present tense serves us well. It is the standard tense for headlines, certainly within the UK and I believe US too (though some MoS in the US is very different to the UK). I can't see anything in the proposal beyond change for the sake of change. doktorb wordsdeeds 22:00, 10 April 2024 (UTC)
- We should use the correct tense. Someone does not "wins" an election or sports match, they won it. The eclipse, after it ended, was visible over North America, but "is" visible is factually inaccurate at that point (and before it starts to happen, we should say it will be visible). A political leader does not "makes" a statement, they made it. On the other hand, it may be accurate to say that a conflict is going on, or rescue efforts after a disaster are underway. So, we should use the natural, normal tense that accurately reflects the actual reality, as it would be used in the article. Seraphimblade Talk to me 06:02, 11 April 2024 (UTC)
- Object I don't think I agree with the premise that ITN blurbs are phrased in the present in the first place. It's in the historical present tense. "A 7.4-magnitude earthquake strikes near Hualien City, Taiwan" doesn't give the impression that the ground is still shaking. Nor does "A solar eclipse appears across parts of North America" read as "a solar eclipse is happening right now." Likewise, "Nobel Prize–winning theoretical physicist Peter Higgs (pictured) dies at the age of 94." doesn't need to be changed to "died at the age of 94", we know it's in the past, we're not under any illusions that he's still in the process of dying. It's phrased in such a way that doesn't really imply either past or present and just kind of makes sense either way. If an event is still happening, the blurb makes sense. And if the event is over, the blurb still makes sense. I think that's intentional. Vanilla Wizard 💙 07:33, 11 April 2024 (UTC)
- Actually, I think that "A 7.4-magnitude earthquake strikes near Hualien City, Taiwan" does give the impression that the ground is still shaking, or at least that it was shaking very recently. Even newspaper headlines avoid that, especially after the first day. "Hualien struck by massive earthquake" is a perfectly normal headline style. In fact, I find these actual headlines in the past tense:
- Taiwan Struck by Deadly 7.4-Magnitude Earthquake
- Taiwan shaken but unbowed as biggest quake in 25 years spotlights preparedness
- Taiwan hit by powerful earthquake
- Taiwan hit by its strongest quake in quarter-century, but death toll is low
- Earthquake in Taiwan blamed for at least 9 deaths as buildings and roads seriously damaged
- Taiwan hit by strongest earthquake in 25 years, killing 9
- WhatamIdoing (talk) 01:00, 20 April 2024 (UTC)
- Agree that this is a normal headline style that we would do fine to adopt. But to my ear, the past participles in those examples sound more like examples of passive voice with zero copula, rather than past tense. -- Visviva (talk) 01:34, 21 May 2024 (UTC)
- Actually, I think that "A 7.4-magnitude earthquake strikes near Hualien City, Taiwan" does give the impression that the ground is still shaking, or at least that it was shaking very recently. Even newspaper headlines avoid that, especially after the first day. "Hualien struck by massive earthquake" is a perfectly normal headline style. In fact, I find these actual headlines in the past tense:
- Keep present tense as general recommendation per above. Discuss individual cases when this is too jarring. —Kusma (talk) 07:43, 11 April 2024 (UTC)
- As an encyclopedia rather than a news agency, I would think past tense fits our vibe more. Archives of our frontpage would remain clearly accurate indefinitely. We are not reporting news, we are featuring a newly updated/written encyclopedic article on currently relevant events. ~Maplestrip/Mable (chat) 08:22, 11 April 2024 (UTC)
- Keep present tense. There is a difference between "X is happening" (which necessarily means right now, at this moment) and "X happens" (which os somewhat more vague). We should always use the second form, regardless of precise moment. As stated above, we even have statements like "an earthquake hits..." or "So and so dies", both of which are clearly over by the tine it gets posted. Animal lover |666| 19:12, 11 April 2024 (UTC)
- Object from a wp:creep standpoint To my knowledge there is no rule regarding this and it's just a practice. This would change it to having a rule. North8000 (talk) 19:25, 11 April 2024 (UTC)
- No, it should not – it's unencyclopaedic and ungrammatical. The Simple Present is used to describe habitual or continuous actions or states (the Sun sets in the West; he is a boot-and-shoe repairman; I'm Burlington Bertie, I rise at ten-thirty; Timothy Leary's dead etc). Events in the past are described using the Present Past when when no time is specified (the lunch-box has landed; London has fallen; mine eyes have seen the glory ...). When a time in the past is specified, the Simple Past is invariably used: in fourteen hundred and ninety-two, Columbus sailed the ocean blue, in fourteen hundred and ninety-three, he sailed right back over the sea; today, I learned; well I woke up this morning and I looked round for my shoes. This is not rocket science. Ours is not a news outlet with a profit target to meet, we have no reason to have 'headlines', which are simply bits of news given some kind of extra urgency by being in the wrong tense. "Wayne Shorter dies!" immediately begs the question "really? how often?" So "A total eclipse of the Sun has occurred; it was visible in [somewhere I wasn't] from [time] to [time]". It gives the information, it's written in English, where's the problem? (NB there are two distinct present tenses in English, the Simple Present and the Present Continuous; the latter is used for things that are actually happening in this moment or about to happen in the future (I'm going down to Louisiana to get me a mojo hand; I’m walking down the highway, with my suitcase ...). Justlettersandnumbers (talk) 20:22, 11 April 2024 (UTC)
- @Justlettersandnumbers: Reading your comment makes it sound like it supports of my proposal instead of opposing it? I don't understand the "no, it should not" unless there's something I'm not getting. Clovermoss🍀 (talk) 21:10, 11 April 2024 (UTC)
- @Clovermoss The title of your section begins with "Should the main page continue to use the present tense". Aaron Liu (talk) 22:49, 11 April 2024 (UTC)
- And then the actual RfC itself is my proposal to change that for situations where this would be misleading readers. I'm not sure it's necessarily the best idea to be messing around with section names at this point but I'm open to suggestions that would help make this less confusing for people. Clovermoss🍀 (talk) 22:53, 11 April 2024 (UTC)
- Eh, never mind. I decided to be bold and make it consistent with how CENT describes this discussion. Hopefully that helps things. Clovermoss🍀 (talk) 23:15, 11 April 2024 (UTC)
- And then the actual RfC itself is my proposal to change that for situations where this would be misleading readers. I'm not sure it's necessarily the best idea to be messing around with section names at this point but I'm open to suggestions that would help make this less confusing for people. Clovermoss🍀 (talk) 22:53, 11 April 2024 (UTC)
- @Clovermoss The title of your section begins with "Should the main page continue to use the present tense". Aaron Liu (talk) 22:49, 11 April 2024 (UTC)
- @Justlettersandnumbers: Reading your comment makes it sound like it supports of my proposal instead of opposing it? I don't understand the "no, it should not" unless there's something I'm not getting. Clovermoss🍀 (talk) 21:10, 11 April 2024 (UTC)
- Support Given that WP:ITNBLURB currently has the guideline that "blurbs should describe events in complete sentences in the present tense," it does not seem like instruction creep to modify an existing rule. isaacl recommends including a time-frame, but I find this impractical for events that occur over multiple time zones. While this eclipse's article reports the event's span over the overall planet in UTC, this level of detail is too cumbersome for a main page blurb. Clovermoss' proposal limits itself to cases where the present tense would be confusing, which is preferable to an individual discussion for each perceived exception to the current guideline. BluePenguin18 🐧 ( 💬 ) 20:50, 11 April 2024 (UTC)
- Yes, the practice should continue - this is a perfectly normal idiomatic feature of English. Headlines are written in the present tense, just like 'in which...' in the chapter sub-headings of old novels, the summaries of TV episodes in magazines and on streaming services, and lots of other places where a reported past action is summarised. GenevieveDEon (talk) 21:33, 11 April 2024 (UTC)
- How about, "is seen over North America" -- passive with present tense and past participle, anyone? :) Alanscottwalker (talk) 21:49, 11 April 2024 (UTC)
- That's a better solution than ending the practice of using the historical present tense. Though I think that suggestion is more likely to be implemented at WP:ERRORS than through a Village Pump policy proposal. (I'm also not entirely sure why this whole discussion isn't just at the ITN talk page since it doesn't affect any other part of the main page, but it's no big deal) Vanilla Wizard 💙 20:10, 12 April 2024 (UTC)
- ERRORS is not the appropriate venue, given that the discussion that was there was removed. As for why it's here specifically, I figured anything regarding the main page was important, that a discussion here would invite more participants, and avoid the possibile issue of a local consensus. Clovermoss🍀 (talk) 20:16, 12 April 2024 (UTC)
- I originally thought this suggestion was sarcastic, given the smiley face. If it is serious, I dislike it because "is seen" is extremely passive voice. Assuming there is a problem (which I don't think there is), the solution is not passive voice. CaptainEek Edits Ho Cap'n!⚓ 20:22, 12 April 2024 (UTC)
- I don't think passive voices are that bad; while I agree that the active voice is usually preferred, do you really think that "North Americans see a total solar eclipse" is better? Aaron Liu (talk) 21:32, 12 April 2024 (UTC)
- No. I think that the current iteration "A total solar eclipse appears across parts of North America" is perfect. CaptainEek Edits Ho Cap'n!⚓ 21:37, 12 April 2024 (UTC)
- I don't think passive voices are that bad; while I agree that the active voice is usually preferred, do you really think that "North Americans see a total solar eclipse" is better? Aaron Liu (talk) 21:32, 12 April 2024 (UTC)
- In fairness, that discussion was removed specifically because ITN uses present tense and the discussion was proposing to change that, and ERRORS isn't the place for proposals to change how we do things. Alanscottwalker's suggestion also uses the present tense, so ERRORS would be a fine venue if they really wanted to see that change made. After all, that discussion at ERRORS is what resulted in the language being changed from "is visible" to "appears". I personally think appears is totally fine (I agree with CaptainEek that there is no problem), but if someone prefers "is seen", that's the place to do it. Vanilla Wizard 💙 20:33, 12 April 2024 (UTC)
- That discussion only happened because I changed "is visible" to "was visible", prompting an errors report. I'd prefer "appeared" over "appears" since that implies that it is still indeed visible per the above discussion. It's better than "is visible", though. Clovermoss🍀 (talk) 01:07, 13 April 2024 (UTC)
- I originally thought this suggestion was sarcastic, given the smiley face. If it is serious, I dislike it because "is seen" is extremely passive voice. Assuming there is a problem (which I don't think there is), the solution is not passive voice. CaptainEek Edits Ho Cap'n!⚓ 20:22, 12 April 2024 (UTC)
- ERRORS is not the appropriate venue, given that the discussion that was there was removed. As for why it's here specifically, I figured anything regarding the main page was important, that a discussion here would invite more participants, and avoid the possibile issue of a local consensus. Clovermoss🍀 (talk) 20:16, 12 April 2024 (UTC)
- That's a better solution than ending the practice of using the historical present tense. Though I think that suggestion is more likely to be implemented at WP:ERRORS than through a Village Pump policy proposal. (I'm also not entirely sure why this whole discussion isn't just at the ITN talk page since it doesn't affect any other part of the main page, but it's no big deal) Vanilla Wizard 💙 20:10, 12 April 2024 (UTC)
- Keep present tense as ITN is supposed to summarize and collect news headlines and the present tense is standard in headlines. Pinguinn 🐧 00:05, 12 April 2024 (UTC)
- Keep using historical present I think a lot of supporters here are confusing the historical present (often used in news headlines) for the simple present. I would agree that the eclipse would have made sense to be an exception to that general rule, as was the focus in the original proposal here, but I wouldn't change the general rule. Anomie⚔ 12:04, 12 April 2024 (UTC)
- Currently, in this proposal, I see a codified exception for when using the present tense would be confusing that would only apply in cases like the solar eclipse. Aaron Liu (talk) 12:43, 12 April 2024 (UTC)
- @Anomie, the lead of our article on the historical present says the effect of the historical present is "to heighten the dramatic force of the narrative by describing events as if they were still unfolding". I'm not convinced that making things sound more dramatic should be a goal for an encyclopedia, and I would not have guessed that you would support such a goal. Do you? WhatamIdoing (talk) 01:09, 20 April 2024 (UTC)
- Currently, in this proposal, I see a codified exception for when using the present tense would be confusing that would only apply in cases like the solar eclipse. Aaron Liu (talk) 12:43, 12 April 2024 (UTC)
- Keep historical present tense Headlines are most compelling and appropriate in the historical present tense. The NYTimes provides that "Headlines are written in the historical present tense. That means they written are in present tense but describe events that just happened."Out of curiosity, I perused the AP Stylebook (56th edition, 2022-2024), which surprisingly had almost nothing to say on tenses, though its section on headlines is generally instructive.
How to best have a vivid headline? Present tense and active voice! One of Wikipedia's most frequent writing errors is using past tense and passive voice out of a misplaced assumption that it is more encyclopedic. But past and passive are weak. Present and active are better, and are what I have been taught in a wide multitude of writing courses and professional spaces. To add to the NYTimes, AP, and personal experience, I consulted my copy of Bryan Garner's Redbook (4th ed.), which while meant as a legal style guide, is useful in other areas. Regarding tense, in heading 11.32, it provides that "generally use the present tense." I then turned to the internet, which backed up the use of present tense in headlines: Grammar expert suggests present tense "Engaging headlines should be in sentence case and present tense." Kansas University on headlines: "Present tense, please: Use present tense for immediate past information, past tense for past perfect, and future tense for coming events."Using the historical present is best practice for headlines. That's not to say that there can't be exceptions, but they should be rare. As for the eclipse, it properly remains in the historical present. As a further consideration: if we are updating ITN tenses in real time, we are adding considerable work for ourselves, and we push ourselves truly into WP:NOTNEWS territory. CaptainEek Edits Ho Cap'n!⚓ 18:35, 12 April 2024 (UTC)"Headlines are key to any story. A vivid, accurate and fair headline can entice people to dig in for more. A bland, vague or otherwise faulty headline can push readers away. Often, a headline and photo are all that many readers see of a story. Their entire knowledge of the piece may based on those elements. Headlines must stand on their own in conveying the story fairly, and they must include key context. They should tempt readers to want to read more, without misleading or overpromising."
- I don't think we're adding considerable work for ourselves. It takes a second or two in the rare situations that require it, anything else regarding the main page has much more work involved. We already update the articles in question, just not the blurb, which is a bit of a jarring inconsistency in itself. I don't understand the argument that the tense we should be using should be comparable to newspaper headlines because we're NOTNEWS? Could you elaborate a bit on your thinking there? Clovermoss🍀 (talk) 19:43, 12 April 2024 (UTC)
- For the last part: they're mistaken that this proposal would require tenses to be updated to the past tense when any event ends, which is way too much effort to stay current which kinda does fall into NOTNEWS. (Note that this proposal would only require past tense if the historical present causes confusion) Aaron Liu (talk) 19:50, 12 April 2024 (UTC)
- We are NOTNEWS. But as my comment above alludes to, ITN is a de facto news stream. Each entry in ITN is effectively a headline. Why try to reinvent the headline wheel? I'm afraid I have to disagree with Aaron's clarification, because Clover did change the tense after the event ended. It would have been incorrect to say "was" when the blurb first posted...because the eclipse was presently happening at that time. I'll add further that "otherwise mislead readers into thinking an event is ongoing" is an unhelpful standard. I don't buy that the average reader is going to be confused by a historical present headline. We read headlines all the time, and the average reader understands the historical present, even if they couldn't define it. CaptainEek Edits Ho Cap'n!⚓ 20:18, 12 April 2024 (UTC)
- I have to disagree with you there. I think that when the main page stated that the eclipse "is visible", that was confusing to the average reader. It confused me, prompting me to check that the eclipse wasn't somehow ongoing. We were giving inaccurate information intentionally and I honestly don't see why we do this for the main page. Because it's interesting? Because newspapers do it before an event happens? Once the eclipse ended, newspapers referred to the event in the past tense as well. My decision to change it to "was visible" took one second (so not a considerable time investment, although everything that ensued certainly has been). Clovermoss🍀 (talk) 20:32, 12 April 2024 (UTC)
- Ah, that's my bad, the "is visible" language is also problematic for its passivity. I like the "appears" solution, and thought that was the original wording. But I think it would be improper to say "appeared." I'm not so sure I buy that newspapers were uniformly using past tense; again, the best practice for newspapers is to use the historical present. The time issue is ancillary to the best practice issue, I agree that the real time sink is the discussions that will surely result from implementing this rule. CaptainEek Edits Ho Cap'n!⚓ 20:42, 12 April 2024 (UTC)
- I could show some examples if you'd like, since you don't seem to buy that newspapers were using the past tense after the eclipse appeared.
- "A total eclipse of a lifetime appeared for hundreds of thousands of visitors and residents in the Hamilton-Niagara region" – Canadian Broadcasting Corporation [4]
- "In middle America, the eclipse was a phenomenon" – Washington Post [5]
- "During the event on April 8, 2024, one of these arcs was easily visible from where I stood, agape beneath our eclipsed, blackened star, in Burlington, VT." – Mashable [6]
- "The great American eclipse appeared Monday, bringing the nation to a standstill as photographers captured stunning shots of the rare celestial event." – CNET [7]
- "The total solar eclipse that swept across Mexico, the United States and Canada has completed its journey over continental North America." – CNN [8]
- I think that "appears" is better than saying "is visible" like the previous phrasing was before my intermediate change of "was visible" but it still runs into the issue of implying the eclipse is appearing somewhere. I agree with what InedibleHulk said above
To be present is to continue to be seen (by those looking, at least). I think you're misreading that as to start to be seen or present. That second to be matters here (and so it appears bold).
Clovermoss🍀 (talk) 21:14, 12 April 2024 (UTC)- The operative issue is that these are headlines from after the event. But the blurb got posted during the event. CaptainEek Edits Ho Cap'n!⚓ 21:19, 12 April 2024 (UTC)
- And the blurb stays days or weeks on the main page, where using the past tense would be more accurate than using present tense the entire time. I also think that having a clear exemption clause would prevent time sink discussions like this one, not cause them. It'd prevent us from needing to have a discussion every time something like this happens. Clovermoss🍀 (talk) 21:25, 12 April 2024 (UTC)
- The operative issue is that these are headlines from after the event. But the blurb got posted during the event. CaptainEek Edits Ho Cap'n!⚓ 21:19, 12 April 2024 (UTC)
- I think that this discussion would prevent some time sink over reluctance to IAR. And again, only a small number of events would need their tense changed. Aaron Liu (talk) 21:34, 12 April 2024 (UTC)
- I could show some examples if you'd like, since you don't seem to buy that newspapers were using the past tense after the eclipse appeared.
- Ah, that's my bad, the "is visible" language is also problematic for its passivity. I like the "appears" solution, and thought that was the original wording. But I think it would be improper to say "appeared." I'm not so sure I buy that newspapers were uniformly using past tense; again, the best practice for newspapers is to use the historical present. The time issue is ancillary to the best practice issue, I agree that the real time sink is the discussions that will surely result from implementing this rule. CaptainEek Edits Ho Cap'n!⚓ 20:42, 12 April 2024 (UTC)
- I have to disagree with you there. I think that when the main page stated that the eclipse "is visible", that was confusing to the average reader. It confused me, prompting me to check that the eclipse wasn't somehow ongoing. We were giving inaccurate information intentionally and I honestly don't see why we do this for the main page. Because it's interesting? Because newspapers do it before an event happens? Once the eclipse ended, newspapers referred to the event in the past tense as well. My decision to change it to "was visible" took one second (so not a considerable time investment, although everything that ensued certainly has been). Clovermoss🍀 (talk) 20:32, 12 April 2024 (UTC)
- I don't think we're adding considerable work for ourselves. It takes a second or two in the rare situations that require it, anything else regarding the main page has much more work involved. We already update the articles in question, just not the blurb, which is a bit of a jarring inconsistency in itself. I don't understand the argument that the tense we should be using should be comparable to newspaper headlines because we're NOTNEWS? Could you elaborate a bit on your thinking there? Clovermoss🍀 (talk) 19:43, 12 April 2024 (UTC)
- Drop present tense and use the tense we'd use anywhere else on Wikipedia. Wikipedia is not a newspaper, even on the Main Page, and there's no reason we should obscure the timing of events for stylistic reasons. Loki (talk) 21:18, 12 April 2024 (UTC)
- The tense we'd use anywhere else is, by default, present? WP:TENSE provides that
By default, write articles in the present tense
. CaptainEek Edits Ho Cap'n!⚓ 21:22, 12 April 2024 (UTC)- MOS:TENSE says
By default, write articles in the present tense, including those covering works of fiction (see Wikipedia:Writing better articles § Tense in fiction) and products or works that have been discontinued. Generally, use past tense only for past events, and for subjects that are dead or no longer meaningfully exist
. We use past tense for past events like we do at the actual article linked in the ITN blurb: Solar eclipse of April 8, 2024. It's just the main page where we make the stylistic choice to not do that. Clovermoss🍀 (talk) 21:31, 12 April 2024 (UTC)
- MOS:TENSE says
- The tense we'd use anywhere else is, by default, present? WP:TENSE provides that
- The present tense makes the main page read like a news ticker, which we are often at pains to explain it is not (e.g. WP:NOTNP). I would favour the past tense for all events that are not ongoing. If we cannot agree on that, I support the proposal to use the past if there might be a misunderstanding (partly in the hope that familiarity will lead to the past tense being used more and more in the future!). JMCHutchinson (talk) 11:06, 13 April 2024 (UTC)
- Support Per WP:NEWSSTYLE, "As a matter of policy, Wikipedia is not written in news style ..." . ITN is especially embarrassing because its blurbs are often weeks old and so its use of the present tense is then quite misleading. It might help if the blurbs were dated to show how old they are. See OTD and the Spanish edition for examples. Andrew🐉(talk) 07:38, 18 April 2024 (UTC)
- Support the thing Clovermoss said we should do (to head off any confusion about whether "support" or "oppose" means to support or oppose making or not making a change, etc). jp×g🗯️ 06:30, 19 April 2024 (UTC)
- Oppose any firm rule. The same style is used in the not-so-current-events sections of year pages, or at least those I've checked so far:
- From 520: The monastery of Seridus, where Barsanuphius and John the Prophet lived as hermits, is founded in the region of Gaza
- From 1020: King Gagik I of Armenia is succeeded by Hovhannes-Smbat III.
- From 1920: A woman named Anna Anderson tries to commit suicide in Berlin and is taken to a mental hospital where she claims she is Grand Duchess Anastasia of Russia.
- From 2020: A total solar eclipse is visible from parts of the South Pacific Ocean, southern South America, and the South Atlantic Ocean.
- Now maybe I'm being a bit OTHERSTUFFy here and it's year pages that should be fixed, but until that's done, it would seem really weird to describe 1000-year-old events with "is", but events from last week with "was". Suffusion of Yellow (talk) 21:48, 19 April 2024 (UTC)
- I think we should use the past tense for some events (e.g., any event that is definitively "finished") and present tense for those that are ongoing. I didn't see a single clear argument above for using the present tense for things that are completely finished [correction: except for CaptainEek, who wants to use historical past for the "vivid" dramatic effect]. There are comments about what label a grammarian would apply to it, and comments saying that this is the way we've always done it, but no comments giving a reason for why it's better for readers if we say that a ten-second earthquake from last week "is" happening instead of that it "did" happen. WhatamIdoing (talk) 00:50, 20 April 2024 (UTC)
- Because the historical present is a convention in English, period. There's also consistency with lists of past events, which also blocks useful things like moving navboxes to the See also. Aaron Liu (talk) 00:53, 20 April 2024 (UTC)
- The historical present is a convention in English. It is not the only convention, which means we could choose a different one. Why should we choose this convention? WhatamIdoing (talk) 01:01, 20 April 2024 (UTC)
- For consistency and compactness. Aaron Liu (talk) 02:51, 20 April 2024 (UTC)
- The amount of compactness is usually one character – the difference between
is
andwas
, orelects
andelected
. In other cases, it's the same or shorter:shook
instead ofshakes
for earthquakes,died
instead ofdies
for deaths. I don't think that sometimes saving a single character is worth the risk of someone misunderstanding the text, especially since we get so many readers who do not speak English natively. - As for consistency, I think that being easily understood is more important than having parallel grammar constructions across unrelated items. WhatamIdoing (talk) 05:28, 20 April 2024 (UTC)
- The amount of compactness is usually one character – the difference between
- For consistency and compactness. Aaron Liu (talk) 02:51, 20 April 2024 (UTC)
- The historical present is not the convention anywhere on Wikipedia's main page. Just see today:
- TFA: "The Nicoll Highway collapse occurred in Singapore...
- DYK: "...librarian Amanda Jones won an award..."
- OTD: "South African Airways Flight 228 crashed shortly after take-off ..."
- ITN is the only possible exception and it's not using the historical present because it's not referring to history.
- Andrew🐉(talk) 12:37, 20 April 2024 (UTC)
- The historical present is a convention in English. It is not the only convention, which means we could choose a different one. Why should we choose this convention? WhatamIdoing (talk) 01:01, 20 April 2024 (UTC)
- Because the historical present is a convention in English, period. There's also consistency with lists of past events, which also blocks useful things like moving navboxes to the See also. Aaron Liu (talk) 00:53, 20 April 2024 (UTC)
- I don't think anything needs to be changed here style-wise, we just need to write better ITN blurbs. "Solar eclipse is visible" isn't the historical present and it isn't sensible either. -- asilvering (talk) 06:21, 22 April 2024 (UTC)
- Not sure why this discussion isn't happening at WT:ITN, but stick with simple present as we have done for years. Stephen 09:49, 22 April 2024 (UTC)
- A notification has been at Wikipedia talk:In the news#Blurb tense for a while now. Putting this here attracts more attention.Most blurbs will not need to be changed to the past tense. Only things like "is visible" need to be changed. Aaron Liu (talk) 12:54, 22 April 2024 (UTC)
- The historical present should be taken behind the barn, shot, burned, and the ashes scattered to the four winds. --User:Khajidha (talk) (contributions) 14:02, 22 April 2024 (UTC)
- Violently expressed dislike is not the same as a reasoned argument. The historic present is used widely in headlines, timelines, and other applications both on this site and elsewhere which are comparable to the ITN headlines. GenevieveDEon (talk) 14:16, 22 April 2024 (UTC)
- Using present tense for completed events is ridiculous (which is even worse than wrong), no matter how much it may be used elsewhere. --~ User:Khajidha (talk) (contributions) 15:43, 22 April 2024 (UTC)
- But Wikipedia cares about consistency, present tense saves characters, and most events will not be confused as ongoing. Aaron Liu (talk) 15:48, 22 April 2024 (UTC)
- As I showed above, the present tense only occasionally saves characters, and the number of characters saved is most often one (1).
- In my experience, the English Wikipedia cares more about clarity accuracy than about consistency. There are ~650 pages citing Emerson: "A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines." (And now there is one more.) WhatamIdoing (talk) 23:30, 22 April 2024 (UTC)
- As you've said, I can't really articulate my thoughts on why we should use the historical present. I guess that's because not all grammar rules and conventions make sense either, yet they're usually prescribed. The most sense I could make is sort of "vividness": they emphasize that these events happen in the present day, as opposed to most of our content on the main page.I also wish that Wikipedia didn't care so much about consistency, but it seems that we do, which has led to navboxes not being moved to the see also section and nearly all of them turned into the standard purple. Maybe that made me think to consistify the consistency. Aaron Liu (talk) 00:01, 23 April 2024 (UTC)
- The rest of the main page uses past tense to refer to events that have occurred. The articles use the past tense to refer to past events. In the News isn't an up-to-the-moment news ticker; it points out articles that are related to current events. isaacl (talk) 00:14, 23 April 2024 (UTC)
- Past, yes, but as you said they’re related to current events. These events are much more current than the rest of the main page and historical present emphasizes that.
- Hopefully we have a rough consensus to at least put “otherwise confusing blurbs can you use the past tense” into the rules. Aaron Liu (talk) 00:17, 23 April 2024 (UTC)
- The point is for the main page, using the same tense as the rest of the page, as well as the underlying articles, would be consistent. isaacl (talk) 01:26, 23 April 2024 (UTC)
- The main page is just a reflection of the rest of the site. We don't need to force everything on the main page to be the same, and the underlying lists of stuff linked above also use historical present. Aaron Liu (talk) 11:14, 23 April 2024 (UTC)
The main page is just a reflection of the rest of the site
. My understanding is that ITN blurbs are literally the only place we enforce this stylistic choice. It's inconsistent with the actual articles linked in the blurb. [9] I can't help but think that if this situation was the other way around (the status quo was to be consistent) that people would find the arguments for this unconvincing. Clovermoss🍀 (talk) 11:19, 23 April 2024 (UTC)- Most of the site doesn't use blurbs, but all the year articles do. See Suffusion of Yellow's comment above. Aaron Liu (talk) 12:27, 23 April 2024 (UTC)
- I suppose then my question is if there's a consensus for year pages that things must be done that way then because it's not otherwise a stylistic choice you see outside of ITN blurbs. Clovermoss🍀 (talk) 15:02, 23 April 2024 (UTC)
- Most of the site doesn't use blurbs, but all the year articles do. See Suffusion of Yellow's comment above. Aaron Liu (talk) 12:27, 23 April 2024 (UTC)
- You brought up consistency as an argument. I feel a reader will notice inconsistency amongst sections of the main page more readily than between the In the News section and the year articles. There's no navigation path between the latter two, but readers can easily jump between sections of the main page. isaacl (talk) 16:26, 23 April 2024 (UTC)
- The main page is just a reflection of the rest of the site. We don't need to force everything on the main page to be the same, and the underlying lists of stuff linked above also use historical present. Aaron Liu (talk) 11:14, 23 April 2024 (UTC)
- The point is for the main page, using the same tense as the rest of the page, as well as the underlying articles, would be consistent. isaacl (talk) 01:26, 23 April 2024 (UTC)
- The rest of the main page uses past tense to refer to events that have occurred. The articles use the past tense to refer to past events. In the News isn't an up-to-the-moment news ticker; it points out articles that are related to current events. isaacl (talk) 00:14, 23 April 2024 (UTC)
- As you've said, I can't really articulate my thoughts on why we should use the historical present. I guess that's because not all grammar rules and conventions make sense either, yet they're usually prescribed. The most sense I could make is sort of "vividness": they emphasize that these events happen in the present day, as opposed to most of our content on the main page.I also wish that Wikipedia didn't care so much about consistency, but it seems that we do, which has led to navboxes not being moved to the see also section and nearly all of them turned into the standard purple. Maybe that made me think to consistify the consistency. Aaron Liu (talk) 00:01, 23 April 2024 (UTC)
- But Wikipedia cares about consistency, present tense saves characters, and most events will not be confused as ongoing. Aaron Liu (talk) 15:48, 22 April 2024 (UTC)
- Using present tense for completed events is ridiculous (which is even worse than wrong), no matter how much it may be used elsewhere. --~ User:Khajidha (talk) (contributions) 15:43, 22 April 2024 (UTC)
- Violently expressed dislike is not the same as a reasoned argument. The historic present is used widely in headlines, timelines, and other applications both on this site and elsewhere which are comparable to the ITN headlines. GenevieveDEon (talk) 14:16, 22 April 2024 (UTC)
- Retain historical present. ITN blurbs are intentionally written in the style of news headlines, and that makes most sense given global usage on this point. It would be silly for Wikipedia to have a set of news items written differently from how every other outlet writes its news items. Cases like the eclipse can be handled on an individual basis, by rewriting the blurb into an alternative historical present form that removes the implication of ongoing nature. Arguably that blurb was simply badly structured in the first place as a normal headline wouldn't contain the word "is". — Amakuru (talk) 09:50, 23 April 2024 (UTC)
- Wikipedia is not trying to be a news outlet; it's an encyclopedia. The correct comparison is then with a site like Britannica. Today, this opens with coverage of Passover:
April 23, 2024
Different from All Other Nights
Last night marked the beginning of the Jewish holiday of Passover, which commemorates the Hebrews’ liberation from slavery in Egypt and the “passing over” of the forces of destruction, or the sparing of the firstborn of the Israelites, on the eve of Exodus. This year’s celebration occurs against a backdrop of conflict—today also marks the 200th day in the Israel-Hamas War—and heightened concerns of rising anti-Semitism. - This makes the temporal context quite clear by dating the item and then using tenses accordingly -- the past tense for "last night" and the present tense for "today". Presumably tomorrow they will have a different item as their lead to reflect the fact that the present has moved on. This seems exemplary -- quite clearly explaining what's happening today specifically.
- Andrew🐉(talk) 11:05, 23 April 2024 (UTC)
- What about the present tense of "occurs"? I don't think a very long holiday is a good example.Looking at a few of their MP blurbs, most of them are anniversaries. Hopefully someone can find more examples of current events. Aaron Liu (talk) 11:13, 23 April 2024 (UTC)
- It's just a matter of looking. Today, Britannica has another holiday as its featured article – Arbor Day. But it also has a section Behind the Headlines which is similar to our ITN in covering current affairs. This consistently uses the past tense:
- Question of immunity
- As Donald Trump sat in a Manhattan courtroom for the hush-money case regarding Stormy Daniels, the Supreme Court heard arguments as to whether the former president was immune from prosecution...
- Weinstein trial
- The 2020 rape conviction of Harvey Weinstein in New York was overturned on Thursday...
- Falling down the rat hole
- Chicago’s “rat hole”—a section of sidewalk bearing the imprint of a rat—has been shuttered...
- Andrew🐉(talk) 22:11, 27 April 2024 (UTC)
- It's just a matter of looking. Today, Britannica has another holiday as its featured article – Arbor Day. But it also has a section Behind the Headlines which is similar to our ITN in covering current affairs. This consistently uses the past tense:
- What about the present tense of "occurs"? I don't think a very long holiday is a good example.Looking at a few of their MP blurbs, most of them are anniversaries. Hopefully someone can find more examples of current events. Aaron Liu (talk) 11:13, 23 April 2024 (UTC)
- Wikipedia is not trying to be a news outlet; it's an encyclopedia. The correct comparison is then with a site like Britannica. Today, this opens with coverage of Passover:
- Use historical present I don't see why WP:NOTNEWS is being brought up, because in that case surely we should be advocating for the elimination of a section titled "In The News"? If ITN continues to exist, it should use the style common to most respected news publications—the historical present. ~~ AirshipJungleman29 (talk) 16:07, 28 April 2024 (UTC)
- Not broken, don't fix. In the vast majority of cases, the current approach works perfectly fine and without any chance of confusion. In the very few cases where the blurb phrasing is ambiguous, that can be brought up at WP:ERRORS and an appropriate rephrasing found. We don't need a new rule here. Also, this RFC confuses ITN with the Main Page - present tense is only used in one section of the MP. Modest Genius talk 12:53, 29 April 2024 (UTC)
- All this does is make the present-tense rule less stringent so that it'd be easily overridden if needed. That's also what this new "rule" says. Aaron Liu (talk) 12:59, 29 April 2024 (UTC)
- ITN is part of the main page. Clovermoss🍀 (talk) 15:51, 29 April 2024 (UTC)
- Comment: I was curious about the assertion that most news organizations use the present tense, so I did a quick survey:
- NYT: mix of present and past
- AP: present
- Reuters: present
- BBC: mix
- The Times: mix
- LA Times: mix
- (NB: I'm not watching this page, please ping.) LittlePuppers (talk) 17:03, 1 May 2024 (UTC)
- I noticed that the main page is currently using the past tense to describe an event (usage of
seen
in regards to the aurorae). My proposal supports this usage but it goes against the current version of the special rules for ITN which is always use present. I suppose my point is that the world hasn't ended and that I think my proposal still has merit. I also think this is leagues better than implying the aurorae is visible or appearing, which was my whole gripe with how we described the solar eclipse when it was on the main page. I'm not sure if this is a sign that my proposal has made any strides in convincing people that certain cases may warrant an exemption or if this will be considered an error that someone will try to fix. Clovermoss🍀 (talk) 14:36, 13 May 2024 (UTC)- "Seen" is used somewhat as the participle here, so while I agree, I don't think this violates the current rules. Aaron Liu (talk) 14:41, 13 May 2024 (UTC)
- Wouldn't it be considered to be past participle, though? The current rules don't allow for anything to be written outside the present tense. Hopefully I'm not making a fool of myself and missing something obvious? Clovermoss🍀 (talk) 14:48, 13 May 2024 (UTC)
A series of solar storms impact Earth, creating aurorae (pictured) seen further from the poles than usual
. Most of this reads to me as present tense, except the usage of "seen". However, I won't outrule the possibility I'm stupid and not understanding how English works. Clovermoss🍀 (talk) 14:56, 13 May 2024 (UTC)- The verb that functions as a verb in the sentence is "impact", which is in the present tense. Aaron Liu (talk) 15:20, 13 May 2024 (UTC)
- I'm confused about what you mean by this. I understand what you're saying here but I don't understand the broader relevance to what I was talking about. I think I need to learn more about how the English language works, then. Clovermoss🍀 (talk) 15:44, 13 May 2024 (UTC)
- With hidden words, apparently. You can read that clause as "which were seen" or "which are seen", thus letting everyone believe that this clause was written "their" way. WhatamIdoing (talk) 16:32, 13 May 2024 (UTC)
- This does make sense to me. Clovermoss🍀 (talk) 12:51, 14 May 2024 (UTC)
- With hidden words, apparently. You can read that clause as "which were seen" or "which are seen", thus letting everyone believe that this clause was written "their" way. WhatamIdoing (talk) 16:32, 13 May 2024 (UTC)
- I'm confused about what you mean by this. I understand what you're saying here but I don't understand the broader relevance to what I was talking about. I think I need to learn more about how the English language works, then. Clovermoss🍀 (talk) 15:44, 13 May 2024 (UTC)
- Wouldn't it be considered to be past participle, though? The current rules don't allow for anything to be written outside the present tense. Hopefully I'm not making a fool of myself and missing something obvious? Clovermoss🍀 (talk) 14:48, 13 May 2024 (UTC)
- "Seen" is used somewhat as the participle here, so while I agree, I don't think this violates the current rules. Aaron Liu (talk) 14:41, 13 May 2024 (UTC)
- Discussion on this seems to be dying down a bit, so I decided to go through and reread the above discussion. It seems there's 14 people for my proposal and 14 against it. Obviously I'm biased here but I think there's stronger policy-based arguments on my side of the debate: WP:NOTNEWS, WP:NEWSSTYLE, MOS:TENSE, and consistency with almost every other part of the project. The arguments on the opposing side for keeping WP:ITNBLURB the way it is without any exemptions include: not broken, historical present/active writing sounds better, and that some newspapers use this in their version of ITN. Clovermoss🍀 (talk) 12:51, 14 May 2024 (UTC)
- I have to support the gist of this, that "
events listed on ITN that have definitively ended should be described in the past tense
". Drop the part reading "if it would otherwise mislead readers into thinking an event is ongoing
, to result in more consistent material (we really have no need to write about ended/past events in the present tense for any reason). In short, the front page needs to be written with the same accuracy and clarity as the rest of our material, including MOS:TENSE and any other applicable style and content guidelines. The wikiprojects that have arisen to manage particular boxes of content on the front page are not in a magically special position to make up their own rules that defy site-wide consensus on how our content needs to be written (per WP:CONLEVEL and WP:PROJPAGE). — SMcCandlish ☏ ¢ 😼 02:48, 23 May 2024 (UTC)
Wikidata Items shown on Wikipedia?
I have come across a template, {{Public art header}}, that has among its far-too-many columns a way to list the Wikidata Item identifier (the number beginning with Q) for all the listed public art installations. It seems to me to be unique; I don't think I have seen a Wikidata Item displayed anywhere else on Wikipedia. Also, I don't think that readers will understand these Q-numbers, and clicking on them doesn't lead to some sort of trove of valuable information. Can this be fixed? Abductive (reasoning) 10:02, 30 April 2024 (UTC)
- Is there a reason you've asked this question here rather than at Template talk:Public art row (where the header template talk page redirects), Wikipedia talk:WikiProject Visual arts or Wikipedia talk:WikiProject Visual arts/Public art? It seems that editors familiar with the template are far more likely to see your query there. Thryduulf (talk) 11:24, 30 April 2024 (UTC)
- I've left notifications at the first and last of those locations, so hopefully someone with relevant knowledge will see your query. I'm still not sure what the connection to policy is though. Thryduulf (talk) 11:27, 30 April 2024 (UTC)
- I'm curious if there is a policy on display of Wikidata item identifiers in Wikipedia mainspace? Abductive (reasoning) 14:29, 30 April 2024 (UTC)
- Wikipedia:Wikidata#Appropriate usage in articles: 2018 RFC decided "Wikidata should not be linked to within the body of the article except in the manner of hidden comment(s) as to mentioning the Q-number." Not the clearest text, but the intention of the RfC was to disallow the display / link to Wikidata Q numbers in body of articles (linking in templates like taxonbox is a grey area). It's about as meaningful as displaying the Wikipedia page ID somewhere (yes, Wikipedia articles have a page ID, e.g. this very page has ID 986140). Fram (talk) 14:50, 30 April 2024 (UTC)
- Per WP:WIKIDATA (an information page, not a policy or guideline) there appears to be a consensus (from 2018) that
"Wikidata should not be linked to within the body of the article except in the manner of hidden comment(s) as to mentioning the Q-number."
the subsequent mentioned February 2023 RFC found no consensus to change the status quo, but it focused almost exclusively on pulling data from Wikidata in lists rather than links to Wikidata, so it appears the 2018 consensus is the most recent relevant one. - That would seem to suggest that such links should not be displayed, but (a) the consensus is old, and (b) consensuses against using Wikidata have always been weaker regarding tables than prose so I don't think there is any justification for making changes without prior discussion.
- As for my opinions on the desirability of inclusion, I'm open-minded about the value of links to the Wikidata item (which sometimes contains additional structured data not in the article, especially for works that don't have a standalone article) but I don't think the QID number is the optimal way to present such a link (although I can't immediately think of anything better). Thryduulf (talk) 14:58, 30 April 2024 (UTC)
- The consensus is not old because sensible editors are nearly universally still following it—even if they don't know it exists. What fraction of the 6.8 million articles display a Q-number? The few uses are cruft and need to be removed forthwith. Abductive (reasoning) 15:32, 30 April 2024 (UTC)
- That's not how consensus works. The consensus is old, because it was arrived at a long time ago. The age of the consensus is unrelated to whether it is still current - that can only be confirmed through discussion. It could be that few articles display Q-numbers because there is a consensus that Q-numbers should not be articles, or it could be that there is a consensus that Q-numbers should only be displayed in particular circumstances (which happen to be uncommon). Both options are consistent with the facts as presented so far. Rather than making hyperbolic assertions and demands it would be better to first have a calm and rational discussion about whether anything has changed in the last six years and see whether consensus still holds or something more nuanced is now appropriate. However, you seem to have actively avoided seeking the views of anyone who might be able to present an explanation for and/or argument in favour of Q-number inclusion in the template I'm not sure that you are actually interested in consensus.
- To be clear I'm not arguing for or against inline links to Wikidata in tables, I'm arguing against adding or removing such links before the matter has been discussed civilly and with an open mind. Thryduulf (talk) 16:06, 30 April 2024 (UTC)
- My take is that the only reason that these Q-numbers have survived is because they are protected by being in a template. (And if February 2023 is old....) Please tell me the process that can enforce or reinvigorate the current/allegedly old consensus for another year at least. Abductive (reasoning) 20:15, 30 April 2024 (UTC)
- I don’t mind confirming the consensus. I will say what I said last time we discussed it… I think the links to Wikidata have no real benefit to Wikipedia. Q-numbers are incomprehensible to those not already familiar with Wikidata, and the structure of the Wikidata pages if you click on the Q-link is even more confusing. Wikipedia uses text to convey information… Wikidata does not. This results in incompatibility. Blueboar (talk) 20:25, 30 April 2024 (UTC)
And if February 2023 is old....
the February 2023 discussion did not discuss in any depth any of templates, tables or links (it was almost entirely concerned with pulling information into running text and infoboxes). No discussion, no matter how old or new, is relevant to matters not featured in that discussion. Thryduulf (talk) 20:58, 30 April 2024 (UTC)
My take is that the only reason that these Q-numbers have survived is because they are protected by being in a template
is definitely true in a sense - I run an AWB run to enforce the 2018 consensus every month, but that just looks for articles that have a link to Wikidata either directly or through {{Wikidata entity link}}. * Pppery * it has begun... 00:44, 2 May 2024 (UTC)- I don't know if this is germane but wanted to mention that we do have "WD" as an option for the interlanguage links template.
- sample usage:
- "He was the founder of Film History: An International Journal "
- source:
- He was the founder of {{ill|Film History: An International Journal|wd=Q15751437|short=yes|italic=yes}}
- I personally would be bummed if this option went away. (But also the Q number proper is not visible inline so maybe policy doesn't apply?) jengod (talk) 06:06, 2 May 2024 (UTC)
- I agree that links like this may be good. No Q number should display on any article, but red-links to pages, along with a WikiData page link, are useful for some readers to get a better understanding of the red-linked topic. This is just like links to other language Wikipedias; a link to a Hebrew article won't benifit most readers, but the few it does benifit along with a red link will gain a lot. Animal lover |666| 07:40, 3 May 2024 (UTC)
- My take is that the only reason that these Q-numbers have survived is because they are protected by being in a template. (And if February 2023 is old....) Please tell me the process that can enforce or reinvigorate the current/allegedly old consensus for another year at least. Abductive (reasoning) 20:15, 30 April 2024 (UTC)
- The consensus is not old because sensible editors are nearly universally still following it—even if they don't know it exists. What fraction of the 6.8 million articles display a Q-number? The few uses are cruft and need to be removed forthwith. Abductive (reasoning) 15:32, 30 April 2024 (UTC)
- I'm curious if there is a policy on display of Wikidata item identifiers in Wikipedia mainspace? Abductive (reasoning) 14:29, 30 April 2024 (UTC)
- I've left notifications at the first and last of those locations, so hopefully someone with relevant knowledge will see your query. I'm still not sure what the connection to policy is though. Thryduulf (talk) 11:27, 30 April 2024 (UTC)
Question for those who think Wikidata is useful
- HOW?
- This isn’t meant as a snarky question… Perhaps it is because I am very text oriented… but I honestly do not even fully understand the purpose of Wikidata. I know Wikidata compiles some sort of metadata about things, but what is it compiling and why?
- When I look at a Wikidata page, I don’t understand what I am looking at… much less how I could use it. So hopefully someone can explain it to me… what information does it compile and how is a reader or editor of Wikipedia use that information? Walk me through an example. Blueboar (talk) 11:50, 3 May 2024 (UTC)
- My impression is it is like a catalogue for data on subjects. Alanscottwalker (talk) 16:20, 3 May 2024 (UTC)
- I think that connecting different articles, pictures etc on the same topic across the various wikis is useful. Wikidata doesn't only compile metadata it also creates metadata, the most important thing it does is assign a Wikidata number to every thing in the known wiki universe. If someone in Russia uploads a picture of a Forest-steppe marmot (Wikidata number Q12841876) to ruwiki Wikidata makes that image findable by someone from enwiki who doesn't speak Russian. Horse Eye's Back (talk) 16:37, 3 May 2024 (UTC)
- No, that's Commons, or should be! I spend a lot of time looking for and at images, but would never use Wikidata, which has tiny numbers, poorly categorized. Johnbod (talk) 17:04, 3 May 2024 (UTC)
- Commons doesn't connect pages, but it could fill that role for imagery alone. Horse Eye's Back (talk) 17:06, 3 May 2024 (UTC)
- It does (Wikidata itself has no pics of your marmots). Before Wikidata we had a generally effective system for connecting articles in different languages. Johnbod (talk) 17:13, 3 May 2024 (UTC)
- Commons does not host article unless I am mistaken. Horse Eye's Back (talk) 20:39, 3 May 2024 (UTC)
- It does (Wikidata itself has no pics of your marmots). Before Wikidata we had a generally effective system for connecting articles in different languages. Johnbod (talk) 17:13, 3 May 2024 (UTC)
- Commons doesn't connect pages, but it could fill that role for imagery alone. Horse Eye's Back (talk) 17:06, 3 May 2024 (UTC)
- No, that's Commons, or should be! I spend a lot of time looking for and at images, but would never use Wikidata, which has tiny numbers, poorly categorized. Johnbod (talk) 17:04, 3 May 2024 (UTC)
- My impression is that the amount of energy and editor effort that goes into putting data into Wikidata is out of all proportion to the amount of data that is extracted from Wikidata. We have dug an enormous deep well, provided with a plastic cup and piece of string for extraction. Johnbod (talk) 17:04, 3 May 2024 (UTC)
- The English Wikipedia extracts only a tiny amount of data from Wikidata (because we have policies against doing more), but other projects use more. The same is true of Commons: an awful lot more effort gets put into adding and maintaining (categorising, etc) images on Commons than the English Wikipedia gets out of it. Thryduulf (talk) 17:15, 3 May 2024 (UTC)
- I don't think the issue is the extraction tools, which can be enhanced as desired, but concerns about the ensuring the quality of the water. (The analogy breaks down a bit here, since the community is putting the water into the well; a water tower might be a somewhat better analogy.) isaacl (talk) 18:03, 3 May 2024 (UTC)
- @Blueboar Wikidata is essentially a collection of factual statements about a subject in a highly structured format similar to infoboxes. In theory a Wikidata entry and a Wikipedia article should convey the same information such that you can construct one from the other (in practice it's not quite the same, but when both are high quality its close).
- Taking a random example Statue of George Canning, Parliament Square and d:Q21546419
- Wikipedia: The statue of George Canning in Parliament Square, Westminster, London, is an 1832 work by Sir Richard Westmacott. The 3.56 metres (11.7 ft) bronze sculpture depicts George Canning (British Prime Minister during 1827)...The statue stands on a 4.4 metres (14 ft) granite plinth which bears the inscription "GEORGE CANNING".
- Wikidata: Instance of: Statue. Location: Westminster. Located on street: Parliament Square. Located in the administrative territorial entity: City of Westminster. Inception: 1832. Creator: Richard Westmacott. Height: 3.56±0.01 metre (applies to part: statue), 4.4±0.01 metre (applies to part: plinth). Made from material: Bronze (applies to part: statue), Granite (applies to part: plinth). Inscription: GEORGE CANNING (language: English; location: Plinth).
- Thryduulf (talk) 17:12, 3 May 2024 (UTC)
- That's a stub article, & doesn't answer the question: what's the point? Johnbod (talk) 17:16, 3 May 2024 (UTC)
- There isn't much of one. The people who boost Wikidata, and the people interested in maintaining and building a verifiable, high-quality encyclopedia, don't seem to have a ton of overlap. Most of the "pros" of Wikidata aren't pros for us (you mean we can autofill infobox fields with stuff that has less quality control and no referencing? Oh boy!) and are more aimed at people who harvest Wikipedia for data. Der Wohltemperierte Fuchs talk 17:26, 3 May 2024 (UTC)
- Wikidata is a structured database of facts with great potential. Unfortunately, as you point out above, this well comes with a plastic cup, rather than the more sophisticated plumbing required for that data to flow freely and be tapped productively. It may turn out to be a dead end but could become a core element of the future of knowledge. For example, rather than having AI mine the net and plagiarise whatever plausible junk it found in someone's blog, one might build a system which can respond to natural-language questions with answers as accurate as Wikidata's content. Certes (talk) 17:39, 3 May 2024 (UTC)
- It being a stub-article is irrelevant. The point is to collate a repository of factual information in a structured format, which is similar to but not the same as Wikipedia's goal to collate a repository of encyclopaedic information in prose (and list) format. The information is mostly the same (although Wikipedia's inclusion criteria are more restrictive), it's just presented very differently. Some people find it extremely useful to have the information in structured format, that other people don't understand why they find it useful is irrelevant. Thryduulf (talk) 17:39, 3 May 2024 (UTC)
- https://www.mediawiki.org/wiki/Structured_Data_Across_Wikimedia Well intentioned at least. Selfstudier (talk) 17:43, 3 May 2024 (UTC)
- Thank you all for at least trying to explain. I get that WD is a compilation of “structured data” … But I suppose I am still confused as to why we are structuring that data in the first place (because we can?)… then I ask: why do we structure it the incomprehensible way we do. To me it looks like gobbledegook. It certainly isn’t the sort of thing “Anyone can edit” (because I certainly couldn’t). Anyway… thanks again for your patience with me. Blueboar (talk) 19:37, 3 May 2024 (UTC)
- Structured data has lots of advantages for situations like machine parsing, assisted translation, etc. The way we structure it is very logical and extremely far from gobbledegook - at least to me (and probably more so to people like computer programmers). The barrier to contributing is slightly higher than Wikipedia, but it is a project anyone can edit. Thryduulf (talk) 20:17, 3 May 2024 (UTC)
- Ah… so the primary purpose is to aid machines? (Not meant as snark). Blueboar (talk) 20:47, 3 May 2024 (UTC)
- Any automated process can benefit. That includes the most used example at present: enabling every language Wikipedia to have the same set of cross-language Wikipedia links for a given article. If the issue of ensuring the data was verified and kept stable according the the standards of all language Wikipedia sites, then pulling more data automatically through, say, templates could be done. Birthdates could be easily synched, citations could be generated automatically, and so forth. The verification and stability issue remains a key challenge, though, and Wikidata's current user interface is likely an impediment for expanding its user base to a more general population. isaacl (talk) 21:15, 3 May 2024 (UTC)
- It's been a while since I entered any data into Wikidata, but when I did, I found it took a considerable amount of time to enter in all the data items to fully cover every property of the source of the data. I appreciate that's the way it goes when every piece of data is an item in its own right with its own properties. It would help a lot, though, if an interface could be devised to automate as much of the work as possible: perhaps something that could traverse down the tree, match up property values to corresponding existing data items as much as possible, show placeholders for new items that need to be created, and present the tree for editing. (Maybe there's been enhancements already that speed up the process?) isaacl (talk) 21:25, 3 May 2024 (UTC)
- Ah… so the primary purpose is to aid machines? (Not meant as snark). Blueboar (talk) 20:47, 3 May 2024 (UTC)
- Wikipedia is legible by humans. Wikidata is legible by computers. Its potential is for answering questions like the example above : "What is the oldest bronze statue in London over 3 metres tall?". It just needs an intuitive interface, and protection from the vandalism which will inevitably occur once non-specialists begin to hear of it. Certes (talk) 21:39, 3 May 2024 (UTC)
- Structured data has lots of advantages for situations like machine parsing, assisted translation, etc. The way we structure it is very logical and extremely far from gobbledegook - at least to me (and probably more so to people like computer programmers). The barrier to contributing is slightly higher than Wikipedia, but it is a project anyone can edit. Thryduulf (talk) 20:17, 3 May 2024 (UTC)
- Thank you all for at least trying to explain. I get that WD is a compilation of “structured data” … But I suppose I am still confused as to why we are structuring that data in the first place (because we can?)… then I ask: why do we structure it the incomprehensible way we do. To me it looks like gobbledegook. It certainly isn’t the sort of thing “Anyone can edit” (because I certainly couldn’t). Anyway… thanks again for your patience with me. Blueboar (talk) 19:37, 3 May 2024 (UTC)
- https://www.mediawiki.org/wiki/Structured_Data_Across_Wikimedia Well intentioned at least. Selfstudier (talk) 17:43, 3 May 2024 (UTC)
- That's a stub article, & doesn't answer the question: what's the point? Johnbod (talk) 17:16, 3 May 2024 (UTC)
- Wikidata is serves as a central repository for all Wikimedia projects. It connects the same topic across languages much easier, the identifiers can be used to build redlists (such as WP:WikiProject Women in Red/Redlist index) quite intuitively using SPARQL, and through WP:Authority control we can connect between the Wikidata entry and outside repositories such as VIAF and national library catalogs and WorldCat (see the Authority control article for why this is of supreme importance to us). You can probably find more info on their help pages. Curbon7 (talk) 20:15, 3 May 2024 (UTC)
- A central repository of what? Blueboar (talk) 20:48, 3 May 2024 (UTC)
- Data. Curbon7 (talk) 20:54, 3 May 2024 (UTC)
- What data? All data? Specific data? Data for the sake of collecting data? Blueboar (talk) 21:08, 3 May 2024 (UTC)
- To explain fully is to explain the entire field of Library and information science, so for our purposes see Thryduulf's Canning example above:
Instance of: Statue. Location: Westminster. Located on street: Parliament Square. Located in the administrative territorial entity: City of Westminster. Inception: 1832. Creator: Richard Westmacott. Height: 3.56±0.01 metre (applies to part: statue), 4.4±0.01 metre (applies to part: plinth). Made from material: Bronze (applies to part: statue), Granite (applies to part: plinth). Inscription: GEORGE CANNING (language: English; location: Plinth)
is all data. Using SPARQL queries, you can use this to find, for example, all listed instances of statues incepted in 1832 or statues by Richard Westmacott in Westminster or whatever other query is desired. This is one of the purposes of Wikidata, but not the only one, as I've explained above. Curbon7 (talk) 21:27, 3 May 2024 (UTC)- Crotos is one of the best applications built from Wikidata in my opinion; it's a search engine for artworks, and the results for individual artists can be browsed in chronological order. These are the results for Richard Westmacott. My hope is that the use of the template {{Public art row}} on pages like (as it happens) Richard Westmacott could be used to further populate Wikidata, by generating Wikidata data items based on instances of the template on the page. In that scenario the
wikidata
parameter in the template would be useful for indicating which items in the list already have Wikidata items and which don't yet. That wouldn't be a reason to display the Wikidata ID on the page, though; it would only need to be in the code. @14GTR, what do you think of this? Ham II (talk) 05:20, 4 May 2024 (UTC)- Thanks for pinging me to this Ham II & apologies for the delay in replying - busy times. I have not come across Crotos before and would need to see more of it before commenting on it. I would say that including the Wikidata number beside individual items in a table of artworks or monuments simply provides a link to further sources of information on that specific item, including the various art databases, national archives and major libraries with relevant entries. To me, including the Wikidata number in such tables performs the same, or a similar, service that the Authority Control template provides at the bottom of a single-subject page. The only substantial difference, I can see is that an AC template, and others such as Art UK bio template, take their data from the Wikidata page while the Q number takes the reader to the Wikidata page. I've yet to see a table or chart with multiple Authority Control templates in it, so presumably that's why the Wikidata option is included in the table header. Again, thanks for the ping.14GTR (talk) 13:52, 14 May 2024 (UTC)
- Crotos is one of the best applications built from Wikidata in my opinion; it's a search engine for artworks, and the results for individual artists can be browsed in chronological order. These are the results for Richard Westmacott. My hope is that the use of the template {{Public art row}} on pages like (as it happens) Richard Westmacott could be used to further populate Wikidata, by generating Wikidata data items based on instances of the template on the page. In that scenario the
- To explain fully is to explain the entire field of Library and information science, so for our purposes see Thryduulf's Canning example above:
- What data? All data? Specific data? Data for the sake of collecting data? Blueboar (talk) 21:08, 3 May 2024 (UTC)
- Data. Curbon7 (talk) 20:54, 3 May 2024 (UTC)
- A central repository of what? Blueboar (talk) 20:48, 3 May 2024 (UTC)
- I imagine big tech companies find it useful as an input for training their AIs. Barnards.tar.gz (talk) 20:42, 3 May 2024 (UTC)
- This applies much more to Wikipedia than to Wikidata, because LLMs take input in the form of long text documents rather than abstract representations of propositions. MartinPoulter (talk) 08:32, 4 May 2024 (UTC)
- @Blueboar You've already received a number of good answers, but here's my perspective. Wikidata has a large number of possible uses, not only for other WMF projects, but also for third parties. For Wikipedias, beyond the basic task of maintaining inter-wiki links, Wikidata generally has the information required to fill in most of an infobox: That is how it is used on most projects, and the English Wikipedia is an outlier in underusing this.
- @Johnbod "
Before Wikidata we had a generally effective system for connecting articles in different languages
" The old system was that every project maintained their own list of equivalent articles. This resulted in a lot of duplicated effort and inconsistency between projects, and generally poor results for small projects, but it more-or-less worked out for larger projects. Bovlb (talk) 18:11, 8 May 2024 (UTC)- What are you talking about? The old system (which can still be seen in the French, Italian & other wps) was nothing to do with projects. Each article had a list of interwiki links off to the side, which was manually maintained, with no doubt bots doing the exact matches. Rather more trouble to maintain, but generally pretty effective. Johnbod (talk) 00:00, 9 May 2024 (UTC)
- One of us is confused. All Wikipedias have been using Wikidata for the interwiki links for some time. The "list off to the side" is now maintained in Wikidata (largely manually). There is no difference in the way ENWP, FRWP, and ITWP do this.
- In the old days, interwiki links were stored within the article on each project. There was some bot support for copying this from project to project, but that process had limitations. Bovlb (talk) 00:54, 9 May 2024 (UTC)
- What are you talking about? The old system (which can still be seen in the French, Italian & other wps) was nothing to do with projects. Each article had a list of interwiki links off to the side, which was manually maintained, with no doubt bots doing the exact matches. Rather more trouble to maintain, but generally pretty effective. Johnbod (talk) 00:00, 9 May 2024 (UTC)
- @David Fuchs "
you mean we can autofill infobox fields with stuff that has less quality control and no referencing
" Every project struggles with quality control and referencing, and Wikidata is no exception. The benefit of storing this information centrally for all projects is that the effort to ensure quality control and add references can be shared across all WMF projects. Again, this is an area where larger projects get the smaller benefit but have an opportunity to contribute more to smaller projects. If larger projects choose to boycott Wikidata because of (perceived) quality problems, then this becomes a self-fulfilling prophecy. Bovlb (talk) 18:11, 8 May 2024 (UTC)
- Wikidata is a wonderful idea in theory, particularly for Wikipedias in less widely known languages than English. For us at English Wikipedia there are two drawbacks - as the largest Wikipedia most of the traffic goes in the direction Wikipedia->Wikidata rather than the reverse, and (from anecdotal evidence) they do not seem to apply policies and guidelines as strictly as we do. Phil Bridger (talk) 19:31, 3 May 2024 (UTC)
- "
they do not seem to apply policies and guidelines as strictly as we do
" I'd be interested to hear more about this. Wikidata has its own policies and guidelines that differ from other projects. Inasmuch as it is a shared resource between all other WMF projects, it is broadly required to permit anything needed to support any client project. For example, this means that it cannot impose general restrictions on IP users or be aggressive about inappropriate usernames. Bovlb (talk) 18:18, 8 May 2024 (UTC)- I didn't mean policies about whether an editor chooses to register and under what user name, but about sourcing. As I say my evidence is anecdotal, and it is from the early days of Wikidata, but I understand that the reason Wikidata is not used more widely on the English Wikipedia is because much of the content is not reliably sourced. Phil Bridger (talk) 19:27, 8 May 2024 (UTC)
- There is a lot of information on Wikidata that is not sourced, and much more that is sourced to a Wikipedia (which may or may not itself be reliably sourced). Just like on Wikipedia lack of sourcing doesn't mean it's necessarily wrong of course. It is far easier to tell what information on Wikidata is and isn't sourced than it is on Wikipedia, as every statement has (or doesn't have) an associated source where here a source at the end of a paragraph my back up all or only some of the claims made within it. This does mean that it's easier to generate sourced Wikipedia content from Wikidata than vice versa.
- Obviously "source" and "reliable source" are not necessarily the same thing, but that's no different to sourcing here - it can only be assessed in terms of the specific claim and context. However the 1:1 link between claim and source means that that assessment can be easier (e.g. there is much less room for argument about whether a non-MEDRS source is being used to support a biomedical claim). Thryduulf (talk) 19:46, 8 May 2024 (UTC)
- In the early days of Wikidata, there was a much weaker emphasis on sources than there is now. This mirrors the development of Wikipedia. Just as with Wikipedia, they don't require a reference for every statement, just those that are challenged. Certain properties are inherently likely to be challenged, so should generally be referenced, and there is automated detection of such problems. References are also important for establishing notability on Wikidata. Many statements are marked as being imported from Wikipedia, which is more of a tracking annotation than a true reference.
- As I said above, Wikidata definitely struggles with quality issues and a lack of references. I believe that a greater use of Wikidata by large projects like the English Wikipedia would improve both of these, not only through many eyes seeing defects and many hands fixing them, but also because it would lead to the development of better tools.
- Wikidata was created to support and improve client projects like the English Wikipedia. If it's not serving those needs, please help it to do better. Bovlb (talk) 21:19, 8 May 2024 (UTC)
- I didn't mean policies about whether an editor chooses to register and under what user name, but about sourcing. As I say my evidence is anecdotal, and it is from the early days of Wikidata, but I understand that the reason Wikidata is not used more widely on the English Wikipedia is because much of the content is not reliably sourced. Phil Bridger (talk) 19:27, 8 May 2024 (UTC)
- "
- Best I can tell, Wikidata was an attempt to crowdsource a world model to be used for development/implementation of "AI" agents; save cost and time for large corporations working AI. That was before transformers happened. Old "AI"s are probably still using it. Usedtobecool ☎️ 05:56, 4 May 2024 (UTC)
- That's a weird bundle of misconceptions. The way Linked data and the Semantic web work is different, arguably opposite, to what transformers do. That's why there's interest in getting them to work together. Also, why focus on "large corporations" rather than the opportunities for programmers to create apps and visualisations in a day that used to take months? MartinPoulter (talk) 08:30, 4 May 2024 (UTC)
- That, or you just misunderstood what I was saying. My point was, post-transformers, AI is reading Wikipedia, and all other natural-language sources directly. I wouldn't be surprised if I was wrong since I'm mainly going by our own articles, but they say Google, among others, funded Wikidata and once it was up and running, closed its own project for a similar base. Google knowledge graph must be using Wikidata, since it closed freebase and exported it to Wikidata. Amazon and Apple also use it for their virtual assistants. Sure, anyone could use it; I mentioned large corporations because they're the ones using it for anything worth mentioning per our articles.
- That's a weird bundle of misconceptions. The way Linked data and the Semantic web work is different, arguably opposite, to what transformers do. That's why there's interest in getting them to work together. Also, why focus on "large corporations" rather than the opportunities for programmers to create apps and visualisations in a day that used to take months? MartinPoulter (talk) 08:30, 4 May 2024 (UTC)
- As the OP likes the way that Wikipedia presents data, they should just read its article Wikidata which provides plenty of information about that project and its uses. One of its sources is a systematic review of the scholarly literature about the project. Andrew🐉(talk) 20:26, 8 May 2024 (UTC)
- Thanks to all for the replies. FYI, I actually did read the Wikidata article before I posted my questions. I found the explanations here in this thread more informative than the article (perhaps there was less “jargon” being used here?) Anyway… while I am still baffled by a lot at WD (and could not edit or contribute to it at all) you have all helped me to at least better understand why it was created in the first place… so thanks again. Blueboar (talk) 21:07, 8 May 2024 (UTC)
Copy paste plagiarism from out of copyright materials.
Hi, I was just wondering what the correct template is for signalling articles which have copypasted text from an out of copyright source. This article is a word for word copy from this source, and I'm pretty sure that's not ok, so we must have a template. Boynamedsue (talk) 16:45, 7 May 2024 (UTC)
- It is ok, since the source is in the public domain and the text is properly attributed. There are many templates used to attribute the sources being copied, and that article uses one of them (Template:DNB). Firefangledfeathers (talk / contribs) 16:49, 7 May 2024 (UTC)
- In the early days, it was considered a good thing to copy articles from the 1911 Encyclopedia Brittanica to fill in the gaps. Donald Albury 17:02, 7 May 2024 (UTC)
- Many people (not the OP) don't seem to understand the difference between copyright violation and plagiarism. Copyright violation is the copying of copyrighted text with or without attribution against the terms of the copyright licence (with an allowance for "fair use" in nearly all jurisdictions). Plagiarism is the passing off of someone else's work as one's own, whether the work is copyrighted or not. This is not copyright violation, because it is out of copyright, and not plagiarism, because it is properly attributed. Phil Bridger (talk) 17:47, 7 May 2024 (UTC)
- So, let me get this straight, are users saying that it is ok to copypaste text from an out of copyright text as long as that text is attributed? This feels very wrong, which wikipolicies allow this?Boynamedsue (talk) 22:19, 7 May 2024 (UTC)
- See the content guideline at Wikipedia:Plagiarism. While at least some editors would prefer that such material be rewritten by an editor, there is no prohibition on copying verbatim from free sources; it is allowed as long as proper attribution to the original source is given. Donald Albury 22:39, 7 May 2024 (UTC)
- I think it needs to be done with considerable caution if at all, and it just seems like a less ideal option in almost every case, save for particular passages that are just too hard to rewrite to the same effect. But I think the consensus is that it is allowed. Remsense诉 01:20, 8 May 2024 (UTC)
- Copyright has a limited term (though these days, in many countries, a very long one) precisely to allow the work of the past to be built upon to generate new creative works. isaacl (talk) 01:48, 8 May 2024 (UTC)
- Nothing new is generated when you copy something verbatim. Traumnovelle (talk) 08:43, 12 May 2024 (UTC)
- Remixing from sampled works is increasingly common. Imitating other people's work is done to learn new styles. Jazz music specifically has a tradition of incorporating past standards into new performances. Critical analysis can be more easily placed in context as annotations. And from an educational standpoint, more people can learn about/read/watch/perform works when the barrier to disseminating them is lessened. What's in copyright today is the source of new widely-spread traditional works in the future. isaacl (talk) 14:44, 12 May 2024 (UTC)
- Aye, every time you read a poem it's a new translation. If this were Wikiversity, I think there'd actually be a lot of room for interesting experiments remixing\ PD material. Remsense诉 14:46, 12 May 2024 (UTC)
- You wrote a lot but none of it actually addresses what I've said. Traumnovelle (talk) 15:33, 12 May 2024 (UTC)
- I gave examples of new creative works that have copied past work verbatim. isaacl (talk) 04:11, 13 May 2024 (UTC)
- Remixing from sampled works is increasingly common. Imitating other people's work is done to learn new styles. Jazz music specifically has a tradition of incorporating past standards into new performances. Critical analysis can be more easily placed in context as annotations. And from an educational standpoint, more people can learn about/read/watch/perform works when the barrier to disseminating them is lessened. What's in copyright today is the source of new widely-spread traditional works in the future. isaacl (talk) 14:44, 12 May 2024 (UTC)
- Nothing new is generated when you copy something verbatim. Traumnovelle (talk) 08:43, 12 May 2024 (UTC)
- Actually, comparing the two, and looking at the edit history, it is not at all true that "...This article is a word for word copy from this source." Much has been changed or rewritten (and many of the spicy bits removed). This is fairly typical for this sort of biography, I would say. Johnbod (talk) 02:48, 8 May 2024 (UTC)
- Yes, I was a bit imprecise there, it is the first three to four paragraphs of the life section that are directly lifted word for word. I'm just a little shocked at this as anywhere other than wikipedia this would be classified as gross plagiarism.Boynamedsue (talk) 05:21, 8 May 2024 (UTC)
- So, let me get this straight, are users saying that it is ok to copypaste text from an out of copyright text as long as that text is attributed? This feels very wrong, which wikipolicies allow this?Boynamedsue (talk) 22:19, 7 May 2024 (UTC)
- Collecting, copying or reproducing high quality, classic writings on a topic is quite common in publishing. See anthology, for example. Andrew🐉(talk) 20:54, 8 May 2024 (UTC)
- That is true, but publishing big chunks of it unchanged as part of a new book under a new name, without specifically stating that this text was written by someone else is not. If you cite someone else, you have to use different language, unless you make it clear you are making a direct quotationBoynamedsue (talk) 21:01, 8 May 2024 (UTC)
- But the article does (and did) specifically state that it was written by someone else. Phil Bridger (talk) 21:31, 8 May 2024 (UTC)
- It didn't. It cited a source, that is not the same as stating the text was a direct quotation from that source. It now states: "This article incorporates text from this source, which is in the public domain" which is an improvement but does not differentiate between which parts are direct quotes and which use the source properly.Boynamedsue (talk) 21:40, 8 May 2024 (UTC)
- That seems very unneeded, as no one is claiming specific authorship of this article, and as the material used for derivation has long been linked to so that one can see what that version said. -- Nat Gertler (talk) 21:50, 8 May 2024 (UTC)
- Anywhere but wikipedia, passing off someone else's words as your own is plagiarism. The kind of thing that people are rightly sacked, kicked out of universities or dropped by publishers for. This includes situations where a paper is cited but text is copy-pasted without being attributed as a quote.
- I'm more than a little shocked by this situation, but if so many experienced editors think that it's ok, there's not much I can do about it.Boynamedsue (talk) 22:00, 8 May 2024 (UTC)
- That's because we aren't trying to impress the teacher with our sooper riting skilz. We're providing information to the WP:READER, who isn't supposed to care who wrote what. This is fundamentally a collective effort. Note the tagline is "From Wikipedia, the free encyclopedia" not "By Wikipedia, the free encyclopedia". There exist WP:FORKS of Wikipedia where 99.9% of the content is unchanged. Are they plagiarizing us?
- An analogy that might help is the stone soup. If you grew the carrots yourself, great! But if you legally gleaned them instead, so what? The soup is still tastier. Suffusion of Yellow (talk) 22:27, 8 May 2024 (UTC)
- Yeah, wiki-mirrors are clearly plagiarising wikipedia, even though they are breaking no law. Wikipedia is a collective effort of consenting wikipedians, it is not supposed to be a repository of texts stolen from the dead. That's wikisource's job.Boynamedsue (talk) 22:34, 8 May 2024 (UTC)
- A Wikipedia article doesn't proport to be your work. They are a collaborative effort by multiple people. The fact that some of these people are long dead before this text shows up here is irrelevant. If copying from a PD source, you certainly should make it clear where the text is from, but it's not an absolute requirement. Additionally, if a statement of the source wasn't done by the revsion author, it can be done subsequently by anyone else (assuming no blocks or bans forbid this particular person from editing this particular article). Animal lover |666| 15:28, 9 May 2024 (UTC)
- I don't see why it would be acceptable for it not to be made clear. Once more, there's a distinction between copyvio and plagiarism—the fault with the latter for our purposes broadly being that readers are not adequately made aware of where what they are reading came from. The obvious default assumption of any reader is that they are reading something a Wikipedia editor wrote. Tucked away as it is, there is an edit history that lists each contributing editor. This is not superfluous context to me, it's about maintaining a sane relationship between editors and audience. Even if there's potentially nothing wrong with it divorced from social context, in terms of pure claims and copyright law—we don't live in a media environment divorced from social context, there's no use operating as if we don't meaningfully exist as authors and editors. Remsense诉 15:34, 9 May 2024 (UTC)
- By the way, plagiarizing Wikipedia would be a copyright violation, since Wikipedia texts are released under a license that requires attribution. Same can't be said for PD texts. Animal lover |666| 18:43, 9 May 2024 (UTC)
- I don't see why it would be acceptable for it not to be made clear. Once more, there's a distinction between copyvio and plagiarism—the fault with the latter for our purposes broadly being that readers are not adequately made aware of where what they are reading came from. The obvious default assumption of any reader is that they are reading something a Wikipedia editor wrote. Tucked away as it is, there is an edit history that lists each contributing editor. This is not superfluous context to me, it's about maintaining a sane relationship between editors and audience. Even if there's potentially nothing wrong with it divorced from social context, in terms of pure claims and copyright law—we don't live in a media environment divorced from social context, there's no use operating as if we don't meaningfully exist as authors and editors. Remsense诉 15:34, 9 May 2024 (UTC)
- When EB1911 was published, copyright in the United Kingdom expired seven years after the author's death, so "the dead" would probably just be surprised that it took so long for their work to be reprinted. Wikipedia exists to provide free content, the defining feature of which is that it can be reused by anyone for any purpose (in our case, with attribution). So it shouldn't really be surprising that experienced editors here are generally positive about reusing stuff. – Joe (talk) 19:18, 9 May 2024 (UTC)
- A Wikipedia article doesn't proport to be your work. They are a collaborative effort by multiple people. The fact that some of these people are long dead before this text shows up here is irrelevant. If copying from a PD source, you certainly should make it clear where the text is from, but it's not an absolute requirement. Additionally, if a statement of the source wasn't done by the revsion author, it can be done subsequently by anyone else (assuming no blocks or bans forbid this particular person from editing this particular article). Animal lover |666| 15:28, 9 May 2024 (UTC)
- Yeah, wiki-mirrors are clearly plagiarising wikipedia, even though they are breaking no law. Wikipedia is a collective effort of consenting wikipedians, it is not supposed to be a repository of texts stolen from the dead. That's wikisource's job.Boynamedsue (talk) 22:34, 8 May 2024 (UTC)
- The stuff you are claiming is "plagiarized" is getting far better attribution than most of the writing in Wikipedia. Most of the contributing writers get no credit on the page itself, it is all in the edit history. I'm not sure whose writing you think we're passing this off as. -- Nat Gertler (talk) 15:19, 9 May 2024 (UTC)
- I think simply being stated at the bottom is pretty much exactly the level of credit editors get—for me to feel comfortable with it it should be stated inline, which is what I added after the issue was raised. Remsense诉 15:21, 9 May 2024 (UTC)
- To be fair I think the only reason these things tend to be noted with a template at the bottom of the article is that the vast majority of public domain content was imported in the project's early days, as a way of seeding content, and back then inline citations were barely used. – Joe (talk) 19:23, 9 May 2024 (UTC)
- I think simply being stated at the bottom is pretty much exactly the level of credit editors get—for me to feel comfortable with it it should be stated inline, which is what I added after the issue was raised. Remsense诉 15:21, 9 May 2024 (UTC)
- Uh, what are we going to do, dock their pay? jp×g🗯️ 07:42, 10 May 2024 (UTC)
- Was thinking more along the lines of tagging the text or reverting, a talkpage message and possibly blocks for recidivists. But like I said earlier, it appears that the consensus is that things are fine how they are. World's gone mad, but what am I off to do about it? Nowt. Boynamedsue (talk) 08:14, 10 May 2024 (UTC)
- The text you're worried about was added twelve years ago by a user who that has been blocked for the last eleven years (for, wait for it... improper use of copyrighted content). I think that ship has sailed. – Joe (talk) 08:24, 10 May 2024 (UTC)
- There you go, gateway drug.Boynamedsue (talk) 08:27, 10 May 2024 (UTC)
- The text you're worried about was added twelve years ago by a user who that has been blocked for the last eleven years (for, wait for it... improper use of copyrighted content). I think that ship has sailed. – Joe (talk) 08:24, 10 May 2024 (UTC)
- Was thinking more along the lines of tagging the text or reverting, a talkpage message and possibly blocks for recidivists. But like I said earlier, it appears that the consensus is that things are fine how they are. World's gone mad, but what am I off to do about it? Nowt. Boynamedsue (talk) 08:14, 10 May 2024 (UTC)
- That seems very unneeded, as no one is claiming specific authorship of this article, and as the material used for derivation has long been linked to so that one can see what that version said. -- Nat Gertler (talk) 21:50, 8 May 2024 (UTC)
- It didn't. It cited a source, that is not the same as stating the text was a direct quotation from that source. It now states: "This article incorporates text from this source, which is in the public domain" which is an improvement but does not differentiate between which parts are direct quotes and which use the source properly.Boynamedsue (talk) 21:40, 8 May 2024 (UTC)
- But the article does (and did) specifically state that it was written by someone else. Phil Bridger (talk) 21:31, 8 May 2024 (UTC)
- That is true, but publishing big chunks of it unchanged as part of a new book under a new name, without specifically stating that this text was written by someone else is not. If you cite someone else, you have to use different language, unless you make it clear you are making a direct quotationBoynamedsue (talk) 21:01, 8 May 2024 (UTC)
- There does appear to be a consensus that such works need to be attributed somehow, and despite whatever disagreement there is, the disagreement in substance appears to be how that is done. What we are doing in these instances is republication (which is a perfectly ordinary thing to do), and yes we should let the reader know that is being done, but I'm not seeing a suggestion for changing how we do that. Alanscottwalker (talk) 14:53, 12 May 2024 (UTC)
- It seems to me that the OP asked a question and got an answer, and discussion since has been extracurricular. Remsense诉 14:57, 12 May 2024 (UTC)
- Sure, but the OP does have a point that the more the use of the work looks like our work and not someone else's work, the more it looks like plagiarism. For example, putting a unique sentence in from another's work, and just dropping a footnote, like all the other sentences in our article, is not enough, in that instance you should likely use quotation marks and even in line attribution. Alanscottwalker (talk) 15:19, 12 May 2024 (UTC)
- I think, as with most things, it depends on the situation. Plagiarism is not just the use of words without attribution, but ideas. An idea that has general acceptance might get attributed inline once in an article if it is associated strongly with a specific person or set of persons. But every mention of DNA's double helix doesn't have to be accompanied with an attribution to Watson and Crick. If some info about a person is written up by a reporter in a now public-domain source, for many cases it's probably not too essential to have inline attribution when including that info in an article. If it's something that reporter was known for breaking to the public, then it would be relevant. isaacl (talk) 15:43, 12 May 2024 (UTC)
- But that was not the situation being discussed, it was word for word, copying the work. Alanscottwalker (talk) 15:48, 12 May 2024 (UTC)
- Sure; just underscoring that if the concern is plagiarism, it applies more broadly to the restatement of ideas. Rewording a sentence doesn't prevent it from being plagiarism. Even with a sentence being copied, I feel the importance of an inline attribution depends on the situation, as I described. isaacl (talk) 15:55, 12 May 2024 (UTC)
- Sure, but that is similar a simple phrase alone, like 'He was born.' cannot be copyrighted nor the subject of plagiarism. Now if you use the simple phrase 'He was born.' in a larger poem and someone baldly copies your poem in large part with the phrase, the copyist violated your copyright, if still in force, and they did plagiarize. Alanscottwalker (talk) 16:19, 12 May 2024 (UTC)
- Yes, copying a poem likely warrants inline attribution, so... it depends on the situation. isaacl (talk) 16:24, 12 May 2024 (UTC)
- And that's the issue raised, regarding republication on wiki, is it currently enough to address plagiarism. Alanscottwalker (talk) 16:35, 12 May 2024 (UTC)
- I think the need for inline attribution depends in the same way as for content still under copyright. The original question only discussed the copyright status as a criterion. I don't think this by itself can be used to determine if inline attribution is needed. isaacl (talk) 16:43, 12 May 2024 (UTC)
- As plagiarism and copyright are two different, if sometimes related, inquiries. -- Alanscottwalker (talk) 17:08, 12 May 2024 (UTC)
- I think the need for inline attribution depends in the same way as for content still under copyright. The original question only discussed the copyright status as a criterion. I don't think this by itself can be used to determine if inline attribution is needed. isaacl (talk) 16:43, 12 May 2024 (UTC)
- And that's the issue raised, regarding republication on wiki, is it currently enough to address plagiarism. Alanscottwalker (talk) 16:35, 12 May 2024 (UTC)
- Yes, copying a poem likely warrants inline attribution, so... it depends on the situation. isaacl (talk) 16:24, 12 May 2024 (UTC)
- Sure, but that is similar a simple phrase alone, like 'He was born.' cannot be copyrighted nor the subject of plagiarism. Now if you use the simple phrase 'He was born.' in a larger poem and someone baldly copies your poem in large part with the phrase, the copyist violated your copyright, if still in force, and they did plagiarize. Alanscottwalker (talk) 16:19, 12 May 2024 (UTC)
- Sure; just underscoring that if the concern is plagiarism, it applies more broadly to the restatement of ideas. Rewording a sentence doesn't prevent it from being plagiarism. Even with a sentence being copied, I feel the importance of an inline attribution depends on the situation, as I described. isaacl (talk) 15:55, 12 May 2024 (UTC)
- >If some info about a person is written up by a reporter in a now public-domain source, for many cases it's probably not too essential to have inline attribution
- It absolutely is essential per WP:V. Traumnovelle (talk) 15:49, 12 May 2024 (UTC)
- Attribution is required. Inline attribution is not (that is, stating the source within the prose). isaacl (talk) 15:58, 12 May 2024 (UTC)
- It still requires sourcing. Traumnovelle (talk) 16:06, 12 May 2024 (UTC)
- Yes, attribution is sourcing. isaacl (talk) 16:15, 12 May 2024 (UTC)
- I think, better to distinguish the two. Attribution is explicitly letting the reader know these words, this idea, this structure came from someone else, whereas sourcing is letting the reader know you can find the gist or basis for the information in my words, there. Alanscottwalker (talk) 18:16, 12 May 2024 (UTC)
- My apologies for being unclear. I was responding to the statement that inline attribution absolutely is essential. Providing a reference for the source of content is necessary. Providing this information within the prose, as opposed to a footnote, is not. isaacl (talk) 19:57, 12 May 2024 (UTC)
- Certainly, it is possible to put explicit attribution in the footnote parenthetical or in an efn note. (I think your response to this might be , 'it depends' :))Alanscottwalker (talk) Alanscottwalker (talk) 20:18, 12 May 2024 (UTC)
- Should be be providing in-line attribution for every sentence on Wikipedia to let the reader know which editor wrote which part of it? Wikipedia isn't an academic paper, as long as we can verify that there are no copyright issues with the content (such as an attribution-required license), attribution doesn't matter. --Ahecht (TALK
PAGE) 19:32, 13 May 2024 (UTC)- Surely there's some reasonable position between "attribution doesn't matter" and "attribute every sentence inline". Remsense诉 09:06, 14 May 2024 (UTC)
- Yah, sorry those two extremes certainly don't follow from each other (Nor does the comment you are responding to discuss inline). The guideline is WP:Plagiarism and it does not go to those extremes on either end. (Also, Wikipedia does publically attribute each edit to an editor, and it does not need to be in the article, it is appendixed to the article.) -- Alanscottwalker (talk) 10:51, 14 May 2024 (UTC)
- My apologies for being unclear. I was responding to the statement that inline attribution absolutely is essential. Providing a reference for the source of content is necessary. Providing this information within the prose, as opposed to a footnote, is not. isaacl (talk) 19:57, 12 May 2024 (UTC)
- I think, better to distinguish the two. Attribution is explicitly letting the reader know these words, this idea, this structure came from someone else, whereas sourcing is letting the reader know you can find the gist or basis for the information in my words, there. Alanscottwalker (talk) 18:16, 12 May 2024 (UTC)
- Yes, attribution is sourcing. isaacl (talk) 16:15, 12 May 2024 (UTC)
- It still requires sourcing. Traumnovelle (talk) 16:06, 12 May 2024 (UTC)
- Attribution is required. Inline attribution is not (that is, stating the source within the prose). isaacl (talk) 15:58, 12 May 2024 (UTC)
- But that was not the situation being discussed, it was word for word, copying the work. Alanscottwalker (talk) 15:48, 12 May 2024 (UTC)
- I think, as with most things, it depends on the situation. Plagiarism is not just the use of words without attribution, but ideas. An idea that has general acceptance might get attributed inline once in an article if it is associated strongly with a specific person or set of persons. But every mention of DNA's double helix doesn't have to be accompanied with an attribution to Watson and Crick. If some info about a person is written up by a reporter in a now public-domain source, for many cases it's probably not too essential to have inline attribution when including that info in an article. If it's something that reporter was known for breaking to the public, then it would be relevant. isaacl (talk) 15:43, 12 May 2024 (UTC)
- Sure, but the OP does have a point that the more the use of the work looks like our work and not someone else's work, the more it looks like plagiarism. For example, putting a unique sentence in from another's work, and just dropping a footnote, like all the other sentences in our article, is not enough, in that instance you should likely use quotation marks and even in line attribution. Alanscottwalker (talk) 15:19, 12 May 2024 (UTC)
- It seems to me that the OP asked a question and got an answer, and discussion since has been extracurricular. Remsense诉 14:57, 12 May 2024 (UTC)
- Around 2006, I reworked a copy-pasted EB1911 biography about a 16th century person, it took me about a week. It has stood the test of time, and remains to this day a pretty good article despite having the same structure and modified sentences. The lead section is entirely new, and there are new sources and section breaks and pictures etc.. but the bulk of it is still that EB1911 article (reworded). I do not see the problem with this. Disney reworked Grimms tales. Hollywood redoes old stories. Sometimes old things are classics that stand the test of time, with modern updates. -- GreenC 16:44, 12 May 2024 (UTC)
- I think everybody is fine with articles which are largely based on a single source when they are reworded. It's not the platonic ideal, but it is a good start. The problem we are discussing is when people don't bother to reword. Well, I say problem, I have been told it's not one, so there's nothing left to say really.--Boynamedsue (talk) 20:06, 12 May 2024 (UTC)
- If you actually just reword a source like 1911, you should still use the 1911 template, and no, the thing you have not explained is why the template is not enough. Alanscottwalker (talk) 20:29, 12 May 2024 (UTC)
- I think everybody is fine with articles which are largely based on a single source when they are reworded. It's not the platonic ideal, but it is a good start. The problem we are discussing is when people don't bother to reword. Well, I say problem, I have been told it's not one, so there's nothing left to say really.--Boynamedsue (talk) 20:06, 12 May 2024 (UTC)
- Oppose. This proposal is WP:GREATWRONGS. The article John Leslie, 1st Duke of Rothes is perfectly fine. It does not violate any policy, guideline or consensus. There is nothing objectionable about that article. The proposal to rewrite the article would not improve the article and would result only in disruption. The proposal to put a template on the article solely to disparage the inclusion of public domain content in the article would result only in disruption. It would be disruptive to discuss this proposal further, because this proposal is disruptive, because this proposal is WP:GREATWRONGS. James500 (talk) 18:50, 12 May 2024 (UTC)
- Huh? There is no proposal. Also, there has long been a template used on the article. Your attempt to shut down discussion is also way, way off, (and your RGW claim is risible). Alanscottwalker (talk) 20:12, 12 May 2024 (UTC)
- I propose all WP:GREATWRONGS should be righted immediately.Boynamedsue (talk) 20:06, 12 May 2024 (UTC)
- WP:IAR! Alanscottwalker (talk) 20:12, 12 May 2024 (UTC)
- Amongst other things, the OP said that copying public domain text, with the correct attribution, "feels very wrong". James500 (talk) 20:49, 12 May 2024 (UTC)
- WP:IAR! Alanscottwalker (talk) 20:12, 12 May 2024 (UTC)
- I propose all WP:GREATWRONGS should be righted immediately.Boynamedsue (talk) 20:06, 12 May 2024 (UTC)
- Huh? There is no proposal. Also, there has long been a template used on the article. Your attempt to shut down discussion is also way, way off, (and your RGW claim is risible). Alanscottwalker (talk) 20:12, 12 May 2024 (UTC)
- So, WP:GREATWRONGS is applicable whenever anyone uses the word "wrong"?Boynamedsue (talk) 20:59, 12 May 2024 (UTC)
- Oppose any change to the practice of incorporating public domain content. Wikipedia is not an experiment in creative writing. It is an encyclopedia. It's sole and entire purpose is to convey information to readers. If readers can be informed through the conveyance of text that has entered the public domain, then this should not only be permissible, it should be applauded. BD2412 T 20:52, 12 May 2024 (UTC)
- Again, there is no proposal to do something different. The OP apparently forgot about things like anthologies and republication of out of copyright (like eg. all of Jane Austin's work, etc), but than when such matter was brought to his attention, retrenched to whether attribution was explicit (which we already do) enough, but has never explained what enough, is proposed. Alanscottwalker (talk) 22:24, 12 May 2024 (UTC)
- The proposal was to create a maintenance template that encourages editors to delete all text copied from public domain sources from all Wikipedia articles, even if that text is correctly attributed, simply because it is copied from a public domain source. He actually tried to tag the article with Template:Copypaste (alleging copyright infringement), despite the fact that the content is public domain and was correctly attributed at the time, with the Template:DNB attribution template. James500 (talk) 23:49, 12 May 2024 (UTC)
- That's not a proposal, he asked what template is appropriate, and he was given the list of templates at Template:DNB. Alanscottwalker (talk) 00:49, 13 May 2024 (UTC)
- The proposal was to create a maintenance template that encourages editors to delete all text copied from public domain sources from all Wikipedia articles, even if that text is correctly attributed, simply because it is copied from a public domain source. He actually tried to tag the article with Template:Copypaste (alleging copyright infringement), despite the fact that the content is public domain and was correctly attributed at the time, with the Template:DNB attribution template. James500 (talk) 23:49, 12 May 2024 (UTC)
- Again, there is no proposal to do something different. The OP apparently forgot about things like anthologies and republication of out of copyright (like eg. all of Jane Austin's work, etc), but than when such matter was brought to his attention, retrenched to whether attribution was explicit (which we already do) enough, but has never explained what enough, is proposed. Alanscottwalker (talk) 22:24, 12 May 2024 (UTC)
- oppose the existence of a proposal: I would like to clarify, wherever people think they are seeing a proposal, there isn't one. I asked a question about what tag to use when people plagiarise out of copyright texts. I got an answer I think is stupid and expressed incredulity for a couple of posts. Then, when I realised that people were indeed understanding what I was talking about, said
if so many experienced editors think that it's ok, there's not much I can do about it
. WP:NOVOTE has never been more literally true, there is nothing to vote on here...Boynamedsue (talk) 04:07, 13 May 2024 (UTC)- Support not adding any more bold-face votes. Suffusion of Yellow (talk) 04:19, 13 May 2024 (UTC)
Alanscottwalker says above that the more the use of the work looks like our work and not someone else's work, the more it looks like plagiarism.
Animal lover says above that A Wikipedia article doesn't proport to be your work. They are a collaborative effort by multiple people. The fact that some of these people are long dead before this text shows up here is irrelevant.
I think this is a difference in how people implicitly view it. The first view says "A Wikipedia article is written by people who type the content directly into the editing window. If your username isn't in the article's history page, then your words shouldn't be in the article. Article content should come exclusively from Wikipedia editors. If it doesn't, it's not really a Wikipedia article. This is our implicit promise: Wikipedia is original content, originally from Wikipedia editors. If it's not original content, it should have a notice to the reader on it to say that we didn't write it ourselves. Otherwise, we are taking credit for work done by someone who is them and not-us in an us–them dichotomy".
The second view says "A Wikipedia article is a collection of text from different people and different places. Where it came from is unimportant. We never promised that the contents of any article came from someone who directly edited the articles themselves. It's silly to say that we need to spam an article with statements that bits and pieces were pasted in from public domain sources. We wouldn't countenance 'written by a random person on the internet' in the middle of article text, so why should we countenance a disclaimer that something was 'previously published by a reliable source'? I don't feel like I'm taking credit for any other editor's article contributions, so why would you think that I'm claiming credit for something copied from a public domain source?"
If you the first resonates strongly with you, then it's shocking to see {{PD-USGov}} and {{EB1911}} content casually and legally inserted into articles without telling the reader that those sentences had previously been published some place else. OTOH, if you hold the opposite view, then the first probably seems quite strange. As this is a matter of people's intuitive feelings about what Wikipedia means, I do not see any likelihood of editors developing a unified stance. WhatamIdoing (talk) 06:56, 13 May 2024 (UTC)
- This is a reasonable summary of the issue. I think many of those who hold the first view work in or have close ties to fields where plagiarism is considered a very bad thing indeed. Academic and publishing definitions of plagiarism include using the direct words of another writer, even when attributed, unless it is explicitly made clear that the copied text is a direct quotation. For people who hold that view outside of wikipedia, the existence of large quantities of plagiarised text would detract seriously from its credibility and validity as a project.Boynamedsue (talk) 07:07, 13 May 2024 (UTC)
- I work in publishing, and there is plenty of space there where such specificities are not generally called for. If one is doing an abridged edition, children's edition, or updated version of a book, one credits the work which one is reworking but does not separate out phrase by phrase of what is from that source. Much the same goes, of course, for film adaptations, music sampling, and so on. -- Nat Gertler (talk) 16:28, 13 May 2024 (UTC)
- I think the difference there is that you are giving primary credit to the original author, and your work is voluntarily subsumed into theirs (while of course correctly stating that it is a Children's version or an abridged edition, giving editor credits etc.). In wikipedia, we are taking other people's work and subsuming it into ours.--Boynamedsue (talk) 16:37, 13 May 2024 (UTC)
- I work in publishing, and there is plenty of space there where such specificities are not generally called for. If one is doing an abridged edition, children's edition, or updated version of a book, one credits the work which one is reworking but does not separate out phrase by phrase of what is from that source. Much the same goes, of course, for film adaptations, music sampling, and so on. -- Nat Gertler (talk) 16:28, 13 May 2024 (UTC)
- I think the dichotomy is useful but I doubt anyone can subscribe to the pure form of either position. If I had to guess, I would assume most editors would agree with most of the sentences in both statements when presented in isolation. Remsense诉 07:13, 13 May 2024 (UTC)
- No. Your characterization is too gross to be useful and your made up dichotomy is just silly. We have those templates precisely because we try to give credit where credit is due, per WP:PLAGIARISM, so there is nothing shocking at all about {{PD-USGov}} and {{EB1911}} content. Sure, there are other ways to do it, than those templates, even so. Plagiarism is not a law, so your reference to the law makes no sense. But what is the law is, Wikipedia has to be written by persons, who can legally licence what they put on our pages, and if you did not write it you can't release it, nor purport to release it nor make it appear you are releasing under your licence, when you can't and you aren't. And Wikipedia does not warrant we offer good information either, in fact Wikipedia disclaims it in our disclaimer, that does not mean Wikipedian's don't care about good information. -- Alanscottwalker (talk) 10:23, 13 May 2024 (UTC)
- Wikipedia is written by people who freely license their contributions by the act of editing. But, public domain material is already free, does not need to be licensed, and so can be freely added to Wikipedia. Material that has been released under a free license can also be freely added to Wikipedia, subject to the conditions of the license, such as attribution (although we cannot copy material under a license that does not allow commercial use, but that has nothing to do with this discussion). There is no policy, rule, or law that Wikipedia has to be written by persons (although the community currently is rejecting material written by LLMs). Reliable content is reliable whether is written by Wikipedia editors based on reliable sources, or copied from reliable sources that are in the public domain or licensed under terms compatible with usage in Wikipedia. I believe that we should be explicitly citing everything that is in articles, even if I know that will not be happening any time soon. We should, however, be explicitly citing all public domain and freely-licensed content that is copied into Wikipedia, being clear that the content is copied. One of the existing templates or a specific indication in a footnote or in-line citation is sufficient, in my opinion. Donald Albury 14:43, 13 May 2024 (UTC)
- Yes, you cannot present it as if you are licencing it (and indeed requiring attribution to you!) which is what you do if just copy the words into an article and don't say, in effect, 'this is not under my licence this is public domain, that other person wrote it.' (Your discussion of LLM's and what not, is just beside the point, you, a person, are copying, not someone else.) And your last point, we are in radical agreement certainly (about letting the reader know its public domain that other person wrote it, and that's what the templates try to do) we are not in a dichotomy, at all. -- Alanscottwalker (talk) 15:28, 13 May 2024 (UTC)
- Alan, I think your response makes me more certain that my two polar ends are real. You're working from the viewpoint that if it's on the page, and does not contain words like "According to EB1911" outside of a little blue clicky number and outside of the history page, then the editor who put that text there is "purporting" that the text was written by that editor.
- There's nothing in the license that requires is to let the reader know that it's public domain or that another person wrote it. You know that a quick edit summary is 100% sufficient for the license requirements, even if nothing in the text or footnotes mentions the source. The story you present sounds like this to me:
- The license doesn't require attribution for public domain content.
- Even if it did, it wouldn't require anything more visible than an edit summary saying "Copied from EB1911".
- So (you assert) there has to be in-text attribution ("According to EB1911, a wedding cake...") or a plain-text statement at the end of the article ("This article incorporates text from EB1911") to the public domain, so the casual, non-reusing reader knows that it wasn't written by whichever editor posted it on the page.
- This doesn't logically follow. I suspect that what you've written so far doesn't really explain your view fully. WhatamIdoing (talk) 16:44, 13 May 2024 (UTC)
- No. Your false dichotomy has already been shown to be of no value. Now you add to your baseless assumptions about clicky numbers and what not. I think that editors add content to Wikipedia under the license (otherwise we would have no license), yet I also think we need to tell the reader that the matter comes from somewhere else, when it comes from somewhere else. None of that should be hard to understand for anyone. (And besides, article histories are not secrets, they are public and publicly tied to text available to the reader and anyone else.) It's just bizarre that you would imagine an unbridgeable void, when basically everyone is saying that a disclosure should be made, and they are only really discussing degrees and forms of disclosure. -- Alanscottwalker (talk) 17:13, 13 May 2024 (UTC)
- Yes, a disclosure should be made, and it was made. Phil Bridger (talk) 18:51, 13 May 2024 (UTC)
- Yes, indeed, and that is why the discussion is about form. Alanscottwalker (talk) 19:14, 13 May 2024 (UTC)
- Alan, I don't agree that the spectrum I describe is a false dichotomy, or that anyone has even attempted to show whether it has value, though I gather that you happen to disagree with it.
- I don't agree that the CC-BY-SA license requires disclosure of the source of public domain material. I think that's a question for a bunch of lawyers to really settle, but based on my own understanding, it does not. I think that Wikipedia should have such requirements (e.g, in Wikipedia:Public domain, which notably does not mention the CC-BY-SA license as a reason to do so; instead, it says only that this is important for Wikipedia's reliability), but I don't think we have any reason to believe that the license does. This distinction may seem a little like hairsplitting, but if we propose to change our rules about how to handle these things, we should be accurate about what's required for which reasons. WhatamIdoing (talk) 17:00, 15 May 2024 (UTC)
- It should not take a lawyer to tell you that to grant a licence you first have to have a right, and that you should not be misrepresenting that you have right when you don't. A lawyer can't give you the ability to be honest. You're not proposing to change rules, and indeed there is no proposal here, so that proposal talk of yours is irrelevant at best. (As for your false dichotomy, it is just a figment of your imagination, a useless piece of rhetoric, where you pretend you know what others think.) Alanscottwalker (talk) 21:37, 15 May 2024 (UTC)
- Yes, indeed, and that is why the discussion is about form. Alanscottwalker (talk) 19:14, 13 May 2024 (UTC)
- Yes, a disclosure should be made, and it was made. Phil Bridger (talk) 18:51, 13 May 2024 (UTC)
- No. Your false dichotomy has already been shown to be of no value. Now you add to your baseless assumptions about clicky numbers and what not. I think that editors add content to Wikipedia under the license (otherwise we would have no license), yet I also think we need to tell the reader that the matter comes from somewhere else, when it comes from somewhere else. None of that should be hard to understand for anyone. (And besides, article histories are not secrets, they are public and publicly tied to text available to the reader and anyone else.) It's just bizarre that you would imagine an unbridgeable void, when basically everyone is saying that a disclosure should be made, and they are only really discussing degrees and forms of disclosure. -- Alanscottwalker (talk) 17:13, 13 May 2024 (UTC)
- Yes, you cannot present it as if you are licencing it (and indeed requiring attribution to you!) which is what you do if just copy the words into an article and don't say, in effect, 'this is not under my licence this is public domain, that other person wrote it.' (Your discussion of LLM's and what not, is just beside the point, you, a person, are copying, not someone else.) And your last point, we are in radical agreement certainly (about letting the reader know its public domain that other person wrote it, and that's what the templates try to do) we are not in a dichotomy, at all. -- Alanscottwalker (talk) 15:28, 13 May 2024 (UTC)
- Wikipedia is written by people who freely license their contributions by the act of editing. But, public domain material is already free, does not need to be licensed, and so can be freely added to Wikipedia. Material that has been released under a free license can also be freely added to Wikipedia, subject to the conditions of the license, such as attribution (although we cannot copy material under a license that does not allow commercial use, but that has nothing to do with this discussion). There is no policy, rule, or law that Wikipedia has to be written by persons (although the community currently is rejecting material written by LLMs). Reliable content is reliable whether is written by Wikipedia editors based on reliable sources, or copied from reliable sources that are in the public domain or licensed under terms compatible with usage in Wikipedia. I believe that we should be explicitly citing everything that is in articles, even if I know that will not be happening any time soon. We should, however, be explicitly citing all public domain and freely-licensed content that is copied into Wikipedia, being clear that the content is copied. One of the existing templates or a specific indication in a footnote or in-line citation is sufficient, in my opinion. Donald Albury 14:43, 13 May 2024 (UTC)
Issues from Deletion Review
Here are two otherwise unrelated issues that have recently come up at Deletion Review.
Non-Admin Close as No Consensus
More than once in recent months, there has been an appeal to Deletion Review where a non-admin closed an Articles for Deletion discussion as No Consensus, and one of the questions at DRV was whether the close was a bad non-administrative close. The language in question is
A non-admin closure is not appropriate in any of the following situations:… The outcome is a close call (especially where there are several valid outcomes) or likely to be controversial.
It seems clear to some editors that a non-administrative close of No Consensus is almost always wrong, or at least may be overturned by an admin and then should be left for the admin. If it is correct that No Consensus is almost always a close call or that No Consensus is often likely to be controversial, then I suggest that the guideline be clarified to state that a non-administrative close of No Consensus is discouraged and is likely to be contested. If, on the other hand, it is thought that No Consensus is sometimes an obvious conclusion that can be found by a non-admin, then the guideline should be clarified in that respect.
Robert McClenon (talk) 05:18, 12 May 2024 (UTC)
- Any outcome can be controversial. But not all no-consensus outcomes are controversial. -- GreenC 17:03, 12 May 2024 (UTC)
- If DRV has a strong consensus that the correct closure for some deletion discussion is "No Consensus", that's certainly not a controversial closure. As such, such a closure can be done and implemented by a non-admin. The DRV closure doesn't actually judge the original thread, only its DRV discussion. Animal lover |666| 17:35, 12 May 2024 (UTC)
- I agree with GreenC. Controversial discussions and discussions which do not reach consensus are overlapping sets but neither is a subset of the other. There are XfDs where it is clear to anybody with experience of Wikipedia that there is no and will be no consensus, there is no and should be no requirement to be an admin to close those discussions (the first example of a discussion that would clearly be suitable for a no-consensus NAC was Wikipedia:Articles for deletion/Réseau Art Nouveau Network). Thryduulf (talk) 19:14, 12 May 2024 (UTC)
- I just want to throw out there that we really should have a category for trusted non-admin editors for discussion closures. There are editors with tremendous experience and a solid and well-demonstrated grasp of policies and procedures who for whatever reason have never become admins, and whose discussion closures should be given more consideration than relative newbies first experimenting with closures. BD2412 T 20:58, 12 May 2024 (UTC)
Frivolous filings at DRV
Sometimes a filing at Deletion Review is frivolous because it does not identify any issue with the close or any error, and does not identify circumstances that have changed. Occasionally a request for Deletion Review misstates the facts. In one recent case, for instance, the appellant stated that there was only one Delete !vote, when there were three. Some of the editors have wondered whether there is some alternative to having such filings open for a week of discussion. Should there be a provision for Speedy Endorse, comparable to Speedy Keep 1 and Speedy Keep 3 at AFD? Robert McClenon (talk) 05:18, 12 May 2024 (UTC)
- Sure why not. If the nom doesn't like it, they can start a new DRV with the problem addressed. Sometimes that gives the nom time to reconsider and refactor in a new light, and they won't follow through. Sometimes it energizes them to create a really good rationale improving their chances of success. Either way it's helpful. And risky for whoever issues the Speedy. The speedy has to be done before too many people engage otherwise it will alienate and irritate the participants whose thoughtful comments are buried. -- GreenC 17:16, 12 May 2024 (UTC)
- Yes. "Speedy Endorse" should be allowed in situations parallel to any Speedy Keep rationale; as with Speedy Keep closures, they address the DRV discussion and not the underlying XFD discussion, and as such are no prejudice closures if the new discussion doesn't have the same issue. Animal lover |666| 17:40, 12 May 2024 (UTC)
- I agree with GreenC and Animal Lover. Although if other editors have also identified issues with the XfD close despite the inadequate nomination then a speedy close of the DRV is unlikely to be appropriate. Thryduulf (talk) 18:54, 12 May 2024 (UTC)
- A user could create a DRV discussion on an inappropriate closure without expressing adequate justification, or while banned from the topic of the underlying article, each of these would be a speedy endorse if caught by someone who supports, or has no opinion on, the original closure. (Someone who supports it could give a justification in the first case, or merely support changing the closure in the second, and prevent any speedy endorse.) Animal lover |666| 05:44, 13 May 2024 (UTC)
- I agree with GreenC and Animal Lover. Although if other editors have also identified issues with the XfD close despite the inadequate nomination then a speedy close of the DRV is unlikely to be appropriate. Thryduulf (talk) 18:54, 12 May 2024 (UTC)
- Yes. "Speedy Endorse" should be allowed in situations parallel to any Speedy Keep rationale; as with Speedy Keep closures, they address the DRV discussion and not the underlying XFD discussion, and as such are no prejudice closures if the new discussion doesn't have the same issue. Animal lover |666| 17:40, 12 May 2024 (UTC)
- Most of these, in my experience, are already speedy-closable per WP:DRVPURPOSE #8, including your motivating example. We, insanely, don't enforce that. Why would you think that, if we added another similar rule, about statements that are less obviously made in bad faith, that we'd enforce it any more consistently? —Cryptic 10:56, 17 May 2024 (UTC)
- Of course we allow speedy closes. Maybe they've just gone out of style since I was active there? See https://quarry.wmcloud.org/query/82914 for a list of speedy closes I've done at DRV. RoySmith (talk) 14:52, 17 May 2024 (UTC)
It should be Speedy Close
Thank you for your comments. It occurs to me, based on further reviewing at DRV, that the provision should not be called Speedy Endorse, but Speedy Close, because some of the DRV's that should be closed in this manner are not really endorses because they are not really deletion reviews, but mistaken filings. There is one today which appears, after machine-translation from Romanian, to be about the deletion of an article in the Romanian Wikipedia. I have also seen Deletion Review requests where the nominator wanted to delete an article, and thought that a deletion review discussed whether to delete the article. So I think that I will take this discussion to the DRV talk page to try to discuss the wording of criteria for Speedy Closes at DRV, which will then probably be followed by an RFC. Robert McClenon (talk) 23:47, 16 May 2024 (UTC)
Should DRV be semi-protected?
I have one more policy idea about Deletion Review. Should Deletion Review, and its daily subpages, be semi-protected? I have occasionally seen Deletion Reviews started by unregistered editors, but I have never seen a reasonable Deletion Review initiated by an unregistered editor. Unregistered editors cannot nominate articles or miscellaneous pages for deletion because those involve creation of a subpage for the deletion discussion. They can start deletion reviews, but I see no encyclopedic purpose that requires that one be logged out or not have a valid account or not have an unblocked account in order to request deletion review. Robert McClenon (talk) 23:47, 16 May 2024 (UTC)
- Unless there are sufficiently many bad filings by new and unregistered users that they are disruptive then semi-protection seems like a solution in search of a problem. Thryduulf (talk) 08:17, 17 May 2024 (UTC)
- While reasonable drvs initiated by ips and non-autoconfirmed users are rare, there are a handful of sensible, longtime IP contributors to DRV - I'm thinking 81.100.164.154 in particular, though there are others. —Cryptic 10:46, 17 May 2024 (UTC)
When should the "inspired by" section be used in an infobox?
I tried looking around but couldn't find anything on this topic. Presumably it is not intended to list every inspiration a work has, but what's the line for inclusion? Eldomtom2 (talk) 21:38, 12 May 2024 (UTC)
- Which infobox are you specifically concerned with? Different infoboxes may have different intended uses for that parameter. DonIago (talk) 22:05, 12 May 2024 (UTC)
- It depends son the infobox, it has been removed from some due to problems it can cause. The documentation for others, such as {{Infobox television}}, say to only use it if it has been
explicitly credited as such
, again it depends which one is used. -- LCU ActivelyDisinterested «@» °∆t° 22:27, 12 May 2024 (UTC)- It's {{Infobox television}}, but there's debate over the precise definition of "explicitly credited". Some are arguing "explicit credit" includes external confirmation by the creators of the work that they were inspired by X, even if X isn't credited in the work itself.--Eldomtom2 (talk) 13:46, 13 May 2024 (UTC)
- The discussion that led to the inspired_by parameter being added (2020) stipulated that
it would only be in instances where an explicit "Inspired by" credit appears for a series, much like how series include "Based on" credits
. Schazjmd (talk) 13:54, 13 May 2024 (UTC) - I think only the latter (an actual on-screen credit) would be a reasonable interpretation on the consensus in that discussion. --Ahecht (TALK
PAGE) 17:26, 13 May 2024 (UTC)
- The discussion that led to the inspired_by parameter being added (2020) stipulated that
- It's {{Infobox television}}, but there's debate over the precise definition of "explicitly credited". Some are arguing "explicit credit" includes external confirmation by the creators of the work that they were inspired by X, even if X isn't credited in the work itself.--Eldomtom2 (talk) 13:46, 13 May 2024 (UTC)
Access date
Recently, Jax 0677 (talk · contribs) was using {{better source needed}} on Dia Frampton to indicate that the "access date" field was anachronistic to the content being cited by the source. This is obviously not the right citation template, as it gives the implication of "we need a more reliable source than Billboard itself for Billboard charts". What would be the right template to say "anachronistic access date"? Or should you just go in and fix it yourself? Ten Pound Hammer • (What did I screw up now?) 00:09, 13 May 2024 (UTC)
- There are several possible unrelated causes. I sometimes see that situation when a fact is cited using a temporally-consistent cite, and then a later fact is added with no update to the cite. The first table entry is reasonable from the original access-date. It's only the second row that is anachronistic. So either the editor who added it did not look for a cite at all or did not update the access-date when they did use that ref. Looking at the ref, either it does support, in which case the solution is to update the ref, or it does not support, in which case {{failed verification}} on the specific entry. I agree that {{bsn}} is clearly the wrong tag. DMacks (talk) 00:23, 13 May 2024 (UTC)
- Perhaps {{update source}}? Masem (t) 00:35, 13 May 2024 (UTC)
- Yes, that's the one. Safari ScribeEdits! Talk! 22:22, 14 May 2024 (UTC)
COI guidelines
When I first came on board as a Wiki editor, I thought what I was learning about COI meant that anyone with even the slightest connection to the subject of a Wiki article couldn't edit or write on that subject in Wikipedia. Now I've come to understand that it actually IS possible as long as the editor makes an official COI declaration. I'd have saved myself a few months of real concern about the fairness of this rule for a couple of topics on which I believed I could make a helpful contribution with a balanced perspective, if I'd grasped that COI doesn't automatically prohibit if disclosed. Like the disclosures that journalists make in stories to which they add "full disclosure" announcements about any connections they have to the subject that might cause assumptions of possible bias.
What I'd like to suggest to Wikipedia policymakers is that this important point about COI be made as clear as possible in all documentation about it. Then other editors — especially newbies, as I was when this issue came up for me — won't stumble around in the dark as to what they can and can't work on — at least, legitimately.
I realize that trying to ensure 100% clarity on this could be challenging, especially because a lot of what we learn about COI is not just through COI-related documentation but also through Teahouse and Help Desk discussions. Still, senior editors can probably think of many ways to make sure the distinction between a flat "NO, you can never" and "YES, you can if you ALSO do X" is better highlighted across the board.
Augnablik (talk) 07:06, 13 May 2024 (UTC)
- It does seem like many new good-faith editors are very concerned about potential COI to a degree that is qualitatively more extreme than the norm among experienced editors. Of course, there are also many new, potentially good-faith editors seem not to feel any concern regarding COI whatsoever—though I cannot honestly characterize this side of the equation as anything but a comparative lack of familiarity with the guideline on average. Let's take a look at the current verbiage of WP:COI and see if there's something we can rewrite to better reflect the actual norms. Here's the first paragraph:
Conflict of interest (COI) editing involves contributing to Wikipedia about yourself, family, friends, clients, employers, or your financial and other relationships. Any external relationship can trigger a conflict of interest. Someone having a conflict of interest is a description of a situation, not a judgment about that person's opinions, integrity, or good faith.
- Emphasis mine. This is tricky: the entire lead seems to define COI as automatically existing to a maximal logical extent. Nowhere does the lead nuance that most people can successfully edit about things they have particular interests in—in short, the lead does not adequately communicate that there can be interests without conflicts of interest.
- I understand why this is: we don't want bad faith COI editors feeling emboldened by our nuance to push POV, or using it as a rhetorical shield when called out. But I still feel the lead should probably have at least one sentence explicating that (unpaid) COI only arises when one is personally unwilling or unable to edit according to site norms like they would on another topic. COI shouldn't be implied to be as total or even subconscious like it is in the lead as written. Remsense诉 07:53, 13 May 2024 (UTC)
- Thank you, @Remsense. Just having acknowledgment by a senior editor as to the validity of the issue — regardless of the eventual outcome — feels so nice and warm and fuzzy that I’ll just lie back and bask in it awhile … 🏖️ Augnablik (talk) 08:50, 13 May 2024 (UTC)
- Why would people understand "external relationships" to encompass interests in the first place? – Joe (talk) 11:13, 13 May 2024 (UTC)
- It's simply a bit of a sticky phrase: it seems easy for nervous minds to give it a very broad definition. But I also understand how it's difficult to rephrase without making easier for bad-faith editors to argue around. Remsense诉 11:15, 13 May 2024 (UTC)
- Presumably working backwards as all "interests" are the result of external relationships of some kind. Horse Eye's Back (talk) 17:08, 15 May 2024 (UTC)
- Just to clarify something that's come up in a few of your recent posts, Augnablik: there are no "senior editors", working groups, or policymakers here. Our policies and guidelines can be edited by anyone, just like every other page, and aim to reflect the consensus of all editors.
- On COI, I actually think your first understanding was correct. As always there are a range of opinions on the subject, but in general the community does not want you to edit topics on which you have a COI. That is why the nutshell summary of WP:COI is
do not edit Wikipedia in your own interests, nor in the interests of your external relationships
and the first sentence, after defining what it is, readsCOI editing is strongly discouraged on Wikipedia
. However, Wikipedia has no firm rules (there are no "you can nevers"), so it's impossible for us to complete forbid it. Hence the procedures for disclosed COI editing; they're there for those who insist on not following the clear instruction at the top of the page (do not edit
). They exist, but that doesn't necessarily mean we want to highlight them. – Joe (talk) 11:10, 13 May 2024 (UTC)- Joe, I think it's more complicated than that. First, I'll take the sentence Remsense highlighted, and highlight it in a different way: Any external relationship can trigger a conflict of interest – but just because it can doesn't mean that it will.
- Second, consider what the OP says: anyone with even the slightest connection to the subject. What's "the slightest connection"? If you take a train to work, do you have at least "the slightest connection" to Commuter rail? To the specific transit agency? Only to the specific line you take?
- I think most editors would say that isn't an "external relationship" at all, though I have had one editor claim that nobody should edit the articles about the towns where they were born, lived, etc., because (in that editor's opinion) it's possible to have a relationship with an inanimate object. WhatamIdoing (talk) 17:00, 13 May 2024 (UTC)
- @Joe Roe, this is something far from what I thought was COI. Firstly, I am still seeing that "slightest connection" as something else. Initially, COI should be editing people you know and not things you know. Okay, IMO, does editing someone/something you know and have seen a COI. Safari ScribeEdits! Talk! 22:30, 14 May 2024 (UTC)
- I'm literally just quoting the guideline.
Slightest connection
is Augnablik's wording, not mine. – Joe (talk) 08:11, 15 May 2024 (UTC)- Actually, “slightest connection” is @WhatamIdoing‘s wording. Augnablik (talk) 12:15, 15 May 2024 (UTC)
- No, "slightest connection" is from the very first sentence of this thread: I thought what I was learning about COI meant that anyone with even the slightest connection to the subject. WhatamIdoing (talk) 16:35, 15 May 2024 (UTC)
- Actually, “slightest connection” is @WhatamIdoing‘s wording. Augnablik (talk) 12:15, 15 May 2024 (UTC)
- I'm literally just quoting the guideline.
- I would say my point is that one can take different emphases away from the lead as written. I think an explicit statement, perhaps a single sentence, which delimits the scope would go a long way to narrow this potential interpretive gap. It's hard to feel because we know what this verbiage means in practice, but it's very plausible to me that a chunk of new editors—those of a nervous disposition, if you like—come away fearing for their own ability to edit neutrally, worried about COI in situations where others generally don't have problems. They simply don't have enough experience yet to know that. Remsense诉 08:30, 15 May 2024 (UTC)
- Beside “those of a nervous disposition” who might be “worried about COI in situations where others generally don’t have problems,” add those of us still somewhat wet behind the ears who’ve now read many Teahouse COI-related exchanges in which the point was driven home about fates like banishment awaiting us if we stray outside the pale. Augnablik (talk) 12:35, 15 May 2024 (UTC)
- I intended my characterization as broadly and neutrally as possible, apologies if that doesn't get across. Remsense诉 12:53, 15 May 2024 (UTC)
- Perhaps what would be most helpful is if the Teahouse regulars didn't try to (over)simplify the COI rules.
- Part of our problem is that the rules are taught by telephone game, with each person in the chain simplifying it just a little more, and making it sound just a little stronger, until the story ends up being a false caricature of the real rules. WhatamIdoing (talk) 16:38, 15 May 2024 (UTC)
- If this is in direct response to me, I‘ll try my best to offer better advice in the future. Remsense诉 16:41, 15 May 2024 (UTC)
- I've no idea who is taking care of the Teahouse these days. I doubt that anyone in this discussion is the primary source of this problem (though perhaps we should all do our best to improve in this and all other areas). WhatamIdoing (talk) 17:07, 15 May 2024 (UTC)
- If this is in direct response to me, I‘ll try my best to offer better advice in the future. Remsense诉 16:41, 15 May 2024 (UTC)
- I intended my characterization as broadly and neutrally as possible, apologies if that doesn't get across. Remsense诉 12:53, 15 May 2024 (UTC)
- Beside “those of a nervous disposition” who might be “worried about COI in situations where others generally don’t have problems,” add those of us still somewhat wet behind the ears who’ve now read many Teahouse COI-related exchanges in which the point was driven home about fates like banishment awaiting us if we stray outside the pale. Augnablik (talk) 12:35, 15 May 2024 (UTC)
- @Joe Roe, this is something far from what I thought was COI. Firstly, I am still seeing that "slightest connection" as something else. Initially, COI should be editing people you know and not things you know. Okay, IMO, does editing someone/something you know and have seen a COI. Safari ScribeEdits! Talk! 22:30, 14 May 2024 (UTC)
- I think WP:COI has a significant weak point, specifically the sentence:
How close the relationship needs to be before it becomes a concern on Wikipedia is governed by common sense.
Because a COI is about the existence of a relationship and not the editor's actual ability to edit without bias, there is no obvious or common way to tell what degree of closeness triggers it. It's inherently arbitrary where that line is drawn. The result of that ambiguity is that some conscientious editors may be unnecessarily excluding themselves from broad swaths of articles where they could productively edit based on a trivial personal connection.--Trystan (talk) 14:00, 15 May 2024 (UTC)- We've also seen in recent discussions that different long-established editors editing in good faith can have very different interpretations of where the line should be drawn. Thryduulf (talk) 15:03, 15 May 2024 (UTC)
- Yes, this has beeen an eye-opener for me as a still-newish editor … and the writer of the post that started off this thread. It hadn’t occurred to me that “different long-established editors editing in good faith” — those in position to make judgments about COI infractions by their less long-established brethren — might be using somewhat different measuring tapes.
- The outcome of this thread is very important to me, as I’ll shortly have to make a self-applied COI label for an article I’ll be submitting, and I want to get everything as straight as I can about COI before then.
- Thank you to everyone who’s added insights to this discussion. I hope it brings about the clarity we need. Augnablik (talk) 19:57, 15 May 2024 (UTC)
- Stick around long enough, and you will find that “long-established editors editing in good faith” can (and do) disagree on how to interpret almost all of our policies and guidelines. We (usually) agree on the essence of P&G, but the nuances? Not so much. But that’s OK. Blueboar (talk) 21:36, 15 May 2024 (UTC)
- If an editor does not think they should edit because of COI, that's fine. As with most everything here, we rely on their judgement, all the time, and if they have a question about it, they can ask in multiple places, as with everything else. This is not the most difficult judgement they will face here. Alanscottwalker (talk) 17:00, 15 May 2024 (UTC)
- To be fair if their edits are entirely appropriate the COI will almost certainly never be identified... We generally only identify COI by first identifying problematic editing and then ending on COI as the most likely explanation for them, in cases where its genuinely not disruptive nobody notices. Horse Eye's Back (talk) 17:16, 15 May 2024 (UTC)
- Doesn't that suggest that the COI analysis is largely irrelevant? If my editing of Famous Author's biography is problematic, does it matter whether it is because I am her sister (COI) or just a devoted fan (no COI, just ordinary bias)?--Trystan (talk) 17:47, 15 May 2024 (UTC)
- Yes the vast majority of the time the COI analysis is largely irrelevant. Also fans have a COI (its an external relationship like any other), just normally one below the common sense threshold. Superfans or similar though do have a serious COI and we have big issues with them. Horse Eye's Back (talk) 17:52, 15 May 2024 (UTC)
- I wouldn't say a fan of any sort has a close relationship with the subject within the meaning of COI. They may have a metric tonne of bias, but per WP:COINOTBIAS, the presence or absence of actual bias is irrelevant to whether a COI relationship exists.--Trystan (talk) 20:46, 15 May 2024 (UTC)
- The President of the Jimmie SingsGood Fanclub has a massive COI in regards to Jimmie SingsGood and you can work down from there, also note that the relationship doesn't have to be close to trigger a COI... The standard here is common sense. Horse Eye's Back (talk) 20:51, 15 May 2024 (UTC)
How close the relationship needs to be before it becomes a concern on Wikipedia is governed by common sense.
Common sense (allegedly) determines whether the closeness of the relationship is problematic, so closeness is inherently important. I could see a fan club president having a COI, but only by virtue of holding that specific role.--Trystan (talk) 21:10, 15 May 2024 (UTC)- Any level of fandom which effects their ability to edit the topic dispassionately is too close, we're supposed to be editors not advocates. Thats the problem with self policing COI... If it is a genuine COI then the person will be incapable of recognizing whether or not their edits are neutral. Horse Eye's Back (talk) 05:17, 16 May 2024 (UTC)
- This is dangerously close to implying a lot of things that would be violations of WP:HID, like that being black is a COI on racial issues. It is also directly contradictory to WP:COINOTBIAS. A COI is not an opinion, it is some sort of concrete relationship to the subject of the article. Loki (talk) 02:30, 21 May 2024 (UTC)
- The idea that If it is a genuine COI then the person will be incapable of recognizing whether or not their edits are neutral is also not true. Any PR hack who removes damaging information knows their goal is not "neutral"; they know they're trying to make the article "favorable". Any person who replaces favorable errors with accurate facts (e.g., the correct number of employees, the correct amount of revenue) knows they're making the article more neutral. There are circumstances in which people won't be able to tell whether their edits result in a neutral article, but that happens to all of us on occasion, and does not always happen to people with a genuine COI. WhatamIdoing (talk) 00:26, 22 May 2024 (UTC)
- This is dangerously close to implying a lot of things that would be violations of WP:HID, like that being black is a COI on racial issues. It is also directly contradictory to WP:COINOTBIAS. A COI is not an opinion, it is some sort of concrete relationship to the subject of the article. Loki (talk) 02:30, 21 May 2024 (UTC)
- Any level of fandom which effects their ability to edit the topic dispassionately is too close, we're supposed to be editors not advocates. Thats the problem with self policing COI... If it is a genuine COI then the person will be incapable of recognizing whether or not their edits are neutral. Horse Eye's Back (talk) 05:17, 16 May 2024 (UTC)
- You're on the right track, but its not so much irrelevant as a different and generally harder inquiry for a person to undertake about themselves, not 'do I have a defined relationship', but the more self-searching and self knowing inquiry of something like, 'am I able to separate here from my bias, or is it too much to be me to be fair.' (I think many editors avoid topics, at least to an extensive level, where they know they have no desire to be unbiased in their writing about it, or they think they cannot, but they have to know themselves on that, not something like an external relationship). -- Alanscottwalker (talk) 21:16, 15 May 2024 (UTC)
- That is very much how I approach my own editing, and identifying when I should step back from a topic. But that is fundamentally about applying WP:NPOV. I am not able to reconcile that self-reflective approach with WP:COINOTBIAS, which explicitly clarifies that a COI exists where a relationship exists, irrespective of the editor’s bias, state of mind, or integrity.--Trystan (talk) 21:48, 15 May 2024 (UTC)
- That's it, it's a different inquiry, as that part says though, they may have some overlap. --Alanscottwalker (talk) 22:01, 15 May 2024 (UTC)
- That is very much how I approach my own editing, and identifying when I should step back from a topic. But that is fundamentally about applying WP:NPOV. I am not able to reconcile that self-reflective approach with WP:COINOTBIAS, which explicitly clarifies that a COI exists where a relationship exists, irrespective of the editor’s bias, state of mind, or integrity.--Trystan (talk) 21:48, 15 May 2024 (UTC)
- The President of the Jimmie SingsGood Fanclub has a massive COI in regards to Jimmie SingsGood and you can work down from there, also note that the relationship doesn't have to be close to trigger a COI... The standard here is common sense. Horse Eye's Back (talk) 20:51, 15 May 2024 (UTC)
- I wouldn't say a fan of any sort has a close relationship with the subject within the meaning of COI. They may have a metric tonne of bias, but per WP:COINOTBIAS, the presence or absence of actual bias is irrelevant to whether a COI relationship exists.--Trystan (talk) 20:46, 15 May 2024 (UTC)
- No. Because the best, most effective, and often only thing between good and the abyss is you, just you alone, so you have got to, got to do the consideration, you're the only one there is. Alanscottwalker (talk) 17:52, 15 May 2024 (UTC)
- Correct. What matters is whether your edits are problematic, not why they are (or aren't). Thryduulf (talk) 18:57, 15 May 2024 (UTC)
- Yes the vast majority of the time the COI analysis is largely irrelevant. Also fans have a COI (its an external relationship like any other), just normally one below the common sense threshold. Superfans or similar though do have a serious COI and we have big issues with them. Horse Eye's Back (talk) 17:52, 15 May 2024 (UTC)
- Doesn't that suggest that the COI analysis is largely irrelevant? If my editing of Famous Author's biography is problematic, does it matter whether it is because I am her sister (COI) or just a devoted fan (no COI, just ordinary bias)?--Trystan (talk) 17:47, 15 May 2024 (UTC)
- We've also seen in recent discussions that different long-established editors editing in good faith can have very different interpretations of where the line should be drawn. Thryduulf (talk) 15:03, 15 May 2024 (UTC)
If you want to follow this literally, if you are a human being, and edit any article about human beings, be sure to declare your COI. :-) We really need to calibrate this to acknowledge the widely varying degrees of strength of COI. Also to fix how this is often usable/used in a McCarthy-esqe way. North8000 (talk) 17:03, 15 May 2024 (UTC)
- If you do not want to not exercize judgement, this is just a rough place to be. COI is certainly easier to navigate and involves a ton less work than NPOV, to anyone who takes NPOV seriously. Alanscottwalker (talk) 17:12, 15 May 2024 (UTC)
- Indeed, it is difficult to be a new editor. I do not see why this means we can't try to help them. Remsense诉 17:14, 15 May 2024 (UTC)
- Best not to assume new editors are helpless. How demeaning that would be. Some need no help, and others should ask. Alanscottwalker (talk) 17:19, 15 May 2024 (UTC)
- Indeed, it is difficult to be a new editor. I do not see why this means we can't try to help them. Remsense诉 17:14, 15 May 2024 (UTC)
- If you do not want to not exercize judgement, this is just a rough place to be. COI is certainly easier to navigate and involves a ton less work than NPOV, to anyone who takes NPOV seriously. Alanscottwalker (talk) 17:12, 15 May 2024 (UTC)
- If it has the appearance of a conflict, it probably is a conflict. Selfstudier (talk) 17:04, 15 May 2024 (UTC)
- If that were truly the case, we wouldn't need the policy. Remsense诉 17:05, 15 May 2024 (UTC)
- Still need the policy, but that criteria always works in edge cases. Selfstudier (talk) 17:08, 15 May 2024 (UTC)
- I don't know about you, but no one I've ever met is able to reliably tell when something is pornography. Ever. Remsense诉 17:17, 15 May 2024 (UTC)
- How is that a COI? Selfstudier (talk) 17:22, 15 May 2024 (UTC)
- Its a Jacobellis v. Ohio reference to the fuzziness of the "I know it when I see it" standard. Horse Eye's Back (talk) 17:25, 15 May 2024 (UTC)
- Sorry, that's an oblique reference as regards the "if it looks like X, then it probably is" device. Remsense诉 17:26, 15 May 2024 (UTC)
- Ah, I see now. Just when it was getting interesting :) Selfstudier (talk) 17:33, 15 May 2024 (UTC)
- How is that a COI? Selfstudier (talk) 17:22, 15 May 2024 (UTC)
- I don't know about you, but no one I've ever met is able to reliably tell when something is pornography. Ever. Remsense诉 17:17, 15 May 2024 (UTC)
- Still need the policy, but that criteria always works in edge cases. Selfstudier (talk) 17:08, 15 May 2024 (UTC)
- Except what has "the appearance of a conflict" to one editor can be completely different to what has "the appearance of a conflict" to another editor, even if they are both very experienced - let alone to those who aren't. Thryduulf (talk) 17:06, 15 May 2024 (UTC)
- As per above, I am talking about the point where the line is drawn (because it isn't). Selfstudier (talk) 17:10, 15 May 2024 (UTC)
- The point where the line is drawn needs to be clear to new and old editors alike, determining the point based on vague phrases that not even all regulars can agree on is actively unhelpful. Thryduulf (talk) 17:13, 15 May 2024 (UTC)
- Let me know when it is drawn, and good luck with that. Selfstudier (talk) 17:15, 15 May 2024 (UTC)
- Oh many people would draw the lines in roughly the same place and they would do it quickly too, but in the end if they have empathy they should probably say, if you are still in significant doubt stay away, you don't need that, do other stuff. Alanscottwalker (talk) 18:24, 15 May 2024 (UTC)
- Let me know when it is drawn, and good luck with that. Selfstudier (talk) 17:15, 15 May 2024 (UTC)
- The point where the line is drawn needs to be clear to new and old editors alike, determining the point based on vague phrases that not even all regulars can agree on is actively unhelpful. Thryduulf (talk) 17:13, 15 May 2024 (UTC)
- Especially for controversial subjects (not all of which are WP:CTOPS), there is an unfortunate pattern of "any edit that doesn't push my POV is motivated by COI". I don't think there's ever going to be an easy agreement here. On the one hand, we have editors feeling obliged to leave serious errors in articles because they have a tenuous connection to the subject, and being praised by those who think readers are better served by unlabeled bad content than by that bad content being removed by someone who is "tainted". On the other hand, we have people leveling COI accusations when an editor with a tenuous connection fixes simple, non-controversial, non-content problems (e.g., an AWB run for WP:REFPUNCT mistakes). WhatamIdoing (talk) 17:24, 15 May 2024 (UTC)
- These hypothetical 'what someone else thinks' of yours, are often absurdist and just caricatures of nothing real. And it appears your statement has no bandwidth for 'if you have a question, ask'. ask'Alanscottwalker (talk) 17:33, 15 May 2024 (UTC)
- I've no objection to people asking, though if they're given permission to edit, I would not want them to trust that the permission is worth much. Absurd accusations are par for the course in some subject areas, and appear whenever the accuser thinks it could give him an advantage in a dispute. WhatamIdoing (talk) 05:31, 16 May 2024 (UTC)
- These hypothetical 'what someone else thinks' of yours, are often absurdist and just caricatures of nothing real. And it appears your statement has no bandwidth for 'if you have a question, ask'. ask'Alanscottwalker (talk) 17:33, 15 May 2024 (UTC)
- As per above, I am talking about the point where the line is drawn (because it isn't). Selfstudier (talk) 17:10, 15 May 2024 (UTC)
- If that were truly the case, we wouldn't need the policy. Remsense诉 17:05, 15 May 2024 (UTC)
We used to have an excellent gold standard in the lead and in bold at wp:coi, it was "when advancing outside interests is more important to an editor than advancing the aims of Wikipedia, that editor stands in a conflict of interest." This is of course a function of several things such as the strength of the potential-coi situation and the ability/propensity of the editor to only wear their Wikipedia hat when editing Wikipedia.North8000 (talk) 17:13, 15 May 2024 (UTC)
- I would support re-adding something concrete like this back to the lead, it's really all I've been asking for. Remsense诉 17:16, 15 May 2024 (UTC)
- How about "An apparent conflict of interest is one in which a reasonable person would think that judgment is likely to be compromised." Selfstudier (talk) 17:25, 15 May 2024 (UTC)
- Given that reasonable, good faith, experienced Wikipedia editors cannot agree when judgement is likely to be compromised that is definitely not a good formulation. I'd support readding the old one that North8000 quotes as is. Thryduulf (talk) 17:28, 15 May 2024 (UTC)
- You think that they will agree then? Selfstudier (talk) 17:30, 15 May 2024 (UTC)
- Given that reasonable, good faith, experienced Wikipedia editors cannot agree when judgement is likely to be compromised that is definitely not a good formulation. I'd support readding the old one that North8000 quotes as is. Thryduulf (talk) 17:28, 15 May 2024 (UTC)
- That was removed in an effort to make our guideline at Wikipedia:Conflict of interest mirror the real-world conception of Conflict of interest. There are advantages to both approaches, but I doubt that there will be much appetite for reverting. The old style requires more trust in other people's willingness to do the right thing. WhatamIdoing (talk) 17:28, 15 May 2024 (UTC)
- It also left us more vulnerable to the crowd who perpetually perceives the communities interests to be one and the same as their own... "What do you mean making a page about my boss wasn't ok? The article is good and the point of wikipedia is having good articles! Better that I, an expert, write this article than someone who doesn't know that they're talking about" Horse Eye's Back (talk) 17:31, 15 May 2024 (UTC)
- The purpose of Wikipedia is making good quality encyclopaedic information available to people. We define good quality encyclopaedic information to be information that is all of:
- Reliable
- Verifiable
- Neutral
- About subjects we deem notable
- If the content meets all of those requirements we want it, if it doesn't we don't. If someone writes a good quality encyclopaedic article about a notable subject (and/or improves an article about a notable subject) we should welcome their content with open arms, regardless of why they wrote it. If their content does not meet those requirements then we should remove it (and explain as best we can why), regardless of why they wrote it. Thryduulf (talk) 19:06, 15 May 2024 (UTC)
- Not sure what the point is, we can block editors and keep their content... we do it all the time. We can also remove content without blocking editors, again we do it all the time. Horse Eye's Back (talk) 19:11, 15 May 2024 (UTC)
- The point is that what content we keep and what content we remove should be decided entirely based on the content, not the attributes or motivation of the author and especially not the alleged or presumed attributes or motivations of the author. We should not be blocking editors who write good content just because we don't like why they wrote it. Thryduulf (talk) 19:23, 15 May 2024 (UTC)
- A behavioral issue is an issue regardless of the quality of the content, just as editor should have little or no bearing on whether we keep content... Content should have little or no bearing on whether we keep an editor. For example undisclosed paid editing is inherently contrary to the purposes of wikipedia regardless of the content of the paid edits. Horse Eye's Back (talk) 20:55, 15 May 2024 (UTC)
- Putting ideological concerns about paid editing and conflict of interest ahead of our objective of building an encyclopaedia is inherently contrary to the purpose of Wikipedia. Hawkeye7 (discuss) 21:15, 15 May 2024 (UTC)
- One could bring ideological concerns into it (I have not), but the practical concerns about paid editing and conflict of interest are significant enough on their own to make it a largely philosophical exercise. Horse Eye's Back (talk) 21:17, 15 May 2024 (UTC)
- The only practical (rather than philosophical) concerns about paid and other COI editing are whether the content is neutral, due and verifiable - and all of those are true whether someone is paid and/or has a COI. The purpose of Wikipedia is to produce and make available good quality encyclopaedic information. Everything that impedes that goal is contrary to Wikipedia's purpose. Deleting good quality encyclopaedic information because it was written by someone who has (or might have) a COI and/or was paid to write it is contrary to Wikipedia's purpose. Blocking someone who writes good content because they were paid to write it and/or had some other POV is contrary to Wikipedia's purpose. Thryduulf (talk) 22:14, 15 May 2024 (UTC)
- Thats not true, there are other practical concerns (such as reader trust, editor time, and subtle NPOV manipulation through for example content exclusion not content inclusion). The #1 thing that people expect for example of the Coca-Cola article in terms of quality is that it isn't written by Coca-Cola... If it is then it serves no encyclopedic purpose because the whole point of encyclopedias is that they aren't written by the subjects of the entries. Horse Eye's Back (talk) 05:23, 16 May 2024 (UTC)
- "Subtle NPOV manipulation" is part of "whether the content is neutral, due and verifiable".
- Reader trust is not affected by this. Readers do not know who writes articles. They never really think about that. Quite a lot of them believe that all articles are written for pay, through an organized professional system, or at least by subjects who are paying to have an article created. The fastest way to reduce reader trust (this is backed up by formal user research done by the WMF over the last decade, and you can read about it on Meta-Wiki and at mediawiki.org if you're interested) is to point out the existence of the Edit button and prove to them that they can actually edit the articles themselves. (But don't worry too much: Cognitive bias usually kicks in before the end of the interview, and they invent reasons to justify their prior trust despite their recent discovery, which really shocks most of them, that Wikipedia actually is the encyclopedia anyone can edit.)
- Reader trust is also affected by article content, but not usually in ways that will make you happy. Specifically, readers trust articles (here and elsewhere on the web) when the article tells them what they already believe and expect. This has an interesting implication for paid editors: Most readers already expect that articles are being paid for; therefore, when you tell them that articles are paid for, they are neither surprised nor disgusted by this revelation. They think that's normal, and they're okay with it. WhatamIdoing (talk) 05:46, 16 May 2024 (UTC)
- The content itself may be neutral, but its addition may make the article non-neutral. Readers don't need to think about who wrote the articles because they trust that independent editors wrote them, that is after all what we've led them to believe. Knowing that some articles contain paid edits is not the same thing as thinking that all edits are paid, clearly there is an expectation that they won't be. I would cease editing wikipedia for good if our COI restrictions were lifted, that is a practical impact you can't deny or obfuscate around. Encyclopedia are not written by their subjects, if you and Thryduulf want Wikipedia articles to be written by their subjects then you don't want us to be an encyclopedia. Horse Eye's Back (talk) 05:58, 16 May 2024 (UTC)
- Now it's even clearer that you are not listening, and now your putting words into our mouths. I'm no longer convinced you are contributing to this discussion in good faith. Thryduulf (talk) 07:48, 16 May 2024 (UTC)
- You didn't say I wasn't listening earlier, you leveled that charge at a different editor ([10]. I'm not not going to assume bad faith, I'm going to assume that you were just mistaken about which editor your comments were addressed to. If you could join me in AGF I would appreciate it. Horse Eye's Back (talk) 16:10, 16 May 2024 (UTC)
- In re clearly there is an expectation that they won't be [paid]: This assertion deserves a [citation needed] tag, or perhaps just [dubious ]. A very substantial fraction of readers think Wikipedia is a for-profit website.
- Those of us on the 'inside' have a really skewed view of reality. @Horse Eye's Back, between your two accounts, you are in the top couple thousand people worldwide for contribution volume. In any sample of 3.5 million people, you are probably the one who edited the English Wikipedia the most. Think about that. There are twenty US states with fewer people than that; if you live in any of them, you are probably the all-time top editor from your state. You are so far from "average" or "typical" that it's silly to pretend otherwise. Things that are commonplace and obvious and clear to you (and me, and all of us here) are completely surprising to people who don't know how Wikipedia works. WhatamIdoing (talk) 22:03, 17 May 2024 (UTC)
- I've never met someone who thought that wikipedia was for profit, but my interactions are of course primarily within a bubble. I'm certainly not typical, but I actually doubt I'm in the top 100 for my state. What I can offer is my take as a "power user" as they say... Which is that I find little as demotivating as sock-masters and COI editors. If regulation those areas got significantly worse I would almost certainly be spending less time around here, at the end of the day this is a philanthropic pursuit which I support with an immense amount (in the global sense multiple average human salaries) of time and money. If its Who's Who not an encyclopedia we're building then the money needs to flow the other way. Horse Eye's Back (talk) 23:11, 17 May 2024 (UTC)
- Read the 2011 survey results: About half of readers and a quarter of editors(!) had no idea that Wikipedia is a non-profit. Fundraising messages have emphasized the non-profit status ever since. I don't know if they've re-run the survey question, but realistically, I wouldn't expect the results to change very much. It's hard to move the needle on perceptions like that, because they're based on the assumptions that people bring in with them, rather than one what you've done to deserve it, and there's a new cohort of readers who need to learn this every day.
- I don't think anyone wants more socking or conflicted editing. Changing the regulations probably won't have much effect on that. Changing practices might. For example – and this is a completely impossible example – if we required everyone to disclose their real-world identity and be pre-approved before they could start an article, then we would probably see less conflicted editing. I expect that this problem will never be fully solved.
- I don't know why you think you wouldn't even make the top 100 in your state. Only about 2500 people have ever made more edits than you. About 40% of enwiki editors are from the US. That means in the whole country, with its 340 million residents, there are only about one thousand people who have made more edits here than you (and many of them are blocked, retired, or dead). It is possible, if you live in California, that you might just barely miss the cutoff for the top 100. It may be uncomfortable to realize how rare each high-volume editor is, but it's still true.
- WhatamIdoing (talk) 07:53, 18 May 2024 (UTC)
- Just taking a gander I think that if we're just talking about the top 2500 people its more like 80% Americans and my state is one that for historical reasons is radically over-represented when it comes to the earliest editors (call them the Sanger clique). I'm not kidding, I can identify 50 Wikipedians who are either from my state or have been associated with it at some point (we don't exactly keep current addresses on people) who have more edits than me... Conservatively there are 50 more I don't know of. What I find uncomfortable is the overrepresentation of older white American men among high volume editors, I don't get any discomfort from the rarity of high volume editors itself per-say I just wish they were more representative of the actual population of the planet. Horse Eye's Back (talk) 15:35, 18 May 2024 (UTC)
- Not knowing that Wikipedia is a non-profit is not the same as specifically believing paid editing is the norm! If this survey is the reason you've been claiming
Most readers already expect that articles are being paid for
then that's a serious misjudgment that should be retracted. JoelleJay (talk) 17:41, 21 May 2024 (UTC)
- I've never met someone who thought that wikipedia was for profit, but my interactions are of course primarily within a bubble. I'm certainly not typical, but I actually doubt I'm in the top 100 for my state. What I can offer is my take as a "power user" as they say... Which is that I find little as demotivating as sock-masters and COI editors. If regulation those areas got significantly worse I would almost certainly be spending less time around here, at the end of the day this is a philanthropic pursuit which I support with an immense amount (in the global sense multiple average human salaries) of time and money. If its Who's Who not an encyclopedia we're building then the money needs to flow the other way. Horse Eye's Back (talk) 23:11, 17 May 2024 (UTC)
- Now it's even clearer that you are not listening, and now your putting words into our mouths. I'm no longer convinced you are contributing to this discussion in good faith. Thryduulf (talk) 07:48, 16 May 2024 (UTC)
- The content itself may be neutral, but its addition may make the article non-neutral. Readers don't need to think about who wrote the articles because they trust that independent editors wrote them, that is after all what we've led them to believe. Knowing that some articles contain paid edits is not the same thing as thinking that all edits are paid, clearly there is an expectation that they won't be. I would cease editing wikipedia for good if our COI restrictions were lifted, that is a practical impact you can't deny or obfuscate around. Encyclopedia are not written by their subjects, if you and Thryduulf want Wikipedia articles to be written by their subjects then you don't want us to be an encyclopedia. Horse Eye's Back (talk) 05:58, 16 May 2024 (UTC)
- HEB wrote: the whole point of encyclopedias is that they aren't written by the subjects of the entries
- I don't think this is true. If it is true, or at least verifiable, then our article at Encyclopedia is wrong, and articles like English Wikipedia, and more or less everything in Category:English Wikipedia, should be deleted.
- I think that "the whole point of encyclopedias" is that they provide a factual summary of information about a subject. WhatamIdoing (talk) 21:46, 17 May 2024 (UTC)
- Describing themselves would be an exception. In general people have believed that in order for an encyclopedia to provide a factual summary of information about a subject it had to be independent of that subject. That means that Coca-Cola shouldn't be writing Coca-Cola, the Chinese Government shouldn't be writing Persecution of Uyghurs in China, and the US Government shouldn't be writing CIA. That doesn't seem like a terribly objectionable idea. This is why the "vanity press" in "Wikipedia is not a soapbox, an advertising platform, a social network, a vanity press, an experiment in anarchy or democracy, an indiscriminate collection of information, nor a web directory." links to COI. Horse Eye's Back (talk) 23:11, 17 May 2024 (UTC)
- I doubt your claim that In general people have believed that...an encyclopedia...had to be independent of that subject, too. I think what you mean is probably closer to "Since sometime after yellow journalism, probably around the Walter Cronkite era, most middle-class, educated Western people at least pay lip service to the idea of editorial independence".
- In other places, and in Western culture before the 20th century, people generally thought that using whatever power you had to help your family and friends was normal and desirable, so if an encyclopedia editor had a family member working for Coca-Cola, then "of course" the resulting article would be favorable and potentially written with the assistance of that relative. To not do this would be to prove yourself disloyal and anti-social. WhatamIdoing (talk) 08:10, 18 May 2024 (UTC)
- "Western middle class" "before the 20th century" quite a bunch of anachronistic assumptions and non-sequiturs you have there, before the 20th century and indeed well into the 20th century almost no one went to high school or its equivalent for even one day, so philosophizing about their general encyclopedia consumption and even access seems bizarre. The past is a foreign land, as they say. -- Alanscottwalker (talk) 08:42, 18 May 2024 (UTC)
- Encyclopedias are not works of journalism, what does that have to do with anything? You should consult a historian, needless to say you are wrong (try pre-15th century and maybe I would partially agree but even the Romans and dynastic Chinese has strong ideas about conflict of interest). Horse Eye's Back (talk) 15:45, 18 May 2024 (UTC)
- Describing themselves would be an exception. In general people have believed that in order for an encyclopedia to provide a factual summary of information about a subject it had to be independent of that subject. That means that Coca-Cola shouldn't be writing Coca-Cola, the Chinese Government shouldn't be writing Persecution of Uyghurs in China, and the US Government shouldn't be writing CIA. That doesn't seem like a terribly objectionable idea. This is why the "vanity press" in "Wikipedia is not a soapbox, an advertising platform, a social network, a vanity press, an experiment in anarchy or democracy, an indiscriminate collection of information, nor a web directory." links to COI. Horse Eye's Back (talk) 23:11, 17 May 2024 (UTC)
- Thats not true, there are other practical concerns (such as reader trust, editor time, and subtle NPOV manipulation through for example content exclusion not content inclusion). The #1 thing that people expect for example of the Coca-Cola article in terms of quality is that it isn't written by Coca-Cola... If it is then it serves no encyclopedic purpose because the whole point of encyclopedias is that they aren't written by the subjects of the entries. Horse Eye's Back (talk) 05:23, 16 May 2024 (UTC)
- The only practical (rather than philosophical) concerns about paid and other COI editing are whether the content is neutral, due and verifiable - and all of those are true whether someone is paid and/or has a COI. The purpose of Wikipedia is to produce and make available good quality encyclopaedic information. Everything that impedes that goal is contrary to Wikipedia's purpose. Deleting good quality encyclopaedic information because it was written by someone who has (or might have) a COI and/or was paid to write it is contrary to Wikipedia's purpose. Blocking someone who writes good content because they were paid to write it and/or had some other POV is contrary to Wikipedia's purpose. Thryduulf (talk) 22:14, 15 May 2024 (UTC)
- One could bring ideological concerns into it (I have not), but the practical concerns about paid editing and conflict of interest are significant enough on their own to make it a largely philosophical exercise. Horse Eye's Back (talk) 21:17, 15 May 2024 (UTC)
- Putting ideological concerns about paid editing and conflict of interest ahead of our objective of building an encyclopaedia is inherently contrary to the purpose of Wikipedia. Hawkeye7 (discuss) 21:15, 15 May 2024 (UTC)
- A behavioral issue is an issue regardless of the quality of the content, just as editor should have little or no bearing on whether we keep content... Content should have little or no bearing on whether we keep an editor. For example undisclosed paid editing is inherently contrary to the purposes of wikipedia regardless of the content of the paid edits. Horse Eye's Back (talk) 20:55, 15 May 2024 (UTC)
- The point is that what content we keep and what content we remove should be decided entirely based on the content, not the attributes or motivation of the author and especially not the alleged or presumed attributes or motivations of the author. We should not be blocking editors who write good content just because we don't like why they wrote it. Thryduulf (talk) 19:23, 15 May 2024 (UTC)
- Thus, proper COI handling is essential to Wikipedia's purpose. No one of any real discernment is going find an encyclopedia good if it can't be honest and even has people pretend they can't even understand COI. -- Alanscottwalker (talk) 19:31, 15 May 2024 (UTC)
- Nobody is pretending they can't understand COI. Multiple people are explaining why they disagree with you about what constitutes a conflict of interest and what level of conflict of interest is relevant to Wikipedia. Handling of COI is essential only to the point that we ensure the content is NPOV, everything else is irrelevant or actively harmful. Thryduulf (talk) 22:16, 15 May 2024 (UTC)
- Then, you really don't understand COI, if you can't bring yourself to disclose it. It's not a good encyclopedia when it misrepresents itself, like when autobiography is misrepresented as biography. Or the writings of the owner of the company on the company is represented as not the writing of the owner of the company. etc. etc. (It also appears you don't understand that Wikipedia is a publisher, and disclosing COI is what good publishers do, certainly good publishers of anything they are presenting to others as something to rely on.) -- Alanscottwalker (talk) 22:58, 15 May 2024 (UTC)
- You are not listening. If the content in a Wikipedia article is encyclopaedic, neutral, verifiable, and DUE then is no misrepresentation because those are the only things a Wikipedia article claims to be (and sometimes not even that, e.g. an article or section tagged as being non-neutral is not representing itself as neutral). Whether an editor has a COI is a completely different matter. Whether an editor who has a COI should, must and/or does disclose that COI is a third matter.
- If editor 1 writes words that other editors (who do not have a COI) state is encyclopaedic, neutral, verifiable and DUE then the content is encyclopaedic, neutral, verifiable and DUE and it is irrelevant whether editor 1 has or does not have a COI. Thryduulf (talk) 23:41, 15 May 2024 (UTC)
- No, you are not listening it's not a good encyclopedia when it is dishonest, and it can't be trusted in anything (certainly no one of any sense can trust it to judge neutrality or reliability) when it won't or refuses to be honest. Alanscottwalker (talk) 23:50, 15 May 2024 (UTC)
- If the words on the page are encyclopaedic, neutral, verifiable, and DUE then there is no dishonesty. That applies regardless of who wrote it and why they wrote it. Whether an article is all of those things is independent of who wrote it and why they wrote it - if every author has a COI with the subject then it could be all or none of those things, if no author has a COI with the subject then it could be all or none of those things. Thryduulf (talk) 00:10, 16 May 2024 (UTC)
- There is dishonesty, and I already showed how, Wikipedia thus cannot be trusted (by anyone of any sense) to judge encyclopaedic, neutral, verifiable, and DUE. Alanscottwalker (talk) 00:13, 16 May 2024 (UTC)
- After all this time do you really not understand how COI works or is this an elaborate act? From where I sit it looks like we have an WP:IDNHT issue here, you're just not being reasonable and its becoming disruptive. Horse Eye's Back (talk) 05:24, 16 May 2024 (UTC)
- You all aren't going to agree. HEB, Thryduulf knows how COI works. He's just saying that there happens to be another value that he finds more important. Different people are allowed to have different values. WhatamIdoing (talk) 05:49, 16 May 2024 (UTC)
- Denial of objective reality is not holding a different value. Horse Eye's Back (talk) 06:04, 16 May 2024 (UTC)
- HEB and Alanscottwalker, please cease the personal attacks and start reading what other people are writing rather than assuming that if someone disagrees with you that they must be denying reality. If you are unable to discuss things rationally then Wikipedia is not the place for you.
- I know what a COI is, I just disagree that it matters in any way beyond whether the article is neutral, etc. If the article is neutral it is neutral regardless of who wrote it. If the article is not neutral it is not neutral, regardless of who wrote it. Thryduulf (talk) 07:54, 16 May 2024 (UTC)
- You're the one not reading. And there is no assumption by me here. Your use of as that a false attack against me, going so far as to invite me off the project, suggests how bereft your position is. -- Alanscottwalker (talk) 08:20, 16 May 2024 (UTC)
- Please explain how accusing me of "not understanding COI" and of "denying reality" because I hold a view with which you disagree is not a personal attack. Thryduulf (talk) 08:35, 16 May 2024 (UTC)
- I already explained how you do not understand COI, as for denying reality that was not me, but it appears to be in reference to denying the reality of COI. COI is not invented by Wikipedia, and it's what good publishers disclose. -- Alanscottwalker (talk) 08:42, 16 May 2024 (UTC)
I already explained how you do not understand COI
except you haven't. You've repeatedly stated that you disagree with my view about the way/degree to which COI matters, but that is not at all the same thing. Who invented COI and what publishers other than Wikipedia do are not relevant to what Wikipedia does and/or should do.- There are multiple things being unhelpfully conflated here:
- What constitutes a COI.
- What constitutes a COI that is relevant to Wikipedia.
- How, when and where a COI (relevant to Wikipedia) should be disclosed.
- Whether Wikipedia content is or is not neutral.
- The last bullet is completely independent of the others: If content is neutral it is neutral regardless of who wrote it. If content is not neutral it is not neutral regardless of who wrote it. Thryduulf (talk) 09:01, 16 May 2024 (UTC)
- No. I did explain it. And as can be told, you do not understand which goes along with you not understanding COI. That you suggest being a good publisher is irrelevant, suggests you don't understand what being a good publisher is, which also suggests you don't understand what we are doing here (the submit button is a publishing button), which also suggests you don't understand COI in publishing, and which also suggests you don't understand what a good published encyclopedia is. -- Alanscottwalker (talk) 10:21, 16 May 2024 (UTC)
- You are the one who is clearly either not reading or not understanding. If it is the former then there is nothing relevant I can say. If it is the latter then trying to explain things in a different way may help, I'll give it one more go but I don't hold out much hope - perhaps someone else will have more luck?
- Every time we click the submit button something is published. That something should be all of encyclopaedic, neutral, verifiable and DUE. In reality it can be in one of three states:
- All of those things
- Some of those things (e.g. verifiable but not DUE, neutral but not verifiable, etc)
- None of those things
- Which it is depends entirely on the actual words that are published. A given set of words falls into one of the above categories regardless of who wrote it. If "MegaCorp is the oldest and largest manufacturer of widgets in the United Kingdom. It won the Queen's Award for Widget Making seven times between 1999 and 2014." is all of encyclopaedic, verifiable, neutral and DUE then it is all of those things regardless of whether they were written by the CEO or by someone with no connection to the organisation at all. If the same two sentences are some or none of the four things an article should be then that is true regardless of who wrote it. Thryduulf (talk) 11:13, 16 May 2024 (UTC)
- Once again you have not been reading. And once again you demonstrate no understanding of COI in publishing. Or to the extent you do understand it, you are encouraging poor publishing, and a poor encyclopedia. Alanscottwalker (talk) 12:56, 16 May 2024 (UTC)
- Now you are just repeating yourself. I understand exactly what you are saying, I just disagree with it. I have repeatedly explained why I disagree with it, but you are clearly either uninterested in or incapable of understanding the difference between disagreeing with you and not understanding you. Either way continuing to engage with you is a waste of time. Thryduulf (talk) 13:03, 16 May 2024 (UTC)
- It seems, you not bothering to even read what you write, to the extent I have repeated iit is to respond to your repetitious demonstration of misunderstanding. As I explained in the beginning, you evidence little to no understanding of COI in publishing, let alone good publishing or the good publishing of an encyclopedia. Alanscottwalker (talk) 13:27, 16 May 2024 (UTC)
- Now you are just repeating yourself. I understand exactly what you are saying, I just disagree with it. I have repeatedly explained why I disagree with it, but you are clearly either uninterested in or incapable of understanding the difference between disagreeing with you and not understanding you. Either way continuing to engage with you is a waste of time. Thryduulf (talk) 13:03, 16 May 2024 (UTC)
- Once again you have not been reading. And once again you demonstrate no understanding of COI in publishing. Or to the extent you do understand it, you are encouraging poor publishing, and a poor encyclopedia. Alanscottwalker (talk) 12:56, 16 May 2024 (UTC)
- No. I did explain it. And as can be told, you do not understand which goes along with you not understanding COI. That you suggest being a good publisher is irrelevant, suggests you don't understand what being a good publisher is, which also suggests you don't understand what we are doing here (the submit button is a publishing button), which also suggests you don't understand COI in publishing, and which also suggests you don't understand what a good published encyclopedia is. -- Alanscottwalker (talk) 10:21, 16 May 2024 (UTC)
- I already explained how you do not understand COI, as for denying reality that was not me, but it appears to be in reference to denying the reality of COI. COI is not invented by Wikipedia, and it's what good publishers disclose. -- Alanscottwalker (talk) 08:42, 16 May 2024 (UTC)
- Please explain how accusing me of "not understanding COI" and of "denying reality" because I hold a view with which you disagree is not a personal attack. Thryduulf (talk) 08:35, 16 May 2024 (UTC)
- You're the one not reading. And there is no assumption by me here. Your use of as that a false attack against me, going so far as to invite me off the project, suggests how bereft your position is. -- Alanscottwalker (talk) 08:20, 16 May 2024 (UTC)
- Denial of objective reality is not holding a different value. Horse Eye's Back (talk) 06:04, 16 May 2024 (UTC)
- You all aren't going to agree. HEB, Thryduulf knows how COI works. He's just saying that there happens to be another value that he finds more important. Different people are allowed to have different values. WhatamIdoing (talk) 05:49, 16 May 2024 (UTC)
- If the words on the page are encyclopaedic, neutral, verifiable, and DUE then there is no dishonesty. That applies regardless of who wrote it and why they wrote it. Whether an article is all of those things is independent of who wrote it and why they wrote it - if every author has a COI with the subject then it could be all or none of those things, if no author has a COI with the subject then it could be all or none of those things. Thryduulf (talk) 00:10, 16 May 2024 (UTC)
- No, you are not listening it's not a good encyclopedia when it is dishonest, and it can't be trusted in anything (certainly no one of any sense can trust it to judge neutrality or reliability) when it won't or refuses to be honest. Alanscottwalker (talk) 23:50, 15 May 2024 (UTC)
- Then, you really don't understand COI, if you can't bring yourself to disclose it. It's not a good encyclopedia when it misrepresents itself, like when autobiography is misrepresented as biography. Or the writings of the owner of the company on the company is represented as not the writing of the owner of the company. etc. etc. (It also appears you don't understand that Wikipedia is a publisher, and disclosing COI is what good publishers do, certainly good publishers of anything they are presenting to others as something to rely on.) -- Alanscottwalker (talk) 22:58, 15 May 2024 (UTC)
- Nobody is pretending they can't understand COI. Multiple people are explaining why they disagree with you about what constitutes a conflict of interest and what level of conflict of interest is relevant to Wikipedia. Handling of COI is essential only to the point that we ensure the content is NPOV, everything else is irrelevant or actively harmful. Thryduulf (talk) 22:16, 15 May 2024 (UTC)
- Not sure what the point is, we can block editors and keep their content... we do it all the time. We can also remove content without blocking editors, again we do it all the time. Horse Eye's Back (talk) 19:11, 15 May 2024 (UTC)
- The purpose of Wikipedia is making good quality encyclopaedic information available to people. We define good quality encyclopaedic information to be information that is all of:
- It also left us more vulnerable to the crowd who perpetually perceives the communities interests to be one and the same as their own... "What do you mean making a page about my boss wasn't ok? The article is good and the point of wikipedia is having good articles! Better that I, an expert, write this article than someone who doesn't know that they're talking about" Horse Eye's Back (talk) 17:31, 15 May 2024 (UTC)
- That statement was always bad, because COI is about relationships which cloud issues of what's important with respect to the subject. Alanscottwalker (talk) 17:39, 15 May 2024 (UTC)
- How about "An apparent conflict of interest is one in which a reasonable person would think that judgment is likely to be compromised." Selfstudier (talk) 17:25, 15 May 2024 (UTC)
- Just as safety regulations are written in blood, Wikipedia's COI guidelines are written in characters scavenged from promotional fluff. – Teratix ₵ 03:48, 16 May 2024 (UTC)
- That's a non sequitur. Promotional fluff can be added to an article by anybody for any reason and it is completely irrelevant why because we don't want it in our articles regardless of who wrote it or why. Thryduulf (talk) 07:59, 16 May 2024 (UTC)
- On the contrary, it's extremely relevant. Editors with a conflict of interest on a subject, all else being equal, are much more likely to add biased content to an article. Pointing out everyone has the capacity to add promotional fluff is trivial because we care more about their propensity to add promotional fluff. – Teratix ₵ 08:24, 16 May 2024 (UTC)
- We don't exclude editors because they might not abide by policies. What matters is whether they do or do not. Wikipedia does not opeate on the basis of thoughtcrime. Thryduulf (talk) 08:33, 16 May 2024 (UTC)
We don't exclude editors because they might not abide by policies.
Yes, we do, on a regular basis:- We exclude unregistered and very new editors from editing protected pages, because they tend to not abide by policies when editing these pages.
- We exclude unregistered and very new editors from creating articles in mainspace, because they tend to not abide by policies when creating pages.
- We exclude new editors from editing certain protected pages and even entire topics (e.g. the Israeli–Palestine conflict), because they tend not to abide by policies when editing these pages.
- We exclude non-administrators from editing the Main Page, because they tend not to abide by policies when editing this page.
- There is nothing new or contentious about Wikipedia policies and guidelines that restrict a user from editing a selected subset of pages merely because they come under a category of editors who have a propensity to shirk policy when editing these pages. That is true even when we have no direct evidence this particular user will edit according to that propensity. This isn't "thoughtcrime", it's ordinary practice. – Teratix ₵ 13:42, 16 May 2024 (UTC)
- I disagree that COI editors add the most. Go check the histories of articles on cartoons, anime, or anything to which someone could be a "fan". You will see plenty of edits by fanboys that prop the subject up to a degree that COI editors wouldn't even consider. Dennis Brown - 2¢ 11:22, 16 May 2024 (UTC)
- I didn't mean to imply that COI editors were the only kind of editor which tends to add fluff, or even the most fluff. I agree fanboys do this as well. – Teratix ₵ 13:52, 16 May 2024 (UTC)
- Fans are just one type of COI editor, those are COI edits (unarguably so if they actually do prop up the subject, meeting the standard raised above that the content also has to be bad not just the editor). Horse Eye's Back (talk) 16:14, 16 May 2024 (UTC)
Fans are just one type of COI editor
It's more like both fans and COI editors are types of editors who tend to be biased. – Teratix ₵ 01:37, 17 May 2024 (UTC)- Bias is the result of a conflict of interest, it does not exist on its own. Horse Eye's Back (talk) 16:15, 17 May 2024 (UTC)
- That is the opposite of what the guideline currently says:
A COI can exist in the absence of bias, and bias regularly exists in the absence of a COI. Beliefs and desires may lead to biased editing, but they do not constitute a COI.
--Trystan (talk) 17:11, 17 May 2024 (UTC)- Sorry for the ambiguity... I'm speaking in the specific context of a fan, not in the universal sense. Being a fan is a parasocial external relationship. Horse Eye's Back (talk) 17:34, 17 May 2024 (UTC)
- That is the opposite of what the guideline currently says:
- Bias is the result of a conflict of interest, it does not exist on its own. Horse Eye's Back (talk) 16:15, 17 May 2024 (UTC)
- We don't exclude editors because they might not abide by policies. What matters is whether they do or do not. Wikipedia does not opeate on the basis of thoughtcrime. Thryduulf (talk) 08:33, 16 May 2024 (UTC)
- On the contrary, it's extremely relevant. Editors with a conflict of interest on a subject, all else being equal, are much more likely to add biased content to an article. Pointing out everyone has the capacity to add promotional fluff is trivial because we care more about their propensity to add promotional fluff. – Teratix ₵ 08:24, 16 May 2024 (UTC)
- That's a non sequitur. Promotional fluff can be added to an article by anybody for any reason and it is completely irrelevant why because we don't want it in our articles regardless of who wrote it or why. Thryduulf (talk) 07:59, 16 May 2024 (UTC)
A few notes:
- The real world common meaning of COI is pretty severe and narrow. Generally a strong personal economic interest of a public official that is very likely to be a strong opposing interest to doing their job properly. And it's also associated with actual or accusations of doing their public job improperly or illegally due to that economic self interest. So the first issue with this in Wikipedia is applying this term with a nasty real world meaning to much more benign situations in Wikipedia.
- The actual problem in Wikipedia is when editing is actually influenced by something other than the objectives of Wikipedia. This takes two things
- The presence of that influence. In this area WP:COI focuses on influences with specific concrete definitions e.g. paid editing, membership in a group rather than ones like side on a on a political or culture-war tussle.
- The editor letting that influence affect their editing against the objective of Wikipedia. And the two main factors affecting this are the presence & strength of the influence and their strength/qualities of being to edit properly resist that influences. This is what actually matters and what was in the "Golden Definition" in the lead which somebody removed. The down side of this is that hard to know, but so is almost any other COI effort
- Wikipedia also wrestles with and is confusing due to the two completely different meanings of COI. One is the end result (per the "golden definition") and the other is the presence of certain of the potential influences.
- One component of a fix is to simply recognize that there are widely varying strengths of influences. At the extreme end of the spectrum is paid editing. At the other extreme is merely being a member of a large group or mere employee of a large organization or company. The latter are far weaker than things like general politics and being on one side of a culture war and should be completely removed from the COI radar screen. They just dillute it and are fodder for McCarthy-esqe tactics used in editing disputes.
- Regarding strong influences (e.g. paid editing) getting disclosure is the most important thing. The current guidlines make it overly difficult for those who disclose and thus work agains the disclosure goal. Once a strong coi influence is exposed and visible, they automatically really aren't going to get away with anything
Sincerely, North8000 (talk) 15:11, 17 May 2024 (UTC)
- And how does this analysis change if Wikipedia is part of the real world and not separate from it? Horse Eye's Back (talk) 16:17, 17 May 2024 (UTC)
- Taking your question literally/structurally, my context was about real world meanings of term vs. Wikipedia meanings or usage of terms. So Wikipedia being a part of the real worlds does not change my comments. Or if you meant how to reconcile, I think that the starting point would be to take the weak influences completely off the wp:coi radar screen or explicitly exclude them from being called coi. This would inherently bring the Wiki usage of the term close to the real world meaning. And also solve lots of other problems. North8000 (talk) 18:08, 17 May 2024 (UTC)
- Taking that in two parts... Firstly I think that wikipedia is informed by a broad spectrum of real world meanings of the term which are more or less plastered over by a consensus (in both senses). Secondly I completely agree with you there, the major miscommunication I see between editors is using (and I am 100% guilty of this) COI as shorthand for significant COI. I don't think anyone wants the radar to pick up the clutter so to speak, to extend the radar analogy we want to set the radar so that we see boats and land but not waves. Horse Eye's Back (talk) 18:17, 17 May 2024 (UTC)
- Given that the opening words of this section say that the OP thought (i.e., had been taught by the rest of us) that COI meant that anyone with even the slightest connection to the subject, I think that you're correct. We have a habit of focusing on trivial or immaterial connections – "even the slightest connection" – when we might do better to reserve COI for significant conflicts. We want to catch "paid to push this" but not "met the subject once", or even "made a necessary correction for someone you know".
- As an example of that last, I recall a dispute years ago about a Wikipedia editor who was contacted by someone he had met professionally and who asked him to correct a strictly objective factual error about which there was some ENGVAR-related confusion (consider, e.g., Eton College, which an American would call a high school instead of a college). We don't really want to trot out the whole of COI just to get an error like that corrected. The connection is slight, the correction is necessary, and there is no chance of bias being introduced in such a case. That's not the scenario our COI rules were created to defend against. WhatamIdoing (talk) 22:27, 17 May 2024 (UTC)
- That seems like the exact scenario we have COI edit requests for. In that specific scenario the wikipedia editor should have instructed this person to make a COI edit request on the talk page instead of acting as their meat puppet. Problem solved, no issues created. Horse Eye's Back (talk) 17:06, 18 May 2024 (UTC)
- I think we have COI rules to stop people from writing puff pieces about themselves or from hyping things (e.g., stocks, products, cryptocurrency, etc.) that they stood to make money off of. I don't think we created the COI rules to slow down the process of correcting obvious and objective errors in BLPs. WhatamIdoing (talk) 04:49, 19 May 2024 (UTC)
- The purpose of COI rules is to ensure the neutrality and factuality of the encyclopaedia. If the rule prevents someone from correcting an obvious, objective error then it it should be ignored. Thryduulf (talk) 07:31, 19 May 2024 (UTC)
- I'm sorry, but you didn't say it was BLP (which is a well established exception to so many things on wiki, including COI) Horse Eye's Back (talk) 17:47, 20 May 2024 (UTC)
- Even if it hadn't been a BLP, it wouldn't matter. Our "interest" in getting objective factual errors corrected is much higher than our interest in running a bureaucratic process. The order is Wikipedia:Product, process, policy: achieving factually correct articles come first. WhatamIdoing (talk) 02:09, 22 May 2024 (UTC)
- One possible order is product, process, policy... The linked is an essay about WP:IAR. You're having issues with hyperbole, please say what you mean not something which is stronger but untrue. Horse Eye's Back (talk) 17:22, 22 May 2024 (UTC)
- The linked essay is not about IAR, it is about policies and guidelines and when to ignore them. Rather than accusing people of saying things that are untrue, first read and understand their argument then, if you actually disagree, refute the argument. I'm not seeing evidence you have done any of those things. Thryduulf (talk) 18:06, 22 May 2024 (UTC)
- If we want to be pedantic (and I usually do
;-)
), it's about when to follow this policy instead of one of the other policies or guidelines, though the same principle appears in other policies, as well. "Wikipedia must get the article right", to quote one of them (emphasis in the original). WhatamIdoing (talk) 21:10, 22 May 2024 (UTC) - Its about those... But its also very obviously and unambiguously about IAR as well... "This is an essay on the policies Wikipedia:Ignore all rules, Wikipedia:Consensus and Wikipedia:Policies and guidelines." If you don't people to say that the things you are saying are untrue stop saying things which are obviously not true! Horse Eye's Back (talk) 17:08, 23 May 2024 (UTC)
- If we want to be pedantic (and I usually do
- The linked essay is not about IAR, it is about policies and guidelines and when to ignore them. Rather than accusing people of saying things that are untrue, first read and understand their argument then, if you actually disagree, refute the argument. I'm not seeing evidence you have done any of those things. Thryduulf (talk) 18:06, 22 May 2024 (UTC)
- One possible order is product, process, policy... The linked is an essay about WP:IAR. You're having issues with hyperbole, please say what you mean not something which is stronger but untrue. Horse Eye's Back (talk) 17:22, 22 May 2024 (UTC)
- Even if it hadn't been a BLP, it wouldn't matter. Our "interest" in getting objective factual errors corrected is much higher than our interest in running a bureaucratic process. The order is Wikipedia:Product, process, policy: achieving factually correct articles come first. WhatamIdoing (talk) 02:09, 22 May 2024 (UTC)
- I think we have COI rules to stop people from writing puff pieces about themselves or from hyping things (e.g., stocks, products, cryptocurrency, etc.) that they stood to make money off of. I don't think we created the COI rules to slow down the process of correcting obvious and objective errors in BLPs. WhatamIdoing (talk) 04:49, 19 May 2024 (UTC)
- That seems like the exact scenario we have COI edit requests for. In that specific scenario the wikipedia editor should have instructed this person to make a COI edit request on the talk page instead of acting as their meat puppet. Problem solved, no issues created. Horse Eye's Back (talk) 17:06, 18 May 2024 (UTC)
- Taking that in two parts... Firstly I think that wikipedia is informed by a broad spectrum of real world meanings of the term which are more or less plastered over by a consensus (in both senses). Secondly I completely agree with you there, the major miscommunication I see between editors is using (and I am 100% guilty of this) COI as shorthand for significant COI. I don't think anyone wants the radar to pick up the clutter so to speak, to extend the radar analogy we want to set the radar so that we see boats and land but not waves. Horse Eye's Back (talk) 18:17, 17 May 2024 (UTC)
- Taking your question literally/structurally, my context was about real world meanings of term vs. Wikipedia meanings or usage of terms. So Wikipedia being a part of the real worlds does not change my comments. Or if you meant how to reconcile, I think that the starting point would be to take the weak influences completely off the wp:coi radar screen or explicitly exclude them from being called coi. This would inherently bring the Wiki usage of the term close to the real world meaning. And also solve lots of other problems. North8000 (talk) 18:08, 17 May 2024 (UTC)
- I think it would help to expand WP:COINOTBIAS on how COI and NPOV/bias differ, serving complementary but distinct functions that are both crucial to the encyclopedia. To my mind, WP:COI should set out clearly and narrowly defined relationships (paid editing, significant financial interest, or close personal friend or family). If such a relationship exists, editors are required to disclose before editing, and strongly discouraged from editing altogether. It is an objective test - it does not matter if there is any actual bias, because the close relationship creates the unavoidable apprehension of bias. Outside of that narrow COI framework, the appropriate lens is WP:NPOV. Every single editor has biases that have the potential to affect every single article they work on. Identifying those biases and working to set them aside is first and foremost an internal, subjective process, though feedback from other editors is also a crucial component. If an editor can't set their biases aside sufficiently to substantially comply with WP:NPOV, they should step back from a topic (or failing that, be topic banned for failing to comply with NPOV). But trying to frame all NPOV failures as COIs just makes COI confusing and ineffectual.--Trystan (talk) 18:31, 17 May 2024 (UTC)
- @Trystan, do you think our differential response to accusations of COI vs POV pushing are part of the problem? It feels to me that COI claims get a more dramatic response than POV pushing claims. If you feel like you need help, you might find it more effective to speculate on whether the problematic content was put there by a paid editor. WhatamIdoing (talk) 22:31, 17 May 2024 (UTC)
- This isn't @Trystan but @Augnablik replying to your message, @WhatamIdoing, only because — as the originator of this thread — I'd like to jump in with a message about the direction the discussion's been going recently but I don't find a way to add a new message except in reply to someone else's. So, apologies for the hijacking, though it's not completely off topic.
- What I'd like to say is that when I started the discussion on COI guidelines, it never occurred to me that it could devolve into actual conflict, especially among longtime editors. I thought about starting a new topic — COI guidelines, "Take 2" — for building on all the discussion in this thread so that the discussants could come up with an improved set of guidelines to help all editors, especially but not only the brand new.
- However, I see that a new related thread has already been made, picking up on, and including several posts from, this one — The Teahouse and COI. Perhaps for now that would be enough to build on, so I won't add the new topic I'd had in mind. Please put back any drawn knives except to help carve out an improved set of guidelines. Augnablik (talk) 02:09, 18 May 2024 (UTC)
- Indeed, it must be odd to have other people try to assume or philosophize about what someone means when they say they have a "connection", because they should just ask the person who said it. Part of that, is this page is not really focused to talk about an individual user's situation, it is a place to talk about policy. For an individual's COI issues, the place for those conversations would be some place like WP:COIN, WP:Help Desk, the WP:Teahouse, or the User's talk page. Alanscottwalker (talk) 12:24, 18 May 2024 (UTC)
- IMV, someone has a COI with a subject if, were they to publish something on it in an RS, it would not be considered "independent" in WP terms. That would mean: don't edit about your family, friends, employees/employer/coworkers, commercial or non-profit orgs/groups you belong to, specific events (but not necessarily general activities) you participated in, entities that have awarded you things on an individual level, etc., with the inverse also being true (those subjects shouldn't edit about you either). The nuance comes with which COIs we actually care about. As I think HEB alluded to somewhere, the status of having a COI is a behavioral concern and should be treated as such regardless of contribution amount or quality. I would analogize having a COI with a topic you don't edit about as equivalent to having a second account that you never edit with; it's something that exists as a potential problem but is a non-issue in practical terms, we don't need to require disclosure or look for it at all, and if it is discovered we have no basis for any sanctions. Editing topics you have a COI with is closer to operating multiple accounts: if discovered for reasons other than problematic editing, there may be cause to evaluate prior contributions, and depending on the timing, type, and extent of affected edits sanctions ranging from nothing to glocking may be warranted. We already have policies governing editor behavior that are quite divorced from the quality of their contributions, and consequences are typically context-dependent and at the discretion of admins or the community. I don't see why we can't use this same approach for COI. JoelleJay (talk) 18:39, 21 May 2024 (UTC)
- I really like this model from @JoelleJay of "if, were they to publish something on it in an RS, it would not be considered "independent" in WP terms". I think that's very functional and understandable to Wikipedia editors. That nicely differentiates the cases we care about (e.g., employed by, married to, in a lawsuit with) from the cases we don't care about (e.g., met once at a party, lived in the same city as). WhatamIdoing (talk) 23:36, 21 May 2024 (UTC)
- @Trystan, do you think our differential response to accusations of COI vs POV pushing are part of the problem? It feels to me that COI claims get a more dramatic response than POV pushing claims. If you feel like you need help, you might find it more effective to speculate on whether the problematic content was put there by a paid editor. WhatamIdoing (talk) 22:31, 17 May 2024 (UTC)
- Re the real world definition of COI being
a strong personal economic interest of a public official that is very likely to be a strong opposing interest to doing their job properly
, I strongly disagree that such a definition reflects general use, if we are to look at basically any organisation that publishes guidance on what to them is considered a disclosable conflict. Hell, I worked at a large public company where posts on social media constituted a disclosable conflict, and looking at the BBC guidelines, said company was not alone in that regard. The Canadian DoJ includesparticipating in outside activities, such as: speaking at a conference; [...] volunteer work; [...] publishing documents;
in their non-exhaustive list, and I don't think any of those can reasonably construed as "strong economic interest". Alpha3031 (t • c) 10:52, 18 May 2024 (UTC)- You are describing particular organizations' rules for their people. IMO that is not the common meaning. I think that if you asked a person on the street I'll bet that it would be something withing my narrower definition which you quoted. Sincerely, North8000 (talk) 17:56, 20 May 2024 (UTC)
- I'll put up twenty that the definition would be more along the lines of "where there are two interests, and they conflict" rather than anything as hyperspecific as the one with three qualifiers (strong personal financial) interest which impact or is likely to impact judgement. The latter, in my unqualified opinion, is more simply called "corruption". But I'm not a dictionary person. Alpha3031 (t • c) 14:02, 21 May 2024 (UTC)
- You are describing particular organizations' rules for their people. IMO that is not the common meaning. I think that if you asked a person on the street I'll bet that it would be something withing my narrower definition which you quoted. Sincerely, North8000 (talk) 17:56, 20 May 2024 (UTC)
- A Google search for conflict of interest definitions is all it takes to see that the real world common meaning of COI is not limited to public officials, nor to economic interests. Levivich (talk) 12:57, 21 May 2024 (UTC)
- Each organisation that has conflict of interest policies has definitions, etc that are tailored to what is relevant to that organisation. None of the organisations that come up when I search are online projects whose goal is to write an encyclopaedia, so none of their can be assumed to be relevant or correct without examining what they are, why they are, how they are interpreted and what relevance the COI has to actions that are or may be taken or not taken. Thryduulf (talk) 13:54, 21 May 2024 (UTC)
- Somehow I'm not surprised you're not finding many encyclopedia-writing COI policies out there... check publishers or journals, see if their COI policies are limited to public officials or economic interests. Levivich (talk) 14:00, 21 May 2024 (UTC)
- Wikipedia is neither a journal nor a traditional publisher, journals and traditional publishers are not in the business of crowdsourcing a general purpose encyclopaedia. What their COI policies say or don't say is not automatically relevant to us - if you think a provision is or is not relevant to us you need to explain why beyond noting that it is relevant to a different organisation. Thryduulf (talk) 14:35, 21 May 2024 (UTC)
- My comment about real world definitions of COI was in response to "The real world common meaning of COI is pretty severe and narrow. Generally a strong personal economic interest of a public official that is very likely to be a strong opposing interest to doing their job properly." This is easily disproven by looking at various definitions of COI in the real world. Meanwhile, you're talking about something entirely different: whether COI should mean the same thing on Wikipedia than it does in the rest of the world. Levivich (talk) 15:34, 21 May 2024 (UTC)
- Wikipedia is neither a journal nor a traditional publisher, journals and traditional publishers are not in the business of crowdsourcing a general purpose encyclopaedia. What their COI policies say or don't say is not automatically relevant to us - if you think a provision is or is not relevant to us you need to explain why beyond noting that it is relevant to a different organisation. Thryduulf (talk) 14:35, 21 May 2024 (UTC)
- Somehow I'm not surprised you're not finding many encyclopedia-writing COI policies out there... check publishers or journals, see if their COI policies are limited to public officials or economic interests. Levivich (talk) 14:00, 21 May 2024 (UTC)
- Each organisation that has conflict of interest policies has definitions, etc that are tailored to what is relevant to that organisation. None of the organisations that come up when I search are online projects whose goal is to write an encyclopaedia, so none of their can be assumed to be relevant or correct without examining what they are, why they are, how they are interpreted and what relevance the COI has to actions that are or may be taken or not taken. Thryduulf (talk) 13:54, 21 May 2024 (UTC)
The Teahouse and COI
There is a concern expressed more or less in the middle of the extended discussion above, to the effect that the conflict of interest policies are oversimplified at the Teahouse. I partly agree and partly disagree, because the usual explanation of conflict of interest policy at the Teahouse has to be oversimplified, because it is in response to a clueless editor who wants to know why their draft about their business or herself or himself was declined or rejected, or sometimes why their article about their business or self was speedily deleted. The large majority of explanations of conflict of interest at the Teahouse are not addressed to clueless new editors who want to improve the encyclopedia. They are addressed to clueless new editors who want to use Wikipedia as a web host or advertising vehicle or platform. It may be that editors in the former class, who want to improve the encyclopedia and would like to edit an article on their employer or their civic association, get a more negative impression than is necessary. But I think that it is more important to discourage clueless misguided editing in that forum than to provide subtle advice to good-faith editors. There may be cases where Teahouse hosts should change the wording of what they say about conflict of interest, but it is essential to discourage promotional editing. Robert McClenon (talk) 00:10, 17 May 2024 (UTC)
- I think a narrower and better-defined COI test would help with both groups. I.e., a rule that you should not edit when you are paid or otherwise have a significant financial interest in the topic, or the content involves you or your close friends and family. The vagueness of "any external relationship can trigger a conflict of interest", and the guidance to determine through common sense whether the closeness of the relationship "becomes a concern on Wikipedia" invites shameless self-promoters to blithely press ahead, because they invariably don't see a problem. Meanwhile, conscientious good-faith editors who don't actually have a COI self-select out just to be on the safe side. In the professional off-wiki contexts I am familiar with, COI is framed as a much more concrete and objective test, identifying well-defined situations that would give rise to the appearance of bias, whether actual bias is present or not. That clarity gives everyone the confidence that conflicted-out individuals can easily recognize that fact and govern themselves accordingly.--Trystan (talk) 01:08, 17 May 2024 (UTC)
- What you’ve just said, @Trystan, really resonates with me as an editor with a COI situation out on the horizon. Having guidelines just a little clearer with real-life examples to make the directives come more alive — including how the editors in each situation handled it and what the resolution was — would be so appreciated.
- After all, there are serious repercussions involved here. Messing up in COI is not quite the same as, let’s say, messing up in not providing good supporting citations.
- Greater COI clarity could also be of value on the other side of the spectrum from messing up, where editors might not understand that they might find themselves in a COI situation yet still be able to proceed in editing an article, even perhaps writing it from scratch.
- I think a similar balance is needed in Wiki directives between making them too hefty and making them too lightweight … but isn’t that the same as what we want in Wiki articles? Augnablik (talk) 03:54, 17 May 2024 (UTC)
- To you or your close friends and family, I'd add "your teachers or co-workers".
- It's tempting to add "your clients", but I'm not sure that's always going to take us in the right direction. Consider a hypothetical long-time Wikipedia editor. Like about 10% of the workforce, he happens to have a job in sales. He's currently researching Bob's Big Business, Inc. at work. Should he (a) update the Wikipedia article with public information about the company, or (b) leave the article inaccurate and out of date, because it's a COI to share information he happened to learn on the job?
- I want to stop paid editing. I want to stop lawyers editing articles during trials. I don't want to stop ordinary people sharing the information they happened to learn at work. WhatamIdoing (talk) 22:46, 17 May 2024 (UTC)
"Paid editing, significant financial interest, or you and close personal friend or family": Well, that is what is laid out in the COI guideline (and somewhat more explicit like "owner", "manager") but than what you get is debate over things like "significant" and "close", anyway.
If some really want a more detailed list one way to do that is to look for good publishing codes, publications on ethics in writing, journalist codes, etc. and write a group WP:Essay, your essay may be so good others start citing it all the time and then it may become guideline or policy (covering such things as executives, board members, fiduciaries, those whose job involves non-public information (because that means overarching duty owed to the org or to the markets regulators), investors, marketers, advertisers, spokespeople, etc. etc.). [Adding, the essay could also consult Arbcom cases, COIN cases, Teahouse COI discussions, and other such onwikiplaces].
Alternatively, or at the same time, if people were interested in creating a list like Wikipedia:Reliable sources/Perennial sources for COI's that get discussed at places like WP:COIN , Teahouse etc. that could work. And ultimately if you get to what someone sees as a sticky wicket, put it to a vote/not vote, it may not be a sticky wicket, at all.
A primary way one might think about the guideline is it is a code for writers/publishers, since here, they are one in the same. -- Alanscottwalker (talk) 13:06, 18 May 2024 (UTC) [added in brackets - Alanscottwalker (talk) 12:09, 19 May 2024 (UTC)]
I think that it's important to remember that COI-related influence is a matter of degree and relates to concentrated tangible personal gain, not just influence by external factors:
- Concentrated. If a mere employee of a company with 100,000 employees writes in their company's article, any gain from their writing will be very dispersed and thus microscopic. If they own the business, are senior management or are the PR department any gain will be much more concentrated. And of course the strongest is paid editing.
- Influence-only is not necessarily COI influence. Otherwise everyone with mere political views or a cause has a COI influence.
- Tangible gain means something more than just feeling good or helping a cause.
And again, the net result comes from the strength of the influence and the ability and propensity of the editor to ignore it and wear only their Wikipedia hat when editing. North8000 (talk) 18:54, 20 May 2024 (UTC)
- Something to remember… having a COI does NOT mean someone is banned from editing an article. We ask those with a close connection to the topic to disclose their connection, so that we can examine their edits … in case their connection leads them to edit inappropriately. However, if they edit appropriately, then there is no problem. Blueboar (talk) 21:07, 20 May 2024 (UTC)
- Is it as simple as that, @Blueboar? If so, 99% of the concern I’ve had ever since I first found out about this Wikipedia issue and its assorted punishments for sinners will evaporate.
- If we can confidently go forward with our articles knowing they won’t be automatically zapped just because we put a COI label on them, that’s eminently fair. A remaining issue will be training (perhaps even required?) to ensure that editors can recognize both objectivity and its opposite, plus a test to ensure that they can apply objectivity in their Wiki efforts. If these are described as for editors’ benefit and success, helping us cut through what’s been a huge area of confusion and anxiety, my experience in the world of training makes me believe most Wikipedians will be likely to go along.
- I assume there are Help tutorials on COI. If so, are they in depth enough or do they need a little tweaking? Augnablik (talk) 02:09, 21 May 2024 (UTC)
- While it should be as simple as that it unfortunately isn't, partly due to very different opinions regarding what is and is not "appropriate" editing - in the view of some people (including me) everything that improves the encyclopaedia in some way is appropriate, in the view of some others every edit by someone with a COI is inappropriate. There are also many different views between the extremes. Thryduulf (talk) 02:20, 21 May 2024 (UTC)
- Because of those differing views, contributors cannot "confidently go forward with our articles knowing they won’t be automatically zapped just because we put a COI label on them". There always will be patrollers who believe that any COI worth disclosing is a COI worth cancelling the content over. WhatamIdoing (talk) 00:35, 22 May 2024 (UTC)
- While it should be as simple as that it unfortunately isn't, partly due to very different opinions regarding what is and is not "appropriate" editing - in the view of some people (including me) everything that improves the encyclopaedia in some way is appropriate, in the view of some others every edit by someone with a COI is inappropriate. There are also many different views between the extremes. Thryduulf (talk) 02:20, 21 May 2024 (UTC)
A suggested more specific definition
Some appetite has been expressed for a more specific definition of COI. I agree with it and so in an attempt to concentrate discussion in that direction, here's my proposal:
You have a COI if you meet any of the following criteria:
1. You know the subject of the article personally. What exactly "know personally" means is somewhat subjective, but it's pretty broad: going out for a beer with someone once is enough. This also explicitly includes yourself.
2. You have a concrete financial interest in the subject of the article, however slight. If you could make or lose money based on the content of the subject's Wikipedia article, you have a conflict of interest with regards to them. This explicitly includes your employer, anyone who is paying you to edit Wikipedia and any subjects they are paying you to edit Wikipedia about, and any stocks or other financial instruments you own and are aware you own.
3. You have some other concrete material interest in the subject of the article (often but not necessarily views or attention). So for instance, both the president of the Taylor Swift fanclub and the guy who tracks Taylor Swift's jet have a conflict of interest with regards to Taylor Swift even if neither of them monetize it. This explicitly includes any organizations you belong to or projects you work on even if not monetized. Note that this material interest must be concrete: a fan club president could gain members and a diss website could gain views, which are both concrete benefits, but an ordinary fan or hater can't gain anything concrete, only an intangible sense that their opinions are correct (which is not enough to trigger a COI).
It's only a first draft so improvements could definitely be made. Is there anything I'm clearly missing? Loki (talk) 03:04, 21 May 2024 (UTC)
- My first impression is that this is extremely overbroad. Simply going out for a beer with someone once does not constitute a COI. The definition in point three would mean that everybody who has ever edited Wikipedia has a COI with Wikipedia. Thryduulf (talk) 03:09, 21 May 2024 (UTC)
- I'm trying to put this middle-of-the-road between people who think COI is very narrow and only covers stuff like editing pages about your employer, and people who think that it's extremely broad and covers just being a fan of a thing. And both of those kinds of people have expressed those opinions in this thread, so clearly both of them are positions a real person could have.
- Also, I'll be honest, this is very close to my own opinions on what constitutes a COI. Which is to say, when it comes to individuals it really is pretty broad and really would cover anyone you have even had a long conversation with. People are very bad at dispassionately editing the articles of people they know personally. Human empathy is a powerful "concrete material interest" that we need to consider.
- There's definitely some improvement to be made in the wording of point three, though. I didn't mean to include Wikipedia in either an organization you belong to (that'd be Wikimedia staff but not ordinary editors) or projects you work on (that was intended for personal stuff, not big collaborative efforts) but I could definitely see how it could be read differently. Wikipedia itself might just need to be a special cutout, though, because despite not intending it, I actually do think it's plausible that Wikipedia editors in general have a COI about Wikipedia itself. Loki (talk) 03:22, 21 May 2024 (UTC)
- I agree that we almost certainly do in general have a COI when it comes to ourself, I think everyone on some level understands that... The community is on its best behavior when covering things which involve us (Criticism of Wikipedia etc) and we seem to make a concerted effort to make sure that such discussions have centralized and broad input and that the content we put out is as close to NPOV as we can possible get. Horse Eye's Back (talk) 17:28, 22 May 2024 (UTC)
- Which proves that it is possible for editors with a COI to write NPOV content. Thryduulf (talk) 17:52, 22 May 2024 (UTC)
- I never said we wrote NPOV content... I said that we got as close to NPOV as we can possibly (SIC in original) get. Its also never been in question whether editors with a COI can write NPOV content, the question is whether editors with significant COI can reliably do so without help (very different questions). Horse Eye's Back (talk) 17:57, 22 May 2024 (UTC)
- This feels like a narrower and more accurate statement than most of the foregoing. It's not any and every relationship, but only significant ones. The question is not whether possible or impossible, but whether the community can rely on it happening. It's not whether they can, but whether they'll need help.
- I would add "inexperienced" to this list of qualifiers. That may not be quite the right word, as I intend for it to encompass anyone with less than expert-level Wikipedia skills. I'm pretty sure that I could write some NPOV content on almost any subject without any help. I'm also pretty sure that I know the limits of my abilities (e.g., whether I'd be able to meet my standards wrt a given subject; which aspects of the subject I could safely write about; whether fixing the article is worth the drama), so you could rely on me to either get my edit right or to avoid that subject. IMO it can be done, but since the world is not made up of highly experienced Wikipedians who have internalized the systems here, I wouldn't count on it happening in any given case. WhatamIdoing (talk) 16:03, 23 May 2024 (UTC)
- I never said we wrote NPOV content... I said that we got as close to NPOV as we can possibly (SIC in original) get. Its also never been in question whether editors with a COI can write NPOV content, the question is whether editors with significant COI can reliably do so without help (very different questions). Horse Eye's Back (talk) 17:57, 22 May 2024 (UTC)
- Which proves that it is possible for editors with a COI to write NPOV content. Thryduulf (talk) 17:52, 22 May 2024 (UTC)
- I agree that we almost certainly do in general have a COI when it comes to ourself, I think everyone on some level understands that... The community is on its best behavior when covering things which involve us (Criticism of Wikipedia etc) and we seem to make a concerted effort to make sure that such discussions have centralized and broad input and that the content we put out is as close to NPOV as we can possible get. Horse Eye's Back (talk) 17:28, 22 May 2024 (UTC)
- I agree with Thryydulf that this definition is too broad.
going out for a beer with someone once
is especially broad. Family, yes; friends, yes; Coworkers you have worked with/do work with, sure (though I wouldn't agree with 'all employees of your organization across all of space and time ever even ones you never interacted with')—but a single conversation? This is far too much.any organizations you belong to or projects you work on
is also too broad, and I don't think it's as simple as making a special carveout for Wikipedia (and even if it was that simple—why the special exception? There are plenty of non-Wikipedia topics that Wikipedia editors could contribute to). The impression this gives is that members of the Conservative Party (UK) have a COI for Winston Churchill, that citizens of the United States have a COI for the Library of Congress, or that a member of D23 (Disney) has a COI for Disneyland, or adherents of religions that measure/register membership—say, the Catholic Church—have a COI (in this example, say, for Paul the Apostle). That seems much too broad. Hydrangeans (she/her | talk | edits) 04:04, 21 May 2024 (UTC)- What if the criterion for COI were anything that could give the slightest appearance of a conflict of interest?
- As long as COI is not in and of itself a bar to writing and editing Wiki articles … and the criterion of admissibility for articles worked on by editors with any degree or possible appearance of COI but the objectivity of their work … then we’d hardly ever have anything to lose by sticking a COI label on our work.
- That is, of course, if we ARE objective. Augnablik (talk) 04:27, 21 May 2024 (UTC)
- If two people think it's too broad, then maybe it is too broad. But I do want to define a COI based on objective tests and not based on subjective tests like "the slightest appearance of a COI", because it's very clear that editors have wildly differing views on what appears to be a COI. Loki (talk) 05:00, 21 May 2024 (UTC)
- Two some examples of how this is too broad: Quite by accident the other day I discovered that one of my coworkers from when I worked at Defra is now a youtuber. I've not investigated whether they are notable, but they don't currently have an article. The only time I interacted with them outside the office environment was occasionally at the pub after work or on team away-days, and haven't seen them for about 20 years. Under your proposed definition I have a COI regarding them, in the real world I don't.
- I have created numerous redirects to articles about people/organisations with the aim of making it easier for people to find those articles (e.g. Comptel Data Systems cycling team, Pure (British radio station), Watercress line, Bridgnorth Castle Hill Railway, Martin Par, Sally Man, San Francisco BART, etc). This will have increased the views of those articles and, at least arguably, thus benefited the subjects. Doing this would, under the proposed definition, mean I have a conflict of interest with those subjects. Thryduulf (talk) 14:31, 21 May 2024 (UTC)
- I do think you have a COI with your former coworker.
- You wouldn't have a COI under this proposed definition for providing material benefits to someone else, including by editing their Wikipedia article. That editing Wikipedia can provide material benefits to someone is the background of the COI policy, it does not itself constitute a COI. (You also wouldn't have a COI under this definition for listening to a radio station or riding a particular train, though you would if you happened to be on that cycling team.) Loki (talk) 16:20, 21 May 2024 (UTC)
- Why do you think I have a COI regarding someone I haven't met for 20 years and are connected to only through a very large organisation I haven't worked for for well over a decade (and presumably who he no longer works for either)? What exactly are the interests that conflict? Thryduulf (talk) 17:21, 21 May 2024 (UTC)
- Same interests that would conflict with someone you know well. Human empathy is a powerful thing. People do not like to do things that would hurt people they know, including negative Wikipedia coverage. Loki (talk) 23:27, 21 May 2024 (UTC)
- @LokiTheLiar, since when is "not wanting to hurt people" considered "An involvement, claim, right, share, stake in or link with a financial, business, or other undertaking or endeavor"?
- I was reminded recently that, about 15 years ago, I added a paragraph about a supplier of medical marijuana. One of their clients used marijuana on their premises and caused a fatal car wreck on his way home. The other driver died. Her baby survived. He died the next day.
- While I was writing it, I remember thinking that I didn't want to hurt the feelings of any surviving family member. Do you think that recognizing that some ways of describing the facts could be hurtful is actually a "conflict of interest"? Personally, I thought it was more of a Golden Rule situation. WhatamIdoing (talk) 00:52, 22 May 2024 (UTC)
- Your quote misses the "they know" part of Loki's statement. Your example is surely a good instance of editing without a COI, as it shows feelings that might apply to anyone, rather than that would apply just to people you know. CMD (talk) 02:20, 22 May 2024 (UTC)
- I don't think I'd have done anything different if it had involved someone I knew, especially if I only knew them slightly or years before. Would you? Could you imagine yourself thinking "This is going to read by two mourning families now, and perhaps in the future by a baby trying to learn something about the car wreck that killed his mother. But I know this group, so I'll write it this way..."? I can't. WhatamIdoing (talk) 16:07, 23 May 2024 (UTC)
- Your quote misses the "they know" part of Loki's statement. Your example is surely a good instance of editing without a COI, as it shows feelings that might apply to anyone, rather than that would apply just to people you know. CMD (talk) 02:20, 22 May 2024 (UTC)
- Same interests that would conflict with someone you know well. Human empathy is a powerful thing. People do not like to do things that would hurt people they know, including negative Wikipedia coverage. Loki (talk) 23:27, 21 May 2024 (UTC)
- Why do you think I have a COI regarding someone I haven't met for 20 years and are connected to only through a very large organisation I haven't worked for for well over a decade (and presumably who he no longer works for either)? What exactly are the interests that conflict? Thryduulf (talk) 17:21, 21 May 2024 (UTC)
- The appearance of a conflict tends to be sufficient for people to assume that there actually is one, even if there actually isn't. Tough, I know, but there you are. Still stuck with the problem of defining that, tho. Selfstudier (talk) 08:40, 21 May 2024 (UTC)
- I think in most other organisations the issue is resolved by the fact that the group adjudicating conflicts of interest are a different group from the persons actually having a conflict. The guidelines for group B disclosing to group A could be somewhat (but not significantly) broader, and group A could continue to simply use the reasonable person standard. On wiki, of course there is only really one group (editiors). I mean, technically editors can privately disclose to ArbCom or something, but that would probably be a waste of time for everyone involved. Alpha3031 (t • c) 14:33, 21 May 2024 (UTC)
- Usually (i.e. outside of Wikipedia) conflicts of interest are defined by a reasonable person standard, that is, if a fair and reasonable person (properly informed) might conclude that the personal interest could improperly or unduly influence their regular responsibilities. This is a significantly lower standard than any possible perception of conflict. For example, I would say that a prototypical reasonable person would likely not consider being a fan of something a disclosable conflict, unless they were a pretty obsessive fan. (note that the prototypical reasonable person is still a fictional construct)
- Of course, most of the reasonable people editing Wikipedia would probably never become problematic in their COI editing, (if they do any) and conversely, most problematic COI editors would probably not meet the standard, so we probably do need to spell some things out. Alpha3031 (t • c) 14:25, 21 May 2024 (UTC)
- Do you mean significantly higher standard? Horse Eye's Back (talk) 13:30, 23 May 2024 (UTC)
- If two people think it's too broad, then maybe it is too broad. But I do want to define a COI based on objective tests and not based on subjective tests like "the slightest appearance of a COI", because it's very clear that editors have wildly differing views on what appears to be a COI. Loki (talk) 05:00, 21 May 2024 (UTC)
I think that a good framework is to define those COI influences which are strong enough to invoke Wikipedia's COI rules and guidance:
- The "strong enough......" criteria leaves out the very weak ones and avoids trying to legislate or philosophize the general "COI" term.
- Saying "COI influence" leaves the door open for re-introduction of the golden definition of COI-driven editing and makes the distinction between COI influences and COI-dominated editing.
Sincerely, North8000 (talk) 18:55, 21 May 2024 (UTC)
There should be a blanket ban on accusations of COI. Hawkeye7 (discuss) 20:09, 21 May 2024 (UTC)
- Just noting that raising the question is 95% of being an accusation. Mostly agree but I'd make an exception for raising the question where it very strongly looks like UPE. North8000 (talk) 20:15, 21 May 2024 (UTC)
- I think people need to be able to bring the point up. Obviously it's impolite to do it without a good reason, but I don't agree with banning the question. One of the big downsides of our WP:OUTING policy is precisely that it can make it hard to bring it up within policy, even when you have a good reason. --Trovatore (talk) 20:22, 21 May 2024 (UTC)
- It is not impolite, it is a personal attack, and it violates our no personal attacks policy. I have been accused four times, and not once was it with anything approaching a good reason. An automatic indefinite block for a personal attack would solve this problem. Hawkeye7 (discuss) 00:27, 22 May 2024 (UTC)
- Well, I disagree rather sharply. I have also been "accused", if you want to consider it an accusation, and I didn't like it either. But you know, you're not going to like every interaction you have here, and it's not a requirement that you should, though of course it's nicer when you do. I think it's legitimate to inquire into the things that might nudge editors into making judgment calls in one direction or another. --Trovatore (talk) 00:59, 22 May 2024 (UTC)
- It is not legitimate, it violates our policies. Hawkeye7 (discuss) 00:27, 23 May 2024 (UTC)
- If so, I would suggest that's a problem with our policies, because it's an objectively legitimate question. --Trovatore (talk) 00:36, 23 May 2024 (UTC)
- I've been in the same boat as you, but what policies does it violate? Because its obviously not inherently a personal attack, although it could be delivered as part of one, so what do you actually mean? Horse Eye's Back (talk) 13:34, 23 May 2024 (UTC)
- It is not legitimate, it violates our policies. Hawkeye7 (discuss) 00:27, 23 May 2024 (UTC)
- Well, I disagree rather sharply. I have also been "accused", if you want to consider it an accusation, and I didn't like it either. But you know, you're not going to like every interaction you have here, and it's not a requirement that you should, though of course it's nicer when you do. I think it's legitimate to inquire into the things that might nudge editors into making judgment calls in one direction or another. --Trovatore (talk) 00:59, 22 May 2024 (UTC)
- It is not impolite, it is a personal attack, and it violates our no personal attacks policy. I have been accused four times, and not once was it with anything approaching a good reason. An automatic indefinite block for a personal attack would solve this problem. Hawkeye7 (discuss) 00:27, 22 May 2024 (UTC)
- The problem with very strongly looks like UPE is that some editors believe that almost anyone starting an article about certain subjects very strongly looks like UPE – to their jaded (or incompetent) eyes.
- Perhaps if we had more of a game-ified software system, we could institute enforceable quotas ("You can only revert an article three times within 24 hours, and you can only accuse two editors of UPE within 30 days, and..."). As it is, we have only messy human-interaction options available to us. WhatamIdoing (talk) 02:13, 22 May 2024 (UTC)
- Yeah, I guess that there are varying standards on what strongly looks like UPE. I was talking about really strong. Maybe an editor with 200 lifetime edits, and all of those are to write 10 articles on living persons who works in an area where they would benefit financially from having a Wikipedia article. And their first edit in their account was to produce a near-finished article, and where they've done an expert job at finding and maxing out references where the pickings are pretty weak. North8000 (talk) 18:05, 22 May 2024 (UTC)
- If they've done an expert job of producing an article that demonstrates notability, what is the problem that you are trying to solve? Thryduulf (talk) 18:07, 22 May 2024 (UTC)
- @Thryduulf: Although it is a sidebar, for the example/what is typical, it's what I'd call edge case notability. They've maxed out finding what is available. Fails a strict reading of GNG, but would likely survive AFD. Now, answering your question, I'm not on any such quest. The only question is when it's looks near-certain UPE, and "do I have a due diligence obligation"? I think this is off topic here, I only brought it up as a possible exception to the "never ask" comment. North8000 (talk) 19:05, 22 May 2024 (UTC)
- If they've done an expert job of producing an article that demonstrates notability, what is the problem that you are trying to solve? Thryduulf (talk) 18:07, 22 May 2024 (UTC)
- Yeah, I guess that there are varying standards on what strongly looks like UPE. I was talking about really strong. Maybe an editor with 200 lifetime edits, and all of those are to write 10 articles on living persons who works in an area where they would benefit financially from having a Wikipedia article. And their first edit in their account was to produce a near-finished article, and where they've done an expert job at finding and maxing out references where the pickings are pretty weak. North8000 (talk) 18:05, 22 May 2024 (UTC)
- I think people need to be able to bring the point up. Obviously it's impolite to do it without a good reason, but I don't agree with banning the question. One of the big downsides of our WP:OUTING policy is precisely that it can make it hard to bring it up within policy, even when you have a good reason. --Trovatore (talk) 20:22, 21 May 2024 (UTC)
- Way too broad. #1 should be close friends and family members. If I go to a trade show and happen to eat lunch with someone that doesn't automatically create a conflict of interest. #2 with its "however slight" is so broad that you'd basically be asking anybody who owns a share of a "whole market index" fund to pretend like they have a COI. #3 is interesting and I had to chew on it a bit to see the conflict of interest, but doesn't that also boil down to a financial conflict of interest? The eventual goal of adding members to your club and attracting viewers to your website ultimately is to make some money, even if it's through ad revenue, right? ~Awilley (talk) 18:49, 22 May 2024 (UTC)
- Enough people have given that same criticism of #1 that I'll incorporate it into the next draft. The reason #2 includes
and are aware you own
is specifically to avoid whole market index funds. - For #3, not necessarily. Many people have no plan whatsoever to monetize their interests. So for instance, as far as I'm aware Azer Koçulu had never made a cent off left-pad, but that doesn't mean he doesn't have a COI for editing npm left-pad incident. Loki (talk) 19:48, 22 May 2024 (UTC)
- Enough people have given that same criticism of #1 that I'll incorporate it into the next draft. The reason #2 includes
My proposal would be to decide to set a course to make the necessary changes to make the COI policy consistent with this:
COI-influenced editing is when advancing outside interests is more important to an editor than advancing the aims of Wikipedia, where those influences are from potential tangible benefits that are somewhat concentrated on the editor. "Tangible" is intended to exclude ethereal benefits (such as feeling good about yourself) or where tangible benefits are of comparitively trivial value. "Somewhat concentrated" is intended to exclude benefits dispersed over a large group where the editor is merely a member of that large group. This also excludes cases where the editor is overly influenced by mere political views and mere causes. Many things might be called a COI-influence, with respect to provisions of this this policy, they fall into three groups:
- Where the nature and strength is such that the provisions of this policy do not apply
- Where the nature and strength is such that the general provisions of this policy apply
- Paid editing where the definitions and provisions of the more stringent special paid editing policy apply
Note this uses the terms "COI-influenced editing" and "COI influence" but not just "COI" because of it's multiple meanings some of which are pejorative. Sincerely, North8000 (talk) 19:32, 22 May 2024 (UTC)
- My first thought is that
COI-influenced editing is when advancing outside interests is more important to an editor than advancing the aims of Wikipedia
says everything that needs to be said. Thryduulf (talk) 19:48, 22 May 2024 (UTC) - This looks about right. Three comments and a question: 1) add "real or" to "potential tangible benefits" 2) Add a footnote to clarify that (paid or volunteer) membership in an organization is likely not COI-influence editing, but employment or serving as as a board member may be. 3) Delete the sentence on political views. Question: I don't understand the somewhat concentrated language. - Enos733 (talk) 19:55, 22 May 2024 (UTC)
- I put "political views" in (merely) as an example of where the editing may be problematically overly influenced by outside interests, but where "COI" provisions really don't apply. So it can go. To give an example of "Somewhat concentrated", if someone is merely a member of a large organization, any tangible benefit from editing the article on that organization would be widely dispersed and thus not "somewhat concentrated" and be microscopic for an individual member. North8000 (talk) 15:11, 23 May 2024 (UTC)
- Given that *any* editing which advances outside interests as such is already banned by WP:PROMO regardless of whether COI is involved what would be the point? You can't double ban something which is already banned. Horse Eye's Back (talk) 13:40, 23 May 2024 (UTC)
I find it helpful to think of "conflict of interest" as "conflict of role". One role is as a Wikipedia editor. Other roles include someone paid to edit; a (close) friend or family member of the person who has a Wikipedia article about them (or the person themselves); an executive of a company, or a member of the company's PR department; and president of a fan club. When the two roles conflict, it's critical to declare COI, and to minimize one's (direct) editing in Wikipedia.
Someone who is simply a supporter of a political candidate doesn't have a COI issue - but does have an NPOV issue when editing the article about that political candidate.
Tying this back to the previous post, "advancing outside interests" and "potential or tangible benefits" [from violating Wikipedia editing rules] are both related to having an (important) role that conflicts with the role of being a fully-compliant Wikipedia editor. -- John Broughton (♫♫) 23:41, 22 May 2024 (UTC)
Simplifying re COI
I have to question why we need to define all this… it strikes me as instruction creep. The concept is simple:
- For editors with a tie to the topic that might be a COI: Assume you have one and please disclose it … And if that tie will prevent you from editing in accordance with our policies and guidelines - Don’t edit. Note that paid editing is strongly discouraged.
- For other editors: If you think some other editor has a conflict, AND that conflict is preventing the other editor from editing in accordance with all of our policies and guidelines - first try to resolve the citation with civility, and if that does not work, report it (but be careful not to violate p&g in the process - especially our rules on “outing”). Note that if the other editor IS editing in accordance with p&g, there is no problem. Just keep an eye on the situation.
I don’t think we need to define things further. Blueboar (talk) 14:10, 23 May 2024 (UTC)
- Well, so as not be naïve, it's never not going to be problem for Wikipedia when it gets reported off-wiki that congressional offices are editing campaigns or CEOs are editing their company, its just not. Alanscottwalker (talk) 16:27, 23 May 2024 (UTC)
- The situations that a definition could help with are:
- Identifying a real-world COI
- This could predictably cause problems (politician replaces an article with puffery) or solve problems (marketing department notices that revenues were overstated).
- We want to warn these people off from editing directly.
- Drawing the line for barely-yes vs barely-no COIs
- This could cause a problem (high school student adds some trivial scandal du jour to the article about their own school) or solve a problem (high school student updates the article with the name of the new principal)
- We want to help the accusers figure out whether we consider attended this school/lived in this town/is one of millions of people who own that product/liked that movie to be a COI (historically, for these examples, we have not).
- Discouraging false accusations
- This could be due to bad behavior ("Nobody would write this kind of marketing bafflegab unless they were paid to!") or good behavior ("Nobody would care enough about this unimportant subject to create an article unless they were paid to!")
- False accusations harm the community. False accusations drive away promising editors. False accusations wielded as weapons by POV pushers are bad. The community does not need another round of "You obviously know something about this religion, and you're not denouncing them, so you have a COI" followed by "My connection with them is that they kicked me out for coming out as trans". That does not protect either articles or the community.
- Identifying a real-world COI
- Views from experienced editors are on a spectrum, but I think the two main areas are:
- We care about the article more than about how it got that way.
- For example: Given a choice between having an article on WhatamIdoing's Gas Station be outdated vs having me correct it, they lean somewhat towards having the article up to date. It would be better for Wikipedia to have a reputation for getting the article right than to have a reputation for incorrect and outdated content.
- We care about Clean hands/the reputation of the community more than having the article improved.
- For example: Given a choice between having an article on WhatamIdoing's Gas Station be outdated vs having me correct it, they lean somewhat towards having only The Right™ editors edit the article. It would be better for Wikipedia to have a reputation for maintaining pure motivations than to have a reputation for letting the subjects of articles influence their content.
- We care about the article more than about how it got that way.
- This is a difference in fundamental human values, so I do not think we will get agreement on which one is "correct". WhatamIdoing (talk) 17:03, 23 May 2024 (UTC)
- Once again, these positions you have made up are just figments when not insulting. Neither of those describe any editor unless the editor is such a fool as to think there is only one way to correct an article, and your "reputation of the community" stuff is just nonsense, unless you are actively trying to make-up nonsense. Alanscottwalker (talk) 17:12, 23 May 2024 (UTC)
- Given that Wikipedia:Edit requests exist for just such a scenario that seems like a false choice. Also you misremember history, the COI was with the Harold B. Lee Library and the Association for Mormon Letters not the religion itself and the editor turned out to be a former employee who had edited wikipedia pages about the library while an employee and an active member of the AML (the COI *was* substantiated, unlike the story you just presented). Horse Eye's Back (talk) 17:17, 23 May 2024 (UTC)
- IF they disclose, and are editing in accordance with our P&G… why should we care what gets reported off-wiki? Blueboar (talk) 17:06, 23 May 2024 (UTC)
- Yes, its when the reporters have to do the disclosing. Alanscottwalker (talk) 17:13, 23 May 2024 (UTC)
- The situations that a definition could help with are:
- Agreed. This seems like four pages of solution looking for a problem. GMGtalk 16:33, 23 May 2024 (UTC)
- I support continued attempts to refine and clarify the guideline. Lack of definition was cited repeatedly in a recent discussion as a reason not to upgrade the COI guideline to policy. I continue to think we deserve and need a clear policy on conflicts of interest. Firefangledfeathers (talk / contribs) 16:40, 23 May 2024 (UTC)
- We HAVE a clear policy… 1) disclose 2) edit in accordance with p&g (and if you can’t - don’t edit). Blueboar (talk) 17:12, 23 May 2024 (UTC)
- I'm not sure how you can think this true, and I think you are probably mistaken. Could you link to the policy you're referencing? Firefangledfeathers (talk / contribs) 17:18, 23 May 2024 (UTC)
- We HAVE a clear policy… 1) disclose 2) edit in accordance with p&g (and if you can’t - don’t edit). Blueboar (talk) 17:12, 23 May 2024 (UTC)
- I have my doubts whether CoI can be sufficiently defined so as to form the basis of a policy but the guideline could definitely be spruced up. Just for clarity, imo paid editing is a CoI. Selfstudier (talk) 16:49, 23 May 2024 (UTC)
imo paid editing is a CoI
- Yes? GMGtalk 17:19, 23 May 2024 (UTC)
- I'm referring to Wikipedia talk:Conflict of interest#Should we upgrade this to policy?, "Though that case also highlighted some ambiguities in the definitions of paid editing and financial COI, and relatedly this guideline's relationship to WP:PAID" Selfstudier (talk) 17:27, 23 May 2024 (UTC)
- Yeah, there's no way I'm reading through that pages long debate (but I do notice a bit of opposition). As far as I've seen, there's been little serious conflict in practice with the status of paid editing, with the exception of something like WP:GLAM, and it's mostly an issue that can normally be resolved with existing guidance and a healthy dose of WP:COMMONSENSE. We don't need to legislate every tiny detail. Most of us have a fairly decent head on our shoulders. GMGtalk 18:18, 23 May 2024 (UTC)
- I'm referring to Wikipedia talk:Conflict of interest#Should we upgrade this to policy?, "Though that case also highlighted some ambiguities in the definitions of paid editing and financial COI, and relatedly this guideline's relationship to WP:PAID" Selfstudier (talk) 17:27, 23 May 2024 (UTC)
- I have finally realized what my problem with this entire discussion is… it is focused on the editors, not their edits. Simply having a COI is not a flaw; allowing your COI to affect your editing to the point where you violate a p&g is. And THAT is best addressed by focusing on the edits, not the editor. Blueboar (talk) 22:58, 23 May 2024 (UTC)
- Yes, this is what I've been trying to say throughout most of this discussion. If someone with a COI and someone without a COI would make the exact same edit, it doesn't matter which one of them did. Thryduulf (talk) 23:49, 23 May 2024 (UTC)
- One might say that there has not been much good faith assumed in this discussion. Donald Albury 00:19, 24 May 2024 (UTC)
- Yes, this is what I've been trying to say throughout most of this discussion. If someone with a COI and someone without a COI would make the exact same edit, it doesn't matter which one of them did. Thryduulf (talk) 23:49, 23 May 2024 (UTC)
User page styling question
Is styling a user page like is done at User:Tevez Tam Gaming ok with our guidelines? It seems to fall under WP:SMI. I'm talking specifically about the hiding of the talk/view/edit/history links and not about the subjectively tacky choices. Gonnym (talk) 09:39, 15 May 2024 (UTC)
- Mm, I see an user talk link right next to the Wikipedia logo. I'd worry about the false claim to be an admin - I am not sure that the average editor knows about Special:UserRights and thus might falsely think that they are an admin. Jo-Jo Eumerus (talk) 09:54, 15 May 2024 (UTC)
- This clearly violates WP:SMI on Vector 2022 – all the UI under the header bar is hidden, and most of the remaining text is unreadable black on purple. It's so messed up I don't even know how to go about fixing it. – Joe (talk) 10:26, 15 May 2024 (UTC)
- Note that Joe blanked the page with a link to the WP:SMI and left an explanatory message on their user talk. Looking at the revision prior to blanking, it was all-but completely unusable on Monobook skin with no link to user talk, etc. Thryduulf (talk) 12:20, 15 May 2024 (UTC)
Use of quote boxes in mainspace articles?
This question arose out of a discussion over at Talk:Climate_crisis#Quote_boxes Essentially, that article used have two quotes placed into highly visible, blue-tinted boxes - roughly similar to how images are placed. You can see an example here. A WP:GOCE volunteer had removed those quote boxes, arguing that they were the equivalent of WP:PULLQUOTES. The article's primary editor, who placed those boxes there, predictably disagrees.
Now, I did a quick search of the archives, and couldn't find if this question had ever been discussed before. What do the editors here think? InformationToKnowledge (talk) 14:52, 18 May 2024 (UTC)
- Balfour Declaration, which went through FA review, has a few. So looks as if it is OK in principle, should be due, NPOV and so on, like everything else. Selfstudier (talk) 14:59, 18 May 2024 (UTC)
- I found this a very interesting example. It appears to provide images of specific documents when they're available, and quotations from the ones that we don't have a photo of. The process of choosing "the image showing these words of this document" is not IMO materially different from the process of choosing "these words of that document". I assume that if suitable scans of the documents became available later, then the quoted text would be replaced by an image, and everyone except those who can't read the text in the images will be satisfied. WhatamIdoing (talk) 21:36, 18 May 2024 (UTC)
- A fallacy of a site-wide blanket ban on all quote boxes (beyond fallacies I list here) is that quote boxes are essentially images of text. They are not inherently pullquotes. A site-wide ban on quote boxes would by implication outlaw { } and { } and { }, and so forth. —RCraig09 (talk) 17:07, 18 May 2024 (UTC) (primary editor of Climate crisis)
- Hi all, I guess I'm the cause of this upset. I thank I2k for bringing this up here, I was thinking to ask at one of the help desks. My view is quote boxes are functional equivalents of pull quotes because they do the same thing as pull quotes; they decoratively present and bring undue attention to single quotations with no proper context in isolation from surrounding text, and sometimes with no relevance to the article's text. They present an editorial points of view decided by a single editor and skew neutrality. I think quote boxes should be deprecated in the mainspace in the same manner as pull quotes, and eventually eliminated from it. RCraig09's view of quoteboxes as a functional equivalent to images makes no sense to me; text and images are not the same thing, nor are they interpreted in the same manner. Cheers, Baffle☿gab 18:08, 18 May 2024 (UTC)
- Added note; the Manual of Style is a guideline, not a policy. Baffle☿gab 18:27, 18 May 2024 (UTC)
- Well, that is obviously not necessarily so, whether it is so in some specific case would need to be discussed. Selfstudier (talk) 18:13, 18 May 2024 (UTC)
- What isn't "obviously not necessarily so"? Please be clear in your replies,
otherwise you may as well just mumble into your hand and vaguely point into the distance!Cheers, Baffle☿gab 18:23, 18 May 2024 (UTC)- I refer you to my initial response (and lose the snarky attitude). Selfstudier (talk) 18:29, 18 May 2024 (UTC)
- Sorry for that, Selfstudier. Thanks everyone else for their input. Baffle☿gab 00:14, 20 May 2024 (UTC)
- (@Selfstudier, I think that was a request to identify which of the many things Bafflegab said that is the antecedent for the pronoun "That" at the start of your sentence. For example: Is it "obviously not necessarily so" that Bafflegab is "the cause of this upset", or that they present an editorial POV, or that the MOS is a guideline, or what?) WhatamIdoing (talk) 21:19, 18 May 2024 (UTC)
- I guess they can speak for themselves, right? And I already clarified that my "that" doesn't refer to anything they said at all. Selfstudier (talk) 22:08, 18 May 2024 (UTC)
- I refer you to my initial response (and lose the snarky attitude). Selfstudier (talk) 18:29, 18 May 2024 (UTC)
- What isn't "obviously not necessarily so"? Please be clear in your replies,
- Almost every, single, substantive edit on Wikipedia potentially involves hurdles re undue weight, context, connection to other text, relevance, editorializing, and neutrality; yet through millions of applications of editor judgement, Wikipedia thrives. Separately: re my 17:07 post re images, I meant that both quote boxes and images of historical texts are simply rectangles of pixels representing alphabetic characters, so that blanket-banning one would imply blanket-banning the other. —RCraig09 (talk) 20:09, 18 May 2024 (UTC)
- Well, that is obviously not necessarily so, whether it is so in some specific case would need to be discussed. Selfstudier (talk) 18:13, 18 May 2024 (UTC)
- If I'm perfectly honest, I think almost all cases of quote boxes are overdue weight. Should we really be highlighting specific things people have said about something. Usually the only time I think it's suitable is when the quote is from the prose/work and the text in the article is directly commenting on that part.
- Others probably have different views on this though. Lee Vilenski (talk • contribs) 18:40, 18 May 2024 (UTC)
- I don't see a significant difference between a block quote and a pull quote. One's in the middle of a paragraph and the other's on the side, but both put all the words in the article. I wonder how much of the instinctive rejection is caused by the default blue background for the latter. WhatamIdoing (talk) 21:28, 18 May 2024 (UTC)
- Looking beyond mere appearance, and contrary to what the copy editor insinuates, the quote boxes in the subject article are simply not pull quotes, for several reasons listed in the first paragraph of this post. +Background color is also choosable on a case-by-case basis. —RCraig09 (talk) 22:16, 18 May 2024 (UTC)
- Just a quick note. Our MOS says
This below-quotation attribution style is intended for famous quotations and is unusual in articles because it may strike an inappropriate tone.
- Are the quotes we are talking about "famous quotes", or just things people have said about a thing? Lee Vilenski (talk • contribs) 23:24, 18 May 2024 (UTC)
- AIUI they're talking about the difference between:
- Now is the time for all good men to come to the aid of the party.[1]
- vs
- Now is the time for all good men to come to the aid of the party.—Charles E. Weller[1]
- WhatamIdoing (talk) 23:36, 18 May 2024 (UTC)
- I don't see a significant difference between a block quote and a pull quote. One's in the middle of a paragraph and the other's on the side, but both put all the words in the article. I wonder how much of the instinctive rejection is caused by the default blue background for the latter. WhatamIdoing (talk) 21:28, 18 May 2024 (UTC)
- Quote boxes are ok, but should be used very sparing, which mostly they are. Johnbod (talk) 01:04, 19 May 2024 (UTC)
- Quote boxes are ideally used, like images, to illustrate an article ('illustrate' used proverbially, in the case of quotes). Of course context matters around the selection and inclusion of quotations in boxes. In principle, I think they can be and are fine. If we were to prohibit quote boxes from main space articles, I can't help but think it would follow to prohibit images as well—couldn't it be said that my decision to include an image of author Gordon Wood in the article about Empire of Liberty draws undue, decontextualized attention to Wood and his appearance or something like that?—and I don't think Wikipedia would be very improved if we did that ('that' being prohibiting either quote boxes or images or both). Hydrangeans (she/her | talk | edits) 01:23, 19 May 2024 (UTC)
- One way to support the weight of including a quote box is to have them sourced not to the original primary documents, but to secondary sources that analyse that quote or use it as an example. CMD (talk) 05:34, 19 May 2024 (UTC)
- I don't use quote boxes often, but when I do, such as in T. Rex and the Crater of Doom, I feel like it does add a sense of style to the article. Of course, my usage is explicitly not as any form of pull quotes, since the quoted material isn't in the article otherwise. So I suppose the context of usage matters. Generally, I would expect quote boxes to have separate material that isn't being duplicated in the regular prose of the article itself. SilverserenC 06:52, 19 May 2024 (UTC)
- I've used them fairly often. They're useful for a number of things, including material I feel will be interesting to the reader that doesn't integrate well to the text.Wehwalt (talk) 15:56, 19 May 2024 (UTC)
- Quote boxes can be useful per Wehwalt, they are not generally "pulled" from the article, but rather like images and illustrations add to the article. (Also, setting off quotes with, for example, different margins and space, is common in expository writing, among other things, it breaks up solid lines of prose upon prose.) -- Alanscottwalker (talk) 01:12, 20 May 2024 (UTC)
- Agree with several comments above that quote boxes are fine but should not be overused. Mike Christie (talk - contribs - library) 02:03, 20 May 2024 (UTC)
- Quote boxes aren't the same as pull quotes: pull quotes repeat text in the article, whereas quote boxes have text that is not in the article. This is a major difference. As others have said, quote boxes shouldn't be overused, but sometimes quotes can add value to articles, for various reasons. Levivich (talk) 05:58, 20 May 2024 (UTC)
- This discussion reminds me of an example of the abuse of quote boxes I ran across not so long ago: § The pretty boxes almost make you forget that none of the quotes so prettily boxed up actually talk about the subject of the entry... (
well, actually, the last one does, which is why it's still there, even if it's not very pretty(turns out it's a single-celled table). Anybody skilled in the elegant art of quote box decoration is welcome to try to fix it up). -- SashiRolls 🌿 · 🍥 08:15, 20 May 2024 (UTC) - If used judiciously, I think quote boxes can be a good resource for providing additional context on an article's topic. For instance, for topics in history or the arts, they can provide perspectives from involved figures that may not fit naturally in a prose summary. As an example: one article where I think quote boxes are well used is Sgt. Pepper's Lonely Hearts Club Band, a current FA. ModernDayTrilobite (talk • contribs) 15:18, 20 May 2024 (UTC)
- I've been hearing for years that quote boxes are inherently POV, and it's nonsense. Judgment must be exercised, and the quote boxes' cases are limited, but a highlighted quote need be POV no more than does a block quote in the article proper, or a photo caption. A quote box is POV if it's POV, its undue if its undue, and it's not if it's not. We make editorial decisions about what to include or not include, what to put in the lead or not put in the lead, what to emphasize or not emphasize, all the time. Quote boxes are just one more such decision. EEng 08:53, 23 May 2024 (UTC)
Infoboxes
I noticed that the Infoboxes of Micronations have disappeared. There is absolutely no good reason for it. We should change it back Eehuiio (talk) 15:25, 19 May 2024 (UTC)
- Have you got the page link to where an infobox has been removed? Lee Vilenski (talk • contribs) 15:32, 19 May 2024 (UTC)
- See archive #191… about a month ago, we held a long discussion about the infoboxes for micro nations. The general feeling was that using the “country” infobox was inappropriate… with some support for creating a brand new “micro-nation” infobox specifically for these articles. Blueboar (talk) 15:36, 19 May 2024 (UTC)
- I see that some work has been to implement the consensus of that RFC. I didn't see any infoboxes removed, but I only checked a few articles.--Trystan (talk) 15:45, 19 May 2024 (UTC)
- The consensus of that RfC was to not use {{Infobox country}} for micronations. Regrettably, nothing further was agreed upon. What I've seen is plenty have had their Infobox country replaced with just plain {{Infobox}}, which of course should not be used directly. There is no reason not to use {{Infobox micronation}}. It currently redirects to Infobox country. The two should be unmerged, it takes just a few clicks to do so. Then micronation articles should be update to use that template. – Finnusertop (talk ⋅ contribs) 16:06, 21 May 2024 (UTC)
- @Finnusertop, Trystan, Blueboar, Lee Vilenski: I started the process of making an RfC compliant version of the infobox at Template:Infobox micronation/sandbox. The template should be mostly good to go, it just needs documentation. --Ahecht (TALK
PAGE) 21:29, 21 May 2024 (UTC)
- @Finnusertop, Trystan, Blueboar, Lee Vilenski: I started the process of making an RfC compliant version of the infobox at Template:Infobox micronation/sandbox. The template should be mostly good to go, it just needs documentation. --Ahecht (TALK
- The consensus of that RfC was to not use {{Infobox country}} for micronations. Regrettably, nothing further was agreed upon. What I've seen is plenty have had their Infobox country replaced with just plain {{Infobox}}, which of course should not be used directly. There is no reason not to use {{Infobox micronation}}. It currently redirects to Infobox country. The two should be unmerged, it takes just a few clicks to do so. Then micronation articles should be update to use that template. – Finnusertop (talk ⋅ contribs) 16:06, 21 May 2024 (UTC)
- I see that some work has been to implement the consensus of that RFC. I didn't see any infoboxes removed, but I only checked a few articles.--Trystan (talk) 15:45, 19 May 2024 (UTC)
Overuse of the term "criminal"
I am opening this topic on seeing recent extension to "<country> <male/female> criminals" categories. This pejorative term is applied here to freethinkers such as Richard Carlile and Thomas Aitkenhead. Both Carlile and Aitkenhead suffered legal consequences for their beliefs, but these are, to my mind, far from the everyday understanding of a criminal as someone taking advantage of their fellows.
As I previously commented, describing as "criminals" all those imprisoned or executed after a process would draw in philosophers and religious figures, discarded wives and courtiers in monarchies, those executed in the Terrors of France in 1793 and the Soviet Union in 1937, opponents of the Nazis but not all the Nazi leadership themselves, astronomers, geneticists, etc.
Could Wikipedia use a stricter definition to attain WP:NPOV? I suggest limiting the term to those found responsible for actions causing harm to specific other people - broadly, what common law jurisdictions might regard as tortious liability. It isn't airtight, as regimes love to convict opponents for corruption, but better than the current arbitrary over-use. AllyD (talk) 10:12, 21 May 2024 (UTC)
- Noting that there is an extra component to that. There is a huge difference between covering some criminal aspect and using "criminal" or their crime as the noun/adjective for the person. North8000 (talk) 20:24, 21 May 2024 (UTC)
- Isn't this already covered by WP:BLPCAT? Clovermoss🍀 (talk) 00:57, 22 May 2024 (UTC)
- I think this is a request to make BLPCAT even stricter and to also apply to long-dead people. Thomas Aikenhead is given as an example above. He not only has been dead for three centuries but also meets all the criteria in BLPCAT. But since he was executed for blasphemy, which is not something that a modern liberal democracy considers a valid crime, should we put him in Category:Scottish male criminals?
- One might decide that Category:People executed for blasphemy and similar cats are enough. A chat on the talk page would be the usual and appropriate way to make a decision. I think it is important to remember that even if the cat exists, and even if the rule permits inclusion in that cat, you are not duty bound to add every qualifying article to that category. WhatamIdoing (talk) 02:29, 22 May 2024 (UTC)
- Oh, that makes sense. Apologies for not thinking this through enough when linking BLPCAT. I think the spirit of this:
Caution should be used with content categories that suggest a person has a poor reputation (see false light). For example, Category:Criminals and its subcategories should be added only for an incident that is relevant to the person's notability; the incident was published by reliable third-party sources; the subject was convicted; and the conviction was not overturned on appeal.
should apply when categorizing long-dead people too. I also think that if a category doesn't quite fit (like what AllyD is describing above) we shouldn't use it. Criminal is a very broad term and it doesn't make sense to lump everyone together. Clovermoss🍀 (talk) 10:47, 22 May 2024 (UTC)
- I am a criminal. I forgot to renew the MOT test on my car once about twenty years ago, was stopped by the police and subsequently convicted of driving without an MOT. If there was a Wikipedia article about me would it be put in Category:English male criminals? I hope not. Phil Bridger (talk) 10:59, 22 May 2024 (UTC)
- Unless the failure to renew your MOT and/or your conviction for doing so was relevant to your notability then it would likely fail WP:CATDEFINE and so should not be included. Thryduulf (talk) 11:29, 22 May 2024 (UTC)
Draft Content Fork Question
Is a draft about a topic that was previously blanked and redirected by AFD a content fork? If so, should the creation of the draft be avoided because it will be a content fork? If not, is there some other policy-based reason why creation of a draft should be discouraged?
The question has arisen at Deletion Review of Shane and Friends. An article by that title existed in 2021, but was nominated for deletion, and the AFD discussion was closed as Redirect. The article was cut down to a redirect, but then there was edit-warring. The AFD was then subject to edit-warring. Three years later, there has been a Deletion Review asking to restore the article that was cut down to a redirect. The DRV is trending to Endorsing the Redirect. I said that the sources of the redirected article had been garbage, but that an editor in good standing could develop a draft with good sources and submit the draft for review via Articles for Creation. (That is common advice at DRV after an article has been deleted.) Another editor criticized my advice that a draft could be developed, and said that the draft would be an impermissible content fork, and would create attribution problems.
On rereading the guideline on content forks, I see that it only prohibits content forks of the same type. My interpretation is that a draft article and the history of an article that has been cut down to a redirect are different types of pages.
So my question is whether the guideline against content forks discourages review of a draft to replace a previous article that was cut down to a redirect. Robert McClenon (talk) 03:51, 22 May 2024 (UTC)
- A draft is not necessarily a content fork, but the message at the DRV seems to be that it is likely that this particular draft would end up being a content fork of the information already at the main page, and that a better course of action regarding the content would be to put it into the main page rather than the draft page. Is drafting generally common advice for articles that have been redirected? In full deletion cases I understand the rationale as a draft shows what a page might look like, but in cases where the article history exists a 'draft' of a kind can be seen there. CMD (talk) 04:24, 22 May 2024 (UTC)
- Where a page is merged and redirected, or simply redirect to the content already at the target, one can assume that the worthy content is in the target article, or should be added there.
- An AfD result to do this is typically done because the spinout article is redundant or contains excessive information. Telling someone unhappy with the result to go recreate it in draftspace is wholly nonproductive. It is going to waste the time of the editor who does this, and it is going to waste the time of reviewer who later deal with that draft. More than likely, it is going to be rejected by WP:SRE if it gets that far, and on the less likely chance that new content is actually worthy, it’s going to be an attribution hazard due to parallel histories with the draft and the mainspace article.
- Where the content is already in mainspace, it should be improved in mainspace, in plain view of all interested editors. If something needs spinning out, there are good instructions at WP:SPINOUT, and nothing there tells an individual editor to go off alone and make more content on a draft page. In an unusual case where editors think a draft will help, it is important that interested editors are aware, and the best way to ensure that is to talk about it on the article talk page.
- Robert McClenon is the ONLY editor I have ever seen tell an unhappy person at DRV to go to draftspace and recreate an article that was redirected via consensus at AfD, and in every circumstance I can imagine, this is a bad idea. SmokeyJoe (talk) 06:53, 22 May 2024 (UTC)
- Here's my take on this, after tracking down the DRV discussion in question: SmokeyJoe is right that a discussion at Talk:Shane Dawson about identifying sufficient reliable sources to establish independent notability would be the best way for someone interested to begin, rather than creating a draft on their own as the first step. But they're wrong or hyperbolizing about pretty much everything else, including the claim that Robert McClenon told the unhappy person at DRV to create the draft (the actual statement was
An editor in good standing may submit a draft ... The appellant is not an editor in good standing with respect to this title.
). As for the question about content forks, I find Wikipedia:Content forks#Temporary subpages most relevant; the implication I get from that is that Draft pages (at least when used correctly) aren't considered content forks, they're "a place to work on consensus". Anomie⚔ 12:14, 22 May 2024 (UTC)- Thank you, User:Anomie. I agree that it appears that User:SmokeyJoe has seriously misinterpreted what I said at the DRV. I did not tell an unhappy editor to create a draft. I have sometimes advised unhappy editors at DRV to create a draft, and I have sometimes disagreed with User:SmokeyJoe as to whether a draft was in order. Anomie is correct that I was not advising the appellant to create a draft. What I advised them was to stop engaging in personal attacks. I don't know why SmokeyJoe thought that I was advising an unhappy editor to create a draft. Robert McClenon (talk) 14:49, 22 May 2024 (UTC)
- In this case, the reason that I thought that a draft created by a good-standing editor might be in order is that I thought that the reason that the original article was blanked and redirected is that its sources were garbage, and that a draft with good sources might be different. Robert McClenon (talk) 14:49, 22 May 2024 (UTC)
- Thank you. Robert McClenon (talk) 14:49, 22 May 2024 (UTC)
- You wrote
An editor in good standing may submit a draft with good sources for review to Articles for Creation
. While always true, it is an inappropriate suggestion at a failed contest of an AfD decision to redirect (history intact, content at the target). Instead, all ideas for reversing the redirect should go to the talk page of the redirect. SmokeyJoe (talk) 23:33, 22 May 2024 (UTC)
- You wrote
IMO the draft idea is OK (regarding fork) but might not be ideal or helpful. One other idea.....suggest that any advocate for revival find two true GNG sources (in depth independent coverage of the topic of the article) on the topic and explain that this is the relevant question. Suggest that if so, the proceed per the above. And suggest that if they are unable to do so to not pursue having a separate article on the topic. North8000 (talk) 19:55, 22 May 2024 (UTC)
- Find two good GNG sources? Yes. Two are sufficient, and no more than three. I think for anyone wanting to reverse an AfD consensus, they should be pointed to WP:THREE for its advice. SmokeyJoe (talk) 23:36, 22 May 2024 (UTC)
- Of course three is better but keep in mind: 1. This is sort of setting "don't move until you have it" criteria. 2. Even two really GNG-solid sources is higher than the defacto standard at AFD for GNG-dependent articles. North8000 (talk) 15:17, 23 May 2024 (UTC)
- Question: What about telling the unhappy editor that they could work on the potential article in their USER space (ie to create a USER draft page)? When done, they can let us know, and we can figure out where best to place it (if at all). Blueboar (talk) 15:07, 23 May 2024 (UTC)
- That's good too. But I see a huge amount of misleading of newer editors all over the place on what matters (on GNG-dependent articles) and they end up on wild goose chases working on article quality issues that are not rejection criteria and then getting rejected again. And also people declining/rejecting/draftifying articles for article quality issues which are not rejection criteria. And so giving this guidance on GNG-dependent articles would help on both fronts. Clarifying, by "GNG-dependent" I mean where it doesn't meet any SNG criteria. North8000 (talk) 15:24, 23 May 2024 (UTC)
RFC notice for DYK and BLP policy
There is currently an RFC at Wikipedia talk:Did you know#RFC on DYK and BLP policy. All editors are welcome to participate.4meter4 (talk) 15:09, 23 May 2024 (UTC)
Technical
IP Information tool
Facing a new issue today regarding the IP Information Tool where access to some of the non-admin information does not show up in the Special:Contributions page for an IP as it did before. That page now only shows "Version", "Active blocks", and "Contributions". Oddly, the country (not city) location still pops up on the watchlist preview, even though it does not show on the Contributions page. Anyone else seeing similar? Best, CMD (talk) 08:00, 15 May 2024 (UTC)
- The IP information drop down has been returning no information for me other than the version (IPv4 vs. IPv6), local block info and contribs for the last two days. It's like it can't access any of the data from whichever database it draws from. Every other field simply states "not available".-- Ponyobons mots 21:43, 15 May 2024 (UTC)
- And regarding my odd note on watchlist preview, this only happens sometimes, with even different edits from the same IP showing me country location in one instance but not another. CMD (talk) 01:50, 16 May 2024 (UTC)
- Further learning, I can refresh the same IP contributions page repeatedly and sometimes it will show me the country, sometimes it will show no access. CMD (talk) 03:25, 16 May 2024 (UTC)
- Can someone link a page where this has recently happened to them, so that I can try to reproduce? –Novem Linguae (talk) 07:15, 16 May 2024 (UTC)
- @Novem Linguae: it happens on any IP contributions page (this one, for example).-- Ponyobons mots 15:29, 16 May 2024 (UTC)
- Thanks, I'm able to reproduce. According to https://phabricator.wikimedia.org/T363118#9804312, "not available" is case #2.
This means Spur/Maxmind doesn't have that data. Looking at these fields, they're all populated by Spur. Maxmind and Spur have different coverage, so we may have a location for an IP but no other data for it.
. So that one is not a bug and they have no plans to patch it, it looks like. –Novem Linguae (talk) 15:56, 16 May 2024 (UTC)- I don't understand how that data was available consistently for all IPs, then suddenly is missing for nearly all of them. It renders the entire IP contribs drop down useless. Oh well.-- Ponyobons mots 16:13, 16 May 2024 (UTC)
- Someone just commented in the ticket that they think it's happening way more than it used to and they think something is broken. So it may be a bug after all. Here's hoping the devs figure it out. –Novem Linguae (talk) 16:47, 16 May 2024 (UTC)
- If I refresh sometimes, sometimes, the location info magically just appears. So the data is there. Sometimes. This is all on the same IP page. The one listed just above if I refresh does show the location 1 time out of 4 or so. Canterbury Tail talk 15:58, 21 May 2024 (UTC)
- Someone just commented in the ticket that they think it's happening way more than it used to and they think something is broken. So it may be a bug after all. Here's hoping the devs figure it out. –Novem Linguae (talk) 16:47, 16 May 2024 (UTC)
- I don't understand how that data was available consistently for all IPs, then suddenly is missing for nearly all of them. It renders the entire IP contribs drop down useless. Oh well.-- Ponyobons mots 16:13, 16 May 2024 (UTC)
- Thanks, I'm able to reproduce. According to https://phabricator.wikimedia.org/T363118#9804312, "not available" is case #2.
- @Novem Linguae: it happens on any IP contributions page (this one, for example).-- Ponyobons mots 15:29, 16 May 2024 (UTC)
- Can someone link a page where this has recently happened to them, so that I can try to reproduce? –Novem Linguae (talk) 07:15, 16 May 2024 (UTC)
This has now been split into two separate Phab issues, Phab:T355392 and Phab:T355393. CMD (talk) 01:42, 24 May 2024 (UTC)
Dark mode is available in Vector 2022 as a beta feature
Hi everyone, the Wikimedia Foundation Web team has just released dark mode for logged-in users on desktop across all wikis for testing purposes. It's part of the Accessibility for Reading (Vector 2022) beta feature.
Just like previously, when we were releasing this feature for logged-in users on mobile, our goals for the early rollout are to:
- Show what we've built very early. The earlier you are involved, the more your voices will be reflected in the final version
- Get your help with flagging bugs, issues, and requests
- Work with technical editors to adjust various templates and gadgets to the dark mode
Known limitations
- Dark mode is only available for logged-in users: on desktop as a beta feature, and on mobile in the advanced mode.
- Gadgets may initially not work well with dark mode and may have to be updated.
- Our first goal is making dark mode work on articles. Special pages, talk pages, and other namespaces (including Wikipedia) have not been updated to work in dark mode yet. We have temporarily disabled dark mode on some of these pages.
What we would like you to do
Our request to you is exactly the same as previously:
- To opt into dark mode, select the Accessibility for Reading beta feature from the beta feature list. This will opt you into the Appearance menu displayed in the right sidebar on every page. More about the menu itself here.
- Next, go to different articles and look for issues:
- If you have noticed an issue with a template but do not know how to fix it
- Go to the recommendations page and find a relevant example
- If no relevant example is available or you're not sure of the fix, contact us
- If you want to debug many templates in dark mode
- Go to https://night-mode-checker.wmcloud.org/ and identify templates that need to be fixed. The tool flags the top 100 most read articles.
- Go to the recommendations page and find a relevant example
- If no relevant example is available or you're not sure of the fix, contact us
- If you want to identify problems beyond the top 100 articles.
- Install the WCAG color contrast browser extension (Chrome, Firefox) and visit some articles. Use it to identify problems
- Go to the recommendations page and find relevant examples
- If no relevant example is available or you're not sure of the fix, contact us
- If you have a bug report for dark mode that is not related to templates
- Take a screenshot of what you are observing.
- Contact us. If possible, please write down your browser version and operating system version.
- If you have noticed an issue with a template but do not know how to fix it
When most issues are solved, we'll be able to make the dark mode available for readers on both desktop and mobile. Go to the Accessibility for Reading project page and the FAQ page to see more information about the basics of this project. Thank you! SGrabarczuk (WMF) (talk) 21:47, 15 May 2024 (UTC)
- I don't know if this was the right move. Tons of pages still look like garbage (shoutout Special:Watchlist)—the theme is definitely not ready for use by non-technical editors. It wouldn't be too bad if you had made a seperate beta option for it—because you've clumped it in with Accessibility for Reading a couple people have gone on the Discord confused. Snowmanonahoe (talk · contribs · typos) 23:54, 15 May 2024 (UTC)
- "Fixing" it is as simple as setting your personal chosen theme to light mode.
- As for tons of pages, I just got separate word that OOUI interfaces don't support light mode (currently/ever?), which is why Watchlist has light elements. Perhaps it shouldn't be displaying as dark. Izno (talk) 00:08, 16 May 2024 (UTC)
- Articles too. Along with interface pages, editnotices, syntax highlighting, half the mboxes... Snowmanonahoe (talk · contribs · typos) 00:27, 16 May 2024 (UTC)
- We do have a long-term solution for OOUI fixes that is in development right now. We hope to have it ready within the next couple of weeks. In the meantime however, pages like Watchlist and should be displaying in light mode so this is a bug. We're tracking it in phab:T365084 and should have a fix out later today. OVasileva (WMF) (talk) 07:36, 16 May 2024 (UTC)
- @SGrabarczuk (WMF): Is there really a plan to take over the right 1/4 of screen with a "settings" panel every time someone opens a page in a new private tab, or clears cookies, or switches to a new language, or doesn't realize what the "hide" button does? Or is that just so in-your-face during the testing phase? Suffusion of Yellow (talk) 02:01, 16 May 2024 (UTC)
- Hey @Suffusion of Yellow - thanks for the question. In general, we think this is the most effective way to launch the new menu and be able to inform users about it. It removes the necessity to add additional modals or notices that say "New menu available!" or "Dark mode available", which would otherwise show on every pageview. So, the current plan is to keep the menu open by default for the wider release as well for all logged-in and logged-out users. Then, after the release, we can look at the data to gauge whether we need to keep it open as default, or collapse, and when. OVasileva (WMF) (talk) 07:40, 16 May 2024 (UTC)
- Why can't it be on the left side, with the TOC? Or better yet, just put a plain-text link at the top? I mean, registered users have already been able to find the "preferences" link for 20 years now. Right when I open up testwiki:LOREM IPSUM (or any page with a TOC) on my phone in a new private tab, then switch to the desktop site, about half my screen is whitespace, and the text is squished into a narrow little strip in the middle. It's unusable until I hide the settings column
- People are reading a website, not installing software. There shouldn't be a "setup" stage before they can get down to the business of looking up that one little fact. The defaults should at least be usable. Suffusion of Yellow (talk) 17:11, 16 May 2024 (UTC)
- Hi @Suffusion of Yellow - we generally have most personalized tools (page tools, the user menu, preferences) on the right side of the page, which is why we chose this location. It would have been confusing to show a menu on the left side of the page, next to the content-related ToC, only to then collapse it into the right side. Hope that makes sense.
- In terms of the defaults - I couldn't agree with you more. We want our defaults to be as usable as possible (and also to provide an easy opportunity for customization). We are currently in the process of defining and setting defaults for all three areas in the menu. These default will become available as the features themselves are ready. For example, the default for dark mode will be "automatic", which will follow the user's device settings. OVasileva (WMF) (talk) 06:46, 21 May 2024 (UTC)
- Hey @Suffusion of Yellow - thanks for the question. In general, we think this is the most effective way to launch the new menu and be able to inform users about it. It removes the necessity to add additional modals or notices that say "New menu available!" or "Dark mode available", which would otherwise show on every pageview. So, the current plan is to keep the menu open by default for the wider release as well for all logged-in and logged-out users. Then, after the release, we can look at the data to gauge whether we need to keep it open as default, or collapse, and when. OVasileva (WMF) (talk) 07:40, 16 May 2024 (UTC)
- @SGrabarczuk (WMF): https://night-mode-checker.wmcloud.org/ appears to only be for the mobile version. Is there is desktop report? Also, the beta is only for Vector 2022. Many editors still use legacy vector or other skins, will the new feature be moved to any other skin besides Vector 2022? How does the new feature compare to the dark mode gadget that is currently available? RudolfRed (talk) 03:31, 16 May 2024 (UTC)
- This dark mode is only going to be supported on Vector 22 and Minerva so far as I know. Izno (talk) 03:54, 16 May 2024 (UTC)
- The main idea of the new feature is that it doesn't invert colors that are not known to be invertable. This causes the colors on Pantone for example to not be distorted. Snowmanonahoe (talk · contribs · typos) 11:43, 16 May 2024 (UTC)
- Users are supposed to mark those themselves, see mw:Recommendations for night mode compatibility on Wikimedia wikis#Overriding night mode styles / disabling the night mode theme. Snævar (talk) 09:29, 18 May 2024 (UTC)
Configuring Git for Gerrit
I have a sort of "hello, world" MediaWiki coding change I'd like to submit as my first-ever contribution to MediaWiki, and to get myself started and oriented with the system for submitting coding changes. If all goes well with that, I hope to follow that up with a more substantial change sometime, hopefully soon, after that. I already have a Wikimedia developer account, with accounts on MediaWiki and Wikitech. My usernames there, including my SSH access (shell) username, are the same as my English Wikipedia username. Now mw:Gerrit/Tutorial#Configure Git is telling me I need to have my "own Gerrit username". Is this a name which is unique to Gerrit, and not used anywhere else, such as the Toolforge? Also, I see on the Gerrit settings page a "Username" (is that the same as Git's "own Gerrit username"?), "Full name", and "Display name" – how are each of these used? Which of these names are used for the CREDITS page, the list that's updated by updateCredits.php? wbm1058 (talk) 20:35, 17 May 2024 (UTC)
- Your Gerrit username is more properly your developer account username, which is the same as on Toolforge and other places. For those three fields, username is what you log in as, I don't think Full name is used anywhere, and display name is how your name appears on the Gerrit UI. updateCredits.php seems to parse "git log", so the name used is whatever shows up in Git, which usually is the same as one of the above but not necessarily. * Pppery * it has begun... 20:52, 17 May 2024 (UTC)
- Full name is actually what's used for sign-ins via web UIs (Wikitech, Toolsadmin). "Username" is only used for SSH access (toolforge / git review). The CREDITS page uses the name from git log, which you'd set through the
git config --global user.name
command. – SD0001 (talk) 21:22, 17 May 2024 (UTC) - Oh, oops, aparently I'm just as confused. * Pppery * it has begun... 21:24, 17 May 2024 (UTC)
- Thanks. Further complicating naming matters, I see there is an "LDAP" (Lightweight Directory Access Protocol) username. See wikitech:SRE/LDAP. Per wikitech:SRE/LDAP/Renaming users, "We do not rename users (Developer accounts) anymore. It can (and has) lead to various problems and errors all over the many separate systems which consume Developer accounts as their local databases and authentication methods will get out of sync." So I guess I'm stuck for now with the name I have (not that I want to change it). But a reason for proceeding cautiously here. I don't want to stumble into doing something irreversible that I wish I'd done differently later, after I figured out what I was actually doing, rather than signing up for it by trial and error. I don't recall seeing the mw:Developer account page before, and I think I created mine before the Create a Wikimedia developer account form was created. Today I just ran into the Bitu Identity Manager, which shows me "My LDAP properties". (see wikitech:IDM). Phabricator says my LDAP User is "Unknown". I don't know if there's a way I can personally make it known, or whether it being unknown is a problem. – wbm1058 (talk) 22:14, 17 May 2024 (UTC)
- I think theres basically 2 logins. #1 is the oauth / centralauth / all wikis but wikitech one. #2 is ldap / gerrit / toolforge / wikitech. Lots of synonyms here. I forget if phabricator is one of those two, or a third one. –Novem Linguae (talk) 22:26, 17 May 2024 (UTC)
- I suppose Phabricator is probably bilingual. Obviously I sign into it using my #1 because my #2 is unknown to the phabulous Phabricator. On the other hand, there must be some developers using it who may not have a #1. – wbm1058 (talk) 22:43, 17 May 2024 (UTC)
- Shout-out to @BMueller (WMF):. I watched your online presentation given at last month's conference in Portland and thought you might be interested in reading this thread. Enjoyed meeting you in Toronto last year. – wbm1058 (talk) 23:21, 17 May 2024 (UTC)
- I think theres basically 2 logins. #1 is the oauth / centralauth / all wikis but wikitech one. #2 is ldap / gerrit / toolforge / wikitech. Lots of synonyms here. I forget if phabricator is one of those two, or a third one. –Novem Linguae (talk) 22:26, 17 May 2024 (UTC)
- Now I just found and opened the Gerrit Code Review - User Privacy page... so Google, as well as Wikimedia, is part of the loop! layers upon layers – wbm1058 (talk) 11:29, 18 May 2024 (UTC)
- Hmm, Gerrit is a Dutch male name meaning "brave with the spear", the Dutch and Frisian form of Gerard. And Gerrit (software) was authored by Google. Whereas Git was written by the guy behind Linux. Learn something new every day. wbm1058 (talk) 11:48, 18 May 2024 (UTC)
- When asked why he called the new software, 'git', British slang meaning 'a rotten person', Torvalds said 'I'm an egotistical bastard, so I name all my projects after myself. First Linux, now git.' Ha! wbm1058 (talk) 12:00, 18 May 2024 (UTC)
- Google is not part of the loop exactly. Google wrote the software, but it's open-source and the website https://gerrit.wikimedia.org is hosted by Wikimedia with no involvement from Google. * Pppery * it has begun... 13:23, 18 May 2024 (UTC)
- More from the "I figured out what was happening only after it already happened" department. Wikimedia Code Review https://gerrit.wikimedia.org/r/settings says I registered @ Monday, May 13, 2024, 9:08:55 PM UTC-04:00 ... what? I don't recall doing anything specific to "register" there last Monday. What was I doing at that time? I thought per mw:Gerrit/Tutorial I had to configure Git in order to register for Gerrit, but here I am already registered for Gerrit, and I haven't configured Git yet! O I C. I think I was looking at a previous code review related to the task I'd decided to work on, when I noticed "Sign up" and "Sign in" links on the upper right corner of that page. Clicking "Sign up" took me to this new IDM "Create account" page to create a Wikimedia developer account. Hey, I thought, I think I already have one of those that I needed for Wikitech/Toolforge. So I left that page, and clicked "Sign in". Voila, my Wikitech password got me in. I thought I had simply logged into Gerrit, not registered for it. What I didn't realize was that the "Bitu Identity Manager" would not only sign me in, but register me as well! wbm1058 (talk) 16:12, 18 May 2024 (UTC)
- Thanks. Further complicating naming matters, I see there is an "LDAP" (Lightweight Directory Access Protocol) username. See wikitech:SRE/LDAP. Per wikitech:SRE/LDAP/Renaming users, "We do not rename users (Developer accounts) anymore. It can (and has) lead to various problems and errors all over the many separate systems which consume Developer accounts as their local databases and authentication methods will get out of sync." So I guess I'm stuck for now with the name I have (not that I want to change it). But a reason for proceeding cautiously here. I don't want to stumble into doing something irreversible that I wish I'd done differently later, after I figured out what I was actually doing, rather than signing up for it by trial and error. I don't recall seeing the mw:Developer account page before, and I think I created mine before the Create a Wikimedia developer account form was created. Today I just ran into the Bitu Identity Manager, which shows me "My LDAP properties". (see wikitech:IDM). Phabricator says my LDAP User is "Unknown". I don't know if there's a way I can personally make it known, or whether it being unknown is a problem. – wbm1058 (talk) 22:14, 17 May 2024 (UTC)
- Full name is actually what's used for sign-ins via web UIs (Wikitech, Toolsadmin). "Username" is only used for SSH access (toolforge / git review). The CREDITS page uses the name from git log, which you'd set through the
SSH keys
I already have SSH keys set up for Toolforge at Toolsadmin which I use on PuTTY and WinSCP but not directly from the Windows command prompt.
mw:SSH keys seems to indicate that I can't use my Toolsadmin SSH but will need another one, set up from the Windows command prompt. Correct?
Also, regarding configuring Git personal information. The guide says "You should have to do this only once." Is that literally true, or does it mean once on my desktop and once on my laptop, if I have two machines that I might want to submit code from? wbm1058 (talk) 18:06, 18 May 2024 (UTC)
- @Wbm1058 You can reuse the same SSH key across multiple projects (in this case toolsadmin and Gerrit). The tutorial assumes that you have not setup the keys before.
- Regarding the configuration of Git, you will need to do it once per machine. Sohom (talk) 23:08, 18 May 2024 (UTC)
- My desktop is still running Windows 7. I know, I know, long in the tooth, but I'm proud to have kept it going for 14 years and would like to make it to 15. It still works for me, for the most part. I've downloaded the production version MediaWiki 1.41.1 and have it running for debugging. I generated my SSH keys with PuTTYgen, since the Windows 7 command prompt does not support the
ssh
command. I suppose I'd need to use PuTTY on that machine to connect to Gerrit, as I use it to connect to the Toolforge bastion. I think I can figure that out; haven't found documentation on how to use Gerrit on a Windows 7 machine. I haven't set up SSH on my Windows 10 laptop yet (only do Toolforge from my desktop). I don't know how to copy my keys from PuTTY to the required location on Windows 10. Might be easier to generate new keys on Windows 10. I have anssh-rsa
key for Toolforge access; the documentation says to use theed25519
type for optimum security and performance. Can I use different SSH keys on each machine? wbm1058 (talk) 16:53, 19 May 2024 (UTC)- As a matter of fact, you are kind of expected to use different keys per user per machine. That’s why all the ssh settings of toolforge and Gerrit allow you to add multiple public keys. —TheDJ (talk • contribs) 16:58, 19 May 2024 (UTC)
- What TheDJ said, you are expected different SSH keys across machines. However, if you are using one machine, you can reuse the key across multiple things (I have mine on Github/Gitlab/Toolforge and Gerrit as well as a bunch of private services). Sohom (talk) 18:15, 19 May 2024 (UTC)
- OK, thanks! New state-of-the-art
ed25519
keys generated and installed for my Windows 10 laptop (which MSFT tells me will be unsupported after next year, and my hardware is too old to run Windows 11(. - I successfully did a git clone. I'm a bit confused by the instructions at mw:Download from Git#Download for development:
- "This clones the entire MediaWiki core repository, synced to the master branch, into a sub-directory named
mediawiki
"
- "This clones the entire MediaWiki core repository, synced to the master branch, into a sub-directory named
- I previously installed MediaWiki 1.40.1 on my laptop last November at the Toronto wikiconference, by downloading the then-current version from mw:Download, and successfully installed that, for testing.
- I want to overwrite my previous 1.40.1 installation with the new files I just
gitgot. - The standard
mediawiki
directory holdscore
anddata
sub-directories. - It doesn't appear that the git download includes any
data
. It appears to be acore
directory, which includes some extra files that aren't part of the mw:Download version. Why don't the instructions say to download to a sub-directory namedcore
rather than a sub-directory namedmediawiki
? - Oh, I see. mw:Manual:Upgrading#Using Git:
- If using Git, export the files into a clean location, and then copy the old customized files into the new location as described in the previous section.
- You will also need to install some external PHP libraries using Composer or a provided collection maintained for the Wikimedia wiki farm. More details on installing and updating external libraries can be found in the Git download documentation
- So, for some reason, although I can test using 1.40.1 without having any PHP problems, I'll need to figure out this "Composer" thing in order to do development testing.
- Hopefully it's not a problem that I'm running the PHP 8.2.12 Development Server – wbm1058 (talk) 23:11, 19 May 2024 (UTC)
- I think all mediawiki unit tests are passing on php 8.1. Not sure about php 8.2. May want to switch to 8.1 to prevent hard to diagnose bugs. –Novem Linguae (talk) 00:45, 20 May 2024 (UTC)
- OK, thanks! New state-of-the-art
- What TheDJ said, you are expected different SSH keys across machines. However, if you are using one machine, you can reuse the key across multiple things (I have mine on Github/Gitlab/Toolforge and Gerrit as well as a bunch of private services). Sohom (talk) 18:15, 19 May 2024 (UTC)
- As a matter of fact, you are kind of expected to use different keys per user per machine. That’s why all the ssh settings of toolforge and Gerrit allow you to add multiple public keys. —TheDJ (talk • contribs) 16:58, 19 May 2024 (UTC)
- My desktop is still running Windows 7. I know, I know, long in the tooth, but I'm proud to have kept it going for 14 years and would like to make it to 15. It still works for me, for the most part. I've downloaded the production version MediaWiki 1.41.1 and have it running for debugging. I generated my SSH keys with PuTTYgen, since the Windows 7 command prompt does not support the
Composer
c:\php\mediawiki\core>php maintenance/run.php update.php
Error: You are missing some external dependencies.
MediaWiki has external dependencies that need to be installed via Composeror from a separate repository. Please see
https://www.mediawiki.org/wiki/Manual:Installation_requirements#PHP and
https://www.mediawiki.org/wiki/Download_from_Git#Fetch_external_libraries
for help on installing the required components.
- mw:Manual:Installation requirements#PHP does not mention "Composer". It says "MediaWiki only requires PHP extensions that are enabled in PHP by default." I assume that's why I didn't get this error when I ran update.php on my desktop, where I'm just running the official MediaWiki releases. "If your hosting provider provides a basic LAMP environment without these, you may need to install or enable these manually."
- OK, I'm going to follow the instructions at mw:Download from Git#Fetch external libraries.
- Hmm, I guess I should mw:Download from Git#Update the Git submodules first? wbm1058 (talk) 14:22, 20 May 2024 (UTC)
- I don't think submodules is what you need. The
php maintenance/run.php update.php
script just wants you tocomposer install
in the mediawiki directory, that should download the required directories. Sohom (talk) 14:34, 20 May 2024 (UTC) - Indeed only the second link is relevant here. I'm clarifying this message in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1034113. Thanks for writing all of this up, it's helpful to see things from a different perspective sometimes. Matma Rex talk 16:07, 20 May 2024 (UTC)
c:\php\mediawiki>composer update --no-dev
Composer could not find a composer.json file in c:\php\mediawikiTo initialize a project, please create a composer.json file. See https://getcomposer.org/basic-usage
- I'm going to reboot my machine and try again. Composer install warned me that I might have a PATH problem. wbm1058 (talk) 15:56, 20 May 2024 (UTC)
- Judging by your previous comments, you're just not in the directory that Composer expects – try going to c:\php\mediawiki\core, where you (and Composer) should find the composer.json file. Matma Rex talk 16:09, 20 May 2024 (UTC)
- Yes, thanks, that was it. Once again the instructions misled me: "then run
composer update --no-dev
from yourMediaWikicore directory." It's still running. This step takes significant time! wbm1058 (talk) 16:20, 20 May 2024 (UTC) - I think it worked. The console log is long, with a pile of "failed to download" warning messages, but it appears to have successfully worked around all of them. Here's the end of the log, showing just the last 3 of many installations:
- Yes, thanks, that was it. Once again the instructions misled me: "then run
- Installing wikimedia/timestamp (v4.1.1): Cloning 138f3099b4 from cache - Installing wikimedia/xmp-reader (0.9.1): Cloning 8338d67969 from cache - Installing zordius/lightncandy (v1.2.6): Cloning b451f73e8b from cache44 package suggestions were added by new dependencies, use `composer suggest` to see details.Generating optimized autoload files11 packages you are using are looking for funding.Use the `composer fund` command to find out more!> MediaWiki\Composer\ComposerVendorHtaccessCreator::onEventNo security vulnerability advisories found.
I think I'm ready to try running update.php again. – wbm1058 (talk) 16:51, 20 May 2024 (UTC)
c:\php\mediawiki\core>php maintenance/run.php update.php
Error: The MinervaNeue skin cannot be loaded. Check that all of its files are installed properly.
- 0 C:\php\mediawiki\core\includes\GlobalFunctions.php(91): ExtensionRegistry->queue('C:\\php\\mediawik...')
- 1 C:\php\mediawiki\core\LocalSettings.php(166): wfLoadSkin('MinervaNeue')
- 2 C:\php\mediawiki\core\includes\Setup.php(216): require_once('C:\\php\\mediawik...')
- 3 C:\php\mediawiki\core\maintenance\run.php(49): require_once('C:\\php\\mediawik...')
- 4 {main}
PHP Fatal error: Error Loading extension. Unable to open file C:\php\mediawiki\core/skins/MinervaNeue/skin.json: filemtime(): stat failed for C:\php\mediawiki\core/skins/MinervaNeue/skin.json in C:\php\mediawiki\core\includes\registration\MissingExtensionException.php on line 96Fatal error: Error Loading extension. Unable to open file C:\php\mediawiki\core/skins/MinervaNeue/skin.json: filemtime(): stat failed for C:\php\mediawiki\core/skins/MinervaNeue/skin.json in C:\php\mediawiki\core\includes\registration\MissingExtensionException.php on line 96
- Sigh. I didn't need no extensions when testing changes to the official release core page-moving functions. Now I do. – wbm1058 (talk) 18:04, 20 May 2024 (UTC)
- You shouldn't need any extensions to run MediaWiki core. It's only trying to load the MinervaNeue skin, because you have a line in your LocalSettings.php like
wfLoadSkin('MinervaNeue');
(maybe you copied it from your previous installation?). You can remove it or comment it out if you don't want it. - If you do want it, then you can install the skin using Git similarly to how you installed MediaWiki, just replacing the path in the
git clone
command: instead ofmediawiki/core
, usemediawiki/skins/MinervaNeue
(and make sure to put it in the skins directory, where MediaWiki is looking for it). Similarly for all other skins and extensions. Matma Rex talk 18:13, 20 May 2024 (UTC)- Thanks! I just used the default LocalSettings.php that came with the release-version installation. Figuring I only need one skin, I just copied the folder from my backup of the release version, and commented out the others. That did the trick, and the database update looks like it ran successfully. – wbm1058 (talk) 20:28, 20 May 2024 (UTC)
MediaWiki internal error.
Original exception: [6d2f7f0574eb09bb447c9687] /index.php/Main_Page Error: Class "ResourceLoaderSkinModule" not found
Backtrace:
from C:\php\mediawiki\core\includes\ResourceLoader\ResourceLoader.php(417)
Another missing piece. The console log looks good, but this come up on the webpage. – wbm1058 (talk) 21:04, 20 May 2024 (UTC)
- Did you git clone, composer install, and npm ci inside your default skin? Probably skins/Vector –Novem Linguae (talk) 21:17, 20 May 2024 (UTC)
- The ResourceLoaderSkinModule class was recently renamed (gerrit:994854). It seems that you've just updated your MediaWiki to a version that doesn't have it any more, but one of your skins is an older version that is still using it. This will occasionally happen with skins and extensions.
- If you've already installed the skin from Git, running
git pull
in the affected skin's repository should fix it. If you haven't, it's probably best if you do :) but you can also remove it from LocalSettings.php, or download the latest master snapshot from SkinDistributor/ExtensionDistributor. Matma Rex talk 21:51, 20 May 2024 (UTC)- Thanks for the nice, detailed response. mw:Special:SkinDistributor/Vector even offers the "master (latest development version)" but https://extdist.wmflabs.org/dist/skins/Vector-master-685a02f.tar.gz gives me a 404 Not Found error. I'll just figure out how to git it the preferred way ) wbm1058 (talk) 00:23, 21 May 2024 (UTC)
- Weird, that link works for me now. Maybe it took a few minutes to generate. Matma Rex talk 00:35, 21 May 2024 (UTC)
- Indeed. Just worked for me too. But rather than tinker with telling my Windows how to unzip that "gz" file ("Look for an app in the Miocrosoft Store"?!), I'm going to mw:Download from Git#Using Git to download MediaWiki skins.
- Follow the exact same procedure as for extensions (described in the previous section), but using
skins
rather thanextensions
in all URLs and paths. wbm1058 (talk) 01:01, 21 May 2024 (UTC)
- Weird, that link works for me now. Maybe it took a few minutes to generate. Matma Rex talk 00:35, 21 May 2024 (UTC)
- Thanks for the nice, detailed response. mw:Special:SkinDistributor/Vector even offers the "master (latest development version)" but https://extdist.wmflabs.org/dist/skins/Vector-master-685a02f.tar.gz gives me a 404 Not Found error. I'll just figure out how to git it the preferred way ) wbm1058 (talk) 00:23, 21 May 2024 (UTC)
c:\php\mediawiki\core\skins>git clone https://gerrit.wikimedia.org/r/mediawiki/skins/Vector
Cloning into 'Vector'...
Enter passphrase for key '/c/Users/Bill/.ssh/id_ed25519':
remote: Counting objects: 99, done
remote: Finding sources: 100% (94/94)
remote: Getting sizes: 100% (70/70)
remote: Compressing objects: 100% (1041262/1041262)
remote: Total 37958 (delta 29), reused 37891 (delta 9)
Receiving objects: 100% (37958/37958), 11.37 MiB | 8.91 MiB/s, done.
Resolving deltas: 100% (28242/28242), done.
c:\php\mediawiki\core\skins>
Appears to have worked. – wbm1058 (talk) 01:17, 21 May 2024 (UTC)
- Done. Success. I have a development environment which seems to be operating identically with the official-release environment I just replaced. Tomorrow I move to the next step. Make minor "hello, world!" type changes in two files, and then figure out how to submit them for review. FYI, the project I'm working on, where I hope to make more substantial enhancements soon, is discussed on my talk: User talk:Wbm1058#My MediaWiki core developers thread. – wbm1058 (talk) 01:40, 21 May 2024 (UTC)
mw:Local development quickstart
- It's just that the way you have cloned the repo is unconventional. mediawiki/core should be cloned to a directory named "mediawiki", not "core". I think you will have a lot easier time going through mw:Local development quickstart instead, which unfortunately isn't advertised more prominently. You may want to discard the existing mediawiki install and use the quick start. You have already done step 1, so start with step 2. It's easy! – SD0001 (talk) 16:40, 20 May 2024 (UTC)
- That "quick start" page has stuff I've already done previously, and insufficient info about stuff I needed to do.
- I've had an "official release" version installed on my laptop since November. It makes a lot of sense to me to have started that way, because as complicated as installing the official release was, installing the developers' version is way more complicated yet.
- I've had PHP installed directly on Windows for over a decade now. My bots use that.
- There was no need for me to update my php.ini file to load the required PHP extensions. I already did that a long time ago. The problem is that this "composer" system basically "ignores" that, it seems to me.
- It just says to "use Git" to clone the core, as if that's easy. No it wasn't. See above for what steps I went through to figure it out.
- I installed SQLite already last year; I don't need to do that again.
- I already knew how to start my server, though I was told by someone to use "localhost:80" in Boston in 2019, not "localhost:4000". I don't know whether it matters which number I use there.
- What I need is a "quickstart" page for upgrading from an "official release" version to the developers' version. – wbm1058 (talk) 17:28, 20 May 2024 (UTC)
- 1 and 2. yes I said as much - you have already done step 1.
3. There's no need to configure git before cloning repos. The steps from mw:Gerrit/Tutorial#Configure_Git are only to prepare for pushing changes.
4.composer mw-install:sqlite
is not for installing sqlite (not required). Instead it initialises MediaWiki itself with sqlite as the db backend. This is a shortcut to avoid going through the web installer.
5. Running something on port 80 is only advisable on linux. On Windows/macOS, it's better to use a non-reserved port (> 1023) to avoid issues with firewalls.What I need is a "quickstart" page for upgrading from an "official release" version to the developers' version.
The easiest way to do that is to delete or forget about the release version and setup the developers' version from scratch. – SD0001 (talk) 17:56, 20 May 2024 (UTC)
- 1 and 2. yes I said as much - you have already done step 1.
- What I did need to do before cloning was download and install Git, and setup SSH to use it. None of that was necessary to download and install the release version, which makes installing the release version an easier task.
- Oh I see. a shortcut to avoid going through the web installer... well, now I know. I was wondering how that was done. But now, water under the bridge. I'd like to keep the database I started last year, for sentimental reasons, and just upgrade. I think upgrading should be easier than installing from scratch every time.
- I've noted that my server runs really slowly on my system. Wrote that off as bloatware overwhelming my 14-year old processor, but, now that you mention it, could be a symptom of firewall intervention. I'll switch to port 4000 and see whether that runs faster.
- I also noticed mw:Gerrit/Tutorial/tl;dr, and have kept that open in another browser window for comparison and reference. – wbm1058 (talk) 20:17, 20 May 2024 (UTC)
- It's just that the way you have cloned the repo is unconventional. mediawiki/core should be cloned to a directory named "mediawiki", not "core". I think you will have a lot easier time going through mw:Local development quickstart instead, which unfortunately isn't advertised more prominently. You may want to discard the existing mediawiki install and use the quick start. You have already done step 1, so start with step 2. It's easy! – SD0001 (talk) 16:40, 20 May 2024 (UTC)
git-review
Running command as an administrator: |
---|
Microsoft Windows [Version 10.0.19045.4412](c) Microsoft Corporation. All rights reserved. C:\WINDOWS\system32>pip install git-review
Collecting requests>=1.1 (from git-review)
Collecting charset-normalizer<4,>=2 (from requests>=1.1->git-review)
Collecting idna<4,>=2.5 (from requests>=1.1->git-review)
Collecting urllib3<3,>=1.21.1 (from requests>=1.1->git-review)
Collecting certifi>=2017.4.17 (from requests>=1.1->git-review)
Downloading git_review-2.4.0-py3-none-any.whl (52 kB)
Downloading requests-2.32.1-py3-none-any.whl (63 kB)
Downloading certifi-2024.2.2-py3-none-any.whl (163 kB)
Downloading charset_normalizer-3.3.2-cp312-cp312-win_amd64.whl (100 kB)
Downloading idna-3.7-py3-none-any.whl (66 kB)
Downloading urllib3-2.2.1-py3-none-any.whl (121 kB)
Installing collected packages: urllib3, idna, charset-normalizer, certifi, requests, git-review |
Per instructed at mw:Gerrit/Tutorial#Setting up git-review:
c:\php\mediawiki\core>git review -s --verbose
git: 'review' is not a git command. See 'git --help'.
c:\php\mediawiki\core>git-review -s --verbose
'git-review' is not recognized as an internal or external command,operable program or batch file.
?? – wbm1058 (talk) 14:09, 21 May 2024 (UTC)
- To use
git review
, you have to be in a git clone directory that already contains a (possibly hidden).gitreview
configuration file (see Setting up a repository for git-remote) — hmm wbm1058 (talk) 14:48, 21 May 2024 (UTC)
- It looks like the directory where git-review got installed is not in your %PATH% environment variable. First of all, try closing the command-line window and opening it again, and retry – maybe it is just seeing outdated env variables.
- If that doesn't help, you'll need to change that env variable, the option to do that is somewhere in your operating system settings. Add the directory where git-review is, probably something like like C:/Python310/Scripts/ (that's where it is on my machine). Note that you need to open a new command-line window every time for the changes to take effect when testing.
- (If I recall, there's a checkbox to do that automatically when you install Python, which you may have left unchecked. You can also try reinstalling Python and finding that checkbox.) Matma Rex talk 15:04, 21 May 2024 (UTC)
- That directory has a .gitreview file in it, with the following content:
host=gerrit.wikimedia.org
port=29418
project=mediawiki/core.git
track=1
defaultrebase=0
Is that good? wbm1058 (talk) 14:58, 21 May 2024 (UTC)
review installation log
c:\php\mediawiki\core>git review -s --verbose
2024-05-21 11:12:37.452765 Running: git config --get gitreview.remote
2024-05-21 11:12:37.468379 ... gitreview.remote = origin
2024-05-21 11:12:37.468379 Config['remote'] = origin
2024-05-21 11:12:37.468379 Running: git config --get gitreview.branchauthor
2024-05-21 11:12:37.499631 Config['branchauthor'] = name
2024-05-21 11:12:37.499631 Running: git symbolic-ref -q HEAD
2024-05-21 11:12:37.530879 Running: git for-each-ref --format=%(upstream) refs/heads/master
Following tracked origin/master rather than default origin/master
2024-05-21 11:12:37.609011 Running: git config --get gitreview.scheme
2024-05-21 11:12:37.671503 Config['scheme'] = ssh
2024-05-21 11:12:37.671503 Running: git config --get gitreview.hostname
2024-05-21 11:12:37.687125 Config['hostname'] = gerrit.wikimedia.org
2024-05-21 11:12:37.687125 Running: git config --get gitreview.port
2024-05-21 11:12:37.718370 Config['port'] = 29418
2024-05-21 11:12:37.718370 Running: git config --get gitreview.project
2024-05-21 11:12:37.749619 Config['project'] = mediawiki/core.git
2024-05-21 11:12:37.749619 Running: git log --color=never --oneline HEAD^1..HEAD
2024-05-21 11:12:38.687096 Running: git remote
2024-05-21 11:12:38.765224 Running: git branch -a --color=never
2024-05-21 11:12:38.890218 Running: git rev-parse --show-toplevel --git-dir
2024-05-21 11:12:38.937083 Running: git config --get core.hooksPath
2024-05-21 11:12:38.983962 Running: git config --get core.hooksPath
2024-05-21 11:12:39.015203 Running: git submodule foreach cp -p .git\hooks\commit-msg "$(git rev-parse --git-dir)/hooks/"
c:\php\mediawiki\core>
I don't see the "found origin push URL" and "fetching commit hook" that the instructions said I should see. – wbm1058 (talk) 15:47, 21 May 2024 (UTC)
- The instructions are probably outdated and everything is probably okay. git-review is being somewhat actively developed, and the example output in mw:Gerrit/Tutorial#Setting_up_git-review has a 2019 date. If it didn't work, you'll find out later if you get an error complaining about a missing Change-Id line. Matma Rex talk 20:57, 21 May 2024 (UTC)
I don't know whether that's a problem or not, but I proceeded as if it wasn't.
c:\php\mediawiki\core>git pull --rebase origin master
Enter passphrase for key '/c/Users/Bill/.ssh/id_ed25519':
remote: Counting objects: 11860, done
remote: Finding sources: 100% (60/60)
remote: Getting sizes: 100% (26/26)
remote: Compressing objects: 100% (108354/108354)
remote: Total 60 (delta 35), reused 35 (delta 28)
Unpacking objects: 100% (60/60), 36.46 KiB | 13.00 KiB/s, done.
From ssh://gerrit.wikimedia.org:29418/mediawiki/core
- * branch master -> FETCH_HEAD
- 2d68215ff7a..25895192125 master -> origin/master
Successfully rebased and updated refs/heads/T12814-hello.
c:\php\mediawiki\core>git review -R
wbm1058@gerrit.wikimedia.org: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
If you get a Permission denied (publickey). fatal: Could not read from remote repository.
, review the instructions at mw:SSH keys#Add SSH Private key to use with Git to make sure your ssh agent is running and your identity is added. If you close your Git Bash shell, you will be signed out and need to re-follow these instructions each time.
c:\php\mediawiki\core>eval `ssh-agent`
'eval' is not recognized as an internal or external command,
operable program or batch file.
Is there a way to run git bash from the Windows cmd prompt?
Inside a git bash window:
Bill@Mobile-laptouch MINGW64 ~
$ eval `ssh-agent`
Agent pid 272
Bill@Mobile-laptouch MINGW64 ~
$ ssh-add ~/.ssh/id_ed25519
Enter passphrase for /c/Users/Bill/.ssh/id_ed25519:
Identity added: /c/Users/Bill/.ssh/id_ed25519 (wbm1058-wikipedia@yahoo.com)
Then I went back to Windows command window, tried "review" again, and still got the "permission denied" error. – wbm1058 (talk) 20:28, 21 May 2024 (UTC)
- I haven't seen this exact error before, and your setup is rather different from mine, so this is a guess, but: the
eval `ssh-agent`
command actually works by setting environment variables, which everything else on your system can read to access the SSH agent. Maybe you just need to close and reopen the command prompt window again, so that it sees the new env variables? Matma Rex talk 21:02, 21 May 2024 (UTC) - "Is there a way to run git bash from the Windows cmd prompt?" You can run something like
"C:\Program Files\Git\usr\bin\bash.exe"
from the command prompt, and it will run, but this is unlikely to do anything good. It will probably be confused about text encodings, file paths, and ANSI escape codes. (On Windows 10, they're slightly less incompatible.) Can you say why you want to do it? Matma Rex talk 21:15, 21 May 2024 (UTC)- (edit conflict) I just tried doing it from my git bash window instead of command prompt...
Bill@Mobile-laptouch MINGW64 /c/php/mediawiki/core (T12814-hello)
$ git review -R
remote:
remote: Processing changes: new: 1 (\)
remote: Processing changes: new: 1 (|)
remote: Processing changes: new: 1 (/)
remote: Processing changes: new: 1 (-)
remote: Processing changes: new: 1 (\)
remote: Processing changes: new: 1 (|)
remote: Processing changes: refs: 1, new: 1 (|)
remote: Processing changes: refs: 1, new: 1 (|)
remote: Processing changes: refs: 1, new: 1, done
remote:
remote: SUCCESS
remote:
remote: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1034588 Show the page name on the MovePage checkbox for "Yes, delete the page" [NEW]
remote:
To ssh://gerrit.wikimedia.org:29418/mediawiki/core.git
- * [new reference] HEAD -> refs/for/master%topic=T12814-hello
I guess that worked?! wbm1058 (talk) 21:11, 21 May 2024 (UTC)
- Yep, that worked. * Pppery * it has begun... 21:15, 21 May 2024 (UTC)
- Yeah, just doing everything from the Git Bash window is probably the best way to have the least amount of weird issues. Matma Rex talk 21:16, 21 May 2024 (UTC)
Rebase
Matma Rex, responding to your request at code review to edit another file. Per the instructions at mw:Gerrit/Tutorial#Rebasing, I clicked on the REBASE button in Gerrit's web interface, and it responded with a "Confirm rebase" box with radio buttons for "Rebase on top of the master branch" or "Rebase on a specfic change, ref, or commit". I'm unclear on which I should choose, and whether to check the "Allow rebase with conflicts" box. "It's best to make rebase updates a separate patch, so that your code reviewers have an easy time seeing what changes you've made."
"Hard reset and checkout the change with this command: (BEWARE: git review -d performs a hard reset that destroys all local changes. Stash or commit changes first which you wish to preserve!)" – what is meant by "stash" a change? That term only appears that one place on that page; it's not defined there. – wbm1058 (talk) 21:22, 22 May 2024 (UTC)
- That patch doesn't have a merge conflict so you don't need to worry about rebasing it at all. And "stash" in that context refers to the
git stash
command. * Pppery * it has begun... 23:17, 22 May 2024 (UTC)- Don't I want to amend / add a file to my existing commit rather than add a second commit to my existing branch? Branches and commits, I'm still not comfortable with the terminology and how they fit together.
- Funny, when I entered 'git' to get the usage and list of "common git commands" it didn't list "stash". – wbm1058 (talk) 00:46, 23 May 2024 (UTC)
- For gerrit and git review, yes. For patchset 2 or higher, you'll want to git stage, then git commit --amend, then git review -R –Novem Linguae (talk) 02:13, 23 May 2024 (UTC)
- Ack, though I see the term "stage" several times in mw:Gerrit/Tutorial, I don't see any explicit "git stage" command. Oh (looking it up), that's a synonym for "git add".
- I was looking at mw:Gerrit/Tutorial#Amending a change (your own or someone else's), and mw:Gerrit/Tutorial#Rebasing is a subsection of that section. The way I'm reading it, it implies that rebasing is a mandatory, not optional, step that's part of the "amending a change" process.
- Oh, I see. the
--amend
tells it to amend my first commit rather than add a second commit. – wbm1058 (talk) 03:02, 23 May 2024 (UTC)- I think if you do git review without the -R, it will auto rebase. But i was taught not to auto rebase, and just to do it manually when needed. –Novem Linguae (talk) 03:05, 23 May 2024 (UTC)
- For gerrit and git review, yes. For patchset 2 or higher, you'll want to git stage, then git commit --amend, then git review -R –Novem Linguae (talk) 02:13, 23 May 2024 (UTC)
- I think a few things on that tutorial page are outdated – both Gerrit and git-review have had some changes related to rebases since it was written, and they mostly removed the footguns that this page tries to teach you to avoid. I'll have to read it more carefully and update it. Generally, you shouldn't have to think about rebasing, or do anything to avoid it, or click the "Rebase" button, unless you see an error somewhere telling you that there is a merge conflict in your change. Matma Rex talk 15:48, 23 May 2024 (UTC)
Sticky row headers issues
Need help fixing the "second" sticky row in this table. With rowspan used in the first column, only the first row in rowgroup is sticky, the rest of the rows in individual rowgroups aren't. I assume it is a "sticky-col2" issue from Template:COVID-19 pandemic data/styles.css. Can it be fixed so it displays all rows in the second column unbroken when horizontally scrolling? Qwerty284651 (talk) 19:04, 18 May 2024 (UTC)
Native Dark Mode Message
I have been using the dark mode gadget for a while now and I quite like it. I tried the native dark mode but I do not like it that much, as it is quite buggy and has a fair few contrast issues, see the phab board. Every time I load a page in namespaces outside of article space I get the message that informs me that I have two dark modes enabled and I need to choose one. When I go to disable the non-gadget dark mode it is not able to be disabled, are there any scripts to suppress this message, it is getting quite annoying. Thanks, v/r - Seawolf35 T--C 00:03, 19 May 2024 (UTC)
- I too have been having this problem for days now. It's caused by some bogus and untested changes to MediaWiki:Gadget-dark-mode-toggle.js by @Jon (WMF). The message literally pops up on almost every page asking to set native theme to Light - except that all controls for setting the native theme are greyed out, and/or it's already set to Light.Can an interface admin please action the edit request on MediaWiki talk:Gadget-dark-mode-toggle.js#Interface-protected edit request on 16 May 2024? – SD0001 (talk) 07:43, 19 May 2024 (UTC)
Page misbehaving in search results
I use this search query to see pages tagged for speedy deletion. For several days it has returned BBL Drizzy as a result even though that page is not tagged for deletion. The search results say it was last edited at 01:12 on 13 May 2024, which corresponds with Special:Diff/1223572833 (now in the history of Draft:BBL Drizzy). Purging or null-editing either the article or the draft will make it disappear from the results temporarily, but so far it's always come back shortly thereafter. Today I tried deleting and undeleting the pages, but this didn't help either. Any suggestions? (This query brings up strange results too, for what it's worth.) Extraordinary Writ (talk) 03:01, 19 May 2024 (UTC)
- I don't experience this. BBL Drizzy is not a result for the first query, and the last query only brings up BBL Drizzy (last edited 19:04, 18 May 2024). – 2804:F1...7F:938A (talk) 03:15, 19 May 2024 (UTC)
- Strange. The second query returns this for me, and some fiddling around at this site (pick Australia, Indonesia, India, etc.) suggests I'm not alone. Extraordinary Writ (talk) 03:40, 19 May 2024 (UTC)
- I've been seeing some outdated search results also related particularly to a couple page moves that got done between when the search was crafted and when my fix was made. Particularly, in this search I'm seeing Draft:Peter the Great Interrogating the Tsarevich Alexei Petrovich at Peterhof and Draft:Ellen Webster Palmer when I hit one or another of the data centers (which I assume is at least part of the problem), but at least once I've gotten a search not to return those two, because neither are drafts any longer nor do either carry the problem that makes them show up in this search. Izno (talk) 20:36, 19 May 2024 (UTC)
Hi everyone! We are the Wikimedia Foundation Web team.We work on making it easier to read Wikimedia projects as part of the objective "Reading and media experience" of the current year’s annual plan. To achieve this goal, we have introduced the "Accessibility for Reading" beta feature. It adds a menu which works on the Vector 2022 skin and allows logged-in users to choose different font sizes and color schemes based on individual needs.
The menu introduces a new Standard font setting. It slightly increases the size and height of the font. It was selected based on multiple sources. You will find more information on this in the section "About the new Standard font setting". As we announced last week, we are now ready to begin bringing some of these feature out of beta and making them available to more people.
What will change
- We are now ready to make the new Appearance menu available for logged-out and logged-in users.
- At the same time, we will also make the Standard option the new default for logged-out users only.
- If no breaking technical issues are found, we plan on making this change within the next three weeks.
- Later, this menu will also include the option to select dark mode, which for the time being will remain a beta feature. For more information, check out our project page.
About the menu
The new menu will allow logged-in and logged-out users to set preferences for:
- Text size and line height (available now as the beta feature): Users will be able to choose between the Small (current default), Standard (recommended for better accessibility), and Large options. Selecting an option will change both the font size and line height of the text.
- Dark mode (available now as the beta feature): Users will be able to choose to see the site in night mode on a permanent basis, or select an "automatic" setting which will set day or night mode based on the device or browser preferences.
- Content width (previously available as a toggle button): We have moved the content width toggle from an icon at the bottom of the page to a labeled radio button in the new menu. It will work exactly the same as the toggle. The previous toggle button will no longer be available.
This menu has been tested as a beta feature by logged-in users across wikis as well as in user testing with readers. Based on the findings of these tests, we changed the menu to improve discoverability and ease of use, and to accommodate gadget compatibility.
The menu will appear to the right of the page, immediately under the Tools menu if that has been pinned. Unlike the Tools menu, the Appearance menu is pinned by default, but can be unpinned. Once unpinned, it collapses under an icon at the top of the page.
About the new Standard font setting
The "Small" option is the current default. We will be changing this default to "Standard" for logged-out users, while keeping "Small" as the default for logged-in users. The "Standard" and "Large" options were built and tested based on the following:
- Academic studies and recommendations for the best average font size for the majority of readers. These recommendations stated that our current size is too small for the majority of people to read comfortably. This means that on average, people read more slowly, strain their eyes while reading, or have difficulty clearly seeing the text. Increasing the font size by default improves these issues for all users, including users who might not have sufficient time to spend adjusting a setting via the appearance menu or browser. Information density is also important, which is why we wanted to increase font size without sacrificing information density. We have achieved this by changing not only font size, but also line height and paragraph spacing.
- Designs submitted by more than 630 Wikipedians from across 13 wikis of different languages, scripts, and sizes. The majority (~450) of these users opted for a font size that was larger than the default. "Standard" represents the average of the most popular cluster of responses (15-20 pixels). "Large" represents the need for an even larger option, as represented by the cluster of sizes between 21-26 pixels. You can read more on how we included volunteers in the process and landed on these options.
- Beta feature usage showed that the majority of users who interact with the feature at least once opt for a font size that is larger than the current default.
Our works so far and next steps
Logged-in users will remain with the "small" setting for the time being as their default, but can change to any other setting at any time. In a few months, we will study how many logged-in users switch to standard and start a conversation on whether it makes sense for logged-in users to make the switch as well. From the early data from the beta feature, 55% of sessions who interacted with the feature chose to use a setting that was standard or larger.
If you'd like to help, we have a few simple requests for you:
- Please, turn on the beta feature ("Accessibility for Reading (Vector 2022)")
- Try out the new menu. Is anything confusing? Do you understand all the labels and how the menu works?
- Try out the small, standard, and large sizes, the color schemes, and the width toggle. Reach out to us if you notice any bugs, or have questions or concerns.
If you'd like to learn more about the project, see our FAQ. Comments and questions are most welcome. Thank you! OVasileva (WMF) and SGrabarczuk (WMF) (talk) 13:58, 20 May 2024 (UTC)
Wikilinks to `((RSS))` article are broken
I noticed this at Aaron Swartz and Web feed: links to the article on the web feed format RSS (link here > RSS <) are not displaying on Wikipedia articles
Type "[[RSS]]" for "RSS" and it displays as "" for me. PK-WIKI (talk) 19:19, 20 May 2024 (UTC)
- Works for me: RSS * Pppery * it has begun... 19:57, 20 May 2024 (UTC)
- The link displays and works normally for me in all five tested browsers. It sounds like something in your browser is messing with the link, maybe an extension for RSS feeds. PrimeHunter (talk) 20:08, 20 May 2024 (UTC)
Strange CSS behavior
I recently noticed that the CSS style background:transparent
seems to turn the text color dark gray when combined with the class thumbinner
and viewed through the beta vector night mode. Does anyone know why this happens? Andumé (talk) 20:12, 20 May 2024 (UTC)
- The text color generally is a dark grey. Can you be more specific ? —TheDJ (talk • contribs) 09:58, 21 May 2024 (UTC)
- In dark mode, there is some blanket CSS for "it has a background but is relying on inherited color" which obviously doesn't work in a lot of places. Izno (talk) 17:13, 21 May 2024 (UTC)
Link classifier missing in Vector 2022
The Link Classifier which if I recall is maintained by Anomie has disappeared from my Vector (2022) skin. I use this frequently and have just now noticed it, so I is likely something very recent. I switched back to Vector (2010) just to check and it was still available there. Any suggestions about how to get this back in Vector (2022)? older ≠ wiser 21:29, 20 May 2024 (UTC)
- WMF has recently changed the software so that in Vector 2022 personal Javascript/CSS are loaded only from Special:MyPage/vector-2022.js and Special:MyPage/vector-2022.css. You are loading it only in Special:MyPage/vector.js. You will need to copy whatever you want from there to the vector-2022 version, or to your Common.js at Special:MyPage/common.js (which is the best place for it - scripts are/should be responsible for loading where they should; styles may vary more so they may not be as obvious to move). Remove it from vector.js if you add it to common.js. Izno (talk) 22:06, 20 May 2024 (UTC)
- Thank you. That worked. older ≠ wiser 23:40, 20 May 2024 (UTC)
- Thanks, this probably should solve the above problem as well. I will try later today. Ymblanter (talk) 08:36, 21 May 2024 (UTC)
- Copied Ymblanter's comment from above:
Izno (talk) 17:09, 21 May 2024 (UTC)Not sure whether it is related but I am using one of the user scripts (do not have time now to search which one) which, in particular, highlights in pink pages proposed for deletion. The highlighting is gone today (checked on two different devices, different browsers), which gives me a HUGE headache for CFD handling. Ymblanter (talk) 08:35, 21 May 2024 (UTC)
Tech News: 2024-21
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
- The Nuke feature, which enables administrators to mass delete pages, will now correctly delete pages which were moved to another title. [12]
- New changes have been made to the UploadWizard in Wikimedia Commons: the overall layout has been improved, by following new styling and spacing for the form and its fields; the headers and helper text for each of the fields was changed; the Caption field is now a required field, and there is an option for users to copy their caption into the media description. [13][14]
Changes later this week
- The new version of MediaWiki will be on test wikis and MediaWiki.org from 21 May. It will be on non-Wikipedia wikis and some Wikipedias from 22 May. It will be on all wikis from 23 May (calendar). [15][16]
- The HTML used to render all headings is being changed to improve accessibility. It will change on 22 May in some skins (Timeless, Modern, CologneBlue, Nostalgia, and Monobook). Please test gadgets on your wiki on these skins and report any related problems so that they can be resolved before this change is made in all other skins. The developers are also considering the introduction of a Gadget API for adding buttons to section titles if that would be helpful to tool creators, and would appreciate any input you have on that.
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
MediaWiki message delivery 23:01, 20 May 2024 (UTC)
- Based on a quick search, it looks like the heading change will affect almost 300 scripts, many of which have inactive maintainers. Some arbitrary highlights from the top of the list include:
- Awesome Aasim's User:Awesome Aasim/rcpatrol.js
- BrandonXLF's User:BrandonXLF/FFUHelper.js
- Cacycle's User:Cacycle/wikEd.js, User:Cacycle/wikEd dev.js, and User:Cacycle/wikEd.user.js
- DannyS712's User:DannyS712/DiscussionCloser.js, User:DannyS712/SectionRemover.js, and User:DannyS712/SectionMover.js
- Enterprisey's User:Enterprisey/reply-link.js, User:Enterprisey/copy-section-link.js, User:Enterprisey/archiver.js, User:Enterprisey/strike-archived.js, User:Enterprisey/section-watchlist.js, and User:Enterprisey/section-redir-note.js
- Equazcion's User:Equazcion/OneClickArchiver.js, User:Equazcion/TeahouseRespond.js, and User:Equazcion/NewSectionSummary.js
- Evad37's User:Evad37/OneClickArchiver.js and MediaWiki:Gadget-XFDcloser-core.js
Mr. Stradivarius's User:Mr. Stradivarius/gadgets/SignpostTagger.js- PhantomTech's User:PhantomTech/scripts/AFCRHS.js
- SD0001's User:SD0001/RFUD-helper.js
- Terasail's User:Terasail/COI Request Tool.js
Technical 13's User:Technical 13/Scripts/OneClickArchiver.js- The Earwig's User:The Earwig/permalink.js and User:The Earwig/afc-helper.js
- The Evil IP address's User:The Evil IP address/hdedit.js
- Plus many, many more. --Ahecht (TALK
PAGE) 19:22, 21 May 2024 (UTC)- A quick way to test these scripts right now, is to enable the Parsoid beta option (which already uses the new html structure) and to disable DiscussionTools, which uses a partial form of the new heading structure. —TheDJ (talk • contribs) 08:39, 22 May 2024 (UTC)
- Indeed, you can already see it in Parsoid mode (but note that there are other differences – e.g. Parsoid output has
<section>
tags around each section, which may require a separate set of updates in some scripts). - Disabling DiscussionTools doesn't actually change anything though. The HTML structure is the same whether it's enabled or disabled, only the styles are different. Also, note that it uses a "hybrid" heading structure currently when using the default parser, as you say, but it uses the new structure when using Parsoid.
- So in short, you can just use Parsoid mode to test these scripts today here on English Wikipedia, but beware that there may be extra issues. But if they work with Parsoid, they will work with the new headings too. Matma Rex talk 11:25, 22 May 2024 (UTC)
- Indeed, you can already see it in Parsoid mode (but note that there are other differences – e.g. Parsoid output has
- The technical 13 script was blanked, so we don't have to worry about that one.
- Will the fact that they're rolling this out for only some wikimedia-deployed skins at this time make the patch more complicated? If I'm reading it right, the scripts may temporarily have to support both heading styles. –Novem Linguae (talk) 09:16, 22 May 2024 (UTC)
- At a glance, it seems that User:Mr. Stradivarius/gadgets/SignpostTagger.js already supports the new style, as it uses
$( '#bodyContent h2:first' ).text()
as a backup if$( '#bodyContent h2:first span.mw-headline' )
doesn't exist (line 291). — Mr. Stradivarius ♪ talk ♪ 13:09, 22 May 2024 (UTC) - Fixed RFUD-helper. Thanks for the ping. – SD0001 (talk) 18:33, 22 May 2024 (UTC)
- This is going to break both my edit request scripts, I will try to fix them at the weekend. Terasail[✉️] 18:41, 22 May 2024 (UTC)
- A quick way to test these scripts right now, is to enable the Parsoid beta option (which already uses the new html structure) and to disable DiscussionTools, which uses a partial form of the new heading structure. —TheDJ (talk • contribs) 08:39, 22 May 2024 (UTC)
Where is the code for an info-box? Where does it go?
I'm trying to create some info-boxes on a small hobby wiki. It had been running fine on "freewiki.in" but that domain disappeared last year. I've re-created it on a domain I control using MediaWiki v1.41.1. I've put up all the article text from .XML backups, but all the formatting is gone.
The software manual at https://www.mediawiki.org/wiki/Global_templates/Taxonomy explains how to use {{ambox}} but not the code required for it to work. It sends me to Wikipedia, to https://www.search.com.vn/wiki/en/Module:Message_box.That, finally, has 600+ lines of code.
Where does this code go? Somewhere on the wiki? Somewhere on the server in one of the .PHP files? There's gotta be a step-by-step procedure somewhere but I can't find it. And I'm not about to do my experimenting here on Wikipedia...
Answers can be here, if this is of general interest. If not, I'd be perfectly happy getting help at my talk page. SandyJax (talk) 13:05, 21 May 2024 (UTC)
- It goes exactly where it is here, on the page
Module:Message box
. Snowmanonahoe (talk · contribs · typos) 16:42, 21 May 2024 (UTC) - ... but otherwise requires only the use of mw:Extension:Scribunto and mw:Extension:TemplateStyles. Izno (talk) 17:08, 21 May 2024 (UTC)
- If you preview code, e.g. an infobox call, then the bottom of the window shows all transcluded templates and modules at "Templates used in this preview". It can be a long list, and the list can change if the same template is called with different parameters or circumstances (e.g. the namespace it's called from). Some of the infobox styling in the English Wikipedia is in MediaWiki:Common.css which is not listed at "Templates used in this preview" since it's not transcluded but used in another way. PrimeHunter (talk) 18:30, 21 May 2024 (UTC)
Template dagger malfunctioning
Immediate assistance required because template:dagger currently outing this †.Anoop Bhatia (talk) 01:14, 22 May 2024 (UTC)
- Link to an edit request about it: Template talk:Dagger#Template-protected edit request on 22 May 2024. – 2804:F1...10:A60F (talk) 02:37, 22 May 2024 (UTC)
- It is not malfunctioning, it is doing what it is supposed to do, to notify everyone about the ongoing discussion. But I can see how this can be disruptive to the reading experience when it is being used multiple times within a short space, i.e. at Atlanta Braves#Braves Hall of Fame. – robertsky (talk) 03:45, 22 May 2024 (UTC)
- @Robertsky: Thanks 👍🏻. Anoop Bhatia (talk) 04:03, 22 May 2024 (UTC)
- It is not malfunctioning, it is doing what it is supposed to do, to notify everyone about the ongoing discussion. But I can see how this can be disruptive to the reading experience when it is being used multiple times within a short space, i.e. at Atlanta Braves#Braves Hall of Fame. – robertsky (talk) 03:45, 22 May 2024 (UTC)
The IPA in Wikipedia comes with some errors.
SUBJECT
The IPA in Wikipedia comes with some errors.
I am quite happy that Wikipedia uses the IPA as a pronunciation guide. I know the IPA moderately well, so its use is convenient for me. Promoting the IPA in Wikipedia might also encourage people to learn it, which probably might not be a bad idea.
I think that the use of the IPA in Wikipedia might often or consitently make some errors. I don’t see these errors being made in Wiktionary though. The IPA there seems to be largely fine.
the approximant rhotic (also the approximant alveolar)
/ɹ/
The English language uses primarily for a rhotic the approximant alveolar which in the IPA is represented as: /ɹ/.
In Wikipedia, this rhotic seems to always get represented by /r/, which actually represents the rolled “r”, as the “r” in the Spanish word “perro”.
I’ve suspected that this error is deliberate in that maybe the people setting up the IPA transcriptions are concerned that an upside down “r” might confuse people. Although, this doesn’t make very good sense since much of the rest of the IPA will still confuse people who are not familiar with it.
From Wikipedia showing the incorrect /r/ use :
Tripoli (/ˈtrɪpəli/; Arabic: طرابلس الغرب, romanized: Ṭarābulus al-Gharb, lit. 'Western Tripoli')
From Wiktionary using the correct /ɹ/. use :
entourage
Pronunciation
(UK) IPA(key): /ˈɒn.tʊ.ɹɑːʒ/, /ˈɑ̃ː.tʊ.ɹɑːʒ/
(US) IPA(key): /ˈɑn.tə.ɹɑʒ/
/ɑ/, /a/, /æ/
These might be described as the “basic a” vowels: /ɑ/, /a/, /æ/
/a/ and /æ/ are similar and are like the “a” in “cat”.
/a/ is more open and might be more typical for Received Pronunciation or a British English. /æ/ is similar sounding but just with an articulation that is a bit more close (closed jaw) and is probably more typical for General American English or Standard Canadian English. Distinguishing between these two is not too much of a big deal, I don’t think for general pronunciation purposes.
The /ɑ/, described as a back, open, unrounded vowel, is like the “o” in the English word “top”. This vowel is more of what is considered an “a” vowel in languages such as Spanish, Italian, and other languages. This /ɑ/ though is significantly different from the /a/ and /æ/.
I’ve seen on a number of occasions in Wikipedia in which words with the /ɑ/ sound were given IPA transcriptions of /a/. I went looking for examples in Wikipedia of this today, but had difficulty finding this.
Here’s an example from Wiktionary where the /ɑ/ sound is written as /a/.
Pronunciation
(UK) IPA(key): /ˈɒn.tʊ.ɹɑːʒ/, /ˈɑ̃ː.tʊ.ɹɑːʒ/
(US) IPA(key): /ˈɑn.tə.ɹɑʒ/
I finally managed to find an example of the /ɑ/ sound being written as /a/.
Croatia (/kroʊˈeɪʃə/ ⓘ, kroh-AY-shə; Croatian: Hrvatska, pronounced [xř̩ʋaːtskaː]
Specifically, the [xř̩ʋaːtskaː]
I noticed in my search for words with an /ɑ/, for words that have this sound in General American English or Standard Canadian English, that same sound in Received Pronunciation often gets pronounced as /ɒ/, which is a very open “o” and pronunciation given in Wikipedia may tend to favor Received Pronunciation.
the schwa and the caret
This is an issue that probably would have to be directed towards the IPA Association or something like that, and not Wikipedia. But, I’ll mention it here anyways.
Apparently, any phonetics course, most phonetics courses, will tell you that no word in English ends with a caret. So, take the word “the” or “California”. Wiktionary will transcribe these into the IPA as :
the:
(when unstressed and preconsonantal)
enPR: thə, IPA(key): /ðə/
California:
(General American) IPA(key): /ˌkæl.ɪˈfoɹ.njə/, /ˌkæl.ɪˈfoɹ.ni.ə/, [ˌkʰæl.ɪˈfo̞ɹ.njə]
It’s typical to see IPA transcriptions of the words “the” and “California” as ending with the schwa, /ə/.
Transcribing the final vowel in the words “the” and “California” as /ə/ to me seems wrong. Maybe my hearing sense is off. Maybe the articulation is /ə/ but to me sounds like /ʌ/ or /ɐ/.
Give it a try? The /ə/ or schwa is the vowel sound you more or less get between the “p” and “l” in “apple” in General American and probably Received Pronunciation. Or find some online IPA chart with audio pronunciation to find out how /ə/ is pronounced.
Now try sticking that sound into the word “the” or at the end of the word “California”. Maybe I’m not getting this right, but it consistently sounds wrong! Like weird!
Maybe when speaking quickly these sounds will reduce to an /ə/ sound. But even when spoken quickly, these words can often just sound like they end with a quick /ʌ/ or /ɐ/.
I used to think that “the” and “California” should be transcribed as /ðʌ/ and /ˈkalɪfɔɹnjʌ/, with the the /ʌ/ at the end of the word. This makes auditory sense to me.
More recently though, when realizing that / ʌ/ and /ɐ/ sound very similar, that for that sound, if the preceeding consonant is more forward, then maybe the more forward of /ʌ/ and /ɐ/ would actually be articulation being used, which is the /ɐ/. So, the word “the” would more likely be transcribed as:
/ðɐ/
With “California”, this might be different. The /j/ sound before the final vowel, it’s more central so would it make the final vowel sound /ɐ/ or /ʌ/? Maybe the /ʌ/ sound fills an entire linear area that connects the more middle /ɐ/ and the more back /ʌ/, in which case it could get kind of complicated or difficult to figure out where the articulation of this sound is taking place exactly.
I suspect that if the /ʌ/ sound is preceeded by a more back consonant, such as in the English word “gut”, then the /ʌ/ sound will take more of a back /ʌ/ articulation, as you get with the Wiktionary transcription of “gut”.
gut
Pronunciation
IPA(key): /ɡʌt/
Zbniorb (talk) 06:34, 22 May 2024 (UTC)
- This is not a technical inquiry. The appropriate venue is the talk page of the IPA key for each language, though I strongly suggest you read the Handbook of the IPA and learn the difference between a phone and a phoneme and the concept of narrowness first. Nardog (talk) 06:57, 22 May 2024 (UTC)
Issue with template
Hi there. There seems to be some kind of issue with {{Population WD}}. I would like to use it to get the bare population figure. At first, {{population WD|qid=Q559227|show=value}}
was not working, and I was getting the figure plus a "<span" at the end. Primefac has solved it, at least partially. But there still seem to be some issues, as can be seen here. Thanks in advance for the help, Alavense (talk) 08:19, 22 May 2024 (UTC)
- My guess is that the {{first word}} is cutting off the coding to show the "edit at Wikidata" icon, but I have a) no idea why it's doing that, and b) no idea how to fix it. Primefac (talk) 08:37, 22 May 2024 (UTC)
- Yes, something like that. The createicon function in Module:WikidataIB starts off with a non-breaking space, so {{first word}} is grabbing a few more tokens than we want. — jmcgnh(talk) (contribs) 08:57, 22 May 2024 (UTC)
- And, yes, nbsp is not considered one of the ASCII whitespace characters by some regular expression engines, including, according to what we've seen here, Lua's %s. — jmcgnh(talk) (contribs) 09:19, 22 May 2024 (UTC)
- This Special:Diff/1225091340 seems to be a possible fix. It returns just the population value, whichever way the noicon parameter is set. Of course, if you really wanted that pencil icon, you'll need to use something different from {{first word}}. @Primefac and Alavense: — jmcgnh(talk) (contribs) 09:37, 22 May 2024 (UTC)
- There should not be any regexes that treat a nbsp as whitespace. For a start, its value is outside the 0x00-0x7F range; second, whilst it's encoded as 0xA0 under Unicode, some character sets use the same value for a different, non-blank, printing character - for example, in Code page 437, it's used for the "á" character. Third, ASCII whitespace is defined as characters 0x09 through 0x0c inclusive plus 0x20. --Redrose64 🌹 (talk) 19:40, 22 May 2024 (UTC)
- @Redrose64 That's a very outdated point of view. Regex engines these days generally operate on Unicode and understand Unicode characters, or at least have an option to do so, and "whitespace" often means all Unicode whitespace, not ASCII whitespace. Matma Rex talk 21:16, 22 May 2024 (UTC)
- The HTML spec is outdated then. Pity, as it was last updated 22 May 2024, which was, er, today. --Redrose64 🌹 (talk) 23:04, 22 May 2024 (UTC)
- Pity, as the HTML spec is irrelevant to how Lua or PHP process whitespace. Izno (talk) 23:36, 22 May 2024 (UTC)
- The HTML spec is very careful to call it out as ASCII whitespace every time that term is used, precisely because just saying whitespace often means Unicode whitespace. Matma Rex talk 15:40, 23 May 2024 (UTC)
- The HTML spec is outdated then. Pity, as it was last updated 22 May 2024, which was, er, today. --Redrose64 🌹 (talk) 23:04, 22 May 2024 (UTC)
- @Redrose64 That's a very outdated point of view. Regex engines these days generally operate on Unicode and understand Unicode characters, or at least have an option to do so, and "whitespace" often means all Unicode whitespace, not ASCII whitespace. Matma Rex talk 21:16, 22 May 2024 (UTC)
- There should not be any regexes that treat a nbsp as whitespace. For a start, its value is outside the 0x00-0x7F range; second, whilst it's encoded as 0xA0 under Unicode, some character sets use the same value for a different, non-blank, printing character - for example, in Code page 437, it's used for the "á" character. Third, ASCII whitespace is defined as characters 0x09 through 0x0c inclusive plus 0x20. --Redrose64 🌹 (talk) 19:40, 22 May 2024 (UTC)
- @Jmcgnh Lua's
%s
should actually match non-breaking spaces, if I understand the documentation correctly. - Template:First word uses Module:String, which uses
mw.ustring
. The docs for Ustring patterns say%s
"represents all characters with General Category "Separator"", and NBSP is a separator (see e.g. the entry in Whitespace character#Unicode for reference). - I think the problem in the original code is that in
[ %s]
the entity isn't interpreted, so it finds the first occurrence of&
,n
,b
, etc. It will probably work if you do just[%s]
. Matma Rex talk 21:14, 22 May 2024 (UTC)- Oh, good, we're getting some people involved who know more than me. @Redros64, Matma Rex, and Izno: As I read it, {{First word}} already supplies
%s
as the default separator AND the results show that it is not treating nbsp as a member of%s
. If I were going to spend more time on this, I'd first get rid of {{First word}} to see how many results are coming back - as an experiment. If there are multiple results (not just one string with multiple values in it), I'd argue that the job of selecting what to return needs to either be pushed down into WikidataIB or maybe do like theshow=year
branch and useUstring|gsub
to pull out the desired part of the data. - Primefac's current fix provides the correct defaults, but if someone wants to specify
show=value|noicon=FALSE
it would be best if the result didn't contain stray markup tokens. I checked for howshow=year|noicon=FALSE
would behave and it seems to get it right for Alavense's test case. I wish I understood a little better how thatUstring|gsub
expression matching worked. As I look at it, it shouldn't be working for this case. If I could figure that out better, I'd be in favor of getting rid of {{first word}} and using a Ustring call forshow=value
as well as for <show=year>. — jmcgnh(talk) (contribs) 02:34, 23 May 2024 (UTC)- I don't know much, I just looked up the docs :)
As I read it, {{First word}} already supplies
%s
as the default separator AND the results show that it is not treating nbsp as a member of%s
.- I had a look at the output of
{{#invoke:WikidataIB|...}}
in Special:ExpandTemplates, and I can at least explain that – it's because the WikidataIB module isn't emitting an actual nbsp character, but rather it's emitting the
HTML entity. The string matching functions just see that as a sequence of&
,n
,b
, and so on. So you would need to make {{First word}} look for that sequence, instead of individual characters, but it has no way to do that. - You could probably implement this by invoking Module:String directly – but at this point I would take a step back, and see if there's some way to just output the bare population figure from Wikidata directly, instead of using a big template and applying another big template on top of it to discard most of its results, because that how you end up with pages that bump into parser limits. I'm not very familiar with this stuff, but there must surely be one. Matma Rex talk 15:31, 23 May 2024 (UTC)
- Oh, good, we're getting some people involved who know more than me. @Redros64, Matma Rex, and Izno: As I read it, {{First word}} already supplies
- This Special:Diff/1225091340 seems to be a possible fix. It returns just the population value, whichever way the noicon parameter is set. Of course, if you really wanted that pencil icon, you'll need to use something different from {{first word}}. @Primefac and Alavense: — jmcgnh(talk) (contribs) 09:37, 22 May 2024 (UTC)
Differentiation of subheading font sizes (or more accurately, lack thereof)
I've just used subheadings for the first time, and was somewhat dismayed to see hardly any noticeable differentiation between Subheadings 2, 3, and 4. Couldn't the subheadings be differentiated more?
Surely some other Wiki editors must have made similar comments long before I came on board ... Augnablik (talk) 11:54, 22 May 2024 (UTC)
- Yes, I think many of us got confused at first and pointed out that h3 looks more prominent than h2, but there doesn't seem to be a consensus to change the styles and eventually we got used to it. I hope it doesn't lead too many readers astray. Certes (talk) 12:04, 22 May 2024 (UTC)
- How could there be any editorial disagreement about the need for a technical fix to remedy this situation, @Certes? Of course it could lead readers astray!
- It's not like the discussion going on elsewhere at the Village Pump on the topic of COI guidelines, with many senior editors all over the field as to just what COI is and what should be required of editors in self-reporting it. Augnablik (talk) 12:42, 22 May 2024 (UTC)
- @Certes, I hope it didn’t seem to you in my reply to you above that I was unhappy with you personally. I was just reacting in surprise — okay, shock — that Wiki editors who deal with this sort of thing wouldn’t have very easily come to consensus about the need to make h2 and h3 look different from each other … for the sake of readers. Augnablik (talk) 16:27, 22 May 2024 (UTC)
- I wasn't at all insulted or offended. I agree with you that h2 should be more prominent relative to h3. I think the problem is that h3 is bolder than h2, which can give the illusion that it is more important despite not being larger. Of course, it's easy for the regulars to put together a bit of CSS to make it look how we prefer it, but we're a tiny minority of the audience: we're both thinking of the casual reader who can't be expected to jump through that hoop for each site they visit. Certes (talk) 19:58, 22 May 2024 (UTC)
- The appearance of headings and subheadings varies with several factors, including (but not limited to): zoom level, skin, browser, installed fonts, operating system. You can experiment using e.g. Wikipedia:Sandbox in various skins - Cologne Blue; MinervaNeue (mobile); Modern; MonoBook; Timeless; Vector legacy (2010); Vector (2022). Notice that besides the font size, there are variations in font family, also underlining. --Redrose64 🌹 (talk) 20:40, 22 May 2024 (UTC)
- I wasn't at all insulted or offended. I agree with you that h2 should be more prominent relative to h3. I think the problem is that h3 is bolder than h2, which can give the illusion that it is more important despite not being larger. Of course, it's easy for the regulars to put together a bit of CSS to make it look how we prefer it, but we're a tiny minority of the audience: we're both thinking of the casual reader who can't be expected to jump through that hoop for each site they visit. Certes (talk) 19:58, 22 May 2024 (UTC)
- @Certes, I hope it didn’t seem to you in my reply to you above that I was unhappy with you personally. I was just reacting in surprise — okay, shock — that Wiki editors who deal with this sort of thing wouldn’t have very easily come to consensus about the need to make h2 and h3 look different from each other … for the sake of readers. Augnablik (talk) 16:27, 22 May 2024 (UTC)
trying to add new GeoJSON map to virgin river article - centering is getting messed up
I'm trying to add this to Virgin River:
{{mapframe|from=Virgin River (Utah).map|text=Route of the Virgin River and the North and East Forks|frame=yes|zoom=7|frame-coord|coord=37.174167,-113.326111}}
The problem is that every time I preview my proposed change the center of the map is completely off. It's like it's pulling the coordinates of the mouth from wikidata.org and using that vs using the more central coordinate that I'm using.
Assuming that that's the case idk that I necessarily want to change it. Ideally I'd like to just overwrite it for that one map. But if that's not possible I guess I could change the wikidata.org entries altho https://www.wikidata.org/wiki/Q1676970 shows multiple coordinate locations. Would just the first one need to be changed? I'm a little hesitant to save experimental changes like that. I'd rather Preview my changes before saving them but, assuming my hypothesis is correct then I'd prob need save it all the same, even if only to save just to preview TerraFrost (talk) 12:04, 22 May 2024 (UTC)
- You are not setting
|frame-coord=
so it's retrieiving the coordinates from Wikidata. You have|frame-coord|
which is acting as a positional parameter, equivalent to|1=frame-coord
. You want to use|frame-coord={{Coord|37.174167|N|113.326111|W}}
which will allow you to shift the centre. — Jts1882 | talk 14:11, 22 May 2024 (UTC)
"Publish" is a little too quick on the draw
I've been editing the Houseboat article and once again when I tried to review my changes before publishing a few minutes ago, they got published — with no summary, because I wanted to be reminded of the things I'd done in my edits. This has happened a few times before as well.
And because these edits were major changes, including the addition of new information along with a supporting citation and the removal of some existing text for greater clarity, I'll probably get a finger wag from a senior editor about this. 🫤
Augnablik (talk) 12:32, 22 May 2024 (UTC)
- In Special:Preferences#mw-prefsection-editing, you can select "Prompt me when entering a blank edit summary". That may help. Certes (talk) 12:38, 22 May 2024 (UTC)
- Aha. Thanks ... but I wonder why we have to opt in about this, given that we're not supposed to send blank edit summaries? Augnablik (talk) 12:45, 22 May 2024 (UTC)
- I recall there being a discussion about this somewhere - if my memory serves me correctly, the idea of not having this on by default is to avoid there being an extra layer of friction that may discourage newer good faith editors.
- In any case, there is no formal obligation to provide an edit summary; rather, the edit should be explained in some manner, or be self-explanatory, something which can be achieved after the fact through talk page discussion. WindTempos (talk • contribs) 12:59, 22 May 2024 (UTC)
- Aha. Thanks ... but I wonder why we have to opt in about this, given that we're not supposed to send blank edit summaries? Augnablik (talk) 12:45, 22 May 2024 (UTC)
- If you have accidentally made major changes without a good edit summary and want to fix that, the standard way is to make a Dummy edit. —Kusma (talk) 13:08, 22 May 2024 (UTC)
- There are several keyboard actions that will trigger a save - in no particular order, they include:
- Pressing Alt+⇧ Shift+S at any time
- Pressing ↵ Enter when the focus is on one of: the edit summary; the "This is a minor edit" or "Watch this page" checkboxes; the Publish changes button
- Pressing Space when the focus is on the Publish changes button
- We forget these when using a mouse all the time. --Redrose64 🌹 (talk) 19:56, 22 May 2024 (UTC)
- There are several keyboard actions that will trigger a save - in no particular order, they include:
Edit Patrol on Android Wikpedia mobile app is now available on English Wikipedia and all wikis!
We invite you to check out a demonstration of the feature and explore more on our project page. If you have tried the feature, we would appreciate any feedback on our discussion page, or your thoughts in response any of the following questions:
- What changes or additions would make this feature more useful to you?
- Would you be interested in using this feature to patrol multiple language wikis at once?
- The feature is currently available to users with rollback rights: would you like to see this feature evolve into something that is available to a broader user group?
--ARamadan-WMF (talk) 10:33, 23 May 2024 (UTC)
Sorting titles, some with appended text
Hello, regarding List of cult films: K, it seems like the listings The Killer and The Killing, both which neighbor listings that have longer titles starting with Killer or Killing, wind up at the bottom of each respective group when sorting alphabetically, when they should come first, having nothing after that keyword. Am I doing something wrong? Is there a way to fix it? See for yourself here. EDIT: I guess I fixed it by adding two spaces after each title, but this feels like too much of a hack. Is there a proper way to do this? Erik (talk | contrib) (ping me) 15:58, 23 May 2024 (UTC)
- It probably should be using {{sort}} rather than {{sortname}}. The latter makes the sort key "Killer, The" because it is intended to be used with the name of a person. Johnuniq (talk) 00:43, 24 May 2024 (UTC)
Prompt for edit summary on rollback from watchlist?
Hi there, long time fan, first time caller...
I very much like having a link on my watchlist page that will allow me to perform rollback while prompting me for a custom edit summary. My JS pages were a bit of a mess, but I believe I'd been using User:Nageh/rollbackSum.js for this purpose.
Earlier this week the 'sum' links provided by that script disappeared for me. Nageh (talk · contribs) hasn't edited since 2014 and, while I tried a few other scripts that I found, none of them seemed to re-add such a link to my watchlist either. Has something changed that makes this no longer possible? The ability to add a custom edit summary when doing rollback from my watchlist is very valuable to me, so it would be a shame if the upshot was that this simply is no longer possible. Thanks for your help! DonIago (talk) 03:43, 24 May 2024 (UTC)
Proposals
Create an alias for the Template namespace
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
- --Task created Cocobb8 (💬 talk • ✏️ contribs) 20:22, 29 April 2024 (UTC)
I am proposing that tp:
be added as an alias to the Template:
namespace per this discussion.
Note: Though previous aliases were already listed on perennial proposals, it proposed t:
, which would have conflicted with some article titles, or be confused with the Talk:
namespace. Tp:
, on the other hand, wouldn't, and would make it way quicker to look up a template in the search bar.
Edit (during rfc): tp:
was not fully supported due to it being confused with "Talk Page", however other options were proposed, like hard coding {{
being replaced by Template:
in the search bar, or other aliases like tmp:
. Cocobb8 (💬 talk • ✏️ contribs) 15:19, 16 March 2024 (UTC)
- Oppose "Template" is not a long word, and nobody abbreviates it as "tp" these days. This seems pointless. * Pppery * it has begun... 15:27, 16 March 2024 (UTC)
- I just thought it'd make it consistent with
wp:
forWikipedia:
, which is 10 characters, whileTemplate:
is 9 characters. Cocobb8 (💬 talk • ✏️ contribs) 15:29, 16 March 2024 (UTC) Nobody abbreviates it as "tp" these days
. Even if that is true it is not a reason for us not to do so. Wikipedia is big enough to be making fashions rather than following them. Phil Bridger (talk) 21:16, 16 March 2024 (UTC)- Well said.
- I just thought it'd make it consistent with
- Support I'd find it useful. It's less effort to type "tp:infobox person" in the search box than "template:infobox person" (which is how I usually navigate to wp: and template: pages). Schazjmd (talk) 15:52, 16 March 2024 (UTC)
- Support per Schazjmd. 🌺 Cremastra (talk) 15:57, 16 March 2024 (UTC)
- Support I'd absolutely love this. I've often wondered if there was some technical problem that was preventing us doing this. Usedtobecool ☎️ 16:00, 16 March 2024 (UTC)
- Support: Pretty nice QOL change. Per Schazjmd. ARandomName123 (talk)Ping me! 16:35, 16 March 2024 (UTC)
- I don't think it's a good idea to create an alias (and implicitly creating more English Wikipedia jargon) just to improve the search function. We should instead improve the search capability directly. isaacl (talk) 17:41, 16 March 2024 (UTC)
- Yeah, but you don't want a casual reader to be confused as to why they ended up on a template page Cocobb8 (💬 talk • ✏️ contribs) 17:42, 16 March 2024 (UTC)
- It would be a lot easier for the casual user to stumble upon a namespace alias, which could happen anywhere they enter an URL that might trigger a browser to launch, than for them to deliberately select the search box and type there. Furthermore, if this isn't intended to be used by a broad audience, then a more targeted solution would be better. Users wanting this functionality can make use of the script to which you were pointed in the previous thread, or they can configure their OS to provide an appropriate macro expansion to shorten the number of keystrokes they use. isaacl (talk) 18:08, 16 March 2024 (UTC)
- For reference, the script seems to be User:Ahecht/Scripts/TemplateSearch. jlwoodwa (talk) 04:53, 18 March 2024 (UTC)
- It would be a lot easier for the casual user to stumble upon a namespace alias, which could happen anywhere they enter an URL that might trigger a browser to launch, than for them to deliberately select the search box and type there. Furthermore, if this isn't intended to be used by a broad audience, then a more targeted solution would be better. Users wanting this functionality can make use of the script to which you were pointed in the previous thread, or they can configure their OS to provide an appropriate macro expansion to shorten the number of keystrokes they use. isaacl (talk) 18:08, 16 March 2024 (UTC)
- Yeah, but you don't want a casual reader to be confused as to why they ended up on a template page Cocobb8 (💬 talk • ✏️ contribs) 17:42, 16 March 2024 (UTC)
- "tp" seems very easily misconstrued as "Talk Page" at a glance. CMD (talk) 18:12, 16 March 2024 (UTC)
- Support I've been wanting this. It really is irksome to type out "Template:" I since learned today there are scripts, and of course
{{tld}}
for talk pages, but it would be much cleaner and simpler to have a standard abbrev. and this is technically easy to implement. TP: or T: it doesn't matter they both are fine. I prefer T: -- GreenC 18:56, 16 March 2024 (UTC) - Comment: Unless I'm missing something, the
TP:
prefix was proposed in 2015, in a discussion which was closed as no consensus - Wikipedia:Village pump (proposals)/Archive 127#Prefix suggestion: TP: for Template:. All the best. —a smart kitten[meow] 19:00, 16 March 2024 (UTC) - Oppose For the reasons in WP:PEREN#Create shortcut namespace aliases for various namespaces. In particular, the Template namespace is generally not linked often enough that saving the typing of 6 characters is likely to be at all worthwhile and there's nothing available to use for the corresponding talk pages. Anomie⚔ 20:00, 16 March 2024 (UTC)
there's nothing available to use for the corresponding talk pages
See Nirvana fallacy.
- The template for linking a template is called {{tl}}. Shouldn't we have some consistency between this and the short-cut? Or is "tl" already used? Phil Bridger (talk) 21:16, 16 March 2024 (UTC)
- @Phil Bridger tl is ISO639 for tagalog. — xaosflux Talk 22:20, 16 March 2024 (UTC)
- {{tl}} is short for {{template link}}, so the el doesn't have anything to do with templates qua templates. jlwoodwa (talk) 04:31, 18 March 2024 (UTC)
- Support – While there are helpful template shortcuts, like {{t}} and its siblings, that can be used in discussions, and a script that can be used in the on-wiki searchbox to convert
{{
toTemplate:
, a namespace shortcut (tp:
) would help in edit summaries and customised browser search boxes. -- Michael Bednarek (talk) 23:55, 16 March 2024 (UTC) - Oppose Adding layers of obfuscation is not helpful. If I want to refer to {{convert}}, writing
Template:Convert
is easy and helpful to someone reading my comment. WritingTp:Convert
is unnecessary jargon that saves under a second of typing at the cost of head-scratching for readers.tp
would be "talk page" for many. Johnuniq (talk) 01:00, 17 March 2024 (UTC) - Oppose As someone who has next to no involvement with template editing, I immediately think of 'talk page' when I see 'tp'. It would confuse many people who edit outside of the technical areas of Wikipedia. (Summoned by bot) JML1148 (talk | contribs) 06:57, 17 March 2024 (UTC)
- Rename the template mainspace from "Template:" to "Plantilla:" and use "Pl:" as a shortcut CactiStaccingCrane (talk) 18:02, 18 March 2024 (UTC)
- Soft Oppose I'd support hard-coding
{{
→Template:
into the search box's autocomplete natively rather than using my script as a hack, but I agree that the widespread use of links like TP:Example are an unnecessary layer of obfuscation/jargon. With theWP
prefix, at least the shortcut links are mostly self explanatory, but it wouldn't be obvious to a newcomer what, for example, tp:birds is, or why it's not an article. --Ahecht (TALK
PAGE) 18:17, 18 March 2024 (UTC)- @Ahecht Yes, hard-coding that directly could be a great alternative. I just think that we need to find a solution for this, and maybe
tp:
wasn't the best as others have pointed out. I'll continue gathering some ideas and then conduct a sub-RfC to see what option would be best, as long as the consensus doesn't seem to be oppose. Cocobb8 (💬 talk • ✏️ contribs) 19:52, 18 March 2024 (UTC)
- @Ahecht Yes, hard-coding that directly could be a great alternative. I just think that we need to find a solution for this, and maybe
- neutral i could go either way. I like the hard coding option of having 'template' be dropdown option in the menu. Slacker13 (talk) 01:29, 20 March 2024 (UTC)
- Support – I don't think that adding the
t:
will add an another level of obfuscation. The current method of making interwiki link is already obscure and complicated, specially for newbies, instead a simple alias to the template namespace will be easy and handy in researches. -- ZandDev 13:57, 20 March 2024 (UTC) - Oppose I do work with templates but I feel that this is not an intuitive shortcut and could easily be confused with "talk page". (t · c) buidhe 04:57, 21 March 2024 (UTC)
- Support , I had typed TP: prefix in the past thinking that I would get the template page without success. This would be useful in different scenarios (just like the WP: prefix). And its use is optional, so if someone doesn't like it, they can go with the full Template: as ever. Alexcalamaro (talk) 05:32, 21 March 2024 (UTC)
- Oppose. Unnecessary, and just as with T=Talk, TP=Talk Page. wjematherplease leave a message... 08:01, 21 March 2024 (UTC)
- Neutral Agree with the principle, would prefer access to a shortened version; but also agree that the proposal is too close to talk page. Regards, --Goldsztajn (talk) 22:08, 21 March 2024 (UTC)
- I think supporting
{{
in the search bar would be sufficient to support the use case of issue. But beside that, I agree with oppose comments above. Izno (talk) 02:48, 22 March 2024 (UTC) - Oppose per above. Not intuitive and I'm not convinced this solves a genuine problem -Fastily 21:26, 24 March 2024 (UTC)
- Strong support because I have typed "Twmplate" in the search bar too many goddamn times. Mach61 21:03, 26 March 2024 (UTC)
- Support: I have to do everything on mobile, and am looking up templates all the time. This would make that a significantly less laborious and typo-prone experience. But I'd be happy with some other 2- or 3-letter shortcut if TP: is a problem. No more than 3 letters, though. Also I keep typing TP:, TMP: or TPL: without thinking, expecting them to work. But I only want it for search purposes. I'd be opposed to its use as jargon for referring to templates. — Preceding unsigned comment added by Musiconeologist (talk • contribs) 01:34, 28 March 2024 (UTC)
- To help you out immediately, you can use the text expansion feature or apps on your phone to expand an abbreviated string to a longer one. isaacl (talk) 01:43, 28 March 2024 (UTC)
- Well yes, this is rather basic and I've already got a vast number of shortcuts set up. The one I'd naturally use for templates translates tem into
{{|}}
. There are two points, though: (i) it's counterintuitive and annoying that the whole word is needed, in contrast to wp: etc.; and (ii) beyond three characters, it stops really being a shortcut because it's only a bit shorter. Part of the annoyance is in having to remember that there isn't a 2-letter prefix to use. Musiconeologist (talk) 00:43, 10 April 2024 (UTC)
- Well yes, this is rather basic and I've already got a vast number of shortcuts set up. The one I'd naturally use for templates translates tem into
- To help you out immediately, you can use the text expansion feature or apps on your phone to expand an abbreviated string to a longer one. isaacl (talk) 01:43, 28 March 2024 (UTC)
- Alias
{{
(if technically possible): no ambiguity and concise. Typing{{Rfc
should take you to Template:Rfc and so should{{Rfc}}
. I'm neutral on aliasingTP
as the ambiguity may be balanced out by utility. I likeT
better despite previous community rejection. — Bilorv (talk) 22:37, 29 March 2024 (UTC)- It is technically possible for
{{
to be implemented, and there already is code for it if you want to try it out. Cocobb8 (💬 talk • ✏️ contribs) 22:41, 29 March 2024 (UTC)
- It is technically possible for
- Support any shortcut except just T. Aaron Liu (talk) 02:00, 30 March 2024 (UTC)
- Support saves me a few characters/seconds when accessing templates through the search bar, might even make up for the seconds wasted to write this comment. Tl, tmp or tpl works for me if people object to tp. Draken Bowser (talk) 21:24, 3 April 2024 (UTC)
- Support, this is an excellent idea. I type "Template:" in the search box a lot and it seems many other users do as well, so it makes sense to add a prefix. Preferably it wouldn't be "TP" if a good amount of people have issues with that; I don't care about what ends up being chosen as it remains relatively short (2 or 3 letters). ― novov (t c) 02:59, 6 April 2024 (UTC)
- Support. Aliasing
{{
is less preferable to me because a shortcut would also allow shortening template links in edit summaries, where {{tl}} is unavailable. The particular shortcut used doesn't matter to me, just that I won't have to type "Template:" every time. Nickps (talk) 12:46, 8 April 2024 (UTC)- Think about the possibility of [[{{example}}]] Aaron Liu (talk) 15:11, 8 April 2024 (UTC)
- No. Why should we introduce a way to link to pages that only works in edit summaries and nowhere else? (Note that using it elsewhere will transclude example instead.) TMP:example on the other hand, will work in Search, in talk pages and in edit summaries and the fact that it's a unified syntax makes it easier for non power users to learn. I'm not opposed to introducing
{{
for Search (alongside a regular shortcut) as long as we take measures to make sure that people don't end up on the wrong page. That is, if e.g. {{foo}} exists we should add a {{technical reasons}} hatnote to Template:foo/doc. Nickps (talk) 16:21, 8 April 2024 (UTC)
- No. Why should we introduce a way to link to pages that only works in edit summaries and nowhere else? (Note that using it elsewhere will transclude example instead.) TMP:example on the other hand, will work in Search, in talk pages and in edit summaries and the fact that it's a unified syntax makes it easier for non power users to learn. I'm not opposed to introducing
- Think about the possibility of [[{{example}}]] Aaron Liu (talk) 15:11, 8 April 2024 (UTC)
- Support. I've been at this for ten years and still hate calling up a template doc because it requires so damn much typing. The more typing, the more opportunity for typos that have to be corrected (and I'm good at typos). No objection to something other than TP, such as TM, although no doubt someone would say that could be confused with something else. The longer it gets (e.g. TMP), the less benefit. Something like this doesn't need to be descriptive, just easy to remember. ―Mandruss ☎ 05:02, 9 April 2024 (UTC)
- Doc pages don't require much more typing - and if four characters is too many, there is always the "view" link top right of the green doc box that is displayed on the main template page. --Redrose64 🌹 (talk) 13:18, 9 April 2024 (UTC)
- I'm talking about calling up template doc when I don't have a link to click, such as
{{infobox person}}
(I'm looking to read the doc, not edit it, so the transclusion on the "main template page" is all I need). So I'm typing into the search box, and typing nine characters before I even get to the template name. I would dislike three characters (tm:
) one-third (3⁄9) as much. My question is: Why NOT do this? Where's the significant downside? ―Mandruss ☎ 19:27, 9 April 2024 (UTC)
- I'm talking about calling up template doc when I don't have a link to click, such as
- @Mandruss: I highly recommend User:Ahecht/Scripts/TemplateSearch. jlwoodwa (talk) 04:05, 10 April 2024 (UTC)
- Doc pages don't require much more typing - and if four characters is too many, there is always the "view" link top right of the green doc box that is displayed on the main template page. --Redrose64 🌹 (talk) 13:18, 9 April 2024 (UTC)
- Support. Don't get why this hasn't been done already. We have
wp:
because typing "wikipedia:consensus" is tedious. And I can't spell template—I misspell it tempalte all the time—so an alias would be very nice. Anything four characters or shorter would be fine by me; I especially like the{{
idea. And to those who think that creating an alias will cause confusion—really? Iswp:sectionlink
any more confusing thantm:sectionlink
or something similar? You'll be lost for all of two seconds, if that. Cessaune [talk] 03:44, 11 April 2024 (UTC)
- Support. Don't get why this hasn't been done already. We have
- Strong Support Been meaning to propose this for a while! Any concerns about confusion can be fixed by an experienced editor spending one minute noticing the new system. — PerfectSoundWhatever (t; c) 02:26, 12 April 2024 (UTC)
Template namespace alias: Second survey
It seems to me we might have wide enough support for this to pass as a general concept. But I think a closer would be unable to decide on the specific alias to use, so we'd be looking at another RfC to decide that (ugh). Therefore a separate survey is in order. Eliminating tp:
, I see at least tentative support for t:
,
, tl:tm:
, tmp:
, and tpl:
(am I missing any?). I don't think this needs ranked voting—the specific choice isn't that critical—so it would be great if editors could just specify their one favorite. ―Mandruss ☎ 22:31, 9 April 2024 (UTC) Redacted 05:55, 14 April 2024 (UTC)
This section is not for opposition to the general concept; see my reply to Anomie's Oppose, below. ―Mandruss ☎ 00:53, 10 April 2024 (UTC)
Notification of all participants to date, regardless of the nature of participation; you commented, you get notified. @Aaron Liu, Ahecht, Alexcalamaro, Anomie, ARandomName123, A smart kitten, Bilorv, Buidhe, CactiStaccingCrane, Chipmunkdavis, Cocobb8, Cremastra, Draken Bowser, Fastily, Frostly, Goldsztajn, GreenC, Isaacl, Izno, Jlwoodwa, JML1148, Johnuniq, Mach61, Michael Bednarek, Mir Novov, Musiconeologist, Nickps, Phil Bridger, Pppery, Redrose64, Schazjmd, Slacker13, Usedtobecool, Wjemather, Xaosflux, and ZandDev: ―Mandruss ☎ 23:13, 9 April 2024 (UTC) |
tm:t: ―Mandruss ☎ 22:31, 9 April 2024 (UTC) Redacted 04:50, 12 April 2024 (UTC)- t: and tm: are no good because they deprive mainspace articles like t:kort of the title they deserve. tl is already in use to refer to the Tagalog Wikipedia. Fine with the others. * Pppery * it has begun... 22:37, 9 April 2024 (UTC) (edited * Pppery * it has begun... 03:05, 10 April 2024 (UTC))
- I struck tl:, it is not valid as it is an ISO language code. — xaosflux Talk 23:35, 9 April 2024 (UTC)
- I find the "title they deserve" argument uncompelling in the greater scheme. Those wacky norsk and a few others might have to take one for the team. By eliminating t and tm, you're effectively forcing a three-character alias (unless we want to back up and introduce something like te at this late date, which would probably meet with its own opposition anyway). Just for fun, how about an example of a tm-"killer"? ―Mandruss ☎ 03:25, 10 April 2024 (UTC)
- Anomie provided one below. And te is already used for the Telugu Wikipedia. * Pppery * it has begun... 03:28, 10 April 2024 (UTC)
- Told ya. Hell, while you might be able to produce a better example, I wonder if t:kort would survive AFD. ―Mandruss ☎ 03:38, 10 April 2024 (UTC)
- T:kort seems to be the only one for t:, other than some redirects which would work just as well from template namespace. But I think it would survive AfD - why would it be any less notable than anything else in Category:Fare collection systems, keeping in mind WP:Systemic bias and that sources are probably in Norwegian? Since I don't see a compelling reason for this proposal at all you aren't going to be able to convince me to cause a clear harm in the name of a dubious benefit. * Pppery * it has begun... 03:48, 10 April 2024 (UTC)
- Told ya. Hell, while you might be able to produce a better example, I wonder if t:kort would survive AFD. ―Mandruss ☎ 03:38, 10 April 2024 (UTC)
- Anomie provided one below. And te is already used for the Telugu Wikipedia. * Pppery * it has begun... 03:28, 10 April 2024 (UTC)
- On t:kort specifically, which appears to be the only article that starts with T:, I don't think it actually should have that title per MOS:TM. The use of a colon isn't standard Norwegian orthography and the majority of third-party sources appear to call it "T-kort". – Joe (talk) 10:55, 11 April 2024 (UTC)
- And I see you've done that move. Well damn, now I'm tempted to change my vote from tm to t. But then I'd have to re-ping everybody; not sure it's worth it. ―Mandruss ☎ 11:26, 11 April 2024 (UTC)
- There are still some links to the redirect at T:kort and quite a few others. OTOH, I don't understand the objections based ISO language codes. -- Michael Bednarek (talk) 12:07, 11 April 2024 (UTC)
- It's established convention that links prefixed with a language code go to that language's edition. Aaron Liu (talk) 12:38, 11 April 2024 (UTC)
- Only if they exist, like tl:, but not for tpl:, tmp:, tem:. -- Michael Bednarek (talk) 13:06, 11 April 2024 (UTC)
- If a Wikipedia is created for a language, the ISO 639 code will be used in its URL and for its wikilinks (like how de: or es: link to German or Spanish Wikipedias, or how they can link back to us with en:). A namespace alias would conflict with that, preventing linking to that Wikipedia, so such aliases are often preemptively avoided. Anomie⚔ 13:14, 11 April 2024 (UTC)
- Only if they exist, like tl:, but not for tpl:, tmp:, tem:. -- Michael Bednarek (talk) 13:06, 11 April 2024 (UTC)
- Most of those other redirects are cross-mainspace redirects to templates, i.e. using "T:" as a pseudo-namespace. Obviously they wouldn't be affected by this proposal. The exceptions I can see are:
- – Joe (talk) 13:30, 11 April 2024 (UTC)
- Of those, Template:A is salted so could be recreated as a redirect to Tribes: Ascend, Template:DS is a pointer to a defunct template so could probably be hijacked as a redirect to Thief: Deadly Shadows, Template:SCC is an unused redirect to Template:Supreme Court of Canada sidebar that could easily be retargeted to Terminator: The Sarah Connor Chronicles, and Template:MP, Template:TSCC, Template:SCC Episodes, Template:New York Times Style Magazine, and Template:Kort are all red. Still opposed to t: since it would cause avoidable confusion, but less strongly so than before. * Pppery * it has begun... 01:36, 12 April 2024 (UTC)
- There's a few more than those, in particular T:APRM→Turbo: A Power Rangers Movie; T:OTD→WP:Selected anniversaries; and T:DYKT, T:TDYK, T:TDYKA, and T:tdyk pointing at Template talk: titles. —Cryptic 12:02, 12 April 2024 (UTC)
- Note that Template:OTD points to Wikipedia:Selected anniversaries/Date. Aaron Liu (talk) 12:47, 12 April 2024 (UTC)
- And Template:DYKT points to a different place than T:DYKT and both are in use. The others are fine: Template:ARPM, Template:TDYK, Template:TDYKA, and Template:tdyk are all red. Template:OTD vs. T:OTD difference seems to be a historical accident not a deliberate difference. * Pppery * it has begun... 17:05, 12 April 2024 (UTC)
- There's a few more than those, in particular T:APRM→Turbo: A Power Rangers Movie; T:OTD→WP:Selected anniversaries; and T:DYKT, T:TDYK, T:TDYKA, and T:tdyk pointing at Template talk: titles. —Cryptic 12:02, 12 April 2024 (UTC)
- Of those, Template:A is salted so could be recreated as a redirect to Tribes: Ascend, Template:DS is a pointer to a defunct template so could probably be hijacked as a redirect to Thief: Deadly Shadows, Template:SCC is an unused redirect to Template:Supreme Court of Canada sidebar that could easily be retargeted to Terminator: The Sarah Connor Chronicles, and Template:MP, Template:TSCC, Template:SCC Episodes, Template:New York Times Style Magazine, and Template:Kort are all red. Still opposed to t: since it would cause avoidable confusion, but less strongly so than before. * Pppery * it has begun... 01:36, 12 April 2024 (UTC)
- It's established convention that links prefixed with a language code go to that language's edition. Aaron Liu (talk) 12:38, 11 April 2024 (UTC)
- There are still some links to the redirect at T:kort and quite a few others. OTOH, I don't understand the objections based ISO language codes. -- Michael Bednarek (talk) 12:07, 11 April 2024 (UTC)
- And I see you've done that move. Well damn, now I'm tempted to change my vote from tm to t. But then I'd have to re-ping everybody; not sure it's worth it. ―Mandruss ☎ 11:26, 11 April 2024 (UTC)
I'd be fine with any of the choices.Schazjmd (talk) 23:18, 9 April 2024 (UTC)- tm: Cremastra (talk) 23:18, 9 April 2024 (UTC)
- T is fine just as we use "h" for help space all over.Moxy🍁 23:36, 9 April 2024 (UTC)
- tm: prefer this than single letter "t" which still retains a "talk" ambiguity. Regards, --Goldsztajn (talk) 23:54, 9 April 2024 (UTC)
- tm: because T: is already used, it's shorter than tpl:, and tmp: is misleading/confusing. -- Michael Bednarek (talk) 00:30, 10 April 2024 (UTC)
- Oppose Since you pinged me, I still oppose the whole idea. I note that "t" could be confused with "talk", as was already noted, "tpl" is the ISO 639 code for Tlacoapa, and "tmp" is a deprecated (but apparently not unassigned) ISO 639 code for Tai Mène. Also of note are articles T:kort and TM:103 Hustlerz Ambition that would be affected by certain of the proposals here (plus a few other redirects starting with "T:", such as T: New York Times Style Magazine). Anomie⚔ 00:40, 10 April 2024 (UTC)
- I pinged you because pinging everybody was a whole lot easier than trying to decide who should be pinged for this section. I might decide wrong and piss somebody off. This section is not for opposition to the general concept; that's the other one. If the general concept doesn't pass, this section will prove a waste of time, but it's still worthwhile. ―Mandruss ☎ 00:43, 10 April 2024 (UTC)
- tm or t8 are fine. The "8" might seem radical, but it's actually a typical method for shortening long words, such as l18n or k8s - eight being a familiar number for this purpose. No matter the choice, there will likely be edge case overlaps. That shouldn't stop it though. There are likely edge cases for WP, File, and whatever else. -- GreenC 01:00, 10 April 2024 (UTC)
- I also support tm. Ideally I'd support tp: the most, which also has no usages, and establishing this convention would prevent confusion, but it seems this has been struck down already. Aaron Liu (talk) 01:00, 10 April 2024 (UTC)
- tm or tp for me. tl would also be OK, and would match the existing {{tl}} template. Musiconeologist (talk) 01:07, 10 April 2024 (UTC)
- Sorry, that seems to have ended up in the wrong place. If anyone feels like moving it properly into the list of replies, please do. I'm hampered by the size of the page. Musiconeologist (talk) 01:10, 10 April 2024 (UTC)
- Done. Protip: Use c:commons:Convenient Discussions. It formats bullet-point replies correctly. Aaron Liu (talk) 01:13, 10 April 2024 (UTC)
- Thanks. We ended up both moving it at the same time! I got an edit conflict, then discovered it was now in the right place anyway. I now know to add a new bullet point, not a new reply via the reply link. Musiconeologist (talk) 01:38, 10 April 2024 (UTC)
- Done. Protip: Use c:commons:Convenient Discussions. It formats bullet-point replies correctly. Aaron Liu (talk) 01:13, 10 April 2024 (UTC)
- tl is off the table; that's why there's a line through it. See this edit. tp was eliminated because of strong opposition to something that looks like "talk page". It helps to read before posting. We'll assume you like tm, then. ―Mandruss ☎ 01:18, 10 April 2024 (UTC)
- (and as said above tl is off the table because it already refers to the tagalog wikipedia) Aaron Liu (talk) 01:32, 10 April 2024 (UTC)
- I did, then I read considerably more (the whole discussion). It's late at night, I was battling to navigate the page in a tiny window, and I didn't remember that specific detail among all the others. Anyway, tp is my first choice. Musiconeologist (talk) 01:33, 10 April 2024 (UTC)
- Anarchist. ;) ―Mandruss ☎ 01:37, 10 April 2024 (UTC)
- Yes, tm is fine. And my irritability suggests I need sleep, (I find the opposition to tp surprising though. I expect the alias to be a contraction of one word.) Musiconeologist (talk) 01:43, 10 April 2024 (UTC)
- tm is a contraction of template. It just uses the first and second consonants instead of the first and third. ―Mandruss ☎ 01:46, 10 April 2024 (UTC)
- Exactly. Same as tp. I wasn't saying any different. I just meant that I'm surprised people would intuitively interpret tp as talk page rather than template when using acronyms would obviously be a different model. But they do, and that's fine. Musiconeologist (talk) 02:01, 10 April 2024 (UTC)
- tm is a contraction of template. It just uses the first and second consonants instead of the first and third. ―Mandruss ☎ 01:46, 10 April 2024 (UTC)
- Yes, tm is fine. And my irritability suggests I need sleep, (I find the opposition to tp surprising though. I expect the alias to be a contraction of one word.) Musiconeologist (talk) 01:43, 10 April 2024 (UTC)
- Anarchist. ;) ―Mandruss ☎ 01:37, 10 April 2024 (UTC)
- Sorry, that seems to have ended up in the wrong place. If anyone feels like moving it properly into the list of replies, please do. I'm hampered by the size of the page. Musiconeologist (talk) 01:10, 10 April 2024 (UTC)
- TM: , as my prefered TP: has been discarded per above. Alexcalamaro (talk) 01:36, 10 April 2024 (UTC)
- Tem. Still saves a whole plate. Hyperbolick (talk) 04:49, 10 April 2024 (UTC)
- Note "tem" is the ISO 639 code for Temne. Anomie⚔ 11:29, 10 April 2024 (UTC)
- It's so obscure!! Hyperbolick (talk) 09:30, 11 April 2024 (UTC)
- Not to the two million people that speak Temne. – Joe (talk) 11:06, 11 April 2024 (UTC)
- @Joe Roe: Aside that being .00025% of the world, what number of Temne speakers would even know that that’s its abbreviation? Hyperbolick (talk) 02:58, 12 April 2024 (UTC)
- Not to the two million people that speak Temne. – Joe (talk) 11:06, 11 April 2024 (UTC)
- It's so obscure!! Hyperbolick (talk) 09:30, 11 April 2024 (UTC)
- Note "tem" is the ISO 639 code for Temne. Anomie⚔ 11:29, 10 April 2024 (UTC)
- Oppose t, not sold on the concept as a whole but the others don't seem to hold the potential confusion the initial proposal did. CMD (talk) 08:46, 10 April 2024 (UTC)
{{
is my first choice and t is my second choice (and I don't understand why I have to say it twice). — Bilorv (talk) 09:18, 10 April 2024 (UTC)- Because to achieve something from this proposal it is necessary to converge to a few and ideally to a single prefix. -- ZandDev 11:25, 10 April 2024 (UTC)
- I'm not sure if a non-alphanumeric namespace alias is possible, but if it is, I suspect
{{:
would pose a problem for many existing tools and scripts that parse wikitext, including syntax highlighting tools. isaacl (talk) 17:29, 10 April 2024 (UTC)- Note that the {{ option does not include a : and would require additional programming. Aaron Liu (talk) 17:34, 10 April 2024 (UTC)
- My apologies for being overly concise. I included the
:
to emphasize that the proposal is for a namespace alias, and not to suggest that there would be a colon in the namespace alias. Yes, the point of my comment was that not only might there be a need for changes to MediaWiki software, but to many existing tools and scripts, including syntax highlighting tools. isaacl (talk) 17:45, 10 April 2024 (UTC)- The {{ option is not supposed to be a namespace alias that would still require the colon. It's proposed to be what seems to be a searchbar alias plus maybe an edit summary alias. Aaron Liu (talk) 02:38, 11 April 2024 (UTC)
- Yes, it's not necessary to explain proposals that I'm already aware of (as per my previous comments). If someone isn't proposing a namespace alias, then they shouldn't list it as their preferred option in this section. isaacl (talk) 04:51, 11 April 2024 (UTC)
- The {{ option is not supposed to be a namespace alias that would still require the colon. It's proposed to be what seems to be a searchbar alias plus maybe an edit summary alias. Aaron Liu (talk) 02:38, 11 April 2024 (UTC)
- My apologies for being overly concise. I included the
- It also wouldn't really help on mobile, at least with SwiftKey, since accessing the braces entails either a long keypress for each one or switching to symbol layout. Either way it's probably easier to type the whole word than use the alias. Musiconeologist (talk) 17:41, 10 April 2024 (UTC)
- Note that the {{ option does not include a : and would require additional programming. Aaron Liu (talk) 17:34, 10 April 2024 (UTC)
- Oppose anything and everything that conflicts with an article, including "T:" and "TM:", I also oppose "tp" as it is more likely to refer to "talk page" than "TemPlate". Neutral on other suggestions. Thryduulf (talk) 11:04, 10 April 2024 (UTC)
- tpl:Slacker13 (talk) 14:12, 10 April 2024 (UTC)
- Immediately comprehensible, easy to remember Musiconeologist (talk) 16:14, 11 April 2024 (UTC)
- tm: for it does not conflict with talk pages in any way, and is the most logical one to me. Would also be fine with
tmp:
andtpl:
. Cocobb8 (💬 talk • ✏️ contribs) 14:21, 10 April 2024 (UTC) - First choices: t, tp, tm
Second choice: Aliasing{{
Last choices: Anything with a number or 3+ letters
Honestly, I would suggest whoever closes this just narrowes down the 2-3 most viable options, selects one randomly, and comes up with a post-hoc justification. This isn't worth spending a lot of time on Mach61 17:22, 10 April 2024 (UTC) - T: is the straightforward and shortest prefix: it does its job better. The main problem is that it could be confused with talk, but I noticed that all here said that 'tp' seems to refer to 'talk page', so why not use it for talk pages? People will adapt to the chosen solution and have to remember it. Also tm is not direct (but for me acceptable). ZandDev 18:09, 10 April 2024 (UTC)
|
- Comment: people realize that
t:
is the existing psudeo-namespace for templates, as seen at T:CN and T:DYK? That doesn't mean you HAVE to support it, but it makes the arguments that it would be "confusing" stange, as it is already in use. Mach61 12:48, 11 April 2024 (UTC)- There's also T:MP, and there's no evidence that people not already in the know aren't confused by those. Plus it could turn out to be more confusing once people can use it for every template rather than only the handful of pseudo-namespace redirects that have been allowed. Anomie⚔ 13:14, 11 April 2024 (UTC)
- Comment. Let me see if I understand this. If the colon were removed from the title at TM:103 Hustlerz Ambition (a vanishingly insignificant cost to the project, although some Jeezy fans would disagree), that would create a redirect with the colon that wouldn't work because of a tm: namespace alias? Then we should consider manually changing all existing links to that article (104 entries in that list, although I don't know how many would have to change) and deleting the unusable redirect. Then all we'd have to worry about is the possibility that some obscure Tamboori Wikipedia (e.g.), Tamboori being spoken by 112 people on a remote island in the South Pacific, will be created in the future and somebody at en-wiki will want to link to it. ―Mandruss ☎ 14:23, 11 April 2024 (UTC)
- @Mandruss actually, we could just create a template page and redirect that (see Help:A Day in the Life for an analogous case). The issue is when there is already an existing template with the same name as a mainspace page after the prefix. Mach61 14:27, 11 April 2024 (UTC)
- Hmmm. Well there's something to be said for knowing I don't understand something, since I'll talk less. I don't know how much of an obstacle we're talking about. I do believe that we should be prepared to make some sacrifice to make this work. ―Mandruss ☎ 14:45, 11 April 2024 (UTC)
- Yeah, it's super easy to create an alias template, provided that the alias doesn't conflict with article titles/redirects already. Which is the main issue. Cessaune [talk] 15:55, 11 April 2024 (UTC)
- Also, it seems that Jeezy is a thoughtful Wikipedian, as he chose an appropriate spelling for his 2019 album title : TM104: The Legend of the Snowman, just to avoid conflict :-) Alexcalamaro (talk) 07:44, 20 April 2024 (UTC)
- Yeah, it's super easy to create an alias template, provided that the alias doesn't conflict with article titles/redirects already. Which is the main issue. Cessaune [talk] 15:55, 11 April 2024 (UTC)
- Hmmm. Well there's something to be said for knowing I don't understand something, since I'll talk less. I don't know how much of an obstacle we're talking about. I do believe that we should be prepared to make some sacrifice to make this work. ―Mandruss ☎ 14:45, 11 April 2024 (UTC)
- @Mandruss actually, we could just create a template page and redirect that (see Help:A Day in the Life for an analogous case). The issue is when there is already an existing template with the same name as a mainspace page after the prefix. Mach61 14:27, 11 April 2024 (UTC)
- Tm or Tl Both are close to the colon-key, which is always practical. Draken Bowser (talk) 15:51, 11 April 2024 (UTC)
- @Draken Bowser: tl is off the table, hence the strikethrough in the intro to this section. See previous discussion in this section. ―Mandruss ☎ 16:14, 11 April 2024 (UTC)
- After further consideration, I would probably go for t: or tmp:/tpl:. Any collision with article space can be solved by redirects, similar to Portal:No Escape, given the number of offenders is relatively small. TM: is a non-starter in my opinion since many keyboards auto-correct it to a U+2122 ™ TRADE MARK SIGN, and the point of a shortcut is to avoid difficulty. ― novov (t c) 02:33, 12 April 2024 (UTC)
- First choice Tm, second choice T: — PerfectSoundWhatever (t; c) 03:11, 13 April 2024 (UTC)
Browser config
I do not know about the rest, but on chrome, using the search engine shortcut feature worked perfectly.
- Go to chrome://settings/searchEngines
- Click "Add" that's next to "Site search"
- Fill out: Name = [Anything], Shortcut = [I picked "tt"] , URL with %s in place of query = https://www.search.com.vn/wiki/en/Template:%s
That's it. After that, just type out your shortcut, followed by title, separated by a space/tab, on the address bar and hit enter. Everyone can pick whatever shortcut they like, for all namespaces and even page prefixes of their choice. You can add one for https://www.search.com.vn/wiki/en/Wikipedia:Requests_for_adminship/%s to go to RFAs by just typing out usernames, for example. Best, Usedtobecool ☎️ 05:47, 9 April 2024 (UTC)
- That's good for an alternative in the meantime! But
tp:
would make it easier regardless of the platform people use to contribute. Cocobb8 (💬 talk • ✏️ contribs) 11:20, 9 April 2024 (UTC) - You can also use User:Ahecht/Scripts/TemplateSearch to automatically replace
TP:
and{{
in the Wikipedia search box withTemplate:
. --Ahecht (TALK
PAGE) 16:31, 11 April 2024 (UTC)
Allow all autoconfirmed users to move pages without leaving a redirect
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
While redirects from page moves are commonly kept, there are reasons why they should not be kept as seen at WP:PMRC. For example, moving an article to draft space or to reverse page moves vandalism. This is common even for those without special tools (such as page mover or admin). This is so that normal users do not have to tag the page to request deletion and saves times for the admins (and users with the page mover tool) to do the work. Obviously this will not be an option for unregistered or new users, or for pages that are already move protected. The 'leave a redirect' button (or something along those lines) will be on by default and users who need to remove the redirect will have to manually press a button to turn it off. JuniperChill (talk) 14:28, 20 April 2024 (UTC)
- Opposed: Being granted pagemover isn't that big a deal, but it does require you to demonstrate that you understand the relevant policies, and a quick look at WP:PERM/PM shows me that most requests are denied. Granting this to all autoconfirmed users with no human review would be unadvisable. RoySmith (talk) 14:57, 20 April 2024 (UTC)
- Per the change in focus, I'm opposed even to making this automatic for all extended confirmed users. If you really need the ability, just apply at WP:PERM/PM when you get the required experience. RoySmith (talk) 19:05, 20 April 2024 (UTC)
- Oppose, I wouldn't feel comfortable with trusting all autoconfirmed users to move a page without leaving a redirect. At the very most, I would slightly support having it for all extended confirmed users (but not autoconfirmed). Cocobb8 (💬 talk • ✏️ contribs) 15:11, 20 April 2024 (UTC)
- Strong Oppose autoconfirmed is trivial, and vandalism of "disappearing" articles (by moving them to say another namespace) can be annoying to fix, can result in patrolling get skipped, and is certainly disruptive to readers. — xaosflux Talk 15:49, 20 April 2024 (UTC)
- Oppose for autoconfirmed, support for extended confirmed. A person who games extended confirmed to make vandalistic moves will quickly find that their extended confirmed permission is gone. Awesome Aasim 16:48, 20 April 2024 (UTC)
- Oppose even for extended confirmed - we already have rampant violations of the WP:PMRC criteria by page movers, and don't need to make it worse. * Pppery * it has begun... 16:49, 20 April 2024 (UTC)
- Own comment, I want to change this to all extended confirmed users, but does the discussion above need to be closed and I have to make a separate one below? It will be the same text I said earlier, but with small changes so that it is now all EC users. JuniperChill (talk) 17:14, 20 April 2024 (UTC)
- I don't think that we are so bureaucratic as to require you to start a new discussion, but I guess that if any of the editors who has already commented objects you should. Phil Bridger (talk) 18:19, 20 April 2024 (UTC)
- Yeah I can leave this discussion to be (leave it as it is) because some others have suggested supporting it for EC users instead. JuniperChill (talk) 18:36, 20 April 2024 (UTC)
- I don't think that we are so bureaucratic as to require you to start a new discussion, but I guess that if any of the editors who has already commented objects you should. Phil Bridger (talk) 18:19, 20 April 2024 (UTC)
- Oppose even for extended confirmed. It's not difficult for anyone that needs and can be trusted with this right to apply for it. If they don't need it then it's just hat collecting. Phil Bridger (talk) 18:23, 20 April 2024 (UTC)
- Oppose even for extended confirmed, per Pppery, Phil Bridger and Xaosflux. Most moves should leave a redirect but many people (even some admins) don't understand this, the pagemover right is a necessary (but not sufficient) check to ensure that the relevant policies and guidelines have been read and understood. Thryduulf (talk) 08:19, 21 April 2024 (UTC)
- Oppose even for extended confirmed. It shouldn't be a thing for anyone but trusted users - all it will lead to is disruption. LilianaUwU (talk / contributions) 05:20, 26 April 2024 (UTC)
oppose, as this would create many controversial page moves and page-move disputes that are prevented by the existence of a redirect. Uncontroversial page moves can be requested at the tecnical requests page.InTheAstronomy32 (talk) 17:51, 27 April 2024 (UTC)
- Weak support for extended confirmed users. As these users are more experienced, aware of the policies and guidelines, I believe that little or no disruption would occur if they could move pages without making redirects, to move pages using the Round-robin method. As we currently have less than 1300 page movers, this would make certain processes (such as moving an accepted draft to mainspace, or reverting page-move vandalism) less bureaucratic and more automatic. I also admit that I never understood why we have a user with the right only to move pages, used by only 1400 editors of which the majority are administrators.InTheAstronomy32 (talk) 17:49, 29 April 2024 (UTC)
- Anyone who is autoconfirmed can move pages. The pagemover right lets you delete the redirect that is left behind. Phil Bridger (talk) 19:42, 29 April 2024 (UTC)
- Oppose both (as a pagemover). Solution in search of a problem. The speedy deletion system is perfectly sufficient to delete these errant redirects. Queen of ♡ | speak 06:52, 28 April 2024 (UTC)
Post closure comment - Looks like I should have said ECP users, but it looks like the proposal will still not survive regardless. I counted 0/10 support for AC users and 3 for EC users (excluding the proposer). I made this proposal because of the amount of times its useful to not leave a redirect, as stated above but other than that, keep it. Maybe at least from main to draftspace, redirects would be deleted regardless. I didn't think that by this way, non admins could effectively delete the page when it was actually moved elsewhere
(not sure if this is the right place to put post closure comments as it is just below the discussion, just no more support/oppose votes) JuniperChill (talk) 23:18, 29 April 2024 (UTC)
Split proposal at Wikipedia talk:Missing Wikipedians
There is a split proposal at Wikipedia talk:Missing Wikipedians § Split proposal that may be of interest to editors. All the best, —a smart kitten[meow] 11:49, 3 May 2024 (UTC)
Add nowrap for para
Wrong venue. Copied from the edit request at Template talk:Para#Add nowrap for para, which was rejected as "consensus required". April 2023 attempt to seek said consensus received no response. That system leaves a lot to be desired.
I used {{para}}
and got a line break after the pipe character. This looked ridiculous and makes little sense. I assume other line breaks would be possible, such as after a hyphen in the parameter name. Adding {{nowrap}}
or equivalent would make far more sense than requiring editors to code, e.g., {{nowrap|{{para|archive-url}}}}
. While Note 2 below the table at "General-purpose formatting" speaks of nowrap options, I'm at a loss to see how they help my situation. In any event, I don't see how automatic, unconditional nowrap for all uses of {{para}}
could be the slightest bit controversial. At the very least, an option could be added to suppress the default of nowrap for cases where horizontal space is limited, such as in tables.
See also Template talk:Para#no line-breaks in output, where a request for this was ignored (or never seen) 13 months ago. As to If the proposed edit might be controversial, discuss it on the protected page's talk page before using this template.
, well, we've seen how effective that was. ―Mandruss ☎ 21:53, 5 May 2024 (UTC)
- It's unfortunate that the edit request was declined, when this seems like a fairly straightforward improvement and there seems to be a silent consensus to implement. I will plan to implement unless there are objections (courtesy pinging @Redrose64 as edit request responder). (Yes, coming here for this is a little POINTy, but the frustration at the edit request is understandable, and in any case let's not get bogged down by process concerns. Next time, though, I'd suggest replying to or talk page messaging the edit request responder.) Sdkb talk 22:05, 5 May 2024 (UTC)
- Thanks. I did reply to Rose, with a ping, a mere four minutes after her rejection. When she hadn't replied after another 25 minutes, I surmised that she wasn't going to. Mea culpa: If I had checked her contribs, I would've seen that she hadn't made an edit after the rejection, so it's likely she left the site during those four minutes. Now self-flagellating for one hour. In any case, Rose doesn't change her mind much in my experience; she's that good.I fail to see any POINTiness here; I'm just playing the cards I was dealt. ―Mandruss ☎ 22:22, 5 May 2024 (UTC)
- I'm generally against adding nowrap, and would rather see it's use curtailed. It's causes endless formatting issues for those not using desktop screens, where the auto-formatter would do a better job. Nor do I see how not having 'para' wrap is an improvement, wrapping won't lead to any misunderstanding and may not even be wrapped on different screen aspects. -- LCU ActivelyDisinterested «@» °∆t° 01:46, 6 May 2024 (UTC)
- From a usability standpoint,
|archive-url=
should all be on one line, not wrapped, because "archive-url" is a single concept (the parameter name) and should not be split in any way, despite the hyphen. I do not find broader ideological opposition to nowrap persuasive if it is applied reflexively to this circumstance without considering the particular situation here. I would find examples of instances in which parameters should be wrapped much more persuasive. Sdkb talk 02:36, 6 May 2024 (UTC)- It would be helpful to hear from TheDJ, who appears to have disabled nowrapping after it had been in place for about 11 years. – Jonesey95 (talk) 04:04, 6 May 2024 (UTC)
- Yes. Applying nowrap to anything longer than a word is really bad practice and causes many issues for mobile, and situations where width is restricted. if you are going to apply it, apply it just to to the param= part, not to values (which can be giant urls) and definitely not to the entire line. A lot has changed in 11 years. —TheDJ (talk • contribs) 06:30, 6 May 2024 (UTC)
- One of the problems here is that people give examples of common usages of this template. The problem is that those are NOT the only usages of the template. Even the doc page of the template itself has examples of pretty long values that basically form an entire sentence. Making an entire line not wrap is bad. Htm has to be flexible for many situations and if you set a very strict css option on a very generic template block that has very differing uses, you will run into problems like this. Solutions are to make the css more targeted (which in this case means being more strict about what the parameters can be, instead of just wrapping the template around a block of arbitrary text) or applying the css more targeted.
|archive-url=
for instance is ok.it just requires more thought by those writing the uses. —TheDJ (talk • contribs) 06:57, 6 May 2024 (UTC)- Applying it only to the
param=
part sounds reasonable. Sdkb talk 14:14, 6 May 2024 (UTC)- I'd be happy with that, provided it included the pipe character (that was the case that brought me here). ―Mandruss ☎ 16:29, 6 May 2024 (UTC)
- @TheDJ: Looks like a limited-participation agreement, but I don't see any edit activity to the template. And this is due to fall off the page in three days. At the least, this comment will keep it for another nine. ―Mandruss ☎ 20:01, 12 May 2024 (UTC)
- Keep for another nine days. ―Mandruss ☎ 20:48, 21 May 2024 (UTC)
- Applying it only to the
- One of the problems here is that people give examples of common usages of this template. The problem is that those are NOT the only usages of the template. Even the doc page of the template itself has examples of pretty long values that basically form an entire sentence. Making an entire line not wrap is bad. Htm has to be flexible for many situations and if you set a very strict css option on a very generic template block that has very differing uses, you will run into problems like this. Solutions are to make the css more targeted (which in this case means being more strict about what the parameters can be, instead of just wrapping the template around a block of arbitrary text) or applying the css more targeted.
- Yes. Applying nowrap to anything longer than a word is really bad practice and causes many issues for mobile, and situations where width is restricted. if you are going to apply it, apply it just to to the param= part, not to values (which can be giant urls) and definitely not to the entire line. A lot has changed in 11 years. —TheDJ (talk • contribs) 06:30, 6 May 2024 (UTC)
- It would be helpful to hear from TheDJ, who appears to have disabled nowrapping after it had been in place for about 11 years. – Jonesey95 (talk) 04:04, 6 May 2024 (UTC)
- From a usability standpoint,
- Support nowrapping the parameter-name, per Sdkb. The left side of param=value is a specific string of characters, not ordinary text, so it's best that it stays unified to it can be recognized or discussed correctly. DMacks (talk) 20:54, 21 May 2024 (UTC)
Another job aid proposal, this time with AI
— Preceding unsigned comment added by Joe Roe (talk • contribs) 07:32, 10 May 2024 (UTC)
Discussion at Wikipedia talk:Growth Team features § Should English Wikipedia enable the Suggested Links newcomer task?
You are invited to join the discussion at Wikipedia talk:Growth Team features § Should English Wikipedia enable the Suggested Links newcomer task?. Sdkb talk 21:13, 16 May 2024 (UTC)
Idea lab
Wikipedia Hall of Fame?
What are your thoughts? Is it going to work? Comment down below. Wolverine XI (talk to me) 17:28, 8 April 2024 (UTC)
Hall of fame topic; section break 1
- I'll bite. What do I get? Like, a room with a comfy chair? The one caution I would have about this is that there are some editors whose positive contributions to the encyclopedia would unquestionably earn them a spot, but who are presently indef-banned for other reasons. BD2412 T 17:37, 8 April 2024 (UTC)
- "The one caution I would have about this is that there are some editors whose positive contributions to the encyclopedia would unquestionably earn them a spot, but who are presently indef-banned for other reasons." That's a good point. Though, IMO, I don't think HOF should be behavior-exclusionary and should be open to anyone who has made an enduring impact on WP, regardless of how they made the impact. For instance, I say induct Jordan French (maybe not in the inaugural cohort, but eventually). Chetsford (talk) 18:47, 8 April 2024 (UTC)
- I agree with Chetsford on this. Wolverine XI (talk to me) 04:11, 9 April 2024 (UTC)
- French certainly made an impact but then so did many LTA vandals. If this idea is adopted, it seems appropriate to limit membership to those who have shown altruism rather than encouraging those who make Wikipedia worse for personal gain. Certes (talk) 08:24, 9 April 2024 (UTC)
- Never say never. Wolverine XI (talk to me) 13:16, 9 April 2024 (UTC)
- Yeah, that's a good point, Certes. I think this was intended more as an exaggeration for emphasis that we not be rules-bound for a HOF, but probably not a good example to underscore that! Anyway, I agree with your suggestion. Chetsford (talk) 15:26, 9 April 2024 (UTC)
- French certainly made an impact but then so did many LTA vandals. If this idea is adopted, it seems appropriate to limit membership to those who have shown altruism rather than encouraging those who make Wikipedia worse for personal gain. Certes (talk) 08:24, 9 April 2024 (UTC)
- I agree with Chetsford on this. Wolverine XI (talk to me) 04:11, 9 April 2024 (UTC)
- "The one caution I would have about this is that there are some editors whose positive contributions to the encyclopedia would unquestionably earn them a spot, but who are presently indef-banned for other reasons." That's a good point. Though, IMO, I don't think HOF should be behavior-exclusionary and should be open to anyone who has made an enduring impact on WP, regardless of how they made the impact. For instance, I say induct Jordan French (maybe not in the inaugural cohort, but eventually). Chetsford (talk) 18:47, 8 April 2024 (UTC)
- We already have a lot of perks for experienced editors (Special holidays, Wikimedian of the Year, Editor of the Week, Service awards, ...), and I honestly don't think we need yet another way to separate "elite" Wikipedians from the rest of us. Chaotıċ Enby (talk · contribs) 18:02, 8 April 2024 (UTC)
- Similar to Internet Hall of Fame, to be serious, there would need to be a reliable advisory board. They can help surface little known but important people from the early founder days. It could be a popular vote nomination process, like the Nobel, but picking the winners would need a small august body, known for deep institutional knowledge and experience. After a few rounds/years of winners, those winners then become members of the advisory board. Overall this is probably something that should be organized by WMF. Or you can just do it, but it will be another "This one is special. This one is also special" award. -- GreenC 18:32, 8 April 2024 (UTC)
- I like it. While we may have a superfluidity of awards, these cost essentially nothing to produce so I'm not sure I ever understand the resistance. All recognition systems are voluntary and those who don't approve can opt-out. Moreover, a HoF -- if managed through some approximation of the way GreenC describes -- would be different from existing accolades which are either interpersonal recognition (editor to editor) or metric-based recognition (e.g. Four Award, etc.). Chetsford (talk) 18:41, 8 April 2024 (UTC)
Hall of fame topic; section break 2
- Of course they "cost nothing to produce", that's not the problem, the problem is that they give one more excuse to divide Wikipedians between "the ones who have power" (i.e. the unblockables) and the plebs like us. Chaotıċ Enby (talk · contribs) 13:36, 10 April 2024 (UTC)
- It might be a good idea. 3.14 (talk) 19:07, 8 April 2024 (UTC)
- The key questions for any initiative is what is the objective, and how helpful is the initiative in achieving this objective? For recognition programs, it's important to also consider how the selection process will work, and whether or not it will create more difficulties than benefits gained. Recognition programs are tricky because the flip side of selecting some is that many others are not selected, and that can result in conflict. isaacl (talk) 02:36, 9 April 2024 (UTC)
- That's how recognition programs work, but I don't think they'll necessarily cause any conflict. Wolverine XI (talk to me) 04:09, 9 April 2024 (UTC)
- "it's important to also consider how the selection process will work" After the inaugural cohort is selected, maybe it should become self-perpetuating with all prior inductees selecting each subsequent cohort. (Though you'd still need some system to choose the inaugural cohort.) This would mitigate politicization and degradation as inducted members would have a vested interest in maintaining its reputational coherence. Chetsford (talk) 05:37, 9 April 2024 (UTC)
- That would be difficult if they are dead or so long retired from WP they don't give a toss about the place anymore/are out of touch about who is still active and "deserves" a shout. - SchroCat (talk) 07:44, 10 April 2024 (UTC)
- "would be difficult if they are dead" I imagine it would. Chetsford (talk) 08:48, 10 April 2024 (UTC)
- I don't think we'll select a cohort that are all dead or inactive, for the reasons you've mentioned. Aaron Liu (talk) 11:34, 10 April 2024 (UTC)
- I think it best if you don't have any intake at all: voting for one's friends make this an inbred and insular process. As I've said before (as has Chaotic Enby), this is a bad idea - divisive and with the potential for conflict when the "wrong" people are elected and the "right" people over looked. - SchroCat (talk) 12:02, 10 April 2024 (UTC)
- That would be difficult if they are dead or so long retired from WP they don't give a toss about the place anymore/are out of touch about who is still active and "deserves" a shout. - SchroCat (talk) 07:44, 10 April 2024 (UTC)
- The English Wikipedia Hall of Fame idea sounds peachy keen, as Babe Ruth would say before tying his hands behind his back and hitting a home run with his neck (Ruth is, all kidding aside, the most underrated ballplayer in baseball history). The initial "class" obviously would include J and L, the pioneering heroes of our story, and I can think of several others who would be obvious. That first class probably shouldn't be large, maybe 7 or 8 inductees. Then the rules get tricky, but doable. In a perfect world we'd lock J and L in a room until they get to a place where they can come up with a plan of how to handle this that everyone says "Of course that's how it should be done". But, bottom line, I think an EWHoF is a good idea all around (without WMF involvement). Randy Kryn (talk) 03:22, 10 April 2024 (UTC)
- A second rate popularity contest with ill-defined criteria? What could possibly go wrong. Terrible and divisive idea. You think someone's great - give 'em a barnstar, or, even better, leave them a thank you note, but to 'promote' people who will undoubtedly be divisive to others? That way grief and conflict lies. And this ignores the fact that "hall of fame" is not a worldwide concept that people everywhere readily grasp or buy into.- SchroCat (talk) 07:44, 10 April 2024 (UTC)
- Schro, the procedure is akin to the Wikimedian of the Year, except that it exclusively concentrates on the English Wikipedia. There's a purpose for these initiatives, and I firmly disagree that this is a "bad idea." Wolverine XI (talk to me) 13:25, 10 April 2024 (UTC)
- You are, of course, entitled to disagree. For what it's worth, I think the Wikimedian of the Year is a fairly crap award too, being a process with no criteria and something else that divides, rather than unites. Most people are happy to do the work for the sake of the work, not to seek vacuously external praise or validation just because they've caught the eye of someone powerful or happen to be pushing a zeitgeist line of thinking. - SchroCat (talk) 14:44, 10 April 2024 (UTC)
- As you haven't yet stated the purpose behind your suggestion, nor proposed a process, there isn't enough info to understand the potential benefits and costs. There's an understandable view that costs quickly outweigh benefits as any process involves more people, adding up to more total effort expended. isaacl (talk) 16:53, 10 April 2024 (UTC)
- Schro, the procedure is akin to the Wikimedian of the Year, except that it exclusively concentrates on the English Wikipedia. There's a purpose for these initiatives, and I firmly disagree that this is a "bad idea." Wolverine XI (talk to me) 13:25, 10 April 2024 (UTC)
Hall of fame topic; section break 3
- More awards? At this rate, all our time will be spent giving ourselves pats on the back and giving each other shiny things. While I don't agree with the more extreme anti-award views (take wiktionary for example; wikt:Template:User barnstar has been nominated for deletion twice, and been described as
cheesy and gaudy. I don't think we need all that Wikipedia's tinsel to encourage people.
), we shouldn't go overboard with this. Cremastra (talk) 22:07, 10 April 2024 (UTC)- (the correct link is wikt:Template:User Barnstar, with a capital B. Aaron Liu (talk) 01:51, 11 April 2024 (UTC)
- It's okay if you choose not to participate in the process. Wolverine XI (talk to me) 04:55, 11 April 2024 (UTC)
- How would one choose not to participate? I would not participate, but saying so would make it look as if I thought I stood a chance of being elected, which I do not. I imagine that most of those who would choose not to participate think the same way. Phil Bridger (talk) 20:07, 11 April 2024 (UTC)
- Maybe. Wolverine XI (talk to me) 16:07, 12 April 2024 (UTC)
- How would one choose not to participate? I would not participate, but saying so would make it look as if I thought I stood a chance of being elected, which I do not. I imagine that most of those who would choose not to participate think the same way. Phil Bridger (talk) 20:07, 11 April 2024 (UTC)
I don't much like anything on Wikipedia which encourages elitism, political campaigns, cliques, inequality, etc. I can imagine that many wiki-politicians would waste a lot of time campaigning to be elected to a HOF and that the results would be divisive. "How come so-and-so got elected, and I didn't?" Smallchief (talk) 21:44, 12 April 2024 (UTC)
- I think this sort of thing is better left to other sites. Maybe the people who hang out at Wikipediocracy would create a Wikipedia Hall of Fame? Or would it become a Wikipedia Hall of Infamy? Phil Bridger (talk) 08:09, 13 April 2024 (UTC)
- I especially don't like the idea of putting infamous characters in a HOF. Follow baseball standards. Pete Rose and Shoeless Joe Jackson are not in the baseball HOF because of scandal, despite being qualified. No bad actors, no matter how famous, in a HOF. Smallchief (talk) 09:04, 13 April 2024 (UTC)
- Good point, but Wikipedia is not baseball. Wolverine XI (talk to me) 06:57, 14 April 2024 (UTC)
- Indeed. Baseball is a sport where defeating others on the field is encouraged. Wikipedia is a cooperative endeavour where it's frowned on. Certes (talk) 09:48, 14 April 2024 (UTC)
- Yes, this program is designed for honoring purposes rather than competition. I hope that's clear to all. Wolverine XI (talk to me) 04:41, 16 April 2024 (UTC)
- In that case, it seems the honor should not be of the Wikipedian itself, but of the work that they accomplished in a given area. That's why the Barnstars exist, of course. Just as WP:NPA encourages us to comment on the content and not on the creator, so too should we be aware to not place individual people on a pedestal.
- Frankly I find it disappointing that, in bringing forth the idea, the OP has not brought forth any comprehensive or detailed arguments in support of this idea and in response to the above critique. We are simply discussing a nebulous concept of recognition, which I think Wikipedia already addresses, and which if people really needed to see more of, they could use other websites or mediums for this purpose. Duly signed, ⛵ WaltClipper -(talk) 12:29, 16 April 2024 (UTC)
- Yes, this program is designed for honoring purposes rather than competition. I hope that's clear to all. Wolverine XI (talk to me) 04:41, 16 April 2024 (UTC)
- Indeed. Baseball is a sport where defeating others on the field is encouraged. Wikipedia is a cooperative endeavour where it's frowned on. Certes (talk) 09:48, 14 April 2024 (UTC)
- Good point, but Wikipedia is not baseball. Wolverine XI (talk to me) 06:57, 14 April 2024 (UTC)
- I especially don't like the idea of putting infamous characters in a HOF. Follow baseball standards. Pete Rose and Shoeless Joe Jackson are not in the baseball HOF because of scandal, despite being qualified. No bad actors, no matter how famous, in a HOF. Smallchief (talk) 09:04, 13 April 2024 (UTC)
section break 4; [wikilounge idea]
- how about a
loungeWikiLounge for experienced wikipedians? would that be immediately misused, or could it serve a helpful purpose? Sm8900 (talk) 13:41, 17 April 2024 (UTC)- That would just be a way to create an in-group, and I don't really see how it would help the project. Chaotıċ Enby (talk · contribs) 13:47, 17 April 2024 (UTC)
- I agree with Enby. What purpose would that serve? Aaron Liu (talk) 15:27, 17 April 2024 (UTC)
- Who decides who is experienced enough? On what basis? I hope it's not edit count, which can vary enormously between people having the same overall effect. Phil Bridger (talk) 15:48, 17 April 2024 (UTC)
- Like an actual lounge, or some cliquey forum that would do nothing to benefit the project? All these ideas go against our core principles. Cremastra (talk) 19:46, 17 April 2024 (UTC)
- ok, fair enough; all of these points are quite valid. so then, how about a lounge which would be labeled as being open to all experienced wikipedians, plus anyone who wishes to shmooze with them? that way, we are actually opening it to everyone, but giving it an underlying theme for those who are interested.
- to use an analogy, it would be like opening a lounge for woodworkers, or one for musicians, or one for ferryboat drivers, and also admitting anyone interested in that specialty. it would be basically open to anyone, and yet the theme would be clearly stated in terms of the specialty which is its actual focus. Sm8900 (talk) 19:56, 17 April 2024 (UTC)
- can an editor nominate themselves for this "Hall of Fame"? if so, then it might preserve the grassroots nature of wikipedia, and still have a positive effect. kind of like hanging out at the local skateboard park, and popping wheelies to show off one's skills to other fellow aficionados. Sm8900 (talk) 20:08, 17 April 2024 (UTC)
- Don't we already have every single needed discussion "board" known to Man? Aaron Liu (talk) 20:24, 17 April 2024 (UTC)
- What would actually be the point of having a lounge with this theme? Like, how would it help the project like, say, the Wikipedia:Teahouse, the Wikipedia:Help desk or the Wikipedia:Administrator's noticeboard does? Chaotıċ Enby (talk · contribs) 21:21, 17 April 2024 (UTC)
- The idea of an "experienced user lounge" very much echoes of Wikipedia:Esperanza which, although it did result in useful derivative projects, very much had a problem back in its day with regards to ingroup/outgroup behavior. Duly signed, ⛵ WaltClipper -(talk) 12:58, 18 April 2024 (UTC)
- how about a
- One downside of this proposal is that it would involve a fair amount of the electorate's time if they are not to just elect people who they already know. That time would be better spent improving the encyclopedia, which is what we are here for (or at least are supposed to be here for). Phil Bridger (talk) 15:48, 17 April 2024 (UTC)
- another idea; how about simply call it something whimsical or jocular, such as "Wikipedia League of Super-friends"? or "league of adventurers"? that way, it still retains the air of a unique league, yet it would be clear it is not anything awarding actual higher privileges here. Sm8900 (talk) 20:15, 17 April 2024 (UTC)
- I still don't see what the actual point is. Even with a funny name, it will still be a pretty divisive thing. Chaotıċ Enby (talk · contribs) 21:22, 17 April 2024 (UTC)
- Divisive programs, like the WP:Editor of the week, already exist. Wolverine XI (talk to me) 22:41, 20 April 2024 (UTC)
- And that's not an excuse to have more of them. Chaotıċ Enby (talk · contribs) 22:46, 20 April 2024 (UTC)
- OK, if you say so. Let us see if we can reach a consensus. Wolverine XI (talk to me) 23:10, 20 April 2024 (UTC)
- And that's not an excuse to have more of them. Chaotıċ Enby (talk · contribs) 22:46, 20 April 2024 (UTC)
- Divisive programs, like the WP:Editor of the week, already exist. Wolverine XI (talk to me) 22:41, 20 April 2024 (UTC)
- I still don't see what the actual point is. Even with a funny name, it will still be a pretty divisive thing. Chaotıċ Enby (talk · contribs) 21:22, 17 April 2024 (UTC)
- another idea; how about simply call it something whimsical or jocular, such as "Wikipedia League of Super-friends"? or "league of adventurers"? that way, it still retains the air of a unique league, yet it would be clear it is not anything awarding actual higher privileges here. Sm8900 (talk) 20:15, 17 April 2024 (UTC)
Section break 5
- Editor of the Week was set up with a specific goal in mind: to demonstrate appreciation of specific positive behaviours and collaborative spirit by its recipients, with an explicit disclaimer that it's not intended to be a judgement about their overall characteristics. It was deliberately set up as a no-big-deal award with a very lightweight process, to avoid making it something that people would argue a lot about. The original pool of candidates was lesser-known editors, in order to give them a bit more encouragement to continue contributing, but has since been broadened to anyone. It's basically a slightly fancier barnstar, with some people slapping recipients on the back with a "good job". As a result of this carefully planned design, it hasn't fostered division. isaacl (talk) 02:05, 21 April 2024 (UTC)
- Many such award schemes have been previously proposed. Only two, to my knowledge, still function: WP:QAI, because of the dedication of one editor, and WP:EOTW. If you want another one, set it up and run it yourself—if people like it, you can then apply to formalize it as a Wikipedia-wide process. ~~ AirshipJungleman29 (talk) 12:13, 26 April 2024 (UTC)
How about a Hall of Shame?
I know generally we are a bit negative especially when it comes to disruption, which is why we generally note previous hurdles as a cautionary tale of what not to repeat. A reminder everyone is human. A hall of fame will make editors more concerned with scoring brownie points than actually improving the project. Awesome Aasim 20:29, 7 May 2024 (UTC)
- We already have Wikipedia:STOCKS, more than this would actually be more harmful than it might help. Chaotıċ Enby (talk · contribs) 20:33, 7 May 2024 (UTC)
- Yeah I know. I was just thinking about why we have a hall of shame but not a hall of fame. Awesome Aasim 00:05, 8 May 2024 (UTC)
- The stocks aren't a hall of shame, it's a humourous list of mistakes. -- LCU ActivelyDisinterested «@» °∆t° 21:04, 9 May 2024 (UTC)
- Yeah I know. I was just thinking about why we have a hall of shame but not a hall of fame. Awesome Aasim 00:05, 8 May 2024 (UTC)
- Awesome Aasim, isn't WP:Long term abuse already kind of that?ipse (talk) (contribs) 14:49, 18 May 2024 (UTC)
Coming up with principles for future icon redesigns
A few years ago I botched an RfC to change to flat icons. Of course I still feel strongly about that we need new icons, for many reasons from accessibility to load times to new features like dark mode (which oceans of white in the middle of some of today's icons are a bit too much).
I want to see if we could figure out ways to propose icon redesigns in a matter that is most likely to pass. I kind of want to discuss some of my principles when choosing icons (and combining User:Awesome_Aasim/Flat_design_idea, where I just added a section for viewing on a dark background; and User:Arsonxists/Flat_Icons).
In general I believe icons must be:
- Clear: Easily understood by many, including new users who may be unfamiliar;
- Accessible: Icons must use multiple properties to distinguish themselves from one another when used in the same context. Uw1 and uw2 fail at this, because they only alter the color of the icon but not the shape or the contents inside of it.
- Fast: Icons must load within seconds even on the slowest of connections. I notice that some flat icons (particularly the OOUI/Codex icons) use a fraction of the space and bandwidth as equivalent skeuomorphic icons.
- Contrast: Icons must be adaptable based on different themes, skins, etc. Icons must be visible on both light and dark themes, and if not then should be easily adaptable from light to dark and vice versa. MediaWiki's default skins do not override the
@media (prefers-color-scheme: dark)
or@media (prefers-color-scheme: light)
properties yet, but when they do there will certainly be icon clashes and colors. - Helpful: If text is able to more clearly communicate an idea than an icon, then we should reconsider whether it is actually necessary. Stop hands do a great job at communicating "stop what you are doing" or "you have been stopped", but the i's in some messages just seem purely decorative rather than actually helpful.
Is there anything else I am missing? I probably want to add more icons that should be switched for better accessibility, etc. Awesome Aasim 03:39, 5 May 2024 (UTC)
- The design principles for icons in the Wikimedia Design Style Guide may be of interest, as well as the guidance for icons in the Wikimedia Codex. Regarding effect on page loading: note images will be cached by the browser, so loading time will be amortized across many page loads. Additionally, for images the size of an icon, the number of requests being made is a more significant bottleneck than the byte size of an image. This is why sites will use the CSS sprite technique to bundle many icons together onto one image. However, this adds more steps for changing icons. isaacl (talk) 05:44, 5 May 2024 (UTC)
- @Isaacl If I recall there is a way to get Codex icons to work in wikitext. Can you maybe show? Awesome Aasim 15:56, 5 May 2024 (UTC)
- Not directly that I know of. If I understand correctly, they are available for use in a gadget/user script or extension. An extension could be written to provide a wikitext interface. (Maybe one exists already? Perhaps someone who knows more about the Codex can weigh in.) Regarding design guidance, here is a more direct link to the principles and guidance for designing icons in the Wikimedia Codex. isaacl (talk) 17:50, 5 May 2024 (UTC)
- I wish there was a parser function like that: . Then it would allow codex icons to be used inline. Awesome Aasim 19:52, 5 May 2024 (UTC)
{{#codex:name_of_icon|size=size|color=color|type=type|...}}
- The WMF's previous, similar icon set OOUI is on Commons which made it easy to use with standard wikitext syntax. Curiously, Codex doesn't seem to be – but surely it has compatible license? – Joe (talk) 21:17, 5 May 2024 (UTC)
- I wish there was a parser function like that:
- Not directly that I know of. If I understand correctly, they are available for use in a gadget/user script or extension. An extension could be written to provide a wikitext interface. (Maybe one exists already? Perhaps someone who knows more about the Codex can weigh in.) Regarding design guidance, here is a more direct link to the principles and guidance for designing icons in the Wikimedia Codex. isaacl (talk) 17:50, 5 May 2024 (UTC)
- @Isaacl If I recall there is a way to get Codex icons to work in wikitext. Can you maybe show? Awesome Aasim 15:56, 5 May 2024 (UTC)
- I am also going to link my past two attempts attempting to gain input on using the OOUI icons on Wikipedia. Wikipedia:Village_pump_(idea_lab)/Archive_37#Changing_to_flat_icons Wikipedia:Village_pump_(proposals)/Archive_168#Flat_Design (the latter is cringe because I was new to how RfCs worked at the time, so I did not really understand the best way to format RfCs at the time, now I do). Awesome Aasim 02:04, 6 May 2024 (UTC)
- I don't think RfCs are the way to go here. It touches too many buttons: Wikipedians are reflexively sceptical about new UI, and about anything the implies changes to many pages, and about anything that implies the WMF might be better at some things than volunteer editors are... What I'd do is write an essay that outlines what guidelines you think people should follow when selecting icons in templates etc., and then try to build consensus around those guidelines by arguing for its application in specific discussions. It's the longer road, but I think it's more likely to build a broad and stable consensus. – Joe (talk) 07:23, 6 May 2024 (UTC)
- I think the argument by many will be "if it ain't broke, don't fix it", and yes some of the icons ain't broke, but this does not mean there wouldn't be benefits to switching. Awesome Aasim 13:02, 6 May 2024 (UTC)
- The key challenge is that interface design decisions are often difficult to make using English Wikipedia's consensus-based decision making traditions, because many users respond on a like it/don't like it level, and aren't fussed about compliance with guidelines. I agree with the idea underlying your original post (which matches Joe Roe's suggestion) of building up support for basic principles, and I think that offers the best path towards UI changes. But for better or worse, results from A-B testing is likely the only hard data that will get some users to overlook their own personal initial reaction, and that generally needs funding. isaacl (talk) 16:18, 6 May 2024 (UTC)
- Let me take a look at another icon redesign RfC: Wikipedia:Village_pump_(proposals)/Archive_155#Proposal/RFC:_Redesigning_page-protection_padlock_icons_to_be_more_accessible. This one focused exclusively on accessibility. I think that might be the key. Showing that accessibility is poor especially in dark mode for some of the images, or if it is there the icons have terrible contrast if Wikipedia had a properly implemented dark mode (which it doesn't yet but one is in the works). Awesome Aasim 16:56, 6 May 2024 (UTC)
- The in-development night mode is a good reason to revisit the use of colour (for instance, some sports team pages use team colours for the text and background in table and infobox headers, which already is a readability problem now). But rather than jumping ahead to discussing new icons, perhaps we can continue discussing the basic principles? isaacl (talk) 17:16, 6 May 2024 (UTC)
- This might be good for a multistaged RfC. One might be asking about design principles, the next icons are found and submitted that meet those design principles, and then after the icons are voted on. This would be a good three phase discussion. Awesome Aasim 18:54, 6 May 2024 (UTC)
- As I mentioned, I'm more interested in getting some discussion going on the original post and my original reply than discussing process matters...
- Again, I think it's looking too far ahead to be planning a multi-stage RfC. As alluded to by Joe and evidenced by the page protection icon discussion, I think it will be more effective to look at a specific icon or set of related icons, gain consensus that there is a specific problem (or problems) with them, and then work on replacements. I think a generic "here's the next stage: let's discuss this bunch of icons as replacements based on design principles" discussion isn't going to build up consensus for a change. isaacl (talk) 22:46, 6 May 2024 (UTC)
- On that note, as well as dark mode, I think the switch to Vector 2022 as the default skin is a good reason to revisit icons and broader template design choices that now look out of place with the rest of the site as most readers see it. – Joe (talk) 07:38, 7 May 2024 (UTC)
- You think so? I actually think it's really important that the icons are as not-flat as they are, so that I don't feel the awful life-sucking I often do from other "flat" mobile-ready web design. Perhaps the C-class etc. icons could be given a refresh, but I would see a bottom-up redesign as searching for a clear problem. Remsense诉 07:46, 7 May 2024 (UTC)
- I actually think that the circle (aka Norro) icons are the ones that don't need to be replaced. They're accessible and consistent across their little bubble.The unblock icons definitely need replacing. They're inaccessible, and there's no reason I can see for making them all clocks. Aaron Liu (talk) 11:30, 7 May 2024 (UTC)
- Whether or not you personally like the new default theme and its flat design, it's here and it's here to stay. With that in mind, I would say the use of two very different design systems (Vector 2022/Codex for Mediawiki UI; an eclectic mix of mid-2000s elements for templates) is a clear problem from both a usability and aesthetic point of view. – Joe (talk) 12:25, 7 May 2024 (UTC)
- Oh, I want to make clear that I quite love Vector 2022, and part of the reason is what I feel in its balance between flat and non-flat. Remsense诉 13:07, 7 May 2024 (UTC)
- I suspect many of the editors who like to weigh in on these matters focus separately on icons that are part of the surrounding general page framework versus the icons that are within the main content area. Thus I'm not sure that differences in the style between these is enough to generate a consensus for change. isaacl (talk) 15:42, 7 May 2024 (UTC)
- Is there a technical way to make icons depend on skin and on whether or not "dark mode" is on, so dinosaurs like me can use icons that work well in Monobook? That way, we could have icons that look good in each of the skins. —Kusma (talk) 13:00, 7 May 2024 (UTC)
- There certainly is to some degree: SVGs are capable of being context-aware using pure CSS. Many will swap the foreground color from black to white based on what mode the browser tells it is being used. Remsense诉 13:01, 7 May 2024 (UTC)
- More straightforwardly, template style sheets can be used to select different icon files based on theme, night mode, or the browser configuration specifying that a dark theme is preferred. I believe SVGs are rendered server-side into bitmap images, so right now they won't be able to adapt based on CSS differences. isaacl (talk) 15:48, 7 May 2024 (UTC)
- There certainly is to some degree: SVGs are capable of being context-aware using pure CSS. Many will swap the foreground color from black to white based on what mode the browser tells it is being used. Remsense诉 13:01, 7 May 2024 (UTC)
- You think so? I actually think it's really important that the icons are as not-flat as they are, so that I don't feel the awful life-sucking I often do from other "flat" mobile-ready web design. Perhaps the C-class etc. icons could be given a refresh, but I would see a bottom-up redesign as searching for a clear problem. Remsense诉 07:46, 7 May 2024 (UTC)
- On that note, as well as dark mode, I think the switch to Vector 2022 as the default skin is a good reason to revisit icons and broader template design choices that now look out of place with the rest of the site as most readers see it. – Joe (talk) 07:38, 7 May 2024 (UTC)
- This might be good for a multistaged RfC. One might be asking about design principles, the next icons are found and submitted that meet those design principles, and then after the icons are voted on. This would be a good three phase discussion. Awesome Aasim 18:54, 6 May 2024 (UTC)
- The in-development night mode is a good reason to revisit the use of colour (for instance, some sports team pages use team colours for the text and background in table and infobox headers, which already is a readability problem now). But rather than jumping ahead to discussing new icons, perhaps we can continue discussing the basic principles? isaacl (talk) 17:16, 6 May 2024 (UTC)
- Let me take a look at another icon redesign RfC: Wikipedia:Village_pump_(proposals)/Archive_155#Proposal/RFC:_Redesigning_page-protection_padlock_icons_to_be_more_accessible. This one focused exclusively on accessibility. I think that might be the key. Showing that accessibility is poor especially in dark mode for some of the images, or if it is there the icons have terrible contrast if Wikipedia had a properly implemented dark mode (which it doesn't yet but one is in the works). Awesome Aasim 16:56, 6 May 2024 (UTC)
- The key challenge is that interface design decisions are often difficult to make using English Wikipedia's consensus-based decision making traditions, because many users respond on a like it/don't like it level, and aren't fussed about compliance with guidelines. I agree with the idea underlying your original post (which matches Joe Roe's suggestion) of building up support for basic principles, and I think that offers the best path towards UI changes. But for better or worse, results from A-B testing is likely the only hard data that will get some users to overlook their own personal initial reaction, and that generally needs funding. isaacl (talk) 16:18, 6 May 2024 (UTC)
- I think the argument by many will be "if it ain't broke, don't fix it", and yes some of the icons ain't broke, but this does not mean there wouldn't be benefits to switching. Awesome Aasim 13:02, 6 May 2024 (UTC)
- Bumping because I got a comment that idea lab might not be a good idea. I am seeing that icon by icon RfCs are going to be more productive. We can use principles in this idea lab to help develop icon sets. Awesome Aasim 16:59, 14 May 2024 (UTC)
- That's a bit oversimplified... I was saying that since no one, including you, has responded to my comments on the design principles, and no one else has said anything about them, that it doesn't seem there is enough interest on the page to reach a consensus viewpoint on the design principles. isaacl (talk) 21:13, 14 May 2024 (UTC)
- Maybe we can then focus on the icons themselves? The last time I tried workshopping in VPIL, I came to the conclusion that finding multiple icon sets and then giving people options to choose would be better. Awesome Aasim 18:29, 17 May 2024 (UTC)
- Maybe the miscellaneous village pump would find more takers to discuss base principles. However it's true enough that usually more editors are attracted to comment on specific examples of icons, rather than discussing abstract concepts. I think it would be helpful for these proposals to have an explanation of how they are improvements with respect to the base design principles.
- I was hoping there would be more discussion on load time considerations and use of colours. Personally I think client-side caching is likely good enough to make loading time a small factor. Colour is a tricky issue, as Wikipedia editors are accustomed to using any colours that strike their fancy, but best practice for supporting themes (which can have light and dark modes) is to have a defined palette that each variation can customize. In accordance with mw:Recommendations for night mode compatibility on Wikimedia wikis, for HTML, CSS variables can be used, and for gadgets/extensions making use of Codex, design tokens can be used. But with pre-rendered icons, any alignment with customized colour palettes would have to be done manually. isaacl (talk) 23:03, 17 May 2024 (UTC)
- Maybe we can then focus on the icons themselves? The last time I tried workshopping in VPIL, I came to the conclusion that finding multiple icon sets and then giving people options to choose would be better. Awesome Aasim 18:29, 17 May 2024 (UTC)
- That's a bit oversimplified... I was saying that since no one, including you, has responded to my comments on the design principles, and no one else has said anything about them, that it doesn't seem there is enough interest on the page to reach a consensus viewpoint on the design principles. isaacl (talk) 21:13, 14 May 2024 (UTC)
- I don't think RfCs are the way to go here. It touches too many buttons: Wikipedians are reflexively sceptical about new UI, and about anything the implies changes to many pages, and about anything that implies the WMF might be better at some things than volunteer editors are... What I'd do is write an essay that outlines what guidelines you think people should follow when selecting icons in templates etc., and then try to build consensus around those guidelines by arguing for its application in specific discussions. It's the longer road, but I think it's more likely to build a broad and stable consensus. – Joe (talk) 07:23, 6 May 2024 (UTC)
Allowing Master's theses when not used to dispute more reliable sources
WP:SCHOLARSHIP generally allows PhD dissertations and generally disallows Master's theses, unless they have had "significant scholarly influence." I feel that this is really locking us out from a lot of very reliable sourcing. I understand that these are often not quite as polished as something like a monograph or PhD dissertation, but often times they are the highest quality sources available about very niche subject matters. They are subject to professional review, they cite their sources, and they are published by reliable institutions. Can we really say that these are less reliable than an entry in a historical society newsletter or an online news report from an assuredly hurried local journalist?
Just today I encountered a 2022 masters thesis, East Meets West in Cheeloo University (doi:10.7916/scmr-6237). As far as I can tell, this is the most comprehensive source available on the architecture of Cheeloo University. But I can't use it, since it's a masters thesis, and as far as Google Scholar can tell, it has yet to be cited elsewhere.
I feel that people should be allowed to use masters theses in certain fields (I can only speak for the humanities, I'd be interested to know this from a STEM perspective) so long as A) They are not used to dispute something said in reliable sources and B) They are not used to confer notability. I feel this would strike a good balance of allowing us to use these often very useful sources, while still recognizing that a book, journal article, or PhD thesis is probably preferable if you have the choice between them. I'd love to hear other folks thoughts! Generalissima (talk) (it/she) 00:43, 7 May 2024 (UTC)
- In the stem area I would expect that important research would also be published in journals. I would discourage use of Masters theses rather than disallow. One issue is lack of accessability. Even when referenced, may not be accessible. The lack of "peer" review can also mean there are more errors included. Graeme Bartlett (talk) 02:03, 7 May 2024 (UTC)
- Is there any public information generally available about the process of publishing masters' theses for a given university? What level of scrutiny or review is generally applied, etc. I think considering whatever information is available there could lend a lot of clarity to deciding whether a given thesis is reliable. Remsense诉 02:09, 7 May 2024 (UTC)
- The rule in question is a counsel of perfection but perfect is the enemy of good and so WP:IAR applies. By coincidence, notice that today's featured article is about a work which started as a dissertation. The main thing I notice about this is that the readership for this topic is tiny. If you're working on a topic like the architecture of an obscure university that no longer exists, then you're mainly writing to please yourself and so should do what you think best. Andrew🐉(talk) 06:49, 7 May 2024 (UTC)
- I both agree and don't, to the extent that I don't think less popular topics should be viewed as less important as regards our content policies. Of course, I certainly understand the distinction between there being less available coupled with internal motivation, and that. Remsense诉 06:54, 7 May 2024 (UTC)
- I'd question whether Master's theses are really
subject to professional review
orpublished by reliable institutions
. By professional review, I assume you mean that somebody examines them. But unlike a PhD examination or journal peer review, which both act as barriers to publication, getting a low grade on a Master's thesis doesn't stop the thesis existing. The author can still put it online – presumably without the grade. Also, and speaking as a university teacher myself, the person who examined it examined it as a Master's thesis, not as a piece of publishable research. A middling or good grade means "I think the student did a good job with this material" not "I think this is a reliable source on this subject". As for publication, in my experience most Master's theses are not published (though those that are, e.g. in a journal, certainly become reliable sources). Some university libraries make archived copies available online, but this isn't really the same thing because again, any Master's theses that meets the formal requirements for submission will be there, regardless of quality. – Joe (talk) 07:59, 7 May 2024 (UTC)- Fair enough, I didn't think about the barrier to publication angle. I guess if we think about them more along the lines of a newspaper article (which can be of wildly different quality) then we could just evaluate them on their own merits. Just like how there is great journalistic coverage of some areas of history and archaeology, there is horrible, misleading coverage; and if it's not used as a major source in the article, it's pretty easy to spot when it's the latter. Generalissima (talk) (it/she) 15:42, 7 May 2024 (UTC)
- Purely anecdotal, but with respect to professional review, the only person on my master's thesis committee (my director) who understood what I was doing left on sabbatical half-way through. His replacement as chair kept me on the straight and narrow in my use of statistics, but knew no more about what I was doing than the rest of the committee. In retrospect, I can say that my thesis did not add anything useful to the sum total of human knowledge. On the other hand, I have dug into the bibliography section in a thesis to find sources I had otherwise missed, but that is a long shot. - Donald Albury 16:20, 7 May 2024 (UTC)
- If we would accept a blog post from the university itself (which would be self-published, primary, and non-independent) for the same kind of contents, then we should probably accept a master's thesis for it. A source only needs to be strong enough to support the weight of the claims it's cited for. If they're non-controversial (e.g., everyone agrees that there are some buildings on the campus), then the source doesn't have to be ideal. WhatamIdoing (talk) 21:53, 7 May 2024 (UTC)
- I believe that you are referring to WP:ABOUTSELF. My understanding of that is that we could cite the thesis for statements about the thesis and the author of the thesis, but not for statements about topics covered by the thesis. Donald Albury 22:33, 7 May 2024 (UTC)
- Not really. With the possible exception of contentious BLP matter, I think we should accept it for pretty much all non-controversial content. WhatamIdoing (talk) 22:50, 17 May 2024 (UTC)
- I believe that you are referring to WP:ABOUTSELF. My understanding of that is that we could cite the thesis for statements about the thesis and the author of the thesis, but not for statements about topics covered by the thesis. Donald Albury 22:33, 7 May 2024 (UTC)
- I agree that rigid exclusion of master's theses does not serve the project well. The language in WP:SCHOLARSHIP regarding Ph.D. dissertations would seem also to address many of the concerns above:
Some of them will have gone through a process of academic peer reviewing, of varying levels of rigor, but some will not. If possible, use theses that have been cited in the literature; supervised by recognized specialists in the field; or reviewed by independent parties.
(Of course, this issue would also be solved more efficiently by treating this guideline like a guideline to be applied flexibly in service of the mission rather than as a pseudo-policy that must be followed rigidly except in the most exceptional circumstances -- but that seems to be a bit too much to ask these days.) -- Visviva (talk) 04:12, 8 May 2024 (UTC) - I have come across some very high quality master's theses and agree that rigid exclusion of master's theses does not serve the project well. I had to work around this on Revolt of the Admirals and it was painful. In the case of my own master's thesis, it was thoroughly reviewed by two external examiners (as well as, of course, by my supervisor). It is available online and widely cited in the literature. The PhD was reviewed by three external reviewers, but is not as widely cited, and while also available online, I never got around to publishing it. Hawkeye7 (discuss) 04:47, 8 May 2024 (UTC)
- I agree that theses provide weak arguments for controversial points, as do other sources often accepted as reliable such as news articles or unreplicated one-off studies (I also think that there are many PhD dissertations that are questionable.) But, in writing research on historical topics, I these can be very useful and informative. They often provide a well-cited overview of a particularly esoteric topic that may not be the focus of a book or major study, which interested readers can read an analyze themselves. I like using them when they can be linked so readers can view them. As others have pointed out, At bare minimum, I'd like to be able to cite them even if they aren't standalone. (e.g., sometimes I can get the point cited by a book by a mainstream press, but it covers the topic in a sentence, whereas the dissertation gives the in-depth detail.) Wtfiv (talk) 20:47, 9 May 2024 (UTC)
- Theses are a mixed bag. Master's thesis even more so. I can say that mine went through a rigorous review process (I had a former president of the Canadian Association of Physicists as an external examiner on mine) as well as one other physics PhD, and had two physics PhD as my supervisors. The comments/feedback were substantive and relevant, and had to be addressed before acceptance.
- But go to a different department, in the same university, and the reviewing standards and requirements for a master's thesis are quite different. Headbomb {t · c · p · b} 21:34, 9 May 2024 (UTC)
- As Visviva said above, if people treat the guideline like a policy that "no masters theses can be cited for anything (or they can only be cited if lots of other people cite and repeat what they say, making it unnecessary to cite them), because we assume no masters thesis has ever been reviewed and made reliable; meanwhile, PhD theses are reliable because we're assuming every one has been reviewed by reviewers who know what they were doing", that's a problem (in fact, it's two problems separated by a semicolon). I think it would make more sense, as Visviva seems to be suggesting, to apply the same kinds of evaluative criteria as are supposed to be applied to PhD theses to both PhD and Masters theses, plus OP's suggestion that we don't use them to contradict a more reliable source; together with the fact that tighter sourcing requirements are already in effect for BLPs, medical topics, and various contentious topics, we'd in practice only cite masters theses when there was reason to think they were reliable for the uncontentious thing we were citing them for, e.g. the architecture of a particular university, which seems reasonable. (As WhatamIdoing said, if we'd accept a passing aside in blog post by the university as reliable for saying the buildings were neoclassical, it seems weird to reject a masters thesis all about the buildings being neoclassical.) Notability seems like a separate issue and it seems reasonable to say masters theses also don't impart much notability. -sche (talk) 00:48, 19 May 2024 (UTC)