Wikipedia:Village pump (proposals): Difference between revisions

Browse history interactively

← Previous edit

Content deleted Content added

VisualWikitext

Inline

Latest revision as of 19:52, 6 June 2024

Table of contents
First discussion
End of page
New post

Shortcuts

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab).
Proposed policy changes belong at Village pump (policy).
Proposed speedy deletion criteria belong at Wikipedia talk:Criteria for speedy deletion.
Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
Proposed new wikis belong at meta:Proposals for new projects.
Proposed new articles belong at Wikipedia:Requested articles.
Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Wikipedia:Village pump (WMF).
Software changes which have consensus should be filed at Phabricator.

Discussions are automatically archived after remaining inactive for nine days.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Add nowrap for para[edit]

Wrong venue. Copied from the edit request at Template talk:Para#Add nowrap for para, which was rejected as "consensus required". April 2023 attempt to seek said consensus received no response. That system leaves a lot to be desired.

I used {{para}} and got a line break after the pipe character. This looked ridiculous and makes little sense. I assume other line breaks would be possible, such as after a hyphen in the parameter name. Adding {{nowrap}} or equivalent would make far more sense than requiring editors to code, e.g., {{nowrap|{{para|archive-url}}}}. While Note 2 below the table at "General-purpose formatting" speaks of nowrap options, I'm at a loss to see how they help my situation. In any event, I don't see how automatic, unconditional nowrap for all uses of {{para}} could be the slightest bit controversial. At the very least, an option could be added to suppress the default of nowrap for cases where horizontal space is limited, such as in tables.

See also Template talk:Para#no line-breaks in output, where a request for this was ignored (or never seen) 13 months ago. As to If the proposed edit might be controversial, discuss it on the protected page's talk page before using this template., well, we've seen how effective that was. ―Mandruss ☎ 21:53, 5 May 2024 (UTC)[reply]

It's unfortunate that the edit request was declined, when this seems like a fairly straightforward improvement and there seems to be a silent consensus to implement. I will plan to implement unless there are objections (courtesy pinging @Redrose64 as edit request responder). (Yes, coming here for this is a little POINTy, but the frustration at the edit request is understandable, and in any case let's not get bogged down by process concerns. Next time, though, I'd suggest replying to or talk page messaging the edit request responder.) Sdkb ^talk 22:05, 5 May 2024 (UTC)[reply]

Thanks. I did reply to Rose, with a ping, a mere four minutes after her rejection. When she hadn't replied after another 25 minutes, I surmised that she wasn't going to. Mea culpa: If I had checked her contribs, I would've seen that she hadn't made an edit after the rejection, so it's likely she left the site during those four minutes. Now self-flagellating for one hour. In any case, Rose doesn't change her mind much in my experience; she's that good.

I fail to see any POINTiness here; I'm just playing the cards I was dealt. ―Mandruss ☎ 22:22, 5 May 2024 (UTC)[reply]

I'm generally against adding nowrap, and would rather see it's use curtailed. It's causes endless formatting issues for those not using desktop screens, where the auto-formatter would do a better job. Nor do I see how not having 'para' wrap is an improvement, wrapping won't lead to any misunderstanding and may not even be wrapped on different screen aspects. -- LCU ActivelyDisinterested «@» °∆t° 01:46, 6 May 2024 (UTC)[reply]

From a usability standpoint, |archive-url= should all be on one line, not wrapped, because "archive-url" is a single concept (the parameter name) and should not be split in any way, despite the hyphen. I do not find broader ideological opposition to nowrap persuasive if it is applied reflexively to this circumstance without considering the particular situation here. I would find examples of instances in which parameters should be wrapped much more persuasive. Sdkb ^talk 02:36, 6 May 2024 (UTC)[reply]

It would be helpful to hear from TheDJ, who appears to have disabled nowrapping after it had been in place for about 11 years. – Jonesey95 (talk) 04:04, 6 May 2024 (UTC)[reply]

Yes. Applying nowrap to anything longer than a word is really bad practice and causes many issues for mobile, and situations where width is restricted. if you are going to apply it, apply it just to to the param= part, not to values (which can be giant urls) and definitely not to the entire line. A lot has changed in 11 years. —TheDJ (talk • contribs) 06:30, 6 May 2024 (UTC)[reply]

