Wikimedia Meta-Wiki

Community Wishlist Survey 2016/Categories/Reading

< Community Wishlist Survey 2016
(Redirected from 2016 Community Wishlist Survey/Categories/Reading)
Reading
10 proposals, 139 contributors, 145 support votes



Expand offline capability within the Wikipedia / Kiwix app

  • Problem: Access to the Internet is often intermittent or expensive in many low and middle income countries (LMICs). People; however, require continuous access to high quality information. This is one of the great successes of the Open Street Map app. Their app allows you to download all the map data for each country you wish to your phone.
Kiwix has also been a great success but each offline version needs to be created separately. Also it does not allow as much flexibility as many people request. Some just want disease related articles and do not want an app that is too large, others want disease related articles and molecular and cell biology articles, etc.
About 75% of all downloads of the medical apps have been from LMIC which is proof that this is a method that reaches populations we have struggled to reach with our online versions. This additionally effectively gets us around the ban on Wikipedia zero in India.
  • Who would benefit: All people in all languages, especially those in LMICs.
  • Proposed solution: We should improve offline capability within the Wikipedia app / Kiwix app. This would involved:
  1. The ability to download groups of articles by Wikiproject within a single app (Kiwix has done much of the proof of concept work with respect to ZIM files)
  2. In languages that do not have a Wikiproject tagging system, the download would be of the corresponding articles for the EN Wikiproject found via the interlanguage links on Wikidata
Additional nice to haves:
  1. Each WikiProject could create an intro page for their topic area such as we do here for medicine to help pull people into the content
  2. People can decide whether they want no images, thumbnail images, or larger images.
  3. Some work is still needed to get videos functioning in ZIM files. With the recent donation of more than 140 medical videos by Osmosis[1] this would add significantly.
  4. The ability for people to share blocks of offline content directly between phones.
  5. The ability to save blocks of data on different SD cards within the phone
  • Phabricator tickets: T64270 is the phab ticket for part of the video not working problem

Community discussion

What I foresee, is a need for Wikipedia to become sections or partitions, then perhaps a hosting of torrents which can be acquired, by "section search" within the program (checkboxes). Medical -> brain 

             -> bones
             -> disease     Etc

Twillisjr (talk) 02:51, 19 November 2016 (UTC)[reply]

I also propose a button which says "save browsing data" apart from the rest of the device, and perhaps an "upload via torrent" to others if interested. A lot can be accomplished by browsing and idling, we should strategize making the most of it. Twillisjr (talk) 03:10, 19 November 2016 (UTC)[reply]

I support this idea it will be entirely useful in no or low connectivity areas. People could always download content for when connection is poor. Flixtey (talk) 14:23, 19 November 2016 (UTC)[reply]

Thanks Flixtey, I believe that it will provide Wikipedia (based on Wiki format, words merging into further articles) for an anticipation of what the user may search next, all while browsing. Twillisjr (talk) 18:44, 19 November 2016 (UTC)[reply]

There were several similar proposals for offline Wikipedia, including one by Orgio89. That proposal had an alternate idea for a solution, which I'll paste below. -- DannyH (WMF) (talk) 01:27, 24 November 2016 (UTC)[reply]
  • Proposed solution: The WMF really need to consider this idea and get into work with their coders team since the hardware/consumers are already in 3 billion units ready.
    • Cut the current over 70GB (archived version of 13.3GB) of offline english wikipedia dump file into key user friendly categories starting from the all scientific and technological categories like: in science: mathematics, physics, biology, chemistry ... ; in technology: mechanics, electronics, nano technology, computer hardware, computer software, AI etc...
    • Maybe then other useful categories like: music, architecture, culture, history, medicine, gardening...
    • And the other software team members might likely figure out better solutions of these categorizing and making it user friendly for efficient smartphone friendly usage.
    • The key principle of the solution is this wikipedia database need to be well categorized and user selectable according to above mentioned categories examples, whether it is Wikitaxi or Kiwix anyone could choose his or her best 5-20 categories and install those in their smartphones which in most cases would take just 2-10GB of space which most of users and even less active users begin to use their pocketed Wikipedia knowledge in quite handy way. -- Orgio89 (talk) 13:16, 13 November 2016 (UTC)[reply]

Voting – Expand offline capability within the Wikipedia / Kiwix app

  1.   Support Anthonyhcole (talk) 02:38, 29 November 2016 (UTC)[reply]
  2.   Support A try to use Kiwix, on mobile without internet and SD card... I doesn't work without lot of space on DD/SSD... Alternately, I try to download individual articles, it is long and borring... --Nouill (talk) 13:54, 1 December 2016 (UTC)[reply]
  3.   Support Ermahgerd9 (talk) 19:08, 1 December 2016 (UTC)[reply]
  4.   Support, imo it would be nice if this was built into the main app or linked from it so that articles or groups of articles can be downloaded with the click of a button in it (it might open the Kiwix app for that). Also the download of groups of articles shouldn't just be articles of a WikiProject but also categories' articles. --Fixuture (talk) 19:18, 1 December 2016 (UTC)[reply]
  5.   Support NMaia (talk) 00:57, 2 December 2016 (UTC)[reply]
  6.   Support The offline options of Wikipedia must be expanded a lot despite above solution the current dump file needed to be released in many different subject categories like science, culture, technology, medical, culture, music history etc's. Orgio89 (talk) 02:32, 2 December 2016 (UTC)[reply]
  7.   Support Jerodlycett (talk) 13:30, 2 December 2016 (UTC)[reply]
  8.   Support Knowledge and information for LMICs. 4nn1l2 (talk) 14:31, 2 December 2016 (UTC)[reply]
  9.   Support -- Ulanwp (talk) 22:13, 3 December 2016 (UTC)[reply]
  10.   Support Pamputt (talk) 11:02, 4 December 2016 (UTC)[reply]
  11.   Support Stevie is the man! Talk • Work 21:26, 4 December 2016 (UTC)[reply]
  12.   Support --Hugo (talk) 18:50, 5 December 2016 (UTC)[reply]
  13.   Support Blue Rasberry (talk) 19:34, 6 December 2016 (UTC)[reply]
  14.   Support --Arjuno3 (talk) 03:31, 7 December 2016 (UTC)[reply]
  15.   Support --Elmidae (talk) 17:23, 7 December 2016 (UTC)[reply]
  16.   Support --Flixtey (talk) 22:43, 8 December 2016 (UTC)[reply]
  17.   Support --10:16, 9 December 2016 (UTC)
  18.   Support --Ziounclesi (talk) 10:28, 9 December 2016 (UTC)[reply]
  19.   Support --OrsolyaVirág (talk) 11:53, 10 December 2016 (UTC)[reply]
  20.   Support -kslays (talk • contribs) 16:14, 10 December 2016 (UTC)[reply]
  21.   Support Heck, I would use this and I live in the San Francisco Bay Area (I just have a crap cell phone and my table isn't cellular, just WiFi, so I can't get stuff onto it when in transit).  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  19:05, 11 December 2016 (UTC)[reply]

