Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Kirill Shrayber (talk | contribs) at 18:06, 30 June 2024 (→City Vector Maps in SVG format: Reply). 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]

Keep for another nine days. ―Mandruss ☎ 12:11, 15 June 2024 (UTC)[reply]

Keep for another nine days. ―Mandruss ☎ 18:40, 26 June 2024 (UTC)[reply]

I think consensus has been generated here, although of course I'm involved. Maybe it would make more sense to rerequest the edit at Template talk:Para with a link to this thread, rather than continuing to bump the thread every week and a half to prevent archiving. Folly Mox (talk) 11:31, 27 June 2024 (UTC)[reply]
NOTBURO. I think the appropriate party(s) is/are aware of this thread. ―Mandruss ☎ 14:09, 27 June 2024 (UTC)[reply]
That doesn't mean that they're watching this thread. WhatamIdoing (talk) 22:58, 27 June 2024 (UTC)[reply]

Mechanism for requesting a neutral facillitator for RfCs

A mechanism where editors sign up to do this role and get selected/pinged randomly by a bot to make an RfC where the involved editors feel they wouldn't be able to be neutral or facilitate discussion and target common ground. The botched RfC I've done at Talk:United States is what propels me to ask for this, I'm too passionate about it and can't find neutrality/respectful constructive discussion. I'm sure this issue is commonplace and I think this would be a good solution, similar to 3O. Alexanderkowal (talk) 11:59, 16 June 2024 (UTC)[reply]

It's certainly true that there are a lot of RfCs that waste a lot of time or affect results with the way they're initially presented, so there could be something here. We could create a 3O for RfC development, but I'm not sure how often it would be used and I'm not sure how many people there are who loves developing RfCs on topics they have no interest in and would actually be good at doing so. At the end of the day, I think what could be accomplished through such a process could probably get just as much pre-RfC buy-in from just using the talk page to workshop it first. Then if people object to your framing, well they shouldn't helped you to write it. — Rhododendrites talk \\ 13:21, 16 June 2024 (UTC)[reply]
yeah that might be a better idea, start a topic about workshopping the rfc. If people agree, that might make a good section at WP:RfC Alexanderkowal (talk) 14:59, 16 June 2024 (UTC)[reply]
A proper RFCbefore, equivalent to workshopping, usually leads to a decent RFC, or it should. Selfstudier (talk) 15:16, 16 June 2024 (UTC)[reply]
I just think the role @BilledMammal is currently doing at Talk:Kerma kingdom#Requested move 9 June 2024 is so important and necessary for rfcs Alexanderkowal (talk) 20:57, 16 June 2024 (UTC)[reply]
@Alexanderkowal Intermittently I have been trying to play a role of discussion facilitator for an example at Talk:Jinn. IMO Probably three type of experienced users can play such role WP:3O volunteers, WP:DRN moderators and substantial experience in RfC closing. Bookku (talk) 07:28, 21 June 2024 (UTC)[reply]
Specially new users are interested in starting RfC and they do not know ins and out, facilitators can be good help. Bookku (talk) 07:31, 21 June 2024 (UTC)[reply]
That’s great, I suppose WP:DRN does this role well. Maybe at WP:RFC have a sentence saying “If there is minimal collaboration and you feel you can’t be neutral when designing the RfC, go to WP:DRN” Alexanderkowal (talk) 09:23, 21 June 2024 (UTC)[reply]
I would support that,
Yeah I think it’d reduce the chance of malformed RfCs and address wasting editors time Alexanderkowal (talk) 09:42, 21 June 2024 (UTC)[reply]
In this latest example one new user went on to begin RfC on their own with personalized complaint. As a discussion facilitator I added a neutrally worded question. Discussion facilitators can have a role. Bookku (talk) 08:42, 21 June 2024 (UTC)[reply]
I have seen Robert McClenon play this role at WP:DRN a few times. When filing a DRN case, you fill in a field asking "How do you think we can help resolve the dispute?". It would be reasonable to say "I would like the dispute participants and the moderator to work together to craft a brief, neutral statement and start an RfC." Firefangledfeathers (talk / contribs) 12:19, 21 June 2024 (UTC)[reply]
What would happen if the other involved editors say this would be a waste of time, meaning the rfc is unlikely to be made neutral? Alexanderkowal (talk) 12:23, 21 June 2024 (UTC)[reply]
I am ready to perform this role again when requested. If the other editors do not want to participate, then I will consider whether I can write a neutral RFC based on working with one participant. It takes a minimum of one involved editor and a facilitator. Mediation requires that the principal involved editors be willing to work with the mediator, but facilitation can be done by the facilitator and one involved editor. It is true that one disruptive editor can gum up the process, but one disruptive editor can gum up many processes, and that is what topic-bans are for. It is also true that one really disruptive editor can ignore a topic-ban and break things, but, unfortunately, that is what indefinite blocks are for. Robert McClenon (talk) 13:12, 21 June 2024 (UTC)[reply]
yeah I'd be happy to help out at WP:DRN once I'm more familiar with policy and done the training, it sounds like a good role Alexanderkowal (talk) 13:18, 21 June 2024 (UTC)[reply]
Wikipedia:Requests for comment#Creating an RfC says:
If you need help writing an RFC question, whether it's because you feel you won't write it neutrally or for any other reason, just ask for help at WT:RFC. We're mostly even nice folks over there, and between us, we have many decades of experience with the RFC process. WhatamIdoing (talk) 23:01, 27 June 2024 (UTC)[reply]