One of the problems here is that people give examples of common usages of this template. The problem is that those are NOT the only usages of the template. Even the doc page of the template itself has examples of pretty long values that basically form an entire sentence. Making an entire line not wrap is bad. Htm has to be flexible for many situations and if you set a very strict css option on a very generic template block that has very differing uses, you will run into problems like this. Solutions are to make the css more targeted (which in this case means being more strict about what the parameters can be, instead of just wrapping the template around a block of arbitrary text) or applying the css more targeted. |archive-url= for instance is ok.it just requires more thought by those writing the uses. —TheDJ (talk • contribs) 06:57, 6 May 2024 (UTC)[reply]

Applying it only to the param= part sounds reasonable. Sdkb ^talk 14:14, 6 May 2024 (UTC)[reply]

I'd be happy with that, provided it included the pipe character (that was the case that brought me here). ―Mandruss ☎ 16:29, 6 May 2024 (UTC)[reply]

@TheDJ: Looks like a limited-participation agreement, but I don't see any edit activity to the template. And this is due to fall off the page in three days. At the least, this comment will keep it for another nine. ―Mandruss ☎ 20:01, 12 May 2024 (UTC)[reply]

Keep for another nine days. ―Mandruss ☎ 20:48, 21 May 2024 (UTC)[reply]

Surely

|quote=Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

should be wrapped, although "|quote=" should not be. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:59, 28 May 2024 (UTC)[reply]

Support nowrapping the parameter-name, per Sdkb. The left side of param=value is a specific string of characters, not ordinary text, so it's best that it stays unified so it can be recognized or discussed correctly. DMacks (talk) 20:54, 21 May 2024 (UTC)[reply]
Support binding the leading pipe with the first alphanumeric string of the first argument passed to the template. I don't much care if |chapter-url-access= wraps on a hyphen, and certainly the "value" passed to the template should be able to wrap (think |title=Dictionary of Law, Containing Definitions of Terms and Phrases of American and English Jurisprudence, Ancient and Modern: Including the Principal Terms of International, Constitutional and Commercial Law; with a Collection of Legal Maxims and Numerous Select Titles from the Civil Law and Other Foreign Systems 1891), but it's disorienting to receive as output |
date=. Folly Mox (talk) 12:11, 31 May 2024 (UTC)[reply]
Redrose64 (as original declining admin), I count here five editors including myself supporting adding {{nowrap}} to the "parameter name" ($1) of {{para}}, with one editor neither supporting nor opposing that specific implementation, and all of us ~~expect possibly the OP~~ opposing nowrapping all arguments to {{para}}. Is that sufficient consensus for change? Folly Mox (talk) 12:29, 6 June 2024 (UTC) updated 13:39, 6 June 2024 (UTC) per below[reply]
OP (me) supports nowrapping the whole parameter name, including the pipe character, no matter how long the parameter name is. For longer parameter names at the ends of lines, we can waste a little space without costing me any sleep. OP does not support nowrapping the parameter value, if any. ―Mandruss ☎ 12:39, 6 June 2024 (UTC)[reply]
Support binding |1= from the leading pipe through the trailing equal. However, I oppose nowrap for |2=. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:16, 6 June 2024 (UTC)[reply]

Political userboxes (especially PIA)[edit]

The recent pages Wikipedia:Miscellany for deletion/User:AtikaAtikawa/Userboxes/Anti-israeli apartheid and Wikipedia:Miscellany for deletion/User:AtikaAtikawa/Userboxes/Antizionist have involved contentious discussion, where commenters have suggested deleting other PIA-related userboxes. Political userboxes in contentious areas, especially ones involving war and violence, have strong potential to antagonize other users and threaten Wikipedia's values of civility, collaboration and discussion. This may outweigh the value of users' political self-expression as Wikipedia is not a forum. In the case of PIA, userboxes open an avenue for unproductive controversy that does not improve PIA articles by users who are blocked from editing them by ECR. Do you believe that such controversial userboxes are a problem? If so, would you consider broader policy restrictions on userboxes that make politically controversial statements about PIA? Air on White (talk) 00:47, 27 May 2024 (UTC)[reply]

I think they may still have to be argued on a case by case basis. One problem may be that some box is "anti" or against something, rather than for something else. eg instead of anti-zionist, they could have said, the user wants only Arabs in Israel. Instead of Anti-israeli apartheid it could have said the user wants one joint Israeli-Palestinian state, and then been acceptable. So MFD probably has to consider the name and the content of each box. Graeme Bartlett (talk) 01:06, 27 May 2024 (UTC) edited Air on White (talk) 03:27, 27 May 2024 (UTC)[reply]

I agree that case-by-case evaluation makes sense, but I don't think that only positive statements will help. Remember the scandal about the editor who made a positive statement that he "respected" Hitler? Or the drama over the positive statement that the editor believed marriage should involve one man and one woman? "I positively affirm that I believe it would be best if your whole nation ceased existing" is not the kind of statement that builds up the community. It is the kind of statement that makes individuals feel excluded and rejected.

