Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 117.197.34.165 (talk) at 08:26, 15 June 2024. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

"WP:PROPOSE" redirects here. For proposing article deletion, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

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

Discussions are automatically archived after remaining inactive for nine days.


Add nowrap for para

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

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

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

Setting focus to the search box by default

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

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]

Non-free license template for thumbnails of online videos

Should an image copyright template be made for copyrighted online video thumbnails, presumably derived from those for non-free title cards and for non-free video screenshots. It would ideally be titled Template:Non-free video thumbnail. JohnCWiesenthal (talk) 03:48, 11 June 2024 (UTC)[reply]

Create a Wikipedia for Arbëresh language

Hi dear Wikipedians!

I am from Albania and I have a request. Can you consider to create a Wikipedia for Arbëresh language, an Indo-European language which belongs to the Albanian language family and is spoken in Italy, but this language is different from Albanian and isn't mutually intelligible with Standard Albanian. That's why I am requesting to someone who can contribute and make available a Wikipedia in Arbëresh language, in order to keep this language alive and for Arbëresh speakers, which are different from Albanian speakers, to have their own Wikipedia and to create and also edit articles on their own Wiki. Thanks SanoIsufi (talk) 10:13, 13 June 2024 (UTC)[reply]

I think you need to post at Meta and show how it is more useful than Gothic. Best of luck! ——Serial Number 54129 10:17, 13 June 2024 (UTC)[reply]
This is not something that editors on the English Wikipedia can help with. Requests for new languages need to be made on meta, specifically at m:Requests for new languages. However, before making a new request it is important that you first read the m:Language proposal policy and follow the instructions at m:Language committee/Handbook (requesters). Thryduulf (talk) 10:20, 13 June 2024 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=1229173457"