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 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 15:43, 29 March 2024 (UTC)

1. OpenStreetMaps presents the least but most important metadata at each level of zoom.
2. The ability of zooming is only provided by OpenStreetMaps
3. If any change occurs for the river, for example the path changes, this is rapidly applied for OpenStreetMaps
4. language of metadata changes automatically for each Wikipedia
5. and many others. Just let me some time to write them.
6. 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)

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:

OpenStreetMap

which yields: (here we hide topological and show OpenStreetMap, but the reverse can be applied)

Seine
The Seine in Paris
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)reply

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)reply

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)reply

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)reply

@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)reply

I'll revert on these pages for now, thank you for the elaboration. Remsense诉 16:35, 29 March 2024 (UTC)reply

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)reply

@SamuelRiv I made a discussion for that here. Thanks, Hooman Mallahzadeh (talk) 16:51, 29 March 2024 (UTC)reply

@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, ~ Lindsay^Hello 20:26, 29 March 2024 (UTC)reply

Proposal 1: Render both; prefer OSM; hide othersedit

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)reply

Agree with proposal 1 re OSMedit

1. Agree Hooman Mallahzadeh (talk) 16:23, 29 March 2024 (UTC)reply
2. 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)reply

   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)reply

3. 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)reply

Disagree with proposal 1 re OSMedit

1.  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)reply
2.  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)reply

   @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)reply

   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)reply

3.  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)reply

   When I disable JS in my browser, the maps above still render with the lines indicating the rivers' courses. They do miss the ability to click to see a larger interactive version, but they're not useless. Anomie⚔ 13:22, 31 March 2024 (UTC)reply

4. OSM map is much less informative for the topic of rivers. CMD (talk) 06:17, 7 April 2024 (UTC)reply

   @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)reply

   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)reply

   @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)reply

   I agree it's a potential solution. But we should judge the solution on a case by case basis, rather than making a swap across an entire class of articles now. Remsense诉 07:22, 7 April 2024 (UTC)reply

   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)reply

5. 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, being 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, ~ Lindsay^Hello 07:42, 7 April 2024 (UTC)reply

   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)reply

   @Remsense See French Wikipedia at this page https://fr.wikipedia.org?pojem=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)reply

   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, ~ Lindsay^Hello 13:19, 7 April 2024 (UTC)reply

   @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)reply

   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, ~ Lindsay^Hello 13:19, 7 April 2024 (UTC)reply

   @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)reply

   My point is that this aphorism has exhausted its usefulness, and that this should be decided case by case, not as a class. Remsense诉 14:28, 7 April 2024 (UTC)reply

   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)reply

   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)reply

   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)reply

6. OSM clearly doesn't include the relevant topographic information. Aaron Liu (talk) 15:57, 29 April 2024 (UTC)reply
7. 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)reply

   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)reply

   Well it has been vandalised and it seems not possible to fix. Traumnovelle (talk) 15:43, 12 May 2024 (UTC)reply

   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)reply

   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)reply

Neutraledit

1. 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)reply

• Please see WP:NOTVOTE. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:26, 29 March 2024 (UTC)reply

• Yeah, that isn't how policy decisions are made. AndyTheGrump (talk) 21:32, 29 March 2024 (UTC)reply

• 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)reply

Proposal 2: Include both (OSM and topographic maps) when appropriateedit

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)reply

@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)reply

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)reply

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)reply

@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:

The simplest and most abstract map is the preferred one for Infobox of articles

Hooman Mallahzadeh (talk) 17:56, 30 March 2024 (UTC)reply

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)reply

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)reply

Proposal 3: Selection of varous types of "topographical maps" as background for OSMedit

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)reply

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)reply

@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)reply

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)reply

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)reply

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)reply

@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)reply

...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)reply

Closing timeedit

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)reply

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:

1. Readable for texts
2. Less detail with most important data

and some other aspects. Hooman Mallahzadeh (talk) 12:08, 12 May 2024 (UTC)reply

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)reply

For clarity, was any of that intended for me? Remsense诉 15:00, 12 May 2024 (UTC)reply

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)reply

More like a consensus to not to change anything, but the effect is the same. Remsense诉 15:21, 12 May 2024 (UTC)reply

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)reply

Consensus contradicts you. Cremastra (talk) 15:26, 12 May 2024 (UTC)reply

@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)reply

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)reply

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)reply