On the other hand, there are some statements that might be acceptable. The community would probably not object to more generic statements like "I'm anti-genocide" or "I support peace in the Middle East". WhatamIdoing (talk) 03:16, 27 May 2024 (UTC)[reply]

This has been discussed ad nauseam, and I'll say what I've been saying: using userspace to make politically charged statements violates WP:SOAPBOX, WP:NOTBLOG, and WP:UPNOT, and it calls into question whether an editor is capable of complying with WP:NPOV. Thebiguglyalien (talk) 01:59, 27 May 2024 (UTC)[reply]

Well the bias would be recorded on the userpage, and is disclosed, so NPOV has something to check. Undisclosed POV pushing could be worse. Graeme Bartlett (talk) 03:01, 27 May 2024 (UTC)[reply]

I agree that it gives us information about how biased an editor might be, but I still think it would hurt the community overall. We have to be able to work together. Sometimes that means not posting messages that you wish people would die, or that countries would fail. WhatamIdoing (talk) 03:18, 27 May 2024 (UTC)[reply]

(edit conflict)Agree with Graeme in that respect, there may be reasons to avoid userboxes taking clear positions on X and Y, but a userbox is, at most, a symptom of NPOV issues. CMD (talk) 03:19, 27 May 2024 (UTC)[reply]

My view, having spent years watching the ARBPIA topic area, is that this is easily resolved by not caring about PIA-related userboxes people put on their user page that no one needs to look at or spend any time thinking about (unless and until an editor does something ANI/AE-report worthy in terms of content editing or their interactions with other editors).

It could be argued that to care about them and draw attention to them can itself be 'unproductive and may antagonize other users and threaten Wikipedia's values of civility, collaboration and discussion' via something resembling the Streisand effect.
Or they can be viewed as a signal in all the noise, a useful public declaration of an editor's biases that may influence their editing.
If someone is deeply offended by an Israel flag on my page, or something about how great the IDF are, or my agreement with human rights organizations' assessments of Israel or Palestine, and such-like, I wonder why they are editing in the ARBPIA topic area. I wonder if they have read Wikipedia:Arbitration/Index/Palestine-Israel_articles#Editors_counselled and should do something else for a while.
The PIA topic area is blessed with a diverse set of editors/drive-by visitors ranging from infuriatingly dumb piece of shit fire-starter motherfuckers to very experienced and knowledgeable editors who (want/try to) focus on content. Those experienced editors all have biases that influence their content edits and talk page comments in various ways that can and do 'antagonize other users and threaten Wikipedia's values of civility, collaboration and discussion' on an almost daily basis. It's okay, the PIA topic area is not that brittle.
For interest (or not), many years ago I added some photos from an Israeli human rights organization to the top of my talk page, arranged in the form of a comic strip. It is deliberately ambiguous. I was interested in whether anyone would interpret them as 'politically charged statements that violate WP:SOAPBOX', because to do so they would have to use inference to decide whether they represented support or opposition to the removal of Palestinians from land in the West Bank by the IDF. No one has ever commented on them. No one cares, and for me, this is how it should be in ARBPIA.

Having opinions about how to socially engineer/nudge the ARBPIA topic area seems to be quite popular, but they are rarely evidence-based, and no one really understands the complicated dynamics and can predict the impact of rule changes and the ways they are interpreted/enforced on content and behavior. As I have said elsewhere, it's probably better to focus on enforcing the existing simple rules that cover PIA. Sean.hoyland (talk) 05:23, 27 May 2024 (UTC)[reply]

None of these boxes belong here at all. Including such things in a user box comes across as more "official" or site supported than the user just writing their views in their own words. While this site isn't a blog, having a user simply state their own biases so that others can tell that they are (or are not) someone you want to associate with is preferable to them slapping these things on their page giving the impression that Wikipedia endorses their position. Short version, we should do away with all user boxes.--User:Khajidha (talk) (contributions) 13:05, 28 May 2024 (UTC)[reply]

Deja vue. User:Donald Albury/The Great Userbox Wars Donald Albury 13:56, 28 May 2024 (UTC)[reply]

I've long thought that Userboxes expressing opinions on social/political issues should all go. I wish we had done it after the Pedophilia userbox wheel war of 2006 or any of the other userbox-related cases, but instead we just carved out very narrow exceptions. They're a pointless waste of far too much time, and don't really have a use in an online encyclopedia. I'd support any proposal that limits userboxes to those related to Wikipedia in some way. The Wordsmith^{Talk to me} 22:57, 29 May 2024 (UTC)[reply]

