Policy | Technical | Proposals | Idea lab | Miscellaneous |
New ideas and proposals are discussed here. Before submitting:
|
« Older discussions, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130 |
Centralized discussion | |||
---|---|---|---|
![]() |
|||
Proposals: policy | other | Discussions | Ideas |
Note: inactive discussions, closed or not, should be archived.
|
|||
Contents
- 1 Personal "to-do" list
- 2 Searching for templates
- 3 New Village Pump page?
- 4 New accounts - initial notification
- 5 Towards a standard biography footer
- 6 Creation of redirects for titles with en-dashes
- 7 Suggested Changes to Wikipedia
- 8 Create a separate "BLP citation needed" template.
- 9 Category name syntax
- 10 Close down Possibly Unfree Files
- 11 Italics in names of spacecrafts vs. no italics in names of orbital launch vehicles (rockets)
- 12 Listen template
- 13 Bring back Esperanza!
- 14 Any thoughts on templates like this??
Personal "to-do" list
One thing I've repeatedly wanted has been a way to tag a page for some sort of follow up action. I've often come across a page needing some work, but without the time to immediately deal with the problem, and there's really not a good way (that I've found) to record that for the future. I'd like to propose the creation of a simple gadget that would add a button to the tools bar (the one with read/edit/history/etc), that would add a line to the end of a user page (perhaps user:username/todo), containing a link to the current article, a timestamp, and a comment. The (optional) comment would come from a dialog box (similar to how Twinkle Rollback AGF and many other tools do it). The line added might look like:
* [[article name]] 05:01, 18 February 2016 - some comment
Even nicer would be to generate a "delete" button on the "to-do" line, so that removing items would not require editing the page.
A button to take you to your to-do list if the gadget is enabled would be nice too. Rwessel (talk) 05:10, 18 February 2016 (UTC)
- People currently use template {{To do}}, which allows you to do this manually. The Quixotic Potato (talk) 10:06, 18 February 2016 (UTC)
- @Rwessel: I've managed to put together a simple userscript that does the basics of what you want: User:Evad37/todo. It adds a link to the interface (location can be customised) which, when clicked, opens a user subpage (can also be customised) in edit mode. A line like you specified above will be preloaded in the edit window, with the article name specified and
~~~~
(which becomes the time/date upon saving). You can then add in a comment and save the page. Obviously not as fancy as a Twinkle-style dialogue box, but it should still be easier than manually filling in a to-do list. - Evad37 [talk] 09:51, 21 February 2016 (UTC)
- @Rwessel: I've updated the script so it has the features you were asking for: optional comment from a dialogue box, remove items without editing the page, and a link to view your to-do list (next to the link to add something to the list). - Evad37 [talk] 06:29, 25 February 2016 (UTC)
Searching for templates
I realize this has been a Perennial Proposal, but is is quite frustrating when searching for the {{r}}
template to have to type template:r
into the search box, and searching for longer-named templates is maddening. Is there an existing alternative that I'm not finding?
I've honestly only skimmed the arguments for and against. While I see that using T:
as a prefix isn't workable, I'm wondering if TL:
would be? Anything that would shorten what's typed in the search box would be most helpful.
I also noticed a comment about setting the search box parameters to search all spaces, not just articles, and the comment said there was a setting in Preferences, but I can't locate it. The comment was from 2010, so I suppose things have changed.
Ah! I found the way to customize searches. Not intuitive at all, but helpful. Even so, if I check the "Template" box and choose to remember my choices, when I type r
into the search box, what I'm actually looking for is way down the list, but at least it's on the first page. Searching for pb
didn't fare nearly as well. Additionally, the "Remember my choices" box fails, sort of. Future searches don't include templates unless I click on the magnifying glass first to open the search page. I hate the extra step; if I've decided that the search box should search in a set of places, it should apply to just typing something in the box at the top of whatever page I'm on, please?
If nothing else, might it be possible to just type {{r}}
into the box?
Thanks!
—D'Ranged 1 | VTalk : 15:02, 26 February 2016 (UTC)
- This was previously discussed at Wikipedia:Village pump (proposals)/Archive 127#Prefix suggestion: TP: for Template:. Following that I made User:SiBr4/TemplateSearch.js, which by default allows "{{" and "TP:" as shortcuts for "Template:" but can be configured for any search shortcut. You can install that if you want. SiBr4 (talk) 16:13, 26 February 2016 (UTC)
- I scanned the discussions and didn't get to this solution. Thanks so much!
—D'Ranged 1 | VTalk : 17:06, 26 February 2016 (UTC)
- To use the double curly bracket, this change to my commom.js file is effective; do it to User:D'Ranged 1/commom.js, and you should be able to search for teplates that way. עוד מישהו Od Mishehu 06:06, 2 March 2016 (UTC)
- @D'Ranged 1: I use AutoHotKey so that it takes me only three keystrokes to type "Template:". See http://pigsonthewing.org.uk/using-autohotkey-macros-make-typing-life-easier/ for details. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:06, 3 March 2016 (UTC)
- Pigsonthewing, thanks for that, but I'm having issues with AHK not being persistent. Every time I want to use it, I have to reload the script file. It's a pain, so I've all but abandoned it, which is frustrating. It was a great tool when it worked and I can't seem to solve the problem at all.
- —D'Ranged 1 | VTalk : 06:43, 4 March 2016 (UTC)
- @D'Ranged 1: I use AutoHotKey so that it takes me only three keystrokes to type "Template:". See http://pigsonthewing.org.uk/using-autohotkey-macros-make-typing-life-easier/ for details. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:06, 3 March 2016 (UTC)
- To use the double curly bracket, this change to my commom.js file is effective; do it to User:D'Ranged 1/commom.js, and you should be able to search for teplates that way. עוד מישהו Od Mishehu 06:06, 2 March 2016 (UTC)
- I scanned the discussions and didn't get to this solution. Thanks so much!
—D'Ranged 1 | VTalk : 17:06, 26 February 2016 (UTC)
New Village Pump page?
I've been thinking for a while that it might be good to have a Village Pump page specifically to facilitate WMF-Community engagement. In particular I was just collaborating with one of the WMF teams drafting an RFC to get feedback from us on one of the projects they're working on. The only place to post it would be Village pump (miscellaneous). Meh. It's unclear how big the discussion would become, and I think it would be beneficial if this sort of thing were to become a common practice. Alsee (talk) 23:32, 2 March 2016 (UTC)
- There is definitely a perceived need for better WMF-Community engagement. Coupled with the lack of a proper forum, it seems to be channeled to Jimbo's talk page a lot. I hope there is a way to make engagement constructive; lately I've been disappointed by this. If there is a way to make the new Village Pump something that encourages constructive engagement instead of Foundation bashing, then I welcome it. One thing to consider though is that WMF works on a variety of areas (technical, legal, "vision" ... in short there is an inherent "miscellaneous" aspect to it). – Finnusertop (talk ⋅ contribs) 11:55, 3 March 2016 (UTC)
- Wouldn't there be a risk of that becoming a page for endless rants? How do you see it being useful? Praemonitus (talk) —Preceding undated comment added 20:04, 3 March 2016 (UTC)
- Praemonitus, I understand the concern about "rants". I've been one of the ranters myself. But I'm seeing real positive changes. Gather was agreeably uninstalled after our RFC requesting it. I just helped the WMF draft a request-for-feedback that is basically ready to go, where one of the opening lines is The WMF... does not want to push it on Wikis that do not want it. It also contains says they made a mistake not consulting us earlier. The project lead is very concerned to avoid any perception that they are "doubling down" to push something out. I'm trying to help the WMF figure out how to talk to us and engage us, the way we want. Alsee (talk) 08:03, 4 March 2016 (UTC)
- I just realized I didn't really address How do you see it being useful? I see the WMF posting new project ideas there, so we can comment before they start building stuff. They can post requests for feedback on things, and most significantly ask us if we want feature-X built or enabled. The WMF ran some feature-enablement RFCs semi-recently regarding Visual Editor on the proposals page. That would probably shift to the WMF page. And yeah, things like the recent RFC to disable Gather would probably move to the WMF page. To be honest I'm not fully sure how it would evolve, but I think it's a needed page. I believe it will help us build better WMF-Community relations. Alsee (talk) 08:16, 4 March 2016 (UTC)
- @Alsee: thank you for your contributions to the improvement of the communication between the Wikimedia Foundation and the communities. In the case of this proposal, I think the intention is correct, but the implementation might not be the best one. One example: what happens when a dozen more wikis decide to follow your steps, creating their own WMF Village Pumps? Can we stop them? Can we satisfy their expectations? Most probably not.
- The WMF plan is to have a product development process open to the participation of all communities. Resolving the communication equation is definitely not simple, but the solution probably needs to start with a centralized location with possibilities for translation and equipped with subscriptions to very specific news (e.g. "New project ideas", "Requests for design review", "Feedback on deployment plans"...), and cross-wiki notifications. This way any individual could subscribe to the types of review corresponding to their interests and skills, and they would receive the updates in their own wikis. All the pieces needed for this process already exist. If you want to join the discussion about product development process and communication channels, please check phab:T124288.--Qgil-WMF (talk) 21:03, 8 March 2016 (UTC)
- Qgil-WMF, thanks for your work on Community engagement and your comment here. I fully share your concerns about scalability to multiple wikis. I have longer term ideas where the Communities may help solve those problems for you. This needs to be tackled from both ends. Your plans for a WMF-Central location is a necessary step, but I believe it is also necessary to have a local page where we can build local processes to assist you. The WMF was nearly overwhelmed trying to handle the Media Viewer Community Consultation, the process and outcome were widely viewed as completely illegitimate and literally making the situation worse. Expecting even larger numbers of people showing up in countless languages, on a WMF ruled wiki, won't work. It's non-scalable and it completely misses the community's fundamental objection: limiting engagement to individuals in bulk, without acknowledging or respecting Communities and consensus.
- Regarding the proposal here, this is a community proposal for a community page where the WMF would be welcome to post. We now have a mixed WMF-response. If the WMF does not find it desirable post here, that is absolutely fine. I still believe the community will find it useful for various purposes. I have some other community-projects in the works that I believe will be valuable, and Village_Pump_(WMF) is absolutely the place for it. Alsee (talk) 01:22, 9 March 2016 (UTC)
- Alsee, indeed, local communities need to have own spaces to organize their participation as stakeholders in the product development process. How you organize yourselves, that is up to you. No matter what, we will continue reaching out for feedback and involvement.
- I just want to stress that this proposal raises higher expectations. We cannot expect that a discussion in en.wiki (or any local project) will decide whether a new project idea moves into development or is parked. Wikimedia communities should have the power to promote or stop new software projects, but in a place and under a process that is common to all the communities. When it comes to local deployments sure, that is a discussion to be handled locally. However, note that even then we need a centralized process to communicate decisions to the teams in charge of the deployments.--Qgil-WMF (talk) 11:41, 9 March 2016 (UTC)
I have drafted the page, but not linked it into the main Village Pump structure. See Wikipedia:Village pump (WMF). Alsee (talk) 11:22, 4 March 2016 (UTC)
- Wikidata has a similar page at d:WD:Contact the development team, which is a hybrid VPT/VPWMF, for the most part. It's very useful, but that may be because Wikidata as a technical project has refined project coordination. That said, most of the big proposals from the technical team which may need social buyin end up at the singular Village pump there, which we don't have here. --Izno (talk) 13:03, 4 March 2016 (UTC)
- Support great idea, fills a big need here. --Tom (LT) (talk) 08:45, 5 March 2016 (UTC)
- Worth trying in principle, although if it did become non-constructive as a venue it would have to be closed down. What do any staffers think? BethNaught (talk) 11:32, 7 March 2016 (UTC)
-
- BethNaught: "What do any staffers think?" - I'm not making any claim about the WMF as a whole, or that there has been widespread WMF comment on it, but I have gotten a clear positive response. A project manager said "I am excited to see your new village pump area, too!" and a liaison used the thanks feature on one of my posts in this section. Assuming no sudden opposition shows up, I plan to make the page live as soon as the WMF greenlights their first official post there. Alsee (talk) 16:25, 7 March 2016 (UTC)
- No. It should go to a WMF site. It's a distraction from English Wikipedia, here. Alanscottwalker (talk) 21:13, 8 March 2016 (UTC)
- Putting efforts for engagement on another wiki, where fewer people will see it, is counterproductive. Moreover if the issue at hand is restricted to enwiki, discussing it here makes eminent sense. BethNaught (talk) 21:18, 8 March 2016 (UTC)
- No it does not. We have four pumps already, English Wikipedia does not need yet another forum to argue over. Put a notice on the relevant pump, if you want to draw attention to a discussion on a sister WMF wiki, people will see it. Alanscottwalker (talk) 22:34, 8 March 2016 (UTC)
- Putting efforts for engagement on another wiki, where fewer people will see it, is counterproductive. Moreover if the issue at hand is restricted to enwiki, discussing it here makes eminent sense. BethNaught (talk) 21:18, 8 March 2016 (UTC)
Ping Risker: If/when the new page goes live, would you like to post your WMF Content Checklist there? The WMF was extremely enthusiastic about it. People could make sure it covers all the bases, and we can establish consensus backing. Alsee (talk) 01:31, 9 March 2016 (UTC)
- Just registering my support for this idea. I think it would be an advantage to have a centralized place for enWP to communicate with the WMF, and this might also help with establishing expectations on process (either formally or de facto). If there are any problems with disruption, we can decide to shut it down again. It might lead to some duplicate discussions, as mentioned above, but all the wikis are independent and make their decisions separately in any case. Sunrise (talk) 05:52, 9 March 2016 (UTC)
I agree that improved communication is necessary, but I have questions about adding this channel, Alsee. How do you envision this new VP working? Do you think it would best operate as a beacon to notify enwiki community of happenings over on Meta or MW in order to direct people to those channels (if they actually check or watch it), or is the expectation that this is an added channel for all staff to communicate in, taking away time from centralized and movement-wide venues such as Meta? Would it be a place for communities to discuss and then decide to bubble issues up to the WMF, or is the expectation that a staffer will be watching it at all times or even some of the time? Or is there another way it could function?
Getting feedback from all of the projects is already time-consuming when it's scattered across multiple venues, and I have doubts about adding this venue for that reason. It's understandable that when testing or launching a project (technical or otherwise) to a particular project, that the specific communities should be able to communicate with the WMF team working on that initiative, but trying to collate different opinions from different locations on a constant basis already takes a significant amount of staff energy that may be best used elsewhere. I'd love to see a solution that supports less channels, rather than more. Do you think there's a way that creating this VP might eventually achieve that goal? -Rdicerb (WMF) (talk) 19:20, 9 March 2016 (UTC)
- Ping Rdicerb (WMF), Qgil-WMF. I'll reply to both together, as you raise related concerns. I apologize if I created an impression of placing a burden on WMF staff. To the contrary, I am trying to build a less burdensome solution. Imagine this possible future: The WMF places ONE post on your central page. It could be brought to various community pages by the community, by a bot, or by some cross-wiki-transclusion(if available). The community could take responsibility for translating that one message. The community can fully apply our local processes to have our big messy discussions. The community then generates a summary result. The community translates that ONE summary back to English (if necessary), and it gets delivered to the WMF. That does scale, and it minimizes load on staff. If the WMF posts a new product idea to default all text to Comic Sans, the Community may return a Consensus Oppose. That would translate as "Go forward with the project if you like, but we are unlikely to support any deployment phase here". If you get conflicting responses from different communities, we'll work together on sorting that out reasonably. Alsee (talk) 21:26, 9 March 2016 (UTC)
- Thank you so much for clarifying, Alsee. I appreciate your intention FWIW :) It sounds like a bit of a project that would require some buy-in from different stakeholders (from staff around workflows to communities agreeing to create summaries), but it isn't impossible. I'm glad there's a little more clarification around how this would work.-Rdicerb (WMF) (talk) 22:24, 9 March 2016 (UTC)
- Rdicerb (WMF), generating discussion summaries is something we already do all the time. We call them Closes :) These would generally be more detailed than usual, and we would probably add a validation step before submitting them, but the importance would make it more rewarding than our usual work. It's all just a general concept. I was hoping we could take baby-steps trying to figure it out together, starting at EnWiki. (Shared language, with the largest and oldest community, makes this the natural place to start.) I helped the Reading team create a very-cautious request for feedback to post here. A toe-in-the-water test. The project manager seems enthusiastic to give it a try, I'm just waiting for the liaison to give the greenlight Alsee (talk) 00:53, 10 March 2016 (UTC)
- Alsee, yes, your description above fits the idea I have in mind. Feedback and help to design and implement that process are very welcome. However, a WMF Village Pump in en.wiki is not a hard requirement for such process. I keep being concerned about the expectation that a forum with "Wikimedia Foundation" / "WMF" in its title will arise, and this concern is shared by other WMF colleagues I have checked with. If en.wiki thinks a new Village Pump is needed, we the WMF have nothing to say about that. Just don't call it WMF anything, please.--Qgil-WMF (talk) 10:59, 10 March 2016 (UTC)
- Rdicerb (WMF), generating discussion summaries is something we already do all the time. We call them Closes :) These would generally be more detailed than usual, and we would probably add a validation step before submitting them, but the importance would make it more rewarding than our usual work. It's all just a general concept. I was hoping we could take baby-steps trying to figure it out together, starting at EnWiki. (Shared language, with the largest and oldest community, makes this the natural place to start.) I helped the Reading team create a very-cautious request for feedback to post here. A toe-in-the-water test. The project manager seems enthusiastic to give it a try, I'm just waiting for the liaison to give the greenlight Alsee (talk) 00:53, 10 March 2016 (UTC)
- Thank you so much for clarifying, Alsee. I appreciate your intention FWIW :) It sounds like a bit of a project that would require some buy-in from different stakeholders (from staff around workflows to communities agreeing to create summaries), but it isn't impossible. I'm glad there's a little more clarification around how this would work.-Rdicerb (WMF) (talk) 22:24, 9 March 2016 (UTC)
New accounts - initial notification
Some while ago it was decided [by whom?] that users opening new accounts should receive a notification when they register, giving a link to a welcome/help/guidance page.
Until recently that page was Wikipedia:Welcoming committee/Welcome to Wikipedia, but within the past 2 weeks or so it has changed to Help:Getting started. Question, who decides on these provisions? - where are changes announced or discussed? If we knew in advance we could ensure that the page to be linked was in the best condition to receive a greatly increased number of views from brand-new editors. Also, these editors, not yet autoconfirmed, find they can't edit the welcome page itself so some of them resort to making all sorts of strange comments on the talk page. The Wikipedia talk:Welcoming committee/Welcome to Wikipedia talk page was eventually redirected to the Teahouse - is this the best course and should Help talk:Getting started now be redirected similarly? In summary we could benefit from more of a dialogue over what is offered to new editors on signup: Noyster (talk), 00:56, 3 March 2016 (UTC)
-
- Thank you Krenair! Been able to track back now. The "Welcome" notification has been provided for several years, but only in November 2015 was a link added, to a welcome/help page to be selected by each wiki. This new feature wasn't announced in Technical News, and even an editor like Moxy so active in the welcoming area doesn't appear to have been in the loop. Anyhow the link is specified in MediaWiki:Notification-welcome-link, and at first Legoktm set it to the Welcoming committee page. In February after a discussion divided between here and here, on the suggestion of Quiddity the link was reset to the Help:Getting started page. I do think the use we make of this facility needs to be better publicised and discussed, and a coherent approach developed to the spate of test edits, "hello"'s, adverts and random comments that appear on the talk page of whatever page is linked. I suggest that the Welcoming committee, although not as active as it was, would be a suitable centre for updates and discussions on this feature: Noyster (talk), 11:26, 3 March 2016 (UTC)
- Erm, it was definitely in tech news: m:Tech/News/2015/47. I don't really have an opinion on where it should link, just that it should link *somewhere*. Legoktm (talk) 17:59, 3 March 2016 (UTC)
- Thank you Krenair! Been able to track back now. The "Welcome" notification has been provided for several years, but only in November 2015 was a link added, to a welcome/help page to be selected by each wiki. This new feature wasn't announced in Technical News, and even an editor like Moxy so active in the welcoming area doesn't appear to have been in the loop. Anyhow the link is specified in MediaWiki:Notification-welcome-link, and at first Legoktm set it to the Welcoming committee page. In February after a discussion divided between here and here, on the suggestion of Quiddity the link was reset to the Help:Getting started page. I do think the use we make of this facility needs to be better publicised and discussed, and a coherent approach developed to the spate of test edits, "hello"'s, adverts and random comments that appear on the talk page of whatever page is linked. I suggest that the Welcoming committee, although not as active as it was, would be a suitable centre for updates and discussions on this feature: Noyster (talk), 11:26, 3 March 2016 (UTC)
I am not sure how the links works ...but a redirect seem not to work....even if the page is redirected new editors seem to use the tlak page any ways somehow. -- Moxy (talk) 16:58, 3 March 2016 (UTC)
- The target for that page is controlled at MediaWiki talk:Notification-welcome-link. — xaosflux Talk 18:17, 6 March 2016 (UTC)
An article such as, for example, Kylie Minogue includes a number of common templates, each of which contain no parameters, as they draw their values from Wikidata:
{{Commons category}}
{{Wikiquote}}
* {{Official website}}
* {{IMDb name}}
{{Authority control}}
It would seem sensible to try to combine templates like these into a single template, say:
{{Biography footer}}
or, for specialist fields of endeavour, one of:
{{Musician footer}}
or
{{Cricketer footer}}
and so on. These could display (or not) the appropriate values and labels on a case-by-case basis. How might we move towards such a template? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:45, 3 March 2016 (UTC)
- Support - simplify the article page. The way to do it would be to look at the common footers based on occupation, and create the templates based on them. עוד מישהו Od Mishehu 15:44, 3 March 2016 (UTC)
- Comment, leaning oppose Most of those templates are problematical if added indiscriminately. {{Official website}} gives a big ugly red error if wikidata has no listing. {{Commons category}} and {{Wikiquote}} claim information is available and create links to potentially nonexistent pages. {{IMDb name}} generates a link to potentially nonsensical search results. It looks like the only one that can consistently be added {{Authority control}}. A unified template could be carefully used where all of the sub-templates happen to be valid, but any added convenience seems minor and I see a downside. It's more confusion and hassles when less familiar editors try to figure out what's going on, or potentially copy it inappropriately. If someone puts the unified template on an article but one of the items is invalid, it is a hassle and extremely non-obvious that they need to swap the unified template for the three correct subtemplates. Alsee (talk) 17:07, 3 March 2016 (UTC)
- The template could check for the existence of the appropriate Wikidata properties (see hu:Template:Filmlinkek for an example). – nyuszika7h (talk) 18:59, 3 March 2016 (UTC)
- For example, Latvian and Norwegian Wikipedia (OK, we (Latvians) simply copied from Norwegians :) ) has template sports external links, which adds some profiles (from Wikidata) to articles. --Edgars2007 (talk/contribs) 08:27, 4 March 2016 (UTC)
- The template could check for the existence of the appropriate Wikidata properties (see hu:Template:Filmlinkek for an example). – nyuszika7h (talk) 18:59, 3 March 2016 (UTC)
- Oppose As has been pointed out, very little upside and a huge downside. We have way too many biographical articles and of a very diverse nature; the proposal would only benefit a very small group of articles. Chris Troutman (talk) 15:46, 4 March 2016 (UTC)
- This isn't a vote, and in any case you appear to be opposing a proposal that I haven't made. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:32, 4 March 2016 (UTC)
- Umm, this is Village pump (proposals), which I guess escaped you since you claim not to be making a proposal. In any case, be honest and just say you don't appreciate my opinion rather than talk at me while not pointing to "!vote" to those who agree with you. I don't think we should be moving "towards such a template". Chris Troutman (talk) 20:54, 5 March 2016 (UTC)
- This isn't a vote, and in any case you appear to be opposing a proposal that I haven't made. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:32, 4 March 2016 (UTC)
- Oppose for now this particular implementation, but the underlying idea is viable per all of the above comments and replies. Right now, we need to add features to pages as they are required. The proposed template would not simplify anything because, as noted, the templates it would call are problematic when not needed or not used properly, so they can't be on by default, but having them off by default puts us in exactly the same position as having no template for this, since they won't be active on the pages that need them until someone manually enables them. The general idea of auto-generating sister-project links and such from Wikidata is a good one, because most users a) don't even know about these features, and b) would have a hard time figuring them out. The present state of things is just too half-baked to do this now. Maybe this could be done with custom code that doesn't throw errors, generate useless links, etc., instead of shelling out to extant templates that have these problems. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 17:49, 4 March 2016 (UTC)
- I don't know which "particular implementation" you think you're opposing, but I haven't proposed one; I asked a question. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:32, 4 March 2016 (UTC)
- There seems to be an inflexibility here. Consider
{{Commons category}}
- that is supposed to go at the top of the last section.{{Authority control}}
by contrast is towards the end of the last section - but before the categories and stubs. There are a number of items, not mentioned above, that should appear between these - such as the true external links (those not covered by templates like{{Official website}}
), succession boxes, and navboxes. It seems that a change to WP:FOOTERS would be necessary before a standardised template like{{Biography footer}}
is introduced, such change would permit the true external links, succession boxes and navboxes to go before the{{Commons category}}
, or after the{{Authority control}}
. I don't think that such change is likely. --Redrose64 (talk) 21:42, 4 March 2016 (UTC) - Great idea - and easily implementable; we already do something similar with infoboxes. I wonder if in future all articles will automatically have in-article links where other wikilinks exist - eg quotes, with wikidata, commons and so forth. @Pigsonthewing. I suggest move this discussion to village pump (ideas) if you don't want a heated support/oppose discussion. --Tom (LT) (talk) 08:53, 5 March 2016 (UTC)
- Oppose for now. This is clearly the direction we are headed and a welcome development, but the way Wikidata and Wikipedia work together isn't just ready yet. This would be a huge development and overwhelming consensus is needed on templates that are transcluded on such a large number of articles. Standardization like this seems to work best with things that are actual standards, i.e. library classifications in Authority control. – Finnusertop (talk ⋅ contribs) 21:20, 5 March 2016 (UTC)
- Maybe It's an interesting idea but I don't like the idea of variations such as {{Cricketer footer}} which will cause trouble when people have more than one possibility. And some people would like us to have the entire article generated by such an omnibus template, which would automatically "fill in the blanks" from Wikidata and other external repositories. We're not there yet. Andrew D. (talk) 08:37, 6 March 2016 (UTC)
- Support. Agree with Pigsonthewing and Od Mishehu. Good way to increase uniformity and ease of standardization through help from our sister project friends at Wikidata. — Cirt (talk) 16:09, 9 March 2016 (UTC)
Creation of redirects for titles with en-dashes
Proposal has been approved. (non-admin closure) — Jkudlick • t • c • s 13:42, 8 March 2016 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
It has been proposed that a bot create redirects for titles with en-dashes, from the corresponding title with hyphens. Please comment at Wikipedia:Bots/Requests for approval/AnomieBOT 74. Anomie⚔ 23:40, 3 March 2016 (UTC)
- The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Suggested Changes to Wikipedia
Everyone must get at least one warning before their first block. If a block is for an action specific to one type of article, then the block should not apply to other types of articles. Wikipedia needs to make its suggestion page easier to find. ----— Preceding unsigned comment added by 2601:2C1:C003:EF7A:4C87:C488:5851:C0EA (talk • contribs) 03:10, 4 March 2016
-
- 1) Pretty much everyone does get a warning before their first block, unless they're obviously a sockpuppet of a blocked user, or maybe if they're doing something they should know is outright illegal, or it's obvious that they created the account only to troll.
- 2) Too cumbersome to program and apply. We do have topic bans, which are similar, but require either community consensus or discretionary sanctions and kind of operate on the honor system (though they can be enforced by admins with blocks). Also, this would really belong as the technical village pump.
- 3) The village pump (which is the closest thing we have to a suggestion page) is linked in the Community Portal, found at the left hand side of the non-mobile version.
- Ian.thomson (talk) 03:39, 4 March 2016 (UTC)
- (1) Not a good idea, as many editors are not a human, but robots, that don't read warnings. I block several trouble-causing robots every day that are trying to promote something. For people that appear to be new here, we should warn them first and check that they have had time to see the warning before a block. But the purpose is to stop damage to Wikipedia, so the damage caused is balanced against the possibility of rehabilitation of the blockee. Graeme Bartlett (talk) 02:08, 5 March 2016 (UTC)
Create a separate "BLP citation needed" template.
We probably have millions of {{citation needed}} tags throughout the encyclopedia, but some citations are more urgent than others. When an otherwise well-cited BLP article has a possibly contentious statement added without a source, or when a non-BLP article has a possibly contentious statement about a living person added without a source, there should be a {{BLP citation needed}} tag to distinguish the urgency of adding a citation from that of an unsourced claim about a non-BLP topic. bd2412 T 12:26, 4 March 2016 (UTC)
- Oppose per WP:BLP, lead section, paragraph beginning "We must get the article right" and the Jimmy Wales quotes linked from that. --Redrose64 (talk) 12:38, 4 March 2016 (UTC)
- I see {{citation needed}} tags in BLPs all the time. You could go and remove all those uncited claims yourself - if there were only some way to tell which tags were for BLPs. bd2412 T 13:22, 4 March 2016 (UTC)
- Still backwards reasoning. The problem is that the questionable info should not have been tagged at all, but removed. Creating a custom tag to tag that which should not be tagged will just encourage more bad tagging, and serve to pseudo-legitimize it. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 17:56, 4 March 2016 (UTC)
- I see {{citation needed}} tags in BLPs all the time. You could go and remove all those uncited claims yourself - if there were only some way to tell which tags were for BLPs. bd2412 T 13:22, 4 March 2016 (UTC)
- Comment per WP:BLP, "Contentious material about living persons (or, in some cases, recently deceased) that is unsourced or poorly sourced – whether the material is negative, positive, neutral, or just questionable – should be removed immediately and without waiting for discussion." we shouldn't be adding {{citation needed}} tags to contentious material about a BLP. It should be removed immediately before any discussion happens. I see cn tags referring to info about BLPs but how often is that referring to contentious info? I don't know but the info should be removed until it is reliably sourced. -- GB fan 13:29, 4 March 2016 (UTC)
- Comment: We have Template:BLP sources and Template:BLP unsourced section and the category Category:BLP articles lacking sources. Generally speaking, inline maintenance templates correspond to the same problem as article/section wide. I'm at a loss as to why we can have the article/section wide but not the inline. – Finnusertop (talk ⋅ contribs) 13:44, 4 March 2016 (UTC)
- Oppose Contentious claims about living persons must be removed when they are unsourced and should be removed when they are poorly sourced. Period. Collect (talk) 13:47, 4 March 2016 (UTC)
- @Collect: I have struck "contentious" from the proposal accordingly. bd2412 T 13:49, 4 March 2016 (UTC)
- And, amazingly enough, when in doubt, the proper course is to remove unsourced claims from BLPs. No real need to add a new template for the few cases where it might be utile. Collect (talk) 13:51, 4 March 2016 (UTC)
- But right now you can tag the whole article as containing unreferenced statements with {{BLP sources}}. In order to do this, you necessarily have to find at least one unsourced statement. If you remove this, you need to find another one to tag {{BLP sources}}. When you remove that one, you need to find yet another one... ad infinitum. {{BLP sources}} is practically impossible to use following the logic ("must be immediately removed") presented in this discussion. – Finnusertop (talk ⋅ contribs) 14:00, 4 March 2016 (UTC)
- And, amazingly enough, when in doubt, the proper course is to remove unsourced claims from BLPs. No real need to add a new template for the few cases where it might be utile. Collect (talk) 13:51, 4 March 2016 (UTC)
- NO, they need not be removed; they should, where possible, have sources added. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:35, 4 March 2016 (UTC)
- If you can reliably source them, then fine, go ahead and do that. But if you can't, they should be removed, as stated by Jimbo Wales (talk · contribs) at 20:30, 16 May 2006 (UTC) in [WikiEN-l] Zero information is preferred to misleading or false information. --Redrose64 (talk) 01:03, 5 March 2016 (UTC)
- @Collect: I have struck "contentious" from the proposal accordingly. bd2412 T 13:49, 4 March 2016 (UTC)
- Oppose as not needed. Non-sourced, non-referenced, and unclear statements in a BLP article should be removed immediately, not tagged, per BLP guidelines; we don't need no stinking templates. GenQuest "Talk to Me" 15:53, 4 March 2016 (UTC)
- Do the more sensible thing: The obvious solution to the problem you and Redrose64 want to address is to have a bot populate a cleanup category, by detecting BLPs (by category) that have cn or other dispute (not cleanup) tags on them. You can just go propose that bot on the bot proposals page, and it would probably get unanimous support. The current proposal is a Rube Goldberg device approach. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 17:56, 4 March 2016 (UTC)
- I am actually just as concerned with assertions on pages that are not themselves BLPs (for example, uncited statements on the party primary pages that a particular politician endorsed a particular candidate). These should in principle be easy to cite, but a less experienced editor may throw a tag on them anyway. bd2412 T 03:25, 5 March 2016 (UTC)
- Oppose - We already have two templates that are basically already highlighting these kind of issues. Guy1890 (talk) 07:15, 6 March 2016 (UTC)
Category name syntax
Hello, almost all of my edits aim to improve the category system.
It's very hard to find previous discussions on this topic, I searched the archive of "Wikipedia talk:Category names".
I propose to you to think about the possibility of a detailed, but extensive change in the name syntax of categories in the form of Category:Foo by Bar". Instead it should look like this: Category:Foo (by Bar).
It's easily confusing to me, that the whole category name is written in one straight, sustained line, without and clear separation between the different parts it consists of.
What the simple looking Category:Foo by Bar actually in our head means, is: Category:Register of "Foo" items, categorized by the parameter "Bar". Putting the sorting key in brackets, logically would make the name much easier to read as one can faster distinguish the object from the sorting key. This becomes evident with larger names like Category:Expatriates by country of residence in comparison with Category:Expatriates (by country of residence).
There are many categories, where the sorting key gets very long, because it consists of two or even three keys at once. Example: Category:Musicians by nationality, genre and instrument vs Category:Musicians (by nationality, genre and instrument). <
Appealing to the possible concern, that brackets do already have another function in category names, which is to clarify, I demonstrate the two possible cases, where the new brackets could collide.
Case 1: brackets before sorting key: Category:People from Georgia (country) (by occupation)
Case 2: brackets in the sorting key: Category:People (by city in Georgia (country))
I think the collision is not tragic in both cases, as the brackets still add to bring structure and clarity. Now tell me what you think. I know it's not likely for such an extensive change to be implemented, but consider to take it serious. I would've preferred squared brackets for the sorting key, that would look even better, but Wikipedia doesn't allow it.
A few hours before making this proposal I created a new category, which for demonstration I gave a name with the brackets. If you don't approve, it can be speedy renamed at any time: Category:Music (by genre and nationality). Regards, CN1 (talk) 01:12, 5 March 2016 (UTC)
- Adding here my point out of my answer to עוד מישהו:
"X by Y" is only easily understandable, when used in a whole sentence, as one would do normally. Like saying "List these people by occupation" or "I sorted the music by genre". But we are talking about category names, which until now are not designed after sentences, but rather as phrases, made as short and handy as possible. But these names still consists of the main object part and the sort key part and visibly setting them apart would make the cat names easier understandable. - After reading Wikipedia:Page_name#Technical_restrictions_and_limitations, I came to an alternative conclusion, which doesn't involve brackets, and even to myself looks better and seems more fitting for future challenges:
Category:People from Georgia (country) - by occupation
Category:People - by city in Georgia (country)
End of Proposal so far. CN1 (talk) 23:45, 7 March 2016 (UTC)
- Not in favor of proposed change. Brackets are as a matter of fact incorrect, since it really is "Music by genre and nationality". Debresser (talk) 16:45, 5 March 2016 (UTC)
-
- We use brackets in category names only where the content of the brackets would be unlikely to show up in normal prose. You wouldn't talk about Georgia Country, so the word "country" goes in brackets. Compare to New York City, which is actually referred to by this name on prose. Names like "Expatriates by country of residence" are more like New York City than like Georgia (country). עוד מישהו Od Mishehu 19:47, 5 March 2016 (UTC)
-
-
- You bring up a good point there, although I don't completely agree with you. "X by Y" is only easily understandable, when used in a whole sentence, as one would do normally. Like saying "List these people by occupation" or "I sorted the music by genre". But we are talking about category names, which until now are not designed after sentences, but rather as phrases, made as short and handy as possible. But these names still consists of the main object part and the sort key part and visibly setting them apart would make the cat names easier understandable. CN1 (talk) 21:01, 6 March 2016 (UTC)
-
-
-
-
- I think [[:Category:People [by city in Georgia (country)]]] is the best solution, and that proposal should not be rejected after five comments. Problem is hard / maybe impossible wikilinking, as you see here...
--Obsuser (talk) 21:26, 6 March 2016 (UTC)
- Can be linked like this: Category:People [by city in Georgia (country)]. However, error pops up: Special page | Bad title | The requested page title contains invalid characters: "[". | Return to Main Page. --Obsuser (talk) 21:36, 6 March 2016 (UTC)
- I think [[:Category:People [by city in Georgia (country)]]] is the best solution, and that proposal should not be rejected after five comments. Problem is hard / maybe impossible wikilinking, as you see here...
-
-
- If the ratio of negative to positive opinions grows by more than two now, please close it up as rejected. CN1 (talk) 02:34, 7 March 2016 (UTC)
- From my experience, the number of users who care about categories are quite low compared to the number of people who care about articles and actual content. If you look at the category project talk pages, the discussions are quite slow, and as in fact absolutely no one regularly visits the talk pages of categories, I tell every new user who writes there, to go directly to project pages or portals. What I'm saying is, we might have to wait a bit longer for this one to unfold. CN1 (talk) 20:25, 7 March 2016 (UTC)
- Other than the proposer, there is no evidence presented that our current category names cause any confusion. I can easily understand all the examples posted, and the proposed alternatives are either not technically possible or are jarring to read. Fences&Windows 23:50, 10 March 2016 (UTC)
Close down Possibly Unfree Files
At this discussion, we reached consensus to close down non-free content review and instead send all such discussions to Files for Discussion. Possibly unfree files (PUF) has many of the same issues. It doesn't get enough attention - current there are unclosed discussions from December. And, more importantly, it isn't clear to many editors, nor to any new editors, whether such a deletion discussion should happen at PUF or FFD. Files for discussion is perfectly capable of handling the additional discussions.
The proposal is this: Close down Possibly Unfree Files, with all future discussion at Files for discussion Oiyarbepsy (talk) 03:48, 6 March 2016 (UTC)
Close PUF
- Support closing. While they may officially have different purposes, in practice they duplicate each other, and we'd do better to have less processes rather than more anyways. --Jayron32 16:30, 7 March 2016 (UTC)
- Support. With the way that the English Wikipedia has evolved over the years, it just makes sense to have all discussions for "File:" namespace pages to happen in the same place. Steel1943 (talk) 19:02, 7 March 2016 (UTC)
- Support - It only makes sense to limit the places that deletion discussions take place; having a different place for each specific reason for discussion leads to bureaucracy. It does make sense to have different places for files, templates, categories, articles, and "other" pages, but since FfD and PUF are essentially duplicating work and many (if not most) editors are not aware of PUF (for example, I was not aware PUF existed), they need to be merged. — Jkudlick • t • c • s 13:34, 8 March 2016 (UTC)
- Support - Easier just to have one place to discuss all the particular aspects of files local to Wikipedia, most of which relate to a files particular free-ness. Redirect to FFD or mark historical with a big pointer to FFD. --Izno (talk) 14:21, 8 March 2016 (UTC)
- Support – I've had users respond with confusion when I took a file to PUF rather than FFD, the former being less well known. Would be simpler and easier for everyone just to have the one venue for everything. CT Cooper · talk 18:06, 8 March 2016 (UTC)
- Support. Seems like unnecessary duplication. --Regards, James(talk/contribs) 18:14, 8 March 2016 (UTC)
- Support Per all the above. Having too many forums for discussion of basically th same thing is unhelpful to the project. Beeblebrox (talk) 18:35, 8 March 2016 (UTC)
- Support – Reduces bureaucracy, improves efficiency. RGloucester — ☎ 19:17, 8 March 2016 (UTC)
- Support - decreases red-tape, and increases performance. — Cirt (talk) 01:39, 9 March 2016 (UTC)
- Support. The distinction was often unclear to me, too. Sandstein 08:15, 9 March 2016 (UTC)
- Support as IMHO it's a completely pointless board - It's pretty much a duplicate of FFD so there's not much point in keeping it around, FFD seems to be the best choice here. –Davey2010Talk 03:07, 10 March 2016 (UTC)
Keep PUF
- Support keeping PUF. PUF and FFD have clearly distinct purposes, and the discussions are typically closed after around a week. Also, most PUF discussions are closed by the same users as those who close the FFD discussions, so if you close down PUF because you think it's backlogged, you will just move a backlog from one place to another place and thus not achieve anything. --Stefan2 (talk) 11:19, 6 March 2016 (UTC)
- Yeah, the policy pages say they're different, but when you actually look at the discussions, they aren't. And giving the closers one place to look instead of two will reduce the backlog for that simple reason. Oiyarbepsy (talk) 16:33, 6 March 2016 (UTC)
Discussion (PUF)
- Comment: Just wondering how the cleanup is going to proceed if this RfC is approved. Just going by what happened after the NFCR/FFD merge, it seems there were many in favor of the merge who decided to not get involved in the cleanup, thus causing it to take much longer than it probably should have. A few editors really spent a lot of time updating templates, closing discussions, etc. and few admins worked their way through NFCR files which were added to FFD to help reduce the backlog. Not sure how many PUF discussions will be added to FFD, but it would be nice if there was also some consideration given to the post-merge cleanup. -- Marchjuly (talk) 02:24, 9 March 2016 (UTC)
-
- @Marchjuly: I already have a bit of an overview about what will need to take place after this merge is approved. This merge probably will not be as complicated as the FFD rename since rather than a forum being shut down and a forum renamed, instead, we only have a forum to shut down. The technical details will include AnomieBOT having to stop creating daily subpages after the merge is finalized, Twinkle needing to be updated to have the WP:PUF option removed, and the instructions at WP:FFD to be updated to encapsulate everything. And, with this proposal, almost no templates should need to be updated due to no forum being renamed (I know that was the biggest headache with the NFCR to FFD merge.) Steel1943 (talk) 03:24, 9 March 2016 (UTC)
-
- Although I didn't mention you by name Steel1943, but you were one of the editors who did a lot of the heavy lifting post merge. So, if you feel things will not take as much time as before than that's good enough for me. Still there may be some discussions on PUF which require further discussion or an admin to close. Is the plan to relist them in stages at FFD like was done with NFCR or will everything be moved at once? Not sure which approach is best. I guess it depends on the number of unresolved discussions at the time of the merge. -- Marchjuly (talk) 04:16, 10 March 2016 (UTC)
- I'll add that this should be way easier to close since PUF actually has daily subpages, making things trackable, unlike NFCR which had squat. Oiyarbepsy (talk) 04:03, 9 March 2016 (UTC)
-
- That's a good point Oiyarbepsy that I forgot about. You also were one of the editors who helped clean things up post merge so if you feel things are going to be more manageable this time, then everything sounds good to go. -- Marchjuly (talk) 04:19, 10 March 2016 (UTC)
- With regards to the existing backlog, in case it isn't clear - for NFCR, the page was just left open and listed at WP:ANRFC, and new requests were directed to FFD by a template. Sunrise (talk) 06:00, 9 March 2016 (UTC)
Italics in names of spacecrafts vs. no italics in names of orbital launch vehicles (rockets)
See WP:MULTI discussion at WT:SPACEFLIGHT#Italics for spacecraft names? --Izno (talk) 13:10, 7 March 2016 (UTC)
- The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
First thing: I do not know if this matter has already been discussed elsewhere. If it has been and is resolved, please give me proper link.
Second thing: If first not true, please tell me if this is not proper place for such queues. If so, I will move it to the proper page...
Third thing: If both first and second not true, I want to ask this question because some administrators on .sr insist on no-italics-writing for names of rockets (just example, I know these are two different languages).
Is there a reason to write spacecrafts names i.e. names and titles of articles because consistency must be fullfilled (such as Juno) in italics, and to write names of rockets i.e. names and titles of articles (such as Falcon 9 v1.1) with no italics?
I think italics is needed in both cases, or if not needed — is not prohibited, at least...
PS One Serbian handbook guide for ortography suggests writing names of cars in italics. Can someone tell me what he/she thinks: can this can be used to create a valid analogy for writing names of rockets, or spacecrafts, or aeroplanes, etc. — all in italics? Sorry for bad English or mistakes in English as I don’t have a professional knowledge of English, and some constructions might be unusual... --Obsuser (talk) 16:59, 6 March 2016 (UTC)
- I think the best analogy is that names of ships are italicized: MOS:ITALICS#Named, specific vessels. I think the parallel here is that both are vessels occupied by humans, rockets aren't. – Finnusertop (talk ⋅ contribs) 17:24, 6 March 2016 (UTC)
- I think the difference is that spacecraft names are the names of individual spacecraft. For example, Eagle was the first lunar excursion module to land on the Moon. Eagle is italicized but "lunar excursion module" is not. Launch vehicles usually only have a model name like "Saturn V". Individual launch vehicles usually are not given a name. Jc3s5h (talk) 18:04, 6 March 2016 (UTC)
- So it hasn’t been discussed before, and this is a right place. Great!
- @Finnusertop: Thank you. Is there any MOS rule to approve that?
- @Jc3s5h: Thank you. What about Falcon 9 v1.1 compared to names of cars [if we do not take in account this argument of "(non-)occupied by humans"]?
- What about "OLV Falcon 9 v1.1" analogy to the "HMS Victory" with italics in both examples [if we do not take in account this argument of "(non-)occupied by humans"; "OLV" stands for "orbital launch vehicle"]?
- What about these italics here, in the beginning? Should they be removed or not? What about italics inside the text of Falcon 9 v1.1 for some rocket names (e.g. Falcon 9 full thrust)?
- One more thing: If there’s no rule in MOS to stop me, can I put italics on .en Wikipedia or any other in both title and text of an article Falcon 9 v1.1 [for .sr I have the secondary source mentioned above that says "Write car names in italics.", and nobody has anything that says "Don’t use italics for names of OLVs."]?
- This is very important for me; if you have time, please try to answer these questions related to MOS for writing titles and names of some articles in italics. Thank you. --Obsuser (talk) 20:25, 6 March 2016 (UTC)
- It has been discussed before, since I was pulled up on the matter of italicisation four or five years ago, I forget which article, but suspect that it was one concerning the Gemini program. Certainly there is an ongoing discussion right now, at WT:SPACEFLIGHT#Italics for spacecraft names?, and per WP:MULTI this discussion should not have been started. --Redrose64 (talk) 12:21, 7 March 2016 (UTC)
- I think the difference is that spacecraft names are the names of individual spacecraft. For example, Eagle was the first lunar excursion module to land on the Moon. Eagle is italicized but "lunar excursion module" is not. Launch vehicles usually only have a model name like "Saturn V". Individual launch vehicles usually are not given a name. Jc3s5h (talk) 18:04, 6 March 2016 (UTC)
- The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Listen template
In the "Listen" template, can we please have a clickable button for playing all files in the template, one after another? Thanks.Anythingyouwant (talk) 22:08, 7 March 2016 (UTC)
Bring back Esperanza!
As jimbo(saw) would say... make wikipedia not suck!66.97.241.196 (talk) 02:25, 8 March 2016 (UTC)
- Well, maybe, but we need to establish a re-activation committee via a non-public election process, and then the re-activation committee would need to establish the making new Esperanza pages committee, and we couldn't do this with an unauthorized heating repairman. Oiyarbepsy (talk) 02:48, 8 March 2016 (UTC)
-
- I guess you mean Wikipedia:Esperanza. --Redrose64 (talk) 15:08, 8 March 2016 (UTC)
- The WP:TEAHOUSE serves much the same purposes. EllenCT (talk) 13:59, 9 March 2016 (UTC)
Any thoughts on templates like this??
Wikipedia has many templates saying "This user..." followed by something that talks about the user's preferred English variant. I would like to know if we can have any templates saying "This user thinks trans people should be referred to in a respectful way" or "This user think trans people should be referred to with their gender of rearing for some purposes"?? Georgia guy (talk) 18:48, 9 March 2016 (UTC)
- @Georgia guy: Do you mean WP:USERBOXes? --Redrose64 (talk) 20:15, 9 March 2016 (UTC)
- By the same token, can we have lots more userboxes saying "This user thinks foo people should be referred to in a respectful way" where foo is each of lesbian / gay / bisexual / trans / queer / female / black / mixed-race / Asian / Mexican / French / ginger-haired ... pick your oppressed minority ... yeah, it gets silly, doesn't it. No. If we're going this way, let's have one userbox saying "This user thinks all people should be referred to in a respectful way." Maybe there is one, I don't know, I'm not into userboxes. Stanning (talk) 11:25, 10 March 2016 (UTC)
- I've found Wikipedia:Userboxes/Life#Gender, Wikipedia:Userboxes/Life/Sexuality and User:ISD/Userboxes/Sexuality; there is something of an overlap here. --Redrose64 (talk) 13:30, 10 March 2016 (UTC)
@Georgia guy:If you can't find the one you want there, you can always make one yourself. They go in your user space. Oiyarbepsy (talk) 00:44, 11 March 2016 (UTC)