And your opinion is that some better way exists, other have disagreed with that opinion. -- LCU ActivelyDisinterested «@» °∆t° 17:14, 12 May 2024 (UTC)reply

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)reply

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...we 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, ~ Lindsay^Hello 17:42, 12 May 2024 (UTC)reply

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)reply

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)reply

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)reply

Problem of vandalismedit

@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)reply

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)reply

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)reply

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)reply

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)reply

Hooman Mallahzadeh, do you have a conflict of interest with Open Street Maps? Cremastra (talk) 17:46, 12 May 2024 (UTC)reply

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)reply

Note: Notification of this discussion was left at Wikipedia talk:In the news.—Bagumba (talk) 12:00, 10 April 2024 (UTC)reply

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)reply

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)reply

Note The blurb currently reads A total solar eclipse appears across parts of North America2—Bagumba (talk) 12:33, 10 April 2024 (UTC)reply

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)reply

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)reply

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)reply

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)reply

Support per nom, see no reason to oppose. Aaron Liu (talk) 13:19, 10 April 2024 (UTC)reply

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)reply

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)reply

@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)reply

Support, though I find isaacl's alternative of including a time frame intriguing. Aaron Liu (talk) 17:11, 10 April 2024 (UTC)reply

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)reply

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)reply

"Is elected" is present tense, specifically present perfect. "Elects" is also present tense, simple present. Levivich (talk) 18:14, 10 April 2024 (UTC)reply

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)reply

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)reply

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)reply

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)reply

I'll have what you're having. InedibleHulk (talk) 22:30, 11 April 2024 (UTC)reply

• Decide case-by-case: we can safely IAR in most cases. Cremastra (talk) 19:43, 10 April 2024 (UTC)reply
• 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)reply
• 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 _words^deeds 22:00, 10 April 2024 (UTC)reply

  Again, it is confusing to say that the solar eclipse is in the sky. Aaron Liu (talk) 22:05, 10 April 2024 (UTC)reply

  It would be confusing to switch from "is....was....did....has" in a single box on a typical ITN week. doktorb _words^deeds 22:28, 10 April 2024 (UTC)reply

  A typical ITN week does not have many blurbs that really need the past tense like the solar eclipse. Aaron Liu (talk) 02:37, 11 April 2024 (UTC)reply

• 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)reply
• 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)reply

  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)reply

  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)reply

• Keep present tense as general recommendation per above. Discuss individual cases when this is too jarring. —Kusma (talk) 07:43, 11 April 2024 (UTC)reply
• 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)reply
• 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)reply
• 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)reply

  How? The present tense rule was always written down there and this proposal does not make ITN a guideline. Aaron Liu (talk) 19:42, 11 April 2024 (UTC)reply

• 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)reply

  @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)reply

  @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)reply

  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)reply

  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)reply

• 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)reply
• 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)reply
• How about, "is seen over North America" -- passive with present tense and past participle, anyone? :) Alanscottwalker (talk) 21:49, 11 April 2024 (UTC)reply

  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)reply

  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)reply

  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)reply

  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)reply

  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)reply

  I was illustrating why the passive voice doesn't deserve to be demonized. Aaron Liu (talk) 21:42, 12 April 2024 (UTC)reply

  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)reply

  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)reply

• 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)reply
• 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)reply

  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)reply

  @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)reply

• 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.

  "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."

  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)reply

  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)reply

  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)reply

  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)reply

  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)reply

  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)reply

  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)reply

  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)reply

  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)reply

  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)reply

• 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)reply

  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)reply

  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)reply

• 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)reply
• 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)reply
• 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)reply
• 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)reply

  None of these except the 2020 one can be mistaken as things that are currently happening. Aaron Liu (talk) 22:20, 19 April 2024 (UTC)reply

• 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)reply

  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)reply

  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)reply

  For consistency and compactness. Aaron Liu (talk) 02:51, 20 April 2024 (UTC)reply

  The amount of compactness is usually one character – the difference between is and was, or elects and elected. In other cases, it's the same or shorter: shook instead of shakes for earthquakes, died instead of dies 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)reply

  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)reply

• 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)reply
• 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)reply

  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)reply

• 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)reply

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)reply

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)reply

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)reply

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)reply

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)reply

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)reply

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)reply

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)reply

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)reply

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)reply

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)reply

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)reply

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)reply

• 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)reply

  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)reply

  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)reply

  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)reply

• 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)reply
• 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)reply

  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)reply

  ITN is part of the main page. Clovermoss🍀 (talk) 15:51, 29 April 2024 (UTC)reply

  I think what Modest is getting at is that "on the main page" is too general and may be misinterpreted to be about the entire main page. However, I don't think we should change the section header this far into the discussion either. Aaron Liu (talk) 15:52, 29 April 2024 (UTC)reply