To clarify my position, I'd oppose a proposal to kill PIA-related userboxen. That just kicks the can down the road until the next big ethnic, religious, social or political conflict just like killing the pedophilia, anti-SSM, Hezbollah or pro-Russian userboxen did. The piecemeal approach isn't working, it just wastes more time with each flare-up and it does nothing to improve the encyclopedia. I'd support a proposal to remove all of them at once. The Wordsmith^{Talk to me} 18:13, 31 May 2024 (UTC)[reply]

I'd also support something like this. I'll note the Hezbollah one as particularly telling because it never got fully resolved. It was clear that some of the editors kept the same userbox endorsing Hezbollah's militant activity and reworded it in the hopes of creating plausible deniability. I tried to point this out last year, they shouted AGF, and nothing was done about it. None of this should matter because it's detrimental to the encyclopedia with minimal benefit—in my mind that should be the start and end of the discussion. Thebiguglyalien (talk) 20:24, 31 May 2024 (UTC)[reply]

I really don't like edgy politics shit in userboxes -- I consider it stupid and in poor taste regardless of whether I agree with it -- but I don't really know how we can put a stop to it without some kind of extremely broad dragnet apparatus that sweeps up all kinds of normal stuff. jp×g 🗯️ 04:05, 30 May 2024 (UTC)[reply]

In the real world, it has proven futile to use the law to ban expressions of dumb, distasteful opinions. It remains legal to say all kinds of obnoxious, provocative trash, and to print it on bumper stickers and T-shirts. Since it’s a big waste of time to try to legislate boundaries on this stuff, we generally deal with it through the use of quiet disdain. That is, rolling our eyes and shaking our heads, but ultimately moving swiftly on. Barnards.tar.gz (talk) 19:48, 31 May 2024 (UTC)[reply]

That's for governments, where these opinions directly affect how the government operates and there are real world implications that make restrictions on this conduct undesirable. Our situation is more analogous to a workspace, where making people feel unwelcome by bringing up controversial topics is absolutely something that's penalized. Thebiguglyalien (talk) 20:27, 31 May 2024 (UTC)[reply]

I'm sorry but I'm shocked that is discussion is categorized as "political" and that these userboxes are even debatable. Both userboxes mentioned support and advocate for violence against Israeli and Jewish people. What next? "Greater Germany" and "Heim ins Reich" userboxes? Gonnym (talk) 06:35, 30 May 2024 (UTC)[reply]

Hitler was a politician, and the Nazis were a political party, so yes, that would straightforwardly be a political issue -- political issues tend to be fairly serious and important, and millions of people die over them all the time. jp×g 🗯️ 06:54, 30 May 2024 (UTC)[reply]

"Both userboxes mentioned support and advocate for violence against Israeli and Jewish people." No they don't, neither one does any of that. Levivich (talk) 10:35, 30 May 2024 (UTC)[reply]

War and struggle over which people govern a piece of land is, by definition, an issue of geopolitics. That's political, and there's really no denying that. The Wordsmith^{Talk to me} 20:22, 30 May 2024 (UTC)[reply]

i don't generally comment here, but i saw it on the dashboard and thought i'd give my ~~brief~~ two cents. i have a single PIA-related userbox on my userpage, which says that apartheid is wrong, and another which advocates for an end to capitalism (nested among about 30 other userboxes unrelated to politics), so of course i'll be a little more generous to political userboxen than some above this comment. in my opinion, political (or otherwise controversial) userboxen are case-by-case. i find gratuitously or emphatically political userboxen usually kind of gauche, and highly provocative userboxen like the first one mentioned to be generally a bad idea, to say the least. however, i believe that self-expression on wikipedia userpages is a good thing to preserve, and i would probably oppose any kind of change to the P&Gs we currently have on this issue. we shouldn't, as some seem to say, expect that editors themselves must be neutral - No One Is Neutral, nor capable of being truly neutral. edits must be what's considered regarding NPOV. the matter here is one of disruption - i don't edit at all in the PIA area, so my userbox really has no indication on my views about the topics that i do edit about, some of which are contentious. for example, i edit articles related to the Caucasus region - if i had a "Georgia for Georgians" userbox with Abkhazia & South Ossetia erased from a map of Georgia, i couldn't blame anyone for assuming i was NOTHERE or a POV-pusher regarding Georgian topics. therefore, i keep my views on the various conflicts in the Caucasus private, as i want my editing in that area to be as explicitly NPOV and inscrutable as possible. i suggest a similarly nuanced approach for others working in contentious areas.