Follow recent updates on current events

  • Problem: Current events such as elections, the olympics, or terrorist attacks get updated quickly on Wikipedia but there is not a convenient way for readers to follow them. Wikipedia provides a reliable perspective from a neutral point of view that is relevant for people following those events. However, following these events in Wikipedia is not easy. Readers need to find the corresponding page, keep refreshing it and look for new information. Tools such as watchlists and diffs are focused on editor needs and they are not reader-friendly solutions to get the updated content.
  • Who would benefit: Readers following current events on Wikipedia. More broadly this can benefit the community as a whole, positioning the project as the place to go to check what's going on in the world (as opposed to a place where people go to learn more on what they read on new sites or twitter/facebook).
  • Proposed solution: Provide a reader-friendly way to follow the relevant updates happening to content in real time. This may involve new ways to find such quickly updated articles, and a user friendly way to view how those articles are updated to see the story develop.
  • More comments: The solution needs to take into account that relevant changes for readers are probably at a different granularity level than those editors are interested in and currently tracking through watchlist (e.g., a reader may not be interested in a small typo being fixed).
  • Phabricator tickets:

Community discussion

I like this. It would be useful on all articles, provided it's not too obtrusive, so readers can see what's been added in the last couple of hours and might not yet have been checked by the article's watchers. Perhaps new or altered sentences could be highlighted in some way: strongly for changes less than two hours old, weakly for changes that are recent but older than two hours. Clicking the highlighted text could take the reader to the relevant diff. --Anthonyhcole (talk) 02:07, 29 November 2016 (UTC)[reply]

This is a very clever idea. Perhaps people could subscribe to an article and then receive an alert when an edit is made that adds a new reference, as this strongly implies that new or updated information has been added to the article. The alert could include the full text of the sections that were changed (showing the changes made in the relevant edit) and the URL of the new reference. - Gareth (talk) 03:33, 29 November 2016 (UTC)[reply]

Voting – Follow recent updates on current events

  1.   Support Anthonyhcole (talk) 02:08, 29 November 2016 (UTC)[reply]
  2.   Support Gareth (talk) 03:33, 29 November 2016 (UTC)[reply]
  3.   Oppose, the proposed solution is very broad. Also while I do think Wikipedia should inform about current events I think this is too much of it: it's too fast so to say - there's too much risk in putting such focus on recent updates (e.g. because of vandalism, manipulation, bad quality etc) - also updates on Wikipedia aren't typically added very early on. There are other sites more suited for such live-updating (such as w:reddit). If users want to see recent changes they can visit the history page. --Fixuture (talk) 19:35, 1 December 2016 (UTC)[reply]
  4.   Oppose Wikipedia is not well-suited for this, per en:WP:NOTNEWS. It's not meant to be a newsreader. Stevie is the man! Talk • Work 21:33, 4 December 2016 (UTC)[reply]
  5.   Oppose Studmult (talk) 07:55, 5 December 2016 (UTC)[reply]

  • Problem: Links to references often form long chains, for example:
word1[1][23][3][5][54][32] and word2[4][7][13][157].
  • Who would benefit: Readers.
  • Proposed solution: It can be solved using Notes section, but maybe other way would be possible to create one cumulative link with all links visible only on mouse over. Or each article could be in two versions - with references and without. But cumulative links appear to be better.
Here is an example: List of mammals of North America
[n 3] replaces [3][8][4][5][6][7], what would be repeated 200-300 times in addition. But this is manual way. Darekk2 (talk) 20:52, 14 November 2016 (UTC)[reply]

Community discussion

  1.   Support Gareth (talk) 03:36, 29 November 2016 (UTC)[reply]
  2.   Oppose I like the creative thinking behind this proposal, but I would rather these instances be resolved by editors of the articles that have them (noting that a cleanup tag can be used to request this), and tweaks to policies/guidelines if necessary. Now, if someone wants to make a script/gadget that automatically combines ref chains, I imagine that would get some use. Stevie is the man! Talk • Work 14:30, 29 November 2016 (UTC)[reply]
  3.   Support --Telaneo (User talk page) 22:17, 29 November 2016 (UTC)[reply]
  4.   Oppose Seems like the proposed solution is policy rather than tech. I doubt there would be consensus for this kind of change, though. There is a design function from having five refs in a row: to visually show the strength of support for a statement, so it's not just for aesthetics' sake. czar 01:26, 2 December 2016 (UTC)[reply]
  5.   Oppose This is actually a matter of style guides. CMOS reads "Although more than one note reference should never appear at a single location (such as5, 6), a single note can contain more than one citation or comment (see 14.52). (A system of numbered references used by many medical publications, however, requires such multiple reference numbers; for more on this system, consult the AMA Manual of Style.)" (registration is required and is free for a 30-day trial) 4nn1l2 (talk) 14:05, 2 December 2016 (UTC)[reply]
  6.   Oppose When their is a large bunch of references, editors should trim all but the best of them. Doc James (talk · contribs · email) 03:46, 3 December 2016 (UTC)[reply]
  7.   Oppose Cite-overkill is an operator problem, not a software problem. 04:03, 11 December 2016 (UTC)

  • Problem: Forwarding to link #targets in redirects only works with JavaScript enabled. Without JavaScript, a redirect like
#redirect [[link#target]]
will forward the user to the top of the article, not to the specified #target anchor inside of the article, just as if the redirect would have been:
#redirect [[link]]
  • Who would benefit: Any Wikipedia user, who cannot enable JavaScript for technical or security reasons.
  • Proposed solution: To me it looks as if the specfied link #targets do not get passed on without JavaScript (for reasons unknown to me), and as if not stripping them off would already solve the problem.
  • More comments:
This is not only a significant inconvenience for users, but some editors use this shortcoming as an argument to replace links to redirects by directly piped links in source articles against established editing guidelines like WP:NOTBROKEN, WP:NOPIPE, MOS:NOPIPE.
Since linking through redirects helps to build the web, improving semantic web and reverse lookup facilities, and keeps articles maintainable through contents reorganizations, these editors thereby actively act against the goals of our project. It is therefore important to make redirects fully functional - including without JavaScript.
JavaScript should never be assumed to be a prerequisite to use Wikipedia - some browsers don't support it, and even if they do, some users cannot enable it as JavaScript imposes security risks.

Community discussion

From what I read there it appears to be a question of (wrong) priorities to me. At the minimum, the "(Redirected from [x])" top message could be expanded to "(Redirected from [x] to [#y])", so that users not using JavaScript could jump to the corresponding anchor #y easily (thereby needing two rather than one click to get there compared to users with JavaScript). Even better, of course, would be to change the implementation to not require JavaScript for the redirect at all.
--Matthiaspaul (talk) 01:51, 16 November 2016 (UTC)[reply]
  • Support at least the workaround of (Redirected from [x] to [#y]). As someone who does browse Wikipedia with JavaScript disabled, it is a significant inconvenience to either have to scroll through long pages to find the section that was the target of the redirect or to currently use three clicks (and page loads): once for the failed redirect, second to click on the (Redirected from [x]) to get to the redirect page and finally a third click on the text of the redirect, itself, to get to the right section of the right page. Two clicks without page reloads would be a significant improvement. Of course, having this work with one click would be even better but don't let the perfect be the enemy of the good. 24.151.10.165 16:00, 22 November 2016 (UTC)[reply]

  1.   Support Anthonyhcole (talk) 01:51, 29 November 2016 (UTC)[reply]
  2.   Support Guycn2 · ☎ 19:11, 29 November 2016 (UTC)[reply]
  3.   Support --Telaneo (User talk page) 22:14, 29 November 2016 (UTC)[reply]
  4.   Support Stevie is the man! Talk • Work 21:52, 4 December 2016 (UTC)[reply]
  5.   Support --LikeLifer (talk) 00:45, 5 December 2016 (UTC)[reply]
  6.   Support ----Iztwoz (talk) 20:16, 7 December 2016 (UTC)[reply]
  7.   Support --Waldir (talk) 12:01, 10 December 2016 (UTC)[reply]
  8.   Support —Ynhockey (talk) 15:57, 10 December 2016 (UTC)[reply]
  9.   Support --Plagiat (talk) 18:59, 11 December 2016 (UTC)[reply]
  10.   Support --Soluvo (talk) 01:04, 12 December 2016 (UTC)[reply]
  11.   Support — NickK (talk) 17:48, 12 December 2016 (UTC)[reply]
  12.   Support --Yann (talk) 23:36, 12 December 2016 (UTC)[reply]

Readers comments and vote

  • Problem: There is a lot of articles which have problems because we don't know the what people exactly want to know in the article. There is also no exact information about people favorite articles. (Not most viewed)
  • Who would benefit: All the persons who read Wikipedia articles.
  • Proposed solution: Add a comment space for readers. Add a thumb-up and thumb-down counter on the top of pages, which people could vote for articles.
  • Phabricator tickets:

Community discussion

We already had that as mw:Article feedback/Version 5 and it was swamped with useless commentary. Jo-Jo Eumerus (talk, contributions) 09:46, 20 November 2016 (UTC)[reply]
The concept of feedback is highly desirable, the way Article feedback/Version 5 was implemented made it a disaster, and it has poisoned the waters because of some poor choices which encouraged useless feedback. A feed-back questionnaire should always allow the reader to bail out without comment, should NEVER make suggestions of what the feedback should be, and from previous experience, should possibly explain to the reader what feedback is and what it is for, because most responders apparently had no idea. · · · Peter (Southwood) (talk): 10:46, 29 November 2016 (UTC)[reply]

Voting – Readers comments and vote

  1.   Oppose per the comment above: when we tried it through 4-5 iterations, the data was very poor, and the quality of the feedback was awful (I filtered through it previously as a reviewer for a while). Perhaps, we could try some type of peer review of the feedback by readers, to make sure its not crap before editors can see it: but there was so much awful comments on the topic itself, not the content, I would be suprised if anything worthwhile comes through. Sadads (talk) 15:26, 28 November 2016 (UTC)[reply]
  2.   Oppose per Jo-Jo Eumerus and Sadads. Perhaps a more direct (and likely much simpler) solution is in order: ensuring that readers understand that if they think something is missing in an article, they can bring that up on the article's talk page. Stevie is the man! Talk • Work 15:52, 28 November 2016 (UTC)[reply]
  3.   Support Darekk2 (talk) 20:55, 30 November 2016 (UTC)[reply]
  4.   Oppose The WMF already tried this and we got left with a stinking mound of garbage in response. No. MER-C (talk) 05:31, 1 December 2016 (UTC)[reply]
  5.   Oppose Feedback suck... --Nouill (talk) 13:56, 1 December 2016 (UTC)[reply]
  6.   Oppose Readers are already invited to add comments to a Talk page, and that's probably the best-quality feedback we'll get. —Patrug (talk) 23:41, 1 December 2016 (UTC)[reply]
  7.   Oppose This isn't gonna work. --Fixer88 (talk) 20:49, 2 December 2016 (UTC)[reply]
  8.   Comment We used to have this in the feedback tool. I liked it. It however generated more feedback than editors wanted and thus was shut down. Would have been better if it was just rolled out on articles were editors wanted it and would follow up. Ah well. Doc James (talk · contribs · email) 03:49, 3 December 2016 (UTC)[reply]
  9.   Oppose Studmult (talk) 07:56, 5 December 2016 (UTC)[reply]
  10.   Oppose Too much like a social website. --Tryptofish (talk) 00:24, 6 December 2016 (UTC)[reply]
  11.   Support Michal Lester לסטר (talk) 11:31, 12 December 2016 (UTC)[reply]
  12.   Neutral, the only scheme that reasonably works is Polish pl:Wikipedia:Zgłoś błąd w artykule and derivatives. This is not the same as the proposal however, thus I cannot support this — NickK (talk) 17:50, 12 December 2016 (UTC)[reply]
  13.   Oppose --Mikheil Talk 21:24, 12 December 2016 (UTC)[reply]

Simple diff

  • Problem: The normal diff displays article text and wiki markup. For readers only interested in changes to the article text, it's overly complicated and it's sometimes difficult to even find the article text changes among all the templates and other markup.
  • Who would benefit: Anyone who just wants to see changes in the article's text (the meaning, as opposed to the formatting and citations).
  • Proposed solution: Offer the reader/editor both options: the normal diff containing article text and wiki markup, and a simple diff showing just the changes to article text.
  • Phabricator tickets:

Community discussion

Sounds like T105173? --Tgr (WMF) (talk) 23:08, 21 November 2016 (UTC)[reply]

  • Relatedly, the diff system handles paragraph swaps poorly, sometimes appearing like each paragraph was modified rather than moved, so if two paragraphs are swapped and a few words changed, it's hard to see what exactly changed at a glance because the paragraphs appear to be rewritten from scratch according to the diff czar 01:29, 2 December 2016 (UTC)[reply]

Voting – Simple diff

  1.   Support although I want this be as seamless as possible. Perhaps let the user have a default diff mode, then on the diff page, the user can switch modes. This would be very useful for readers and editors. Stevie is the man! Talk • Work 02:22, 28 November 2016 (UTC)[reply]
  2.   Support. Jules78120 (talk) 13:16, 28 November 2016 (UTC)[reply]
  3.   Support, as long as the simple diff is not the default. ThePlatypusofDoom (talk) 17:30, 29 November 2016 (UTC)[reply]
  4.   Support, the mode should be switchable during display of the diff. Maybe the default mode for logged out reader should be the simple mode while for logged-in users it should be the normal mode. --Fixuture (talk) 22:19, 29 November 2016 (UTC)[reply]
  5.   Support SamanthaNguyen (talk) 02:16, 1 December 2016 (UTC)[reply]
  6.   Support Draceane (talk) 10:33, 2 December 2016 (UTC)[reply]
  7.   Support Shubha (talk) 10:40, 2 December 2016 (UTC)[reply]
  8.   Support --Continua Evoluzione (talk) 10:12, 5 December 2016 (UTC)[reply]
  9.   Support --Andropov (talk) 18:46, 5 December 2016 (UTC)[reply]
  10.   Support, quite useful with switchable display modes, as commented above. --Arjuno3 (talk) 03:24, 7 December 2016 (UTC).[reply]
  11.   Support --Iztwoz (talk) 20:11, 7 December 2016 (UTC)[reply]
  12.   Support Preferably with toggle to switch between this and normal view. Rivertorch (talk) 05:44, 8 December 2016 (UTC)[reply]
  13.   Support - Akela (talk) 22:07, 8 December 2016 (UTC)[reply]
  14.   Support I find it hard to make sense of the current diff. Too much white space, for a start, and not enough context. --Ziounclesi (talk) 10:34, 9 December 2016 (UTC)[reply]
  15.   Support - Useful, at times, for experienced editors, as well as others. The paragraph move diff problem is not the same thing, but also would be very helpful to cure (or just improve). --R. S. Shaw (talk) 17:48, 9 December 2016 (UTC)[reply]
  16.   Support Miniapolis 20:39, 9 December 2016 (UTC)[reply]
  17.   Support - DPdH (talk) 19:27, 11 December 2016 (UTC)[reply]
  18.   Support on the condition that references are somehow still visible in the diff (not necessarily in full form) so that it's still possible to detect removal or refs or addition of text to content that is already referenced. Uanfala (talk) 01:18, 12 December 2016 (UTC)[reply]

Better interface and visualisation for coordinates and map

  • Problem: When someone click on a coordinates link, he is redirect to en:Template:GeoTemplate (wp:en version) but :
  • Geohack isn't manage by the WMF. It's a volunteer interface. It's host on wikilabs, It's surely the most used tools of wikilabs. I don't think wikilabs should host so useful tools. So when wikilabs was/will be down, Geohack is down, and for everyone is very complicated to geolocate coordinates on wikipedia without Geohack.
  • Geohack has one version for each wikipedia, I still don't understand why each wikipedia need a different interface and a different list of siteweb for access to a map. Did each wikipedia have a different interface for visualize a picture ?
  • Geohack interface doesn't upgrade (for many reason). The shared part of Geohack's interface doesn't upgrade ; Many and many wiki doesn't upgrade or maintain the "editorial" part of Geohack. Kartographe should be much prominent on lot of version of Geohack. Exemple : Geohack's english version still have it visualization windows down since january 2016, not body care. See the buged grey square on en:Template:GeoTemplate...

Others stuffs :

  • Kartographer should replace some visualisation's tools on lot of wiki, tools like WikiMiniatlas or WikiOpenStreetMap.
  • Kartographer could be used on some infobox on wikipedia. (It's not permit currently, only on Wikivoyage)
  • Lot and lot of coordinates links aren't clickable on wikidata (like on d:Q21650786, d:Q555925, d:Q461210). I have report the problem few month ago, still not resolved...

More generally, I'm a occasional reader of Liveuamap (founded on 2014) or Wikimapia (founded on 2006). For me, Wikimedia should offer similar services...

  • Who would benefit: Reader of geographic pages or pages which have coord on wikipedia/wikipedia/commons/wikinews/wikivoyage...
  • Proposed solution: WMF should more directly manage Geohack. Simple. The developement of Kartographer is done. It's the hard part of the job. Just need to more deploy that.

Community discussion

Yurik's input is probably welcome here to elaborate on existing plans regarding GeoHack and Kartographer and related Phabricator tasks (like phab:T137253). --AKlapper (WMF) (talk) 13:55, 9 November 2016 (UTC)[reply]

After a few conversations, including ones with the GeoHack's author Magnus_Manske and maintainer Dispenser, I feel GeoHack really needs to be phased out. It has been providing a great value, but at the same time it has many fundamental flaws, such as running in unstable and unmonitored labs environment, and low security protection with a possible privacy violations. Most importantly, geohack does not offer any easy integration with the content and functionality of Wikipedia - using geohack is vising a different web site, without any ability to do per-user or other customization, nor good mobile support. In other words, GeoHack has been a perfect proofing ground to see what may be useful, and we should work to migrate its most desired functionality to Kartographer's full screen view (details). Some communities, like ru-wiki, has mentioned that they might be interested to migrate if region-specific external services (e.g. Yandex for ruwiki) are more prominently placed at the top of the list. We may also need to implement per-region/per-country list of external services to capture all the useful tools communities have assembled. --Yurik (talk) 03:39, 10 November 2016 (UTC)[reply]
As yurik says, just get each community to switch them. I might suggest the WMF to link to geohack from the interface of opened maplinks, to possibly ease transition. —TheDJ (talk • contribs) 11:45, 11 November 2016 (UTC)[reply]
Humm. I also have been frustrated by unstable responses to attempts to present geographic coordinates, and would favour a coherent scheme such as seems to be suggested. However my particular interest is in presenting the likes of a Google Earth .kmz file, which currently can only be done via an odd protocol involving the massive text of a .kml file, which file arrives called index.php and must be renamed to index.kml before Google Earth will recognise it. Such a file can contain many coordinates (and annotations, and etc.) but its text form as .kml is large and tedious, and WP does not provide a facility for storing and retrieving such files, as it does with say image files, whose content is not displayed as text. NickyMcLean (talk) 11:14, 10 December 2016 (UTC)[reply]
Wikivoyage shows how Geohack can be integrated inside mediawiki. A filtering is useful to not show tons of local mapservices, that don't cover the area of the coordinate.
As much as I like free geodata, sometimes I need aerial images that I only can get from commercial providers. So we will need geohack also in the future but perhaps more hidden than our own map, as geohack is confusing for normal users.
But maps means not the geohack alone. We need to improve IMO especially the mobil support. --Kolossos (talk) 18:13, 12 December 2016 (UTC)[reply]

Voting – Better interface and visualisation for coordinates and map

  1.   Support Integration Geohack and wikimedia maps--Shizhao (talk) 03:10, 28 November 2016 (UTC)[reply]
  2.   Support--Afernand74 (talk) 19:16, 28 November 2016 (UTC)[reply]
  3.   Support JAn Dudík (talk) 22:10, 28 November 2016 (UTC)[reply]
  4.   Support Anthonyhcole (talk) 01:47, 29 November 2016 (UTC)[reply]
  5.   Support Gareth (talk) 03:43, 29 November 2016 (UTC)[reply]
  6.   Support --Jarekt (talk) 03:36, 30 November 2016 (UTC)[reply]
  7.   Support --Una giornata uggiosa '94 · So, what do you want to talk about? 01:20, 1 December 2016 (UTC)[reply]
  8.   Support This, that and the other (talk) 08:52, 1 December 2016 (UTC)[reply]
  9.   Support Ermahgerd9 (talk) 19:09, 1 December 2016 (UTC)[reply]
  10.   Support -- Haku (talk) 00:14, 2 December 2016 (UTC)[reply]
  11.   Support NMaia (talk) 00:58, 2 December 2016 (UTC)[reply]
  12.   Support Jmvkrecords ⚜ (Intra talk) 10:11, 2 December 2016 (UTC).[reply]
  13.   Support Draceane (talk) 10:35, 2 December 2016 (UTC)[reply]
  14.   Support Shubha (talk) 10:41, 2 December 2016 (UTC)[reply]
  15.   Support —Jc86035 (talk) 11:19, 2 December 2016 (UTC)[reply]
  16.   Support Important point: "We may also need to implement per-region/per-country list of external services to capture all the useful tools communities have assembled". Cf. [3]. --Thgoiter (talk) 11:45, 2 December 2016 (UTC)[reply]
  17.   Support --Adert (talk) 22:27, 2 December 2016 (UTC)[reply]
  18.   Support --Yiyi (talk) 15:44, 3 December 2016 (UTC)[reply]
  19.   Support Pamputt (talk) 11:01, 4 December 2016 (UTC)[reply]
  20.   Support -- the wub "?!" 14:15, 4 December 2016 (UTC)[reply]
  21.   Support --By erdo can • TLK 17:01, 4 December 2016 (UTC)[reply]
  22.   Support whatever improvements can be made in this area. Stevie is the man! Talk • Work 22:03, 4 December 2016 (UTC)[reply]
  23.   Support --Continua Evoluzione (talk) 10:12, 5 December 2016 (UTC)[reply]
  24.   Support --Yeza (talk) 10:14, 5 December 2016 (UTC)[reply]
  25.   Support --β16 - (talk) 11:32, 5 December 2016 (UTC)[reply]
  26.   Support Sadads (talk) 15:00, 5 December 2016 (UTC)[reply]
  27.   Support --Kogo (talk) 12:56, 6 December 2016 (UTC)[reply]
  28.   Support Blue Rasberry (talk) 19:34, 6 December 2016 (UTC)[reply]
  29.   Support --Arjuno3 (talk) 03:27, 7 December 2016 (UTC)[reply]
  30.   Support with reference to that → «« Man77 »» [de] 12:39, 7 December 2016 (UTC)[reply]
  31.   Support TheCatalyst31 (talk) 04:21, 8 December 2016 (UTC)[reply]
  32.   Support — Rhododendrites talk \\ 14:31, 8 December 2016 (UTC)[reply]
  33.   Support Ayack (talk) 11:59, 9 December 2016 (UTC)[reply]
  34.   Support --Spencer (talk) 14:42, 9 December 2016 (UTC)[reply]
  35.   Support -- FriedhelmW (talk) 19:35, 9 December 2016 (UTC)[reply]
  36.   Support —Ynhockey (talk) 19:48, 9 December 2016 (UTC)[reply]
  37.   Support --OrsolyaVirág (talk) 11:52, 10 December 2016 (UTC)[reply]
  38.   Support --Sabas88 (talk) 17:05, 10 December 2016 (UTC)[reply]
  39.   Support --Plogeo (talk) 19:09, 10 December 2016 (UTC)[reply]
  40.   Support Ale And Quail (talk) 05:04, 11 December 2016 (UTC)[reply]
  41.   Support - DPdH (talk) 19:30, 11 December 2016 (UTC)[reply]
  42.   Support--David1010 (talk) 20:42, 11 December 2016 (UTC)[reply]
  43.   Support --Soluvo (talk) 01:06, 12 December 2016 (UTC)[reply]
  44.   Support Michal Lester לסטר (talk) 11:32, 12 December 2016 (UTC)[reply]
  45. Conditional   Support, only if local communities will still have choice to add or remove certain lines. If you look at geohack in different wikis you will notice that many communities have chosen their own interface, usually for a reason. It would be harmful to force all of them use the same interface and the same set of websites: while ruwiki might want to place Yandex on top, bewiki may want to keep it in the middle and ukwiki might want to remove it from the list altogether. This should not be MediaViewer #2, so please let local communities decide — NickK (talk) 17:57, 12 December 2016 (UTC)[reply]
  46.   Support --Kolossos (talk) 18:13, 12 December 2016 (UTC)[reply]
  47.   Support--Mikheil Talk 21:24, 12 December 2016 (UTC)[reply]
  48.   Support --Yann (talk) 23:37, 12 December 2016 (UTC)[reply]

Browser reading list

  • Problem: Though the mobile application gives you the option to create reading lists of articles and also save them offline, this feature is missing when accessing Wikipedia through browsers, be it the desktop or the mobile version, a desktop browser or a mobile application browser.
  • Who would benefit: Giving the option to registered users to make reading lists, will attract more people to actually create an account and as a result to get more involved in editing Wikipedia. Of course, this feature main purpose is to give the users the chance to organise better how to study topics on Wikipedia, which ultimately is the essence of an encyclopedia.
  • Proposed solution: Simply create a gadget or a settings feature that gives you that option.
  • More comments: The watchlist doesn't come handy for this, as a watchlist's main goal is to make editing and not reading easier.
  • Phabricator tickets:

Community discussion

Voting – Browser reading list

  1.   Support--Shizhao (talk) 03:09, 28 November 2016 (UTC)[reply]
  2.   Support, phab:T91902. --Fixuture (talk) 22:20, 29 November 2016 (UTC)[reply]
  3.   Support Ermahgerd9 (talk) 19:17, 1 December 2016 (UTC)[reply]
  4.   Support --Barcelona (talk) 14:19, 2 December 2016 (UTC)[reply]
  5.   Support See also 2015 survey: 2015 Community Wishlist Survey/Reading#Reading List. 4nn1l2 (talk) 14:23, 2 December 2016 (UTC)[reply]
  6.   Support Ale And Quail (talk) 03:58, 11 December 2016 (UTC)[reply]
  7.   Support Giorgos ab1234 (talk) 13:07, 11 December 2016 (UTC)[reply]
  8.   Support - Have been asking for this for nearly a decade. DPdH (talk) 13:26, 11 December 2016 (UTC)[reply]
  9.   Support It's ridiculous that a tool already developed is being held back from the regular version of the site.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  19:08, 11 December 2016 (UTC)[reply]
  10.   Support – Uanfala (talk) 01:20, 12 December 2016 (UTC)[reply]
  11.   Support Just support! And I propose the possibility to create separate reading lists (like "Nature", "Places to visit" etc. And synchronizing with the mobile app (for registered users). The feature is not only for readers - I have in the mobile app the list "To edit in computer" because of complexicity of requered changes in article. --KuboF (talk) 23:31, 12 December 2016 (UTC)[reply]

Debug PDF export for Non-Latin scripts

  • Problem: PDF export is having multiple issues with "exotic" scripts, for example (all ocurring in w:de:Dad (Arabischer Buchstabe)):
    • letters in Latin transcription of Arabic appear in the wrong order (rawādfi instead of correct rawādif)
    • words in Latin transcription of Arabic appear in the wrong order (aḍ-ḍād luġat instead of correct luġat aḍ-ḍād)
    • strange behaviour in case of word wrap (ḥarf ḥāffat al-lisān gets wrapped ḥarf / al-lisān ḥāffat)
    • in a reference (Thackston, currently #86) the Arabic text of the weblink does not display, similarly in another reference (Kashmiri, currently #79) neither the Arabic text nor the Devanagari text are visible in the PDF
    • in the table of figures (10.2 Bilder) Arabic letters are not connected, letters are instead displayed in their isolate state (ض‌د instead of correct ضد)
  • Who would benefit: PDF exporters, offline readers
  • Proposed solution: Fix those bugs ;) Onwiki it is possible to get it right, so it will be in PDF.
  • Phabricator tickets: T73869 (Bidirectional text sometimes in wrong order in PDF)

Community discussion

Is this about the MediaWiki PDF export feature ("Download as PDF" link in sidebar), the browser functionality (e.g. Ctrl+P, "Save as PDF" in Chrome) or something else? --Tgr (WMF) (talk) 23:04, 21 November 2016 (UTC)[reply]

Hi Man77, can you answer this question? We need some more details for the problem statement here. -- DannyH (WMF) (talk) 21:02, 22 November 2016 (UTC)[reply]
Thanks for question. These are bugs of the "Download as PDF" feature provided in the sidebar. → «« Man77 »» [de] 21:42, 22 November 2016 (UTC)[reply]

"Export as PDF" seems to generate mojibake for Chinese text while "Books" don't, per w:zh:User:星耀晨曦 on zhwp VPT. --Artoria2e5 (talk) 17:11, 30 November 2016 (UTC)[reply]

Voting – Debug PDF export for Non-Latin scripts

  1.   Support. -Anthonyhcole (talk) 01:36, 29 November 2016 (UTC)[reply]
  2.   Strong support Very good to me. --Liuxinyu970226 (talk) 11:10, 30 November 2016 (UTC)[reply]
  3.   Support. --Artoria2e5 (talk) 17:09, 30 November 2016 (UTC)[reply]
  4.   Support → «« Man77 »» [de] 21:57, 1 December 2016 (UTC)[reply]
  5.   Support better support for Non-Latin scripts 4nn1l2 (talk) 14:24, 2 December 2016 (UTC)[reply]
  6.   Support Everything improving the PDF export would be a good thing. And if this is done then it also would be a nice thing to:
    fix the completely missing table display in PDF export and
    fix the broken german Template:Wide image display in PDF export. See discussion de:Vorlage Diskussion:Panorama#Buchdruck_und_PDF_Export (german language). --StefanMeister (talk) 19:53, 3 December 2016 (UTC)[reply]
  7.   Support Pamputt (talk) 11:02, 4 December 2016 (UTC)[reply]
  8.   Support --LikeLifer (talk) 00:39, 5 December 2016 (UTC)[reply]
  9.   Support --HHill (talk) 10:49, 5 December 2016 (UTC)[reply]
  10.   Support Support anything related to PDF and Book export --Ziounclesi (talk) 10:30, 9 December 2016 (UTC)[reply]
  11.   Support Lt2818 (talk) 11:16, 9 December 2016 (UTC)[reply]
  12.   Support --Plagiat (talk) 18:56, 11 December 2016 (UTC)[reply]
  13.   Support — NickK (talk) 18:03, 12 December 2016 (UTC)[reply]
  14.   Support We are world-wide movement and we should help people of as many languages as possible to acces libre knowledge. --KuboF (talk) 23:35, 12 December 2016 (UTC)[reply]

Display the authorship of a Wikipedia page

  • Problem: Authors deserve attribution: knowing who created something is obviously useful to everybody. Commons, for example, shows the author of a photograph in a clear way, but on Wikipedia, readers have to find and click a few hyperlinks to find out who wrote the article they are reading.
  • Who would benefit: Wikipedia readers and authors
  • Proposed solution: There are, of course, many authors to a single WP page, but I think the, say, 5 authors who have written the highest percentage of the article should be recognised at the top of every page. Here is a mock-up, which should go below the page title:

Authored by user:example1 (27%), user:example2 (19%), user:example3 (13%), user:example4 (10%), user:example5 (8%) ... and 13 more

  • More comments:
  • Userpages will get a lot more traffic, because of the prominent links. This allows the general readership to gain insight into the authors, which I think is a good thing for reader trust of an article's quality.
  • Authors will be vying to find themselves in this top 5 spots, so if we simply rank by how much of the article they've written, this will encourage longer and longer articles. To encourage quality, not quantity, it might instead be better to rank by number of contributions to an article, or some other metric (or combination of metrics).
Either way, it's important that authors are recognised in a far more prominent way on Wikipedia, because they deserve credit for their work.
  • There is also a possibility for that this would clash with the Metadata gadget. I think it should be fine to put the authors below the assessment, in which case it's not an issue.
  • Finally, to be clear, I am writing this request as someone who mainly reads WP.
  • Phabricator tickets:

Community discussion

  • This is highly non-trivial when one takes vandalism into consideration. I don't think this would be feasible performance-wise. MER-C (talk) 04:33, 14 November 2016 (UTC)[reply]
    • Even if you can identify full recerts and ignore anything between the original time the revision showed up and the revert, you still nbeed to deal with issues such as texct being moved around, incorperationg text from an older revision which had since been removed, significant grammar changes or tense changing, etc. עוד מישהו Od Mishehu 06:03, 14 November 2016 (UTC)[reply]
  • My ego loves this idea, but I have the same concerns expressed above. Editors feeling they are in a contest to get their name in lights would seem to work against the Wikpedia's best interests. The current tool for viewing similar stats ("Revision history statistics") should be as far as we go. Perhaps a compromise would be to link to this tool from the article, near the quality info, with the text "Authorship info". Stevie is the man! Talk • Work 15:48, 14 November 2016 (UTC)[reply]
  • I'm afraid this feature could be easily abused. You cannot automatically detect the main authors of the article. But even if you can do it with 95% accuracy, one can use the 5% of inaccuracy to make changes specially to trick the algorithm to believe that this article is written mainly by them. Some users could do it even unintentionally. Alexei Kopylov (talk) 20:30, 14 November 2016 (UTC)[reply]
  • This would require WIDE community support, for which i currently see no evidence here. Tasks like that are thus unlikely to be taken up by the community tech team I think. —TheDJ (talk • contribs) 20:43, 14 November 2016 (UTC)[reply]
  • Thanks for the comments. I can see this might be abused, but a discussion at least needs to be raised about this point within the community, because readers need to know who wrote what they're reading. Stevie's "Authorship info" link might well be a suitable compromise, though I'd prefer to see it under the title like on any other document. -- Thennicke (talk) 02:26, 15 November 2016 (UTC)[reply]
    • On the English Wikipedia, articles show something like "A B-class article from Wikipedia, the free encyclopedia" under the title. I was thinking " • Authorship info" (the underscore being a link) could follow that. Stevie is the man! Talk • Work 15:27, 19 November 2016 (UTC)[reply]
    • Yes, there are many parasites changing only sequence of words and even spoiling articles, or splitring them etc. It is difficult to recognize real edit. Maybe for example authors adding references, not necessarily in given edit are more dependable. Or words could be compared. If almost same words or they forms are used, such edit would not be accounted to the authorship.
      Perhaps such tool would be useful. Better such one than no one. I think that this worth to develop. Darekk2 (talk) 18:51, 20 November 2016 (UTC)[reply]
  • Per Stevie. Daniel Case (talk) 01:42, 16 November 2016 (UTC)[reply]
    Write an essay "en:WP:Who wrote this page?" or similar, which would explain links to the page's author stats under "Revision history statistics". -Wikid77 (talk) 13:47, 18 November 2016 (UTC)[reply]

I have just completely overwritten an article and it went from 74Kb to 64Kb in size (and drastically improved in quality). The overlap of previous writing and the new article is a just a couple kilobytes. In the diff my edit shows as "minus 10 Kbytes". So I should be credited as the main author (I wrote 95% of it) but there is no feasible way to determine this programmatically. --SSneg (talk) 18:17, 19 November 2016 (UTC)[reply]

  • We built something similar here [4] and there was an option were one could turn this on for medical articles. "Authors" than linked to [5] which gives a break down by number of edits and bytes of edit. That page however could use some improvement. One could subtract out reverts by canceling out those edits. Doc James (talk · contribs · email) 18:36, 19 November 2016 (UTC)[reply]
  • It would make sense to separate the issue of where to display authorship information (trivial technical task, needs consensus) from having it in the first place (nontrivial technical task, does not need consensus). Depending on how you define the authorship metric, this can range from easy to very hard (but more useful). See for example Research:Content_persistence for a good but hard to compute metric (% of words written). --Tgr (WMF) (talk) 23:00, 21 November 2016 (UTC)[reply]
  • This isn't something I'd like to see automated. Identification of the main authors can take place on the article's talk page. --Anthonyhcole (talk) 02:36, 29 November 2016 (UTC)[reply]
  • The whole world doesn't need to see a list of usernames on every article, most of them pseudonyms and many of them silly, enigmatic or unreadable. Noyster (talk) 00:28, 1 December 2016 (UTC)[reply]

Voting – Display the authorship of a Wikipedia page

  1.   Oppose IKhitron (talk) 12:18, 29 November 2016 (UTC)[reply]
  2.   Support only the compromise that I laid out above (provide an "Authorship info" link to "Revision history statistics"). The original proposal is too problematic to implement, per discussion above. Stevie is the man! Talk • Work 14:41, 29 November 2016 (UTC)[reply]
  3.   Oppose !! Darekk2 (talk) 16:54, 4 December 2016 (UTC)[reply]
  4.   Support Much needed. The lack of this feature is the main reason why third parts who copy and reuse Wikipedia articles do not attribute at all the authors of the work they're reusing (or, in the best case, they just state "source: Wikipedia" which is clearly not enough). Nobody can humanly bother browsing the history page and counting by hand how many edits anyone has made, to see which one is worth crediting. There should be an automatic tool doing this, so that the reuser can easily find a short, standard list of significant users to credit. I don't think there is the risk of users abusing this tool: Wikipedia is 15 years old and most pages have thousands of edits; it takes quite an effort to overcome years and years of edits and enter the top five if you don't really make deep changes to the article. In most articles, top 5-10 editors have a much, much higher editcount than those who rank 10 or more, so it's really hard to surpass them (in particular, there's no way the same vandal could make so many edits to surpass them withouth being blocked); this feature can be disabled for new articles with too little edits, so that vandals don't get the chance to make it into the top five. I think that even a simple algorithm will end up actually showing significant users (algorithms as simple as counting how many edits you made, or counting how many overall bytes were added by you). I think authorship info (with usernames) should be kept in the article page (for example at the bottom, near the "Privacy informations" etc.); if the community thinks a link to a separate page is more appropriate I suggest at least that the link is located in a well-visible place: it must be easy to find if we want reusers to notice it when he reuses Wikipedia content. In addition, it should also appear in the history page and, more importantly, in en:Special:CiteThisPage. --Una giornata uggiosa '94 · So, what do you want to talk about? 02:06, 1 December 2016 (UTC)[reply]
  5.   Oppose It sounds nice in theory but it will be too easy to generate a false positive. Does changing the punctuation in every sentence count for more than writing half the article? The Xtools offers pie charts for article authorship and this is what happens a lot. Connor Behan (talk) 19:16, 1 December 2016 (UTC)[reply]
  6.   Oppose How would you differentiate between someone writing lengthy entries into Wikipedia (providing the substance to the article) and the someone else moving that entire segment to another part of the page? Does the second person get credit for all those words moved because technically they introduced it to a new area? More broadly, how will this help the site besides inflating the egos of some people who would clearly abuse having their (potentially unintelligible) usernames all over the pages of this site? Semmendinger (talk) 19:38, 1 December 2016 (UTC)[reply]
  7.   Support First, we should fix the long-broken Revision History Statistics (so that Text Share isn't blank), and add Content Persistence or any other metrics that are better than raw # Edits (which often gives high rankings to insignificant tweaking from bots & gnomes). Then, pick more prominent place(s) to display the Revision History Statistics link as "Authorship info". —Patrug (talk) 23:27, 1 December 2016 (UTC)[reply]
  8.   Oppose --JB82 (talk) 01:19, 2 December 2016 (UTC)[reply]
  9.   Comment (1) I fear that this is against the spirit of Wikipedia, or perhaps a clash of spirits—some clearly see article credits as a game and will be emboldened/encouraged by such a change, but I imagine more see any additional opportunity to game stats as being against the spirit of collaboration. (2) If this for whatever reason is implemented, I would much sooner rather the breakdown be by percentage of prose written in the current version. For example, if no text remains from the original 2006 version of an article, there's no reason that author should be "credited" for having the highest number of edits (regardless of contribution) when none of their work is in the current draft. I imagine that this is much harder to calculate, but it much better approximates the truest representation of authorship for attribution's sake. czar 01:23, 2 December 2016 (UTC)[reply]
  10.   Oppose Jmvkrecords ⚜ (Intra talk) 10:13, 2 December 2016 (UTC).[reply]
  11.   Support Doc James (talk · contribs · email) 03:50, 3 December 2016 (UTC)[reply]
  12.   Support Daylen (talk) 06:28, 3 December 2016 (UTC)[reply]
  13.   Oppose I don't like the idea, to encourage authors to be in the top 5 list. I'm against this kind of competition. -- Ulanwp (talk) 21:45, 3 December 2016 (UTC)[reply]
  14.   Oppose If you want your name on top (!) of it, publish it somewhere else Studmult (talk) 07:47, 5 December 2016 (UTC)[reply]
  15.   Oppose per above comments. --Tryptofish (talk) 00:27, 6 December 2016 (UTC)[reply]
  16.   Oppose while I actually appreciate the healthy competition this would create between contributing editors, I fear, as pointed above, that it would be difficult or even impossible to check automatically the main contributors to an article. Would it be bytes added or removed? (that would create a problem with people who edit an article to make it better, but actually remove superfluous wording, untrue details or vandalism. It would also be totally wrong for pages such as sports seasons, where the majority of ongoing edits are changes of details, and not addition of). Would it be by number of edits? (that would create a problem of people making edits by quantity over quality - a problem which already somewhat exists because of the edit count tools, which some users love displaying on their pages). I have not seeing a comment above convincing me this is feasible automatically. --SuperJew (talk) 19:38, 6 December 2016 (UTC)[reply]
  17.   Strong oppose On the most basic level, it's antithetical to core community norms and the collaborative wiki basis of the site. More practically, percentages aren't actually reliable measures of contributions. Nor edit count. There's the name of the person who created it to begin with, which could've been a redirect or unsourced stub, but that's already visible [without having to click twice] via the xtools gadget. Having a list of top contributors (or even all contributors) would also add clutter (assuming it's to be visible by default). And it would create a scoreboard, which, again, is problematic on the most fundamental levels. — Rhododendrites talk \\ 14:16, 8 December 2016 (UTC)[reply]
  18.   Oppose -- FriedhelmW (talk) 19:24, 9 December 2016 (UTC)[reply]
  19.   Oppose, there's no way of calculating the actual input share automatically --NaBUru38 (talk)
  20.   Oppose -- Goonsquad LCpl Mulvaney (talk) 04:01, 11 December 2016 (UTC)[reply]
  21.   Oppose -- Not how Wikipedia works. If someone blanks a large section and I replace it, immediately or 6 months later, would any system be able credit it's original authors? All far too messy. But a clearer link to page history, for mobile readers too, would be useful. PamD (talk)•
  22.   Support - In the way described by StevieistheMan. DPdH (talk) 13:31, 11 December 2016 (UTC)[reply]
  23.   Oppose Wiki pages are authored by a community, not credited "authors". This "I'm an author" mentality is causing severe problems at en.wp. Nothing at all should be done to embolden it; rather, steps should be taken to minimize it.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  19:02, 11 December 2016 (UTC)[reply]
  24.   Oppose as potentially controversial. I am not aware of any method that would be reasonably accurate in measuring % of contributions of each individual author. In addition, this is not a value we should present to a reader — NickK (talk) 17:46, 12 December 2016 (UTC)[reply]
  25.   Oppose Something similar (without percentage) is on Polish Wikivoyage, see e.g. voy:pl:Słowacja on bottom. It distracts attention by GUI smog and I am very happy that it is not on another projects I am using. --KuboF (talk) 23:45, 12 December 2016 (UTC)[reply]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2016/Categories/Reading&oldid=21242930"