• 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)reply
• 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)reply

  "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)reply

  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)reply

  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)reply

  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)reply

  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)reply

  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)reply

  This does make sense to me. Clovermoss🍀 (talk) 12:51, 14 May 2024 (UTC)reply

• 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)reply
• 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)reply

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)reply

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)reply

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)reply

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)reply

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)reply

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)reply

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)reply

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)reply

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)reply

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)reply

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)reply

Ok… then let’s continue to discuss and form a NEW consensus on whether these links are appropriate or not. Blueboar (talk) 21:19, 30 April 2024 (UTC)reply

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)reply

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  d"

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)reply

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)reply

Question for those who think Wikidata is usefuledit

• 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)reply

My impression is it is like a catalogue for data on subjects. Alanscottwalker (talk) 16:20, 3 May 2024 (UTC)reply

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)reply

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)reply

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)reply

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)reply

Commons does not host article unless I am mistaken. Horse Eye's Back (talk) 20:39, 3 May 2024 (UTC)reply

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)reply

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)reply

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)reply

@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)reply

That's a stub article, & doesn't answer the question: what's the point? Johnbod (talk) 17:16, 3 May 2024 (UTC)reply

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)reply

Without looking at the statistics (meaning I might be wrong) a majority of Wikidata administrators who list English as their mothertongue are also English Wikipedia administrators. Ymblanter (talk) 18:08, 3 May 2024 (UTC)reply

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)reply

Exactly, using Wikipedia it would be extremely hard work (if not impossible) to find the answer to something like: "What is the oldest bronze statue in London over 3 metres tall?" But that's trivial on Wikidata (assuming the data has been added). Thryduulf (talk) 17:43, 3 May 2024 (UTC)reply

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)reply

https://www.mediawiki.org?pojem=Structured_Data_Across_Wikimedia Well intentioned at least. Selfstudier (talk) 17:43, 3 May 2024 (UTC)reply

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)reply

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)reply

Ah… so the primary purpose is to aid machines? (Not meant as snark). Blueboar (talk) 20:47, 3 May 2024 (UTC)reply

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)reply

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)reply

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)reply

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)reply

A central repository of what? Blueboar (talk) 20:48, 3 May 2024 (UTC)reply

Data. Curbon7 (talk) 20:54, 3 May 2024 (UTC)reply

What data? All data? Specific data? Data for the sake of collecting data? Blueboar (talk) 21:08, 3 May 2024 (UTC)reply

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)reply

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)reply

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)reply

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)reply

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)reply

@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)reply

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)reply

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)reply

@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)reply

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)reply

"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)reply

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)reply

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)reply

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)reply

• 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)reply

  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)reply

  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. — Usedtobecool ☎️ 07:35, 5 May 2024 (UTC)reply

• 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)reply
• 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)reply

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)reply

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)reply

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)reply

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)reply

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)reply

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)reply

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)reply

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)reply

Nothing new is generated when you copy something verbatim. Traumnovelle (talk) 08:43, 12 May 2024 (UTC)reply

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)reply

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)reply

You wrote a lot but none of it actually addresses what I've said. Traumnovelle (talk) 15:33, 12 May 2024 (UTC)reply

I gave examples of new creative works that have copied past work verbatim. isaacl (talk) 04:11, 13 May 2024 (UTC)reply

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)reply

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)reply

If it's clearly noted as an excerpt (and not just a reference) I wouldn't feel able to say that. However like I've said above, the number of cases where this would be the best option editorially is vanishingly few for an excerpt of that length. Remsense诉 05:22, 8 May 2024 (UTC)reply

(As such, I've explicated the attribution in the footnote itself, not just the list of works.) Remsense诉 05:37, 8 May 2024 (UTC)reply

• 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)reply

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)reply

But the article does (and did) specifically state that it was written by someone else. Phil Bridger (talk) 21:31, 8 May 2024 (UTC)reply

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)reply

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)reply

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)reply

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)reply

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)reply

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)reply Zdroj:https://en.wikipedia.org?pojem=Special:NewSection/Wikipedia:Village_pump_(policy)
Text je dostupný za podmienok Creative Commons Attribution/Share-Alike License 3.0 Unported; prípadne za ďalších podmienok. Podrobnejšie informácie nájdete na stránke Podmienky použitia.

---