tl;dr - it's really all about context and disruptive potential in the areas an editor works in, rather than a hard-and-fast line. MfDs for particularly offensive or provocative userboxen are perfectly effective here. ... sawyer * he/they * talk 06:49, 31 May 2024 (UTC)[reply]

quick addendum: sean.hoyland i think says it best, regarding PIA specifically.
(edit: also, i'm unsubscribing from notifications for this and don't plan on replying or reading this thread further) ... sawyer * he/they * talk 06:58, 31 May 2024 (UTC)[reply]

Article name change - nuances in a bilingual context[edit]

Hello, I am not entirely sure if this belongs here, but I wanted to ask if I could change the title of the article 'CD Atlético Baleares' to 'CE Atlètic Balears'. This football (soccer) club is from Mallorca, Spain, where both Spanish (dominant language) and Catalan (original language) are spoken. I want to change the club name in the article from Spanish to Catalan because the majority of supporters uses the Catalan name and all bibliography about the club and its history always uses the Catalan name as well. On the other hand, the club's official name is only in Spanish. Still, I consider the Catalan name more appropriate and representative. Does anyone know what the policy on these topics is? Thanks in advance! Liamb723 (talk) 14:58, 31 May 2024 (UTC)[reply]

The relevant policy is WP:TITLE, which instructs us to choose titles based on what is most recognizable to English-speaking audiences, which in practice means following English-language RS's conventions. _signed,Rosguill ^talk 19:54, 31 May 2024 (UTC)[reply]

Setting focus to the search box by default[edit]

I would guess that most of the time one opens Wikipedia it's to search for something.

It would be so very much easier if, when the page is opened and after a search, focus could be set to the search box, and any content there be selected.

Please. AlStonyBridger (talk) 21:06, 1 June 2024 (UTC)[reply]

See the FAQ on WP:VPT. In short, WP will not be setting focus on the search box. DalsoLoonaOT12 (talk) 21:58, 1 June 2024 (UTC)[reply]

Text:

No, we will not use JavaScript to set focus on the search box.

This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.

DalsoLoonaOT12 (talk) 22:01, 1 June 2024 (UTC)[reply]

Random Article Feature Could Use Some More Work[edit]

I have come to observe that the random article function on wikipedia doesn't make use of the logged history of one's past searches e.g. A person who maybe predominantly searches and edits sports articles, biographies, scientific or whatsoever type of article, the random article that might be brought up could be something of a far different angle, e.g. medievial hisory, gothic architecture or even ancient people/languages. So I want to request if there could be a change to this, because sometimes I may want to edit an article, preferably stubs, on a topic that I'm interested in by using the random article feature and it brings out something else! So, I believe there could be a few needed adjustments here so that random articles will get the interest of the editor/reader by following the past pattern of the user's search history, and making the work done faster and more enjoyable. elias_fdafs (talk) 00:41, 3 June 2024 (UTC)[reply]

If it draws from a selection of articles based on what topics a given editor isn't contributing to, then it isn't very random, is it? Also, I'd have concerns about the feature automatically tracking and analyzing my contributions. Cremastra (talk) 00:54, 3 June 2024 (UTC)[reply]

Try Special:RandomInCategory instead. Folly Mox (talk) 01:07, 3 June 2024 (UTC)[reply]

And if that's more technical or specific than what you're looking for, you could try enabling the Newcomer Homepage (if you haven't already) select all tasks from the Suggested Edits pane, then choose a topic or topics you're interested in working on. Folly Mox (talk) 01:13, 3 June 2024 (UTC)[reply]

The problem with Special:RandomInCategory is that it doesn't know how to drill down through high-level cats. To use the examples here, Category:Sports, Category:People, and Category:Science are all useless for a RandomInCategory search. I tried a few experiments using Google's site: qualifier, i.e. site:en.wikipedia.org science. The results weren't terrible, but not as good as I would have hoped. RoySmith (talk) 15:15, 3 June 2024 (UTC)[reply]

You can try combining sort=random with articletopic: (like this) or with deepcat:, but deepcat: will fail for such large container categories as listed just above (it even fails against Category:Gothic architecture) due to the number of subcategories. Folly Mox (talk) 11:38, 5 June 2024 (UTC)[reply]

Some of the WikiProject categories might actually be more suitable for the OP's task than the content categories. (The discussion shows that this is one of the disadvantages of the "tree" model for categories as opposed to the "tag" model). —Kusma (talk) 11:51, 5 June 2024 (UTC)[reply]