Mention drafts after redirects

I propose showing a notice similar to {{Draft at}} to visitors who are being redirected from an article that has a draft, as such: "(Redirected from X; there is a draft at Y)" This proposal was previously added as an idea here, where another editor commented it could technically work and would be useful to have. --Talky Muser (talk) 05:43, 22 June 2024 (UTC)[reply]

Interesting idea! I'd definitely support having this be an optional option for experienced editors, who might have an interest in improving the draft. I'm a little more wary of showing it to readers, given that they may not understand what draftspace means and how article there may be unvetted. (If we design a notice to appear on all draftspace pages, that could alleviate that issue.) Cheers, Sdkb talk 14:54, 22 June 2024 (UTC)[reply]
{{R with possibilities}} already does this when viewing the redirect - automatically if the draft's at the same title, or with the (undocumented) draft parameter if not. It shouldn't be shown on the redirected-to article, for all the same reasons that articles shouldn't link to draftspace. —Cryptic 20:23, 24 June 2024 (UTC)[reply]
I'd agree with Cryptic that this shouldn't appear on the article the reader is pointed to, as drafts are not checked for their content like articles are, and things that would never be kept in the reader-facing mainspace are tolerated in drafts. However, I would definitely support this being an option for experienced editors that can be enabled in user preferences (here, the criterion for "experienced editor" only being "knowing that Special:Preferences exists"). Chaotic Enby (talk · contribs) 02:40, 27 June 2024 (UTC)[reply]

City Vector Maps in SVG format

I invite the community to consider the following question: Do articles about cities need vector maps of cities in SVG format - editable, with a full CC-0 license, for free use in any media, publications, presentations, projects, etc.

Let me explain. I have been designing vector maps for many years. Now I have the opportunity to provide a large number of my city maps in SVG format.

I am sure that a map of streets and roads of a city is the main and most necessary content in Wiki articles about cities. In most cases - in articles about cities - there are no such maps. I tried to publish some of my maps in Wiki articles.

And I was extremely surprised that my maps were immediately removed. Reasons for deletion - some users did not like my nickname, some - my user page (and what is written there) - they considered it advertising, some - generally claim that city maps in articles about cities are not needed at all (most users) - and I’m sure that all these claims are unfounded and constitute a form of vandalism. Discuss. and all the arguments of the parties can be read HERE: https://en.wikipedia.org/wiki/User_talk:Vectormapper#Maps_and_promotion

LIST OF THE FREE CITY MAPS in SVG EDITABLE CC-0

