Wikipedia:Village pump (idea lab)

From Wikipedia, the free encyclopedia
Jump to: navigation, search
  Policy   Technical   Proposals   Idea lab   Miscellaneous  
The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, please note:

Before commenting, note:

  • This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
  • Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.
« Older discussions, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22


Centralized discussion
Proposals: policy other Discussions Ideas

For a listing of ongoing discussions, see the dashboard.


Accessible Citations (Experiment with .PDF#page links)[edit]

>>>> Updated Version =) <<<<<


The Goal:

  • Find the easiest/quickest route to follow a reference all the way back to the original paragraph/sentence on the original document in which the writer/editor was reading.

Current Experiment:

Where this can be Improved:

  • Ideally, use one of the simple {{command|name|#page}} when citing sources in the WikiCode, and automatically create http://example.pdf#pageNumber external links to the specific pages.
  • Use something other than {{efn}}

Example (still in experimental phase):

This is how it looks in WikiCode:

<nowiki>
Sentence.
{{efn|[https://ia601509.us.archive.org/18/items/LetterFromRome/Letter_from_Rome.pdf#56 ''Letter from Rome'', page 56.]}}

Another Sentence.
{{efn|[https://ia601509.us.archive.org/18/items/LetterFromRome/Letter_from_Rome.pdf#71 ''Letter from Rome'', page 71.]}}

== References ==

{{reflist}}

|- !Result |- | MIT Server downloaded articles.[1] Aaron Swartz is legendary.[2]

Normal Referenced content.[1]

open access publication – free to read Accessible Citations
1.^ JSTOR Evidence.[1] [PDF]. View Page 3127.
2.^ JSTOR Evidence.[1] [PDF]. View Page 3142.
References
  1. ^ a b c JSTOR (30 July 2013). "JSTOR Evidence in United States vs. Aaron Swartz" (PDF). Archived from the original (PDF-1.6) on 1 March 2017 – via Archive.org. 

|}


Popcrate (talk) 12:29, 1 March 2017 (UTC)

I'm dubious about using the {{ref}} template, which is unpopular. I believe that mw:Extension:Cite.php isn't meant to support nested refs like that anyway. Why don't you just make separate citations for the source when you change the page number? WhatamIdoing (talk) 02:01, 2 March 2017 (UTC)
Insert plug for the Comm Tech tasks related to phab:T138601. --Izno (talk) 12:52, 2 March 2017 (UTC)
@Izno: this looks very related to what I am thinking of =) It would definitely be better to program in some functionality, rather than misuse a bunch of other templates and references ;) How would you recommend I get involved over there? Popcrate (talk) 23:34, 2 March 2017 (UTC)
Whatever we do, it should allow the linked to page in the PDF to not be the page number that the person sees on Wikipedia. That is because page XYZ of the PDF is often not page XYZ of the document. For example, extra intro pages are included often or the PDF is just part of a larger document. AManWithNoPlan (talk) 21:05, 12 March 2017 (UTC)

Good point, AManWithNoPlan , and I agree... A further use I could see for this, is to add links to existing references with page numbers. For example... let's say a book becomes part of the public domain, or is already part of public domain, and can then add links to the new book. <- That would make it especially important to have a separation of actual page number versus PDF page number (in order to preserve the "real" page number from original text). Popcrate (talk) 04:58, 18 March 2017 (UTC)

Because User:Izno referred me to the phabricator page, it looks like I'm not the only one to consider this, and I would definitely be willing to program it in. I think there just needs to be some consensus on how it should appear on Wikipedia. I think there's a lot of potential having very accessible reference links in Wikipedia, and having a way for editors to easily create them will be essential. Popcrate (talk) 04:58, 18 March 2017 (UTC)

What are the pros and cons / benefits and costs of changing title capitalization?[edit]

Why are article titles of subjects that are not proper nouns capitalized?

It looks like it might be a hybrid form of title capitalization, since the words that follow aren't capitalized unless they are proper nouns.

Wikipedia could become a much better linguistic tool if the starting words in titles reflected the general capitalization rules for words.

Programs, for instance could rely on titles to identify proper nouns. Scripts that create titles from existing ones (History of x), could do so much easier if the terms were correctly capitalized. "History of Acupuncture" just doesn't cut it.

I post this concept at the idea lab, to explore the benefits and costs, and pros and cons, of changing titles to relect appropriate capitalization.

I look forward to your replies. The Transhumanist 03:27, 1 March 2017 (UTC)

Why are article titles of subjects that are not proper nouns capitalized? Examples please? Possible reasons include 1. Article creator was not aware of WP:TITLEFORMAT and 2. Article creator was aware of TITLEFORMAT but didn't care about it. Cost of changing a title is miniscule, as a redirect using the old title is always created pointing to the new title. Thus the cost is the few seconds required to do the move. Benefit is often a matter of contentious debate that gets all philosophical about "what is MOS?" and "what is a guideline?". I generally sit out such debates because I see little community will to establish high-level consensuses on such foundational issues. ―Mandruss  04:39, 1 March 2017 (UTC)
 
I don't think it has anything to do with the article creator. Pretty much every article is capitalized, meaning pretty much every word that isn't a proper noun is capitalized. "Dog", for example, doesn't show up as "dog". According to WP:TITLEFORMAT, "The initial letter of a title is almost always capitalized by default." I'm here to talk about possibly changing that default. My questions about pros/cons & benefits/costs pertain to that.
 
According to WP:NCLOWERCASEFIRST, "The MediaWiki software is configured so that a page title on the English Wikipedia (as stored in the database) cannot begin with a lower-case letter, and links that begin with a lower-case letter are treated as if capitalized, i.e. foo is treated the same as Foo."
 
So, it looks like we have to come to consensus first, before putting in a community request that the software be modified accordingly. Oh damn. What are the chances of that happenin'? The Transhumanist 21:01, 1 March 2017 (UTC)
The first word in a sentence is always capitalized. Thus, "Dogs are creatures with four legs." should be capitalized. However, "Furry four-legged creatures are called dogs." should not. Even though the title of an article is not a complete sentence, the first word of the title should still be capitalized regardless of if it is a proper noun or not, as it represents the beginning of a thought. ~ ONUnicorn(Talk|Contribs)problem solving 21:39, 1 March 2017 (UTC)
The software setting is mw:Manual:$wgCapitalLinks where https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php (which controls Wikimedia wikis) says:
'wgCapitalLinks' => [
        'default' => true,
        'jbowiki' => false,
        'wiktionary' => false,
],
The current settings make sense to me. Wiktionary is a dictionary and we are an encyclopedia. jbowiki is the Lojban Wikipedia, a special case: "Lojban is written almost entirely with lower-case letters; upper-case letters are used to mark stress in words that do not fit the normal rules of stress assignment, or when whitespace is omitted." If we change our setting then Dog and dog become links to different pages like GOLD and Gold. We would need to rely on redirects or start sentences with piped links like "[[dog|Dogs]] have four legs" instead of the current "[[Dog]]s have four legs". Search result pages would mix article titles with and witout a capital which I think is ugly. Categories would also do it but only to a limited degree since most categories would be dominated by one of the cases. In wikitext like lists, see also sections, navboxes, disambigutaion pages we could decide whether to use piped capitals or mixed capitalization. Our current system works fine to me and would cause a lot of confusion to suddenly change, especially if other Wikipedias don't do it. PrimeHunter (talk) 23:04, 1 March 2017 (UTC)
Interesting. It's engrained into Wikipedia culture as well as the infrastructure, and would therefore be difficult to change, and almost impossible to get consensus. I went looking around and was surprised to find that while Encyclopædia Britannica capitalizes its articles (see Domestic cat), it does not capitalize them in their search results (see search for "cat"). Weird. The Transhumanist 01:36, 10 March 2017 (UTC)
Yeah, sorry, I misunderstood earlier. Lowercasing the first letter when it's a common noun is so far outside the box that it didn't occur to me that's what you meant. What PrimeHunter said. ―Mandruss  23:16, 1 March 2017 (UTC)

ISBN formatting[edit]

This tool can format many ISBNs, but it is javascript and you have to do it manually on every page and include it in your .js files. Is there a bot that does this, or does anyone have a suggestion for which bot to ask to add this as a task? https://de.wikipedia.org/w/index.php?title=Benutzer:TMg/autoFormatter.js Here is an example of me running this auto format tool (it does more than just ISBN's): https://en.wikipedia.org/w/index.php?title=Zenodotion&diff=prev&oldid=768496080 Lastly, can anyone think of a reason that this would be a bad idea? AManWithNoPlan (talk) 16:19, 4 March 2017 (UTC)

  • There was a BRFA but issues were thrown up. I don't have a direct link to it though. It's referenced in Wikipedia:Bots/Requests for approval/CitationCleanerBot and you can review at your leisure. --Izno (talk) 22:19, 4 March 2017 (UTC)
  • Summary: ISBNs, can be unhyphenated, although this is not recommended officially. The bot in question specifically left ISBN hypendation out since that's a legitimate stylistic alternative actually found in the outside world (e.g. Google Books does not hyphenate ISBNs, many books have unhyphenated ISBNs on their information page). A different bot hyphenated ISBNs for a while according to ISO rules, which are not used by the Library of Congress, Amazon, or Google books. Hyphens might interfere with finding books with google. With dashes is the approved method of display, according to ISO, The International ISBN Agency and Wikipedia. Dashes conveys information about the book in human accessible form, such as publisher is a section. AManWithNoPlan (talk) 01:29, 6 March 2017 (UTC)
  • My ISBN tool is built around a very basic API I wrote (example) that'd be sufficient, and I think I technically wrote some code to output CORS headers … but since I haven't gotten around to getting SSL certs for the domain that's relatively useless (you can't pull from it on-wiki). In the first version of my tool, I converted all the hyphenation data from RangeMessage.xml into a big JSON object and then embedded that in a pure-JS tool. Then I noticed that the ISBN Agency's TOU forbids sharing the data file, proxying it, etc., and they don't provide CORS for the file. :( To be compliant I had to rewrite my tool from pure JS (which exposed the converted data), to one that pulled from the aforementioned PHP-based API (the underlying data file is only available server-side). {{Nihiltres |talk |edits}} 23:29, 13 March 2017 (UTC)

Clarification that some lists are not intended to be exhaustive, but only should include items which are standalone notable[edit]

We have quite a few articles in Wikipedia which are lists or contain lists. (More information can be found in the MOS - Lists)

There are quite a few types and they can be categorized in various ways but for the present discussion I'll break them into two categories:

  1. Lists intended to be exhaustive (The list itself must be notable while the items in the list may or may not be separately notable.) E.g. List of characters in The Lion King
  2. Lists not intended to be exhaustive, and inclusion means the entries should be individually notable. E.g. List of Medal of Honor recipients


At OTRS, it is quite common to receive an email from someone who notes the omission of an item in a list and asks us to add it. In some cases, the request is legitimate and we attempt to be helpful, but in many cases, they mistakenly think the list is intended to be exhaustive rather than a list of items which in addition to meeting the inclusion criteria, are also notable and have an existing article.

I think it would be useful to add a head note to lists of type 2, to let readers know that the list is not intended to be exhaustive with respect to items in the universe but only exhaustive with respect to items that are individually notable. Like investment my motivation is to cut down on the number of people who ride into OTRS to request that their friend or relative be added to some list, I think it would provide a useful service to readers who might otherwise be misled.

I emphasize the two types of lists, because if we could agree on wording for such a head note, it should not be indiscriminately added to all standalone or embedded lists, it should only be added to those that qualify as type 2.

I'm including this in the idea section rather than as a formal proposal because I think there are some details to be worked out. For example, it may be unobtrusive to add such a head note to standalone list articles, but I'm not sure how best to include this information in this case of school and location articles which often have a section for notable alumni or residents.--S Philbrick(Talk) 15:55, 11 March 2017 (UTC)

The difference between lists that are intended to be complete and those that are not can already be signaled: {{Dynamic list}} (not intended to be exhaustive) versus {{Incomplete list}} and {{Complete list}} (intended to be exhaustive).
Of course, there are various list inclusion criteria (notability being just one of them) and there has never been a convenient way to signal editors, let alone readers, what the criteria is. There are lists that are dynamic (not intended to be exhaustive) but individual entries don't need to be notable. – Finnusertop (talkcontribs) 16:09, 11 March 2017 (UTC)
I don't see that as adequate. For example, the specific motivation is this article: List of books written by children or teenagers. A reader wrote in to tell us about a book not on the list that was written by someone under the age of 20. I'm not sure which template you think belongs on that list but I don't see how any of them would send the message that a non-notable book should not be added.--S Philbrick(Talk) 16:12, 11 March 2017 (UTC)
List articles are expected to be clear about their inclusion criteria. However, many such lists identify the inclusion criteria without stating that this particular list also requires that the individual items be notable. My guess is that this is not mentioned because most experienced editors treat it as implicit. I don't disagree, but I can tell you from experience that many readers do not pick up on this. I am not attempting to propose ways to improve the general inclusion criteria discussion — I am only pointing out that the implicit need to meet the notability hurdle is misunderstood by many readers and I'd like to find a way to make it explicit rather than implicit.--S Philbrick(Talk) 16:18, 11 March 2017 (UTC)
Moving pages such as List of books written by children or teenagers to List of notable books written by children or teenagers could go a long way to solving the problem. Roger (Dodger67) (talk) 11:14, 13 March 2017 (UTC)
I suspect that most readers don't know what we mean by "notable". WhatamIdoing (talk) 20:17, 22 March 2017 (UTC)

A "Wiki word processor"[edit]

I'm so comfortable and familiar with wiki-markup that I frequently find myself using it while working on MS Word. Then I get frustrated when the headings, italics, footnotes, etc don't appear as I want them. I find it so muck quicker and easier to simply type raw wiki-code than having to constantly click toolbar buttons. Is there a way to "teach" MS Word to parse some basic MediaWiki markup? Or how about some clever coder(s) create a "Wiki word processor" app that uses MediaWiki markup. Roger (Dodger67) (talk) 11:10, 13 March 2017 (UTC)

You can look at this. Ruslik_Zero 20:46, 14 March 2017 (UTC)
Ruslik0, thanks but that is actually the exact opposite of what I'm looking for. That MS addon converts the MS Word document format to MediaWiki markup. What I want is a word processor that natively uses wiki-markup. The rules of Wikipedia does not allow me to use my sandbox for my own personal, business and academic writing. What I'd like is the MediaWiki "source editor" as a standalone app. Roger (Dodger67) (talk) 15:31, 15 March 2017 (UTC)
Almost certainly not. There's no single standard for wikitext, and even within WMF projects there's variation between how formatting is handled—those footnote templates are mostly en-wiki specific templates, not Mediawiki modules. I suppose theoretically you could embed Parsoid into a word processor, but I can't imagine anyone would bother, especially since the devs are trying to discourage the use of Wikitext markup. (As a very clumsy fudge, you could use Word's autoreplace function to turn Wikitext markup into Wordstar markup (e.g., '''text''' becomes *text* and ''text'' becomes _text_), which Word can be coaxed into understanding, but it seems like more trouble than it's worth. (Is typing three apostrophes really any easier than ctrl-b, anyway?) ‑ Iridescent 16:25, 15 March 2017 (UTC)
(Adding) This may be a stupid question, but if you want something with the look and feel of Mediawiki but without using Wikipedia, why not just install Mediawiki on your own computer? ‑ Iridescent16:29, 15 March 2017 (UTC)
(edit conflict) It's not exactly what you're asking, but you don't actually have to "constantly click toolbar buttons" in MS Word. You just need to learn the keyboard shortcuts. For example, you can tell it to put things in italics by holding down the "Ctrl" button and pushing "i" ("Ctrl+i"), bold is Ctrl+b, underline is Ctrl+u, etc. Headings get a LOT easier if you learn to use styles. The biggest problem with MS Word is that people don't know how to use it, and the designers want it to be as intuitive as possible, so they hide some of the more powerful features like styles. ~ ONUnicorn(Talk|Contribs)problem solving 16:31, 15 March 2017 (UTC)
If you know (or are willing to learn) Markdown, pandoc can be used to convert it to html, pdf, epub, or even .docx formats. Many text editors support it – vim comes with markdown syntax highlighting out-of-the-box, I believe; emacs, if it doesn't have it by default, certainly has a package for it. For a fuller-featured, but more complex and harder to learn, alternative, LaTeX might be worth investigating. Caeciliusinhorto (talk) 10:55, 17 March 2017 (UTC)
mw:Extension:VisualEditor can be run stand-alone (with or without MediaWiki). With its new built-in wikitext mode (which might or might not be packaged up for third-party installation right now), you could type in wikitext markup, switch to visual mode, and then copy and paste the contents to a word processor if you needed a particular format. I would be worried about it not handling complex formatting though: character formatting and links would probably convert nicely, but ref tags would be hopelessly lost or garbled.
The last time I used Microsoft Word (which was a l-o-n-g time ago), it was also possible to define all manner of keyboard shortcuts, and if that's still possible, then you could probably define keyboard shortcuts that way. Whatamidoing (WMF) (talk) 20:25, 22 March 2017 (UTC)
Yes, it's still possible to define keyboard shortcuts; I do it all the time. How you go about doing it depends which version of Word you're using as they're always moving features around and hiding them in different places. ~ ONUnicorn(Talk|Contribs)problem solving 20:35, 22 March 2017 (UTC)

Idea: proof of self teaching with Wikipedia[edit]

Just an idea that could be discussed.

Wikipedia has a lot of knowledge and many people are eager to learn from it. What if an automated quizz could be offered to the reader at the end of an article so that eventually, if passed, the latter would receive a "proof of knowledge", like a MOOC but self-taught.

At the end of the day this person eager to learn could receive this kind of certificate and put it on his/her CV and LinkedIn profile for example.

If this idea is taken further, companies could ask their new recruits (or even candidates for a position) to pass these tests so that people could prove they have some kind of knowledge on a specific topic.

One issue we could see: the answers could be put online and everyone could cheat very easily and obtain 100% on any topic. Thus one solution would be to develop a smart algorithm to draw more or less randomly generated quizz. — Preceding unsigned comment added by 2A02:120B:2C4C:7BB0:D8E:38E8:7AF2:752 (talk) 11:27, 17 March 2017 (UTC)

That's not a bad idea. I wouldn't do it but I could see how some people would eat it up. I'd suggest it be limited to FA articles, though. There's a lot of terrible articles here which study of shouldn't entitle one to even a PDF download of a certificate. BlueSalix (talk) 03:44, 18 March 2017 (UTC)

Wiki 4 Coop[edit]

Hello everyone,

I come to you to invite to re-read the submission of a new partnership project between the Wikimedia movement and the Belgian NGOs. The project is titled Wiki 4 Coop and I invite you to discover its submission page on Meta-Wiki. Do not hesitate to endorse the project if you like it and even correct my English if you have a little time. A beautiful end of day for all of you, Lionel Scheepmans Contact (French native speaker) 11:44, 17 March 2017 (UTC)

The effects of milestones on achieving A-class articles[edit]

I've been improving articles in an effort to get GA status, and eventually FA status, but I came to the realization that it completely undermines the value of A-class status. A-class is supposed to be when an article is "considered 'complete'", according to Wikipedia:Article classes. In fact, look at the statistics: there are more Good Articles than A-class articles, not because A-class status is hard to achieve, but because GA and FA status are both milestones that are preferable to A-class (which, incidentally is why there are far more FA as well; note that I don't have the full statistics, but in WikiProjects such as CGR and Military History that is the case, whereas WP such as Video Games have eschewed A-class altogether). Why do we settle with GA status, if A-class is supposed to be the goal? People just edit until they've reached GA status and stop because that's considered the milestone, and only settle for A-class if they can't get if Featured. A-class IS the goal, because a complete article is the goal.

I'm not suggesting we get rid of GA and FA status, but that we should give reason for people to bother writing an A-class article - which is supposed to be the highest point of completion achievable in articles, spare Featured. So:

  1. What are everyone's thoughts on some WikiProjects eschewing A-class altogether?
  2. Thoughts on ways to encourage people to achieve A-class after GA status?
  3. Is there a point in claiming A-class is the point of completion when, in practice, FA status is that point? Psychotic Spartan 123 07:07, 19 March 2017 (UTC)
One factor is that virtually no wikiprojects have functioning A-class review processes - milhist does; I have not seen CGR's a-class review used since I have been around, and iirc the last discussion on CGR's a class review essentially concluded that it was dead... Caeciliusinhorto (talk) 09:05, 19 March 2017 (UTC)
The other issue is that these X-class schemes are effectively obsolete; a remnant of the now dormant Wikipedia:Version 1.0 Editorial Team process and should probably be scrapped except in these projects where they are still in use. Jo-Jo Eumerus (talk, contributions) 09:52, 19 March 2017 (UTC)