[[1]] [[2]] [[3]] [[4]] [[5]] [[6]] [[7]] [[8]] [[9]] [[10]] [[11]] [[12]] [[13]] [[14]] [[15]] [[16]] [[17]] [[18]] [[19]] [[20]] [[21]] [[22]] [[23]] [[24]] [[25]] [[26]] [[27]] [[28]] [[29]] [[30]] [[31]] [[32]] [[33]] [[34]] [[35]] [[36]] [[37]] [[38]] [[39]] [[40]] [[41]] [[42]] [[43]] [[44]] [[45]] [[46]] [[47]] [[48]] [[49]] [[50]] [[51]] [[52]] [[53]] [[54]] [[55]] [[56]] [[57]] [[58]] [[59]] [[60]] [[61]] [[62]] [[63]] [[64]] [[65]] [[66]] [[67]] [[68]] [[69]] [[70]] [[71]] [[72]] [[73]] [[74]] [[75]] [[76]] [[77]] [[78]] [[79]] [[80]] [[81]] [[82]] [[83]] [[84]] [[85]] [[86]] [[87]] [[88]] [[89]] [[90]] [[91]] [[92]] [[93]] [[94]] [[95]] [[96]] [[97]] [[98]] [[99]] [[100]] [[101]] [[102]] [[103]] [[104]] [[105]] [[106]] [[107]] [[108]] [[109]] [[110]] [[111]] [[112]] [[113]] [[114]] [[115]] [[116]] [[117]] [[118]] [[119]] [[120]] [[121]] [[122]] [[123]] [[124]] [[125]] [[126]] [[127]] [[128]] [[129]] [[130]] [[131]] [[132]] [[133]] [[134]] [[135]] [[136]] [[137]] [[138]] [[139]] [[140]] [[141]] [[142]] [[143]] [[144]] [[145]] [[146]] [[147]] [[148]] [[149]] [[150]] [[151]] [[152]] [[153]] [[154]] [[155]] [[156]] [[157]] [[158]] [[159]] [[160]] [[161]] [[162]] Vectormapper (talk) 01:07, 27 June 2024 (UTC)[reply]

Where was the data for these maps obtained? AndyTheGrump (talk) 02:15, 27 June 2024 (UTC)[reply]
My family has been involved in cartography since the 17th century. I have a huge archive of geodata. Personally, I have been designing maps for over 25 years. Much was drawn from satellite images. Vectormapper (talk) 02:43, 27 June 2024 (UTC)[reply]
This a fantastic body of work but I think unfortunately they are of limited use on Wikipedia, now that we have the Kartographer extension. – Joe (talk) 07:55, 27 June 2024 (UTC)[reply]
I know about this application - Kartographer. It is suitable for creating previews, but not suitable for creating maps in vector formats suitable for use in media. And of course, maps created in the Cartographer project cannot be edited in a regular graphical environment. That is, you can look at them, but actually cannot use them. Vectormapper (talk) 16:50, 27 June 2024 (UTC)[reply]
People come to Wikipedia to look at things. Wikimedia Commons is for those who edit. Many cities have so-called gallery pages there (like c:New York City), I think that's the best place to put your vector maps for people (professionals like you, I'm afraid) to reuse them. Ponor (talk) 03:11, 28 June 2024 (UTC)[reply]
And on the page you indicated (gallery c:New York City ) there is also no good map of New York City.
Compare what is there now and what I offer. FREE and unlimited use.
https://commons.wikimedia.org/wiki/File:New_York_City_Greater_NY_US_street_map.svg Vectormapper (talk) 03:26, 28 June 2024 (UTC)[reply]
That's why I said someone (YOU!) should add them there. I'd also suggest using the c:Template:Map on Commons, with coordinates added, like I did for the NYC map. That's needed for our {{Location map}} templates (examples: Category:New York (state) location map modules). Ponor (talk) 14:18, 28 June 2024 (UTC)[reply]
Well, I hope that my city maps will be used by others in the community - which I see already happening. And I'm very happy about it. Vectormapper (talk) 18:12, 28 June 2024 (UTC)[reply]
I'm not seeing why we should make an exception to either our image use policy (due to the in-image credits) or username policy (due to yours matching the website promoted in them). —Cryptic 08:27, 27 June 2024 (UTC)[reply]
Don't you find it strange that a username CANNOT DISPLAY HIS PROFESSION? For example, a COOK, or a MECHANIC, or an ENGINEER, OR a MUSICIAN? This is not a policy, this is a contrived restriction. And this is obviously wrong. If, for example, a COOK edits a page with methods for preparing jerboa meat in his own tears, then it would probably be correct if the user name is still a COOK, and not “CRUEL_TORMORER OF_JERBOAS” Vectormapper (talk) 16:54, 27 June 2024 (UTC)[reply]
You're very much allowed to have your profession in your username. You're not allowed to have a username be only the name of a company/organization/etc, or a position in a company/organization/etc, that would imply possible shared use and/or doesn't identify you as being a single person. "Cook" is extremely generic, but wouldn't really imply shared use as it doesn't make sense for an account to be shared between all cooks, but "Trade Union of the Cooks of Example-land" would imply potential shared use. Chaotic Enby (talk · contribs) 17:45, 27 June 2024 (UTC)[reply]
My company is registered in the USA, and the name is SOLICITY NAV LLC - there is not the slightest coincidence with the name of the company. Vectormapper (talk) 18:02, 27 June 2024 (UTC)[reply]
I admire your work, @Vectormapper, but at 300px these maps are just abstract paintings in yellow and green. I'd have them printed on A0, but zooming-in to see the labels and streets (and anything) is too painful on Wikipedia. Kartographer is much better suited for that. Ponor (talk) 11:59, 27 June 2024 (UTC)[reply]
Are you joking? These are vector files and can be scaled to any size. 300 pixels is a tiny preview. You can't see anything in this preview. Vectormapper (talk) 16:45, 27 June 2024 (UTC)[reply]
So they're good for printing, but not for online viewing. Labels (and streets, buildings...) are of a decent size only when the map is rendered at thousands of pixels, and to get there you need to click on your map (served as a ~300px bitmap in Wikipedia articles), click again, click again and click again, only so you'd get the pristine svg in the browser. And then moving around the map is a pain, at least for the users spoiled by non-static Google or OpenStreet maps. Ponor (talk) 03:03, 28 June 2024 (UTC)[reply]
Google maps and Open Street maps are good for viewing online, and are completely unacceptable if you need to edit the map, use it in media and presentations, and, of course, for printing at any scale. And it is no coincidence that Wiki articles use SVG files for many images - (schemes, district maps, state and district maps, as well as emblems, flags and coats of arms) - their authors thought that someone would use these images in their projects . And this is absolutely correct. Vectormapper (talk) 03:52, 28 June 2024 (UTC)[reply]
Not sure about that. I make them so they would look better at the scales used in Wikipedia articles, which is anywhere from 220px to 300px. What we see in articles is always a scaled-down bitmap version of an svg, never the svg itself. Readers will never get 20–40+ MB maps on their devices, even if WMF decides to switch to native SVG support. (after some manipulation, your NYC map just crashed my laptop browser!) Ponor (talk) 14:10, 28 June 2024 (UTC)[reply]
Well, first of all, there is a large amount of software for viewing and editing SVG files. In the maps of streets and roads I published, the amount of data is reduced as much as possible for large cities. But New York City is a big city. Nothing can be done about this. Vectormapper (talk) 18:10, 28 June 2024 (UTC)[reply]
@Vectormapper, may I suggest that you spend a while lurking at voy:en:Wikivoyage:Travellers' pub? The travel guide usually wants some SVG maps. WhatamIdoing (talk) 23:06, 27 June 2024 (UTC)[reply]
Thanks))) I do it))) Vectormapper (talk) 23:47, 27 June 2024 (UTC)[reply]
These are impressive maps, I suspect use on article will depend on individual discussion. One note is that given these are so specifically detailed, they should probably have a date (title or description) to note when their underlying data was obtained. Best, CMD (talk) 03:30, 28 June 2024 (UTC)[reply]
This is a valuable point. But in general, the date of creation of the map is on the file description page. In any case, they are all spring 2024. Vectormapper (talk) 03:44, 28 June 2024 (UTC)[reply]
Checking my city, I see the map is at least a year out of date. So some data used to construct it was old. So I suppose we need newer versions over time. But I think the idea is good. Graeme Bartlett (talk) 10:37, 30 June 2024 (UTC)[reply]
Just indicate the city you need. I will try to update the city map as quickly as possible. Vectormapper (talk) 18:06, 30 June 2024 (UTC)[reply]
https://commons.wikimedia.org/wiki/File:Charlottesville_Virginia_US_street_map.svg Vectormapper (talk) 21:34, 28 June 2024 (UTC)[reply]

Animations

Animations are very useful, but also distracting. As a matter of policy, the animations on Wikipedia pages should be set up so the reader can choose whether and when to run them. Running them automatically when the page is opened is not necessary or recommended, but if it is done, then there should be a simple way to stop (and restart) them. CCDobson (talk) 15:23, 29 June 2024 (UTC)[reply]

Tracked in Phabricator
Task T85838
@CCDobson, the problem isn't policy; most of us want that. The problem is technological. Doing this, and making it work for all the relevant file types in all the web browsers, is apparently complicated. I've linked one of the technical tasks on the side here, if you want to read a bit more about the considerations. WhatamIdoing (talk) 05:04, 30 June 2024 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=1231866594"