Community Wishlist Survey 2017/Reading

Community Wishlist Survey 2017

Reading

13 proposals, 229 contributors

Download as eBook on WikiBooks

Edit proposal/discussion

Problem: users want to read the WikiBooks in eBook format

Who would benefit: all users

Proposed solution:

More comments:

Phabricator tickets:

Proposer: Toniperis (talk) 07:34, 13 November 2017 (UTC)[reply]

Translations: none yet

Discussion

Voting

Support Boehm (talk) 22:07, 27 November 2017 (UTC)[reply]
Support MichaelSchoenitzer (talk) 22:45, 27 November 2017 (UTC)[reply]
Support NMaia (talk) 00:14, 28 November 2017 (UTC)[reply]
Support —viciarg⁴¹⁴ 08:38, 28 November 2017 (UTC)[reply]
Support --Liuxinyu970226 (talk) 13:23, 28 November 2017 (UTC)[reply]
Support --OrsolyaVirág (talk) 20:23, 28 November 2017 (UTC)[reply]
Support Thomas Obermair 4 (talk) 23:06, 28 November 2017 (UTC)[reply]
Support Jamez42 (talk) 00:43, 29 November 2017 (UTC)[reply]
Support Shizhao (talk) 03:27, 29 November 2017 (UTC)[reply]
Support Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 11:20, 29 November 2017 (UTC)[reply]
Support Simon Villeneuve 14:56, 29 November 2017 (UTC)
Support —TheDJ (talk • contribs) 16:38, 29 November 2017 (UTC)[reply]
Support Mewtow (talk) 22:07, 29 November 2017 (UTC)[reply]
Support X:: black ::X (talk) 00:31, 30 November 2017 (UTC)[reply]
Support Danii.3 (talk) 13:03, 30 November 2017 (UTC)[reply]
Support Exilexi (talk) 14:37, 30 November 2017 (UTC)[reply]
Support Rachel Helps (BYU) (talk) 17:17, 30 November 2017 (UTC)[reply]
Support Dromedar61 (talk) 21:40, 30 November 2017 (UTC)[reply]
Support Epub Sahaquiel9102 (talk) 21:48, 30 November 2017 (UTC)[reply]
Support For offline reading, for possibility to enlarge the text Hogne (talk) 09:50, 1 December 2017 (UTC)[reply]
Support ~Cybularny ^Speak? 12:54, 2 December 2017 (UTC)[reply]
Support Tom Ja (talk) 14:22, 2 December 2017 (UTC)[reply]
Support Ented (talk) 15:04, 2 December 2017 (UTC)[reply]
Support Otapka (talk) 18:53, 2 December 2017 (UTC)[reply]
Support Victorgrigas (talk) 20:11, 2 December 2017 (UTC)[reply]
Support Paucabot (talk) 19:09, 3 December 2017 (UTC)[reply]
Support HugoHelp (talk) 03:01, 4 December 2017 (UTC)[reply]
Support Halibutt (talk) 15:06, 4 December 2017 (UTC)[reply]
Support Trockennasenaffe (talk) 21:18, 4 December 2017 (UTC)[reply]
Support And why limit only for wikisource? JAn Dudík (talk) 21:56, 4 December 2017 (UTC)[reply]
Support Richard Nevell (WMUK) (talk) 13:45, 8 December 2017 (UTC)[reply]
Support --Nicor (talk) 14:45, 10 December 2017 (UTC)[reply]
Support Ruslik (talk) 17:00, 10 December 2017 (UTC)[reply]

A new wiki skin developed specifically with readers in mind

Edit proposal/discussion

Problem:
- Many sites, like Wikiwand, and browsers, like Readable wikipedia exists to solve a "readability" problem of wikipeia.
- They are apparently more readable than wikipedia interface according to their users, and thus some wikipedia readers switched away from wikipedia to those sites
- As those sites does not have an edit button to lead people back to edit the page on wikipedia, if the situation continue with more and more reader using these alternative sites instead, there could be a reduction in wikipedia's source of editor in the future

Who would benefit: The entire wiki community

Proposed solution: Develop a skin for these wikipedia readers, and then after extensive trials and ask for feedback from all wikipedian and wikimedian communities, consider how to make the skin available to users especially unregistered anonymous readers.

More comments:

Phabricator tickets:

Proposer: I’m happy to own this. Doesn’t have to be a skin, per se; any solution that simplifies and improves our presentation and readability will do, up to and including dumping MediaWiki for everything but editing. —Anthonyhcole (talk) 03:05, 17 November 2017 (UTC)[reply]

Translations: none yet

Discussion

Endorse. Readability of regular wiki is a pain. I had to tweak my user CSS manually to change font type, font size, text width,... A new skin is an interesting idea imho. Afernand74 (talk) 14:42, 18 November 2017 (UTC)[reply]
This request is similar to the work that Isarra put in to the Timeless skin, as well as the split that the Reading team worked on to get Minerva into its own skin. mw:Skin:Timeless is the Mediawiki page and they are generally working on deploying right now. --Izno (talk) 03:29, 19 November 2017 (UTC)[reply]
- Some wiki like French Wikipedia have already enable the Timeless skin, see this page as an example. I have considered about the skin when writing about it but I don't think it addressed some of the main concern brought up by peoples who create other tools to replace wikipedia interfaceC933103 (talk) 23:29, 19 November 2017 (UTC)[reply]
  - What problems? --Izno (talk) 03:32, 20 November 2017 (UTC)[reply]
- MinervaNeue is a reader-centric skin, although heavily optimized for mobile devices. (random example) --Tgr (WMF) (talk) 02:17, 20 November 2017 (UTC)[reply]
  - Yes, MinervaNeue is specifically optimized for readers. It's unlikely that we will switch to it as the default skin any time soon though. Ryan Kaldari (WMF) (talk) 23:50, 20 November 2017 (UTC)[reply]
The typography on Wikipedia (and Mediawiki in general) is terrible, and with such a vast selection of CSS/front-end frameworks to choose from that put an emphasis on typography, it really shouldn't be like that. See some of the "skins" here. François Robere (talk) 16:53, 9 December 2017 (UTC)[reply]

Voting

Support --Liuxinyu970226 (talk) 13:23, 28 November 2017 (UTC)[reply]
Support Thomas Obermair 4 (talk) 23:06, 28 November 2017 (UTC)[reply]
Support Libcub (talk) 05:17, 29 November 2017 (UTC)[reply]
Support Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 11:20, 29 November 2017 (UTC)[reply]
Support Ermahgerd9 (talk) 20:45, 29 November 2017 (UTC)[reply]
Support Zhangj1079 ^talk 01:52, 30 November 2017 (UTC)[reply]
Support Nocowardsoulismine (talk) 02:31, 30 November 2017 (UTC)[reply]
Support Rampion 07:29, 30 November 2017 (UTC)[reply]
Support Nizil Shah (talk) 18:38, 30 November 2017 (UTC)[reply]
Support Dromedar61 (talk) 21:35, 30 November 2017 (UTC)[reply]
Support Sahaquiel9102 (talk) 21:48, 30 November 2017 (UTC)[reply]
Support ThePlatypusofDoom (talk) 00:09, 1 December 2017 (UTC)[reply]
Support Tom Ja (talk) 14:25, 2 December 2017 (UTC)[reply]
Support Afernand74 (talk) 16:37, 2 December 2017 (UTC)[reply]
Support Nabla (talk) 22:19, 2 December 2017 (UTC)[reply]
Support Ciao • Bestoernesto • ✉ 02:57, 4 December 2017 (UTC)[reply]
Support — Bilorv (talk) 01:55, 6 December 2017 (UTC)[reply]
Support Ahm masum (talk) 21:08, 7 December 2017 (UTC)[reply]
Support Richard Nevell (WMUK) (talk) 13:46, 8 December 2017 (UTC)[reply]
Support François Robere (talk) 16:43, 9 December 2017 (UTC)[reply]
Support Tokenzero (talk) 18:53, 10 December 2017 (UTC)[reply]
Support Jack who built the house (talk) 22:42, 10 December 2017 (UTC)[reply]
Support There realy is a need for a new contemporary, responsive skin to relace Vector on desktop. Especially the way to long line-length needs to be limited. Martin Kraft (talk) 17:46, 11 December 2017 (UTC)[reply]

Simple diff

Edit proposal/discussion

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: I have a use in mind for this that is aimed at academic reviewers and the general reader but patrollers, editors and authors will benefit from this feature too.

Proposed solution: Offer both options: the normal diff containing article text and wiki markup, and a simple diff showing just the changes to article text.

More comments:

Phabricator tickets:

Proposer: Anthonyhcole (talk) 23:16, 11 November 2017 (UTC)[reply]

Translations: none yet

Discussion

I recommend flipping a few times between these two images in a media viewer. Compare the experiences. Anthonyhcole (talk) 14:37, 12 November 2017 (UTC)[reply]

What about changes in files, references, tables and templates? --Vachovec1 (talk) 19:13, 12 November 2017 (UTC)[reply]
- Vachovec1: Sure. If it’s technically possible to display the original and replacement citation, image, category, table, etc., I’m all for it. (To be clear, I’m talking about a diff where the original image, citation, etc. itself, not its code, appears in the left column and the replacement image, citation, etc., not its code, appears in the right column.) The more that can be included in the simple diff, the better, provided it”s all simple and not code, but if the best that can be achieved initially is just a diff showing how the text of the article has changed, that’s OK, too. This isn’t going to replace the standard diff, and a diff showing just article word changes would be of benefit to editors. That said, maybe there should be a warning at the top pointing out the kinds of changes that the diff doesn’t highlight. —Anthonyhcole (talk) 06:47, 13 November 2017 (UTC)[reply]
I really would like to see an API for this, but it might not for performance reasons. MER-C (talk) 04:16, 13 November 2017 (UTC)[reply]
- MER-C, I’m not technically literate but this conversation with James Forrester leaves me thinking a simple diff might be doable once the visual editor diff is a bit more mature. —Anthonyhcole (talk) 06:47, 13 November 2017 (UTC)[reply]
Is this basically mw:VisualEditor/Diffs? Anomie (talk) 17:42, 13 November 2017 (UTC)[reply]
Anomie, can I link to a visual diff comparing versions in a page’s history? Do I need to do something in my preferences? —Anthonyhcole (talk) 03:11, 14 November 2017 (UTC) I’ve just been told to add &visualdiff to a standard diff url and select “visual (beta)”, like this: https://en.wikipedia.org/w/index.php?diff=749832945&oldid=749832814&title=User:Anthonyhcole/Sandbox&visualdiff which achieves nothing like what I’m looking for, unfortunately. Compare that diff (after selecting “Visual (beta)”) with this. The latter is the same two pages in the standard diff with all the code and markup removed - just article text. Anthonyhcole (talk) 10:29, 14 November 2017 (UTC)[reply]
It looks like the current beta isn't very good with a complex edit like that. Anomie (talk) 14:39, 14 November 2017 (UTC)[reply]
- I would say so. Then this task would be about to make it available for "normal" diff screen, not for VE only (e.g. like Two Column Conflict). --Vachovec1 (talk) 18:52, 13 November 2017 (UTC)[reply]
Could be added as a button to the dif view. When clicked on it switches between one view and the other. I would definitely use it. Doc James (talk · contribs · email) 22:14, 13 November 2017 (UTC)[reply]
- Yes, that's exactly what I thought. --Vachovec1 (talk) 11:23, 14 November 2017 (UTC)[reply]

A notice: there is a very similar proposal in the section Editing, namely Community Wishlist Survey 2017/Editing#Support_multiple_diff_variants Support multiple diff variants. --Vachovec1 (talk) 14:45, 15 November 2017 (UTC)[reply]

Voting

Support —viciarg⁴¹⁴ 08:38, 28 November 2017 (UTC)[reply]
Support Jcornelius (talk) 10:01, 28 November 2017 (UTC)[reply]
Support --Liuxinyu970226 (talk) 13:23, 28 November 2017 (UTC)[reply]
Support YFdyh000 (talk) 16:16, 28 November 2017 (UTC)[reply]
Support Dexxor (talk) 18:23, 28 November 2017 (UTC)[reply]
Support Gripweed (talk) 21:32, 28 November 2017 (UTC)[reply]
Support Thomas Obermair 4 (talk) 23:06, 28 November 2017 (UTC)[reply]
Support Libcub (talk) 05:18, 29 November 2017 (UTC)[reply]
Support Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 11:19, 29 November 2017 (UTC)[reply]
Support Ermahgerd9 (talk) 20:46, 29 November 2017 (UTC)[reply]
Support CogitoErgoSum14 (talk) 01:12, 30 November 2017 (UTC)[reply]
Support Long wanted such a thing Force Radical (talk) 06:50, 30 November 2017 (UTC)[reply]
Support --Dalka (talk) 07:44, 30 November 2017 (UTC)[reply]
Support - yona B. (D) 08:33, 30 November 2017 (UTC)[reply]
Support -donald- (talk) 11:12, 30 November 2017 (UTC)[reply]
Support אשר1234567890 (talk) 12:29, 30 November 2017 (UTC)[reply]
Support Exilexi (talk) 14:38, 30 November 2017 (UTC)[reply]
Support Dromedar61 (talk) 21:36, 30 November 2017 (UTC)[reply]
Support Jith12 (talk) 22:47, 30 November 2017 (UTC)[reply]
Support But as an added "option" as Doc James said above. –Ammarpad (talk) 23:40, 30 November 2017 (UTC)[reply]
Support Braveheidi (talk) 07:19, 1 December 2017 (UTC)[reply]
Support Hogne (talk) 09:51, 1 December 2017 (UTC)[reply]
Support Eug (talk) 11:52, 1 December 2017 (UTC)[reply]
Support Tigerzeng (talk) 16:07, 1 December 2017 (UTC)[reply]
Support CosmosAway (talk) 17:24, 1 December 2017 (UTC)[reply]
Support --Superchilum^{(talk to me!)} 20:25, 1 December 2017 (UTC)[reply]
Support as an option to check when you are on a diff, yes. GrandCelinien (talk) 23:33, 1 December 2017 (UTC)[reply]
Support SEMMENDINGER (talk) 23:53, 1 December 2017 (UTC)[reply]
Support Whats new? (talk) 00:20, 2 December 2017 (UTC)[reply]
Support Szoltys (talk) 12:13, 2 December 2017 (UTC)[reply]
Support ديفيد عادل وهبة خليل 2 (talk) 12:30, 2 December 2017 (UTC)[reply]
Support ~Cybularny ^Speak? 12:54, 2 December 2017 (UTC)[reply]
Support Wolbo (talk) 13:07, 2 December 2017 (UTC)[reply]
Support Tom Ja (talk) 14:22, 2 December 2017 (UTC)[reply]
Support Ented (talk) 15:05, 2 December 2017 (UTC)[reply]
Support Nabla (talk) 22:19, 2 December 2017 (UTC)[reply]
Support Ooh, I really like this idea. Boing! said Zebedee (talk) 22:37, 2 December 2017 (UTC)[reply]
Support Waldir (talk) 11:03, 3 December 2017 (UTC)[reply]
Support FULBERT (talk) 19:07, 3 December 2017 (UTC)[reply]
Support Paucabot (talk) 19:09, 3 December 2017 (UTC)[reply]
Support TheNavigatrr (talk) 01:14, 4 December 2017 (UTC)[reply]
Support --Jarekt (talk) 13:28, 4 December 2017 (UTC)[reply]
Support Pau Colominas (talk) 16:28, 4 December 2017 (UTC)[reply]
Support Medol (talk) 17:11, 4 December 2017 (UTC)[reply]
Support Tiputini (talk) 17:13, 4 December 2017 (UTC)[reply]
Support Unapersona (talk) 17:28, 4 December 2017 (UTC)[reply]
Support JAn Dudík (talk) 21:57, 4 December 2017 (UTC)[reply]
Support Doc James (talk · contribs · email) 03:18, 5 December 2017 (UTC)[reply]
Support Vincent Simar (talk) 11:57, 5 December 2017 (UTC)[reply]
Support Kudpung (talk) 21:10, 6 December 2017 (UTC)[reply]
Support Klaas `Z4␟` V: 22:27, 6 December 2017 (UTC)[reply]
Support Richard Nevell (WMUK) (talk) 13:45, 8 December 2017 (UTC)[reply]
Support It would be helpful many times for me, especially if tables have been edited. Dolotta (talk) 21:41, 8 December 2017 (UTC)[reply]
Support Fano (talk) 11:54, 9 December 2017 (UTC)[reply]
Support RolandUnger (talk) 18:22, 9 December 2017 (UTC)[reply]
Support This can be a part of another proposal: Support multiple diff variants. Ruslik (talk) 17:05, 10 December 2017 (UTC)[reply]
Support Tokenzero (talk) 18:56, 10 December 2017 (UTC)[reply]
Support Jack who built the house (talk) 22:38, 10 December 2017 (UTC)[reply]
Support Darylgolden (talk) 03:54, 11 December 2017 (UTC)[reply]
Support Yohannvt (talk) 12:10, 11 December 2017 (UTC)[reply]

Make Wikimedia accessible via Tor and/or I2P

Edit proposal/discussion

Problem: Some countries aren't familiar with spreading free and open knowledge. The proofs of censoring Wikipedia and the Internet in China People's Republic is already known. Turkey has blocked the whole Wikipedia this year. Such a tries there will be also in the future.

Who would benefit: Theoretically any Wikipedia-reader concerned about their privacy while reading. More practically for readers from countries with strong censorship of the Internet and especially from those directly blocking Wikimedia projects.

Proposed solution: To make Wikipedia and maybe some other Wikimedia projects available read-only as Hidden Service of Tor, I2P eepsite or using any other convenient technology.

More comments: Wikimedia projects are of course accessible via Tor network already today, but as being on the normal Internet, the users have to use exit nodes which can theoretically (and some of them practically) attack them as well as the countries which they're trying to avoid. As Tor Hidden Sevices and I2P eepsites (which is technically the same only on different networks) are end-to-end encrypted, it's harder to attack the users from the middle. As these protocols don't support subdomains, it could be possible to use similar thing as was used on secure.wikimedia.org before introducing of TLS on the main domains.

Phabricator tickets: T168218 - Tor hidden service for WMF websites, T35779 - Allow access to wikimedia servers through an I2P router

Proposer: Venca24 (talk) 09:43, 16 November 2017 (UTC)[reply]

Translations: none yet

Discussion

And hosting on en:IPFS?--YFdyh000 (talk) 16:18, 28 November 2017 (UTC)[reply]
"the users have to use exit nodes which can theoretically (and some of them practically) attack them as well as the countries which they're trying to avoid." - This is not true. Exit nodes cannot maliciously modify Wikipedia content due to us using HTTPS and HSTS. Concerns about malicious exit nodes really only apply to plain HTTP sites. Quite frankly, in my opinion, creating an exit node is more of a political statement than anything else. The effect hidden tor nodes have on privacy, security or censorship resitence is minimal to non-existent. At most, an exit node could determine which domain traffic is going to (due to SNI), but they cannot link that information to the originator of the request. (That said, I like tor, and support creating an exit node for political reasons) BWolff (WMF) (talk) 23:15, 28 November 2017 (UTC)[reply]
- CNNIC has issued root TLS certificates and this organization is under the influence of the government of People's Republic of China. Having this root certificate in computers, they can technically issue a certificate for any domain, or am I mistaken? I haven't find on HTTPS Everywhere site if it checks the certificates (like I think did the Observatory). --Venca24 (talk) 21:16, 29 November 2017 (UTC)[reply]
  - you're correct that a mitm via a misissued certificate or malicious/incompetent CA is an attack that a tor hidden service can prevent. (Of course a tor hidden service introduces a risk of a mitm by tricking users into viewing the wrong onion url because onion urls arent human readable. Id consider that a much easier to pull off attack than malicious CA attack). CNNIC is probably not the CA id worry about - afaik they are already untrusted by apple and google chrome and firefox only trusts certificates from them prior to 2015 (which is kind of meaningless as they could backdate but i digress). However your point still stands with other CAs. That said I think it would be very difficult to pull off this type of attack without being discovered - the moment the attacker is detected their root gets immediately distrusted and they go out of bussiness, so there is a strong economic incentive not to be involved. And it would be difficult to participate in the attack secretly because a tor exit node doesnt know where the traffic is coming from so the attacker cannot target the attack. Thus there is a high likelyhood that anyone doing such an attack for any length of time would be discovered. Once expect-CT header becomes available in browsers (hopefully soon) the risk of this attack goes down quite a bit. (expect-CT: tells browsers to only accept certificates that are in the public certificate transparency lists. This ensures that anyone can figure out all the valid certificates for a domain, preventing a malicious CA from secretly issuing a cert for a domain they are not supposed to). BWolff (WMF) (talk) 03:21, 1 December 2017 (UTC)[reply]
Additionally - "As these protocols don't support subdomains, it could be possible to use similar thing as was used on secure.wikimedia.org before introducing of TLS on the main domains". I can't speak as to I2P, but for tor this statement is untrue. Subdomains work like virtual hosts when using tor with HTTP(S). BWolff (WMF) (talk) 23:18, 28 November 2017 (UTC)[reply]
- I didn't know, thanks. --Venca24 (talk) 21:16, 29 November 2017 (UTC)[reply]

Voting

Support Tim Landscheidt (talk) 20:12, 27 November 2017 (UTC)[reply]
Support MichaelSchoenitzer (talk) 22:46, 27 November 2017 (UTC)[reply]
Support NMaia (talk) 00:16, 28 November 2017 (UTC)[reply]
Support Jc86035 (talk) 02:04, 28 November 2017 (UTC)[reply]
Support Dvorapa (talk) 10:04, 28 November 2017 (UTC)[reply]
Support Oscar_. (talk) · @ 11:42, 28 November 2017 (UTC)[reply]
Support Jamez42 (talk) 12:27, 28 November 2017 (UTC)[reply]
Support --Liuxinyu970226 (talk) 13:23, 28 November 2017 (UTC)[reply]
Support--YFdyh000 (talk) 16:18, 28 November 2017 (UTC)[reply]
Support — Arkanosis ^✉ 17:15, 28 November 2017 (UTC)[reply]
Support Laboramus (talk) 20:47, 28 November 2017 (UTC)[reply]
Support Gripweed (talk) 21:32, 28 November 2017 (UTC)[reply]
Support Thomas Obermair 4 (talk) 23:06, 28 November 2017 (UTC)[reply]
Support Shizhao (talk) 03:28, 29 November 2017 (UTC)[reply]
Support Libcub (talk) 05:18, 29 November 2017 (UTC)[reply]
Support Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 11:18, 29 November 2017 (UTC)[reply]
Support —TheDJ (talk • contribs) 16:38, 29 November 2017 (UTC)[reply]
Support Venca24 (talk) 21:16, 29 November 2017 (UTC)[reply]
Support — putnik 01:12, 30 November 2017 (UTC)[reply]
Support Nocowardsoulismine (talk) 02:32, 30 November 2017 (UTC)[reply]
Support A read only tor hidden service is a good first step to being supportive of the tor project. The real issue though is somehow reconciling abuse prevention with anonoymous editing over tor BWolff (WMF) (talk) 07:10, 30 November 2017 (UTC)[reply]
Support Danii.3 (talk) 13:04, 30 November 2017 (UTC)[reply]
Support Nizil Shah (talk) 18:38, 30 November 2017 (UTC)[reply]
Support Sahaquiel9102 (talk) 21:48, 30 November 2017 (UTC)[reply]
Support Barcelona (talk) 00:37, 1 December 2017 (UTC)[reply]
Support Ypirétis (talk) 17:27, 1 December 2017 (UTC)[reply]
Support Lofhi (talk) 17:36, 1 December 2017 (UTC)[reply]
Support --Gratus (talk) 17:56, 1 December 2017 (UTC)[reply]
Support There is a real danger that the entire log files could be stolen by a non democratic state and use this to kill political opponents who though that there were safe to contribute. Malosse (talk) 18:35, 1 December 2017 (UTC)[reply]
Support Pamputt (talk) 18:51, 1 December 2017 (UTC)[reply]
Support Ckoerner (talk) 21:53, 1 December 2017 (UTC)[reply]
Support GrandCelinien (talk) 23:13, 1 December 2017 (UTC)[reply]
Support Titou (talk) 12:29, 2 December 2017 (UTC)[reply]
Support ~Cybularny ^Speak? 12:55, 2 December 2017 (UTC)[reply]
Support Tom Ja (talk) 14:23, 2 December 2017 (UTC)[reply]
Support Termininja (talk) 16:12, 2 December 2017 (UTC)[reply]
Support Emir of Wikipedia (talk) 16:40, 2 December 2017 (UTC)[reply]
Support Waldir (talk) 11:04, 3 December 2017 (UTC)[reply]
Support TheNavigatrr (talk) 01:17, 4 December 2017 (UTC)[reply]
Support --Jarekt (talk) 13:34, 4 December 2017 (UTC)[reply]
Support --Tractopelle-jaune (talk) 18:18, 4 December 2017 (UTC)[reply]
Support Fixer88 (talk) 20:58, 4 December 2017 (UTC)[reply]
Support JAn Dudík (talk) 21:57, 4 December 2017 (UTC)[reply]
Support Elmidae (talk) 19:21, 5 December 2017 (UTC)[reply]
Support Read only B25es (talk) 13:02, 6 December 2017 (UTC)[reply]
Support Of course: Wikimedia for all including people in areas with governments that hide just about all info not of themselves Klaas `Z4␟` V: 22:40, 6 December 2017 (UTC)[reply]
Support the wub "?!" 01:02, 7 December 2017 (UTC)[reply]
Support Tacsipacsi (talk) 22:00, 7 December 2017 (UTC)[reply]
Support Fano (talk) 11:56, 9 December 2017 (UTC)[reply]
Support Psychoslave (talk) 08:38, 11 December 2017 (UTC)[reply]
Support BugWarp (talk) 13:28, 11 December 2017 (UTC)[reply]

Night-mode for read articles?

Edit proposal/discussion

Problem: when we're at night, the white skin of Wikipedia dazzles us and it's very umcorfortable. I suggest a Night mode switch for users or at least a darker color, like YouTube. Also available for the mobile version.
Who would benefit: Everyone in general.

Proposed solution:

More comments:

Phabricator tickets:

Proposer: VictorPines (talk) 22:38, 18 November 2017 (UTC)[reply]

Translations: none yet

Discussion

Something similar to wow.gamepedia.com? --Izno (talk) 04:24, 19 November 2017 (UTC)[reply]
Isn't it better to use an OS-level solution for that, like f.lux or redshift? --Tgr (WMF) (talk) 22:44, 19 November 2017 (UTC)[reply]
Or browser level like stylish Wikipedia Dark skin —TheDJ (talk • contribs) 13:29, 20 November 2017 (UTC)[reply]

The three options are good.--VictorPines (talk) 21:03, 29 November 2017 (UTC)[reply]

What will happen if a reader's terminal device provides night mode? Will it be too dark or yellowish to read?--Tigerzeng (talk) 15:58, 1 December 2017 (UTC)[reply]
I rehabilitated the Green on black skin, but stopped as any fixes took weeks to integrate. Along with unmerged changes, I have prototype color for finding template/pages that break, and was planning on making the crowd pleaser gray-on-gray scheme. Dispenser (talk) 04:11, 11 December 2017 (UTC)[reply]

Voting

Support --Liuxinyu970226 (talk) 13:23, 28 November 2017 (UTC)[reply]
Support Matěj Suchánek (talk) 14:59, 28 November 2017 (UTC)[reply]
Support Thomas Obermair 4 (talk) 23:06, 28 November 2017 (UTC)[reply]
Support bspf (talk) 07:54, 29 November 2017 (UTC)[reply]
Support Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 11:18, 29 November 2017 (UTC)[reply]
Support Ermahgerd9 (talk) 20:48, 29 November 2017 (UTC)[reply]
Support Luan (discussão) 20:56, 29 November 2017 (UTC)[reply]
Support X:: black ::X (talk) 23:55, 29 November 2017 (UTC)[reply]
Support I lie in bed and edit on mobile. Wife asleep. Anything to reduce glare is gr8 idea. Nick Moyes (talk) 01:49, 30 November 2017 (UTC)[reply]
Support The WIkipedia app already has a great night-mode setting. But night-mode on desktop has been a perennial problem; a solution would be most appreciated. Thennicke (talk) 04:22, 30 November 2017 (UTC)[reply]
Support Love having dark-mode on the app, I would love if this was extended to web users. Daylen (talk) 04:36, 30 November 2017 (UTC)[reply]
Support Force Radical (talk) 06:51, 30 November 2017 (UTC)[reply]
Support - yona B. (D) 08:33, 30 November 2017 (UTC)[reply]
Support M11rtinb (talk) 10:45, 30 November 2017 (UTC)[reply]
Support Danii.3 (talk) 13:04, 30 November 2017 (UTC)[reply]
Support Nizil Shah (talk) 18:57, 30 November 2017 (UTC)[reply]
Support Dromedar61 (talk) 21:37, 30 November 2017 (UTC)[reply]
Support Sahaquiel9102 (talk) 21:49, 30 November 2017 (UTC)[reply]
Support MorpheusKafka (talk) 01:15, 1 December 2017 (UTC)[reply]
Support Daniel Case (talk) 03:22, 1 December 2017 (UTC)[reply]
Support Haytham^Abulela 18:35, 1 December 2017 (UTC)[reply]
Support --Superchilum^{(talk to me!)} 20:22, 1 December 2017 (UTC)[reply]
Support SEMMENDINGER (talk) 23:51, 1 December 2017 (UTC)[reply]
Support Whats new? (talk) 00:19, 2 December 2017 (UTC)[reply]
Support Gnom (talk) Let's make Wikipedia green! 10:09, 2 December 2017 (UTC)[reply]
Support ديفيد عادل وهبة خليل 2 (talk) 12:30, 2 December 2017 (UTC)[reply]
Support Tom Ja (talk) 14:25, 2 December 2017 (UTC)[reply]
Support Ented (talk) 15:07, 2 December 2017 (UTC)[reply]
Support Recared (talk) 15:28, 3 December 2017 (UTC)[reply]
Support LikeLifer (talk) 18:46, 3 December 2017 (UTC)[reply]
Support Gryllida 01:06, 4 December 2017 (UTC)[reply]
Support Dark mode also saves energy on AMOLED screens, meaning longer battery life and reduced global energy usage. TheNavigatrr (talk) 01:15, 4 December 2017 (UTC)[reply]
Support --Epìdosis 08:25, 5 December 2017 (UTC)[reply]
Support Gareth (talk) 16:46, 5 December 2017 (UTC)[reply]
Support NessieVL (talk) 20:05, 5 December 2017 (UTC)[reply]
Support — Bilorv (talk) 01:50, 6 December 2017 (UTC)[reply]
Support PamD (talk) 10:20, 7 December 2017 (UTC)[reply]
Support Tacsipacsi (talk) 22:03, 7 December 2017 (UTC)[reply]
Support Richard Nevell (WMUK) (talk) 13:46, 8 December 2017 (UTC)[reply]
Support Fano (talk) 11:57, 9 December 2017 (UTC)[reply]
Support Ruslik (talk) 17:18, 10 December 2017 (UTC)[reply]
Support BugWarp (talk) 13:27, 11 December 2017 (UTC)[reply]
Support KPFC 💬 16:59, 11 December 2017 (UTC)[reply]

Further develop the Timeless skin

Edit proposal/discussion

Problem: The Timeless skin has already been deployed to several WMF wikis, but has a lot of bugs that need to be fixed, and it needs to be improved if it is to be used as a base from which to rewrite or replace Vector, which has a number of problems outlined by Isarra at this Project Grant request (which was unfortunately not accepted). Because of these issues, readers have been turning to websites with better and more modern reader-facing styling such as Wikiwand. Bugs are not currently being fixed, presumably because Isarra is busy in real life and no other devs have volunteered to fix them.

Who would benefit: Readers (so basically everyone, I guess)

Proposed solution: Finish the design review, fix the bugs, replace the colour scheme, etc.

More comments: This is similar to this proposal, but regardless of whether Timeless or another skin is used as "reader-facing", Timeless would probably end up being used as a base anyway because apparently the other skins' code is a mess (see the grant request).

See also: Grants:Project/Isarra/Post-deployment support (pending)

Phabricator tickets:

Proposer: Jc86035 (talk) 02:02, 20 November 2017 (UTC)[reply]

Translations: none yet

Discussion

Voting

Support Jc86035 (talk) 01:22, 28 November 2017 (UTC)[reply]
Support --Liuxinyu970226 (talk) 13:22, 28 November 2017 (UTC)[reply]
Support FriedhelmW (talk) 21:13, 28 November 2017 (UTC)[reply]
Support Thomas Obermair 4 (talk) 23:06, 28 November 2017 (UTC)[reply]
Support Bawolff (talk) 23:19, 28 November 2017 (UTC)[reply]
Support Shizhao (talk) 03:28, 29 November 2017 (UTC)[reply]
Support bspf (talk) 07:54, 29 November 2017 (UTC)[reply]
Support Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 11:17, 29 November 2017 (UTC)[reply]
Support NMaia (talk) 12:55, 29 November 2017 (UTC)[reply]
Support —TheDJ (talk • contribs) 16:39, 29 November 2017 (UTC)[reply]
Support Ermahgerd9 (talk) 20:50, 29 November 2017 (UTC)[reply]
Support MGChecker (talk) 22:18, 29 November 2017 (UTC)[reply]
Support Zhangj1079 ^talk 01:54, 30 November 2017 (UTC)[reply]
Support Nocowardsoulismine (talk) 02:35, 30 November 2017 (UTC)[reply]
Support --CycloneIsaac (talk) 03:22, 30 November 2017 (UTC)[reply]
Support M11rtinb (talk) 10:45, 30 November 2017 (UTC)[reply]
Support I love Timeless and there's so much to be done with it. I strongly endorse this. Exilexi (talk) 14:39, 30 November 2017 (UTC)[reply]
Support Nizil Shah (talk) 18:53, 30 November 2017 (UTC)[reply]
Support ThePlatypusofDoom (talk) 00:11, 1 December 2017 (UTC)[reply]
Support GrandCelinien (talk) 23:24, 1 December 2017 (UTC)[reply]
Support Gnom (talk) Let's make Wikipedia green! 10:08, 2 December 2017 (UTC)[reply]
Support Afernand74 (talk) 16:40, 2 December 2017 (UTC)[reply]
Support Unapersona (talk) 19:43, 2 December 2017 (UTC)[reply]
Support Waldir (talk) 11:05, 3 December 2017 (UTC)[reply]
Support LikeLifer (talk) 18:50, 3 December 2017 (UTC)[reply]
Support Jcc (talk) 19:53, 3 December 2017 (UTC)[reply]
Support nice skin Gryllida 01:06, 4 December 2017 (UTC)[reply]
Support Ciao • Bestoernesto • ✉ 02:59, 4 December 2017 (UTC)[reply]
Support JAn Dudík (talk) 21:59, 4 December 2017 (UTC)[reply]
Support Keeping the project looking up-to-date helps to keep it credible to non-technical users. Bryanrutherford0 (talk) 17:36, 5 December 2017 (UTC)[reply]
Support Ahm masum (talk) 21:00, 7 December 2017 (UTC)[reply]
Support Incorporating modern UI R&D principles into MediaWiki? What a swell idea! François Robere (talk) 17:52, 9 December 2017 (UTC)[reply]
Support Tokenzero (talk) 18:57, 10 December 2017 (UTC)[reply]
Support Darylgolden (talk) 03:55, 11 December 2017 (UTC)[reply]
Support Dispenser (talk) 04:12, 11 December 2017 (UTC)[reply]
Support KPFC 💬 17:00, 11 December 2017 (UTC)[reply]

Make language conversion work in the Electron Pdfs Service

Edit proposal/discussion

Problem: Afaics it's still impossible to unify the variant of downloaded PDF files of pages, this could be a nightmare e.g. for a Taiwan user who does not have zh-hans knowledge (does "维基百科，自由的百科全書" fair for you rather than "维基百科，自由的百科全书" or "維基百科，自由的百科全書"?). PS: I was requesting Google Code In mentors to handle the task below, but no one replied me that's OK or not.

Who would benefit: Users of wikis that have Language conversion support

Proposed solution: post "variant" parameter from printable mode?

More comments:

Phabricator tickets: phab:T167603

Proposer: Liuxinyu970226 (talk) 05:26, 9 November 2017 (UTC)[reply]

Translations: none yet

Discussion

I think this will just happen once the underlying APIs become variant-aware (T43716, T159985) which is probably too specialized for Community Tech, and planned anyway. --Tgr (talk) 08:06, 28 November 2017 (UTC)[reply]

Voting

Support Jc86035 (talk) 01:25, 28 November 2017 (UTC)[reply]
Support As proposer. --Liuxinyu970226 (talk) 13:22, 28 November 2017 (UTC)[reply]
Support Thomas Obermair 4 (talk) 23:06, 28 November 2017 (UTC)[reply]
Support Shizhao (talk) 03:28, 29 November 2017 (UTC)[reply]
Support Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 11:17, 29 November 2017 (UTC)[reply]
Support It will help a lot! Tigerzeng (talk) 16:01, 1 December 2017 (UTC)[reply]
Support Ciao • Bestoernesto • ✉ 03:01, 4 December 2017 (UTC)[reply]

Visually indicate if a page has been edited since loaded

Edit proposal/discussion

Problem: When viewing a wiki page (article or talk) and the page is edited, people currently reading the page must manually refresh the page or check the page history to see if it has been updated. People may read incorrect information (in the case of vandalism or breaking news) or miss important updates.

Who would benefit: This would be particularly useful:
- For readers who are reading a vandalized page, to be informed that it has been corrected
- For readers who are reading a topic of breaking news, to be informed that information is rapidly changing
- For users who are on a talk page, to be informed when a topic is actively being discussed.

Proposed solution: For this proposal I suggest a simple visual indicator, similar to how many email or task management websites (e.g. Gmail, Phabricator) display small growl notifications in the bottom corner. "This page has been edited since you opened it. Refresh to see changes."

A long-term solution could be to visually show the edits as they are made, like visual diffs or Google Docs/Etherpad.

More comments:
- I'm not sure if there's already a gadget for this? Even if there is, I think this could benefit logged-out readers.
- There should be some logic for circumstances of when the indicator should not appear (e.g. if ORES think the edit is probably vandalism, when an edit is marked as minor and is not a revert, etc.)

Phabricator tickets: couldn't find any.

Proposer: Trevor Bolliger (talk) 17:47, 16 November 2017 (UTC)[reply]

Translations: none yet

Discussion

There are semi-related tasks, but mostly concerned with edit-conflicts, at phab:T120882, phab:T136815, and phab:T94918. I don't believe there's an existing task for this idea (which I think would be a great feature!). Quiddity (WMF) (talk) 21:38, 16 November 2017 (UTC)[reply]
For vandalism it would make more sense to not show probably-vandalized revisions in the first place (Community Wishlist Survey 2017/Miscellaneous/Implement deferred changes is one way to achieve that). For talk pages this would be quite nice. (A similar suggestion for StructuredDiscussions: T98047) --Tgr (WMF) (talk) 01:24, 20 November 2017 (UTC)[reply]
- Personally, I wouldn't like this for talk pages. It seems likely that I'd miss when someone made a reply in a part of the page I had already read, because I'd be reading a later part of the page by then. Anomie (talk) 14:34, 20 November 2017 (UTC)[reply]
No... This is completely the opposite of an encyclopedia. That's a news site... Plus auto-reloading pages is a horrible idea in general. I want to know what I am readin, I do not want a machine to tell me what to read, or guess when to "turn the page" for me. No... This is deal breaker...- Nabla (talk) 22:09, 2 December 2017 (UTC)[reply]
Wouldn't the constant popups from when an editor is overhauling a page with hundreds of edits be annoying? How about along with not popping up for likely vandal edits it also wouldn't pop up for when several edits are being made(except for when one of those several edits is a revert which would suggest removal of a vandal that edited several times). -glove- (talk) 06:23, 8 December 2017 (UTC)[reply]

Voting

Support Ainali (talk) 21:24, 27 November 2017 (UTC)[reply]
Support Dvorapa (talk) 09:58, 28 November 2017 (UTC)[reply]
Support ·addshore· ^{talk to me!} 10:49, 28 November 2017 (UTC)[reply]
Support HHill (talk) 11:37, 28 November 2017 (UTC)[reply]
Support Oscar_. (talk) · @ 11:44, 28 November 2017 (UTC)[reply]
Support Jamez42 (talk) 12:43, 28 November 2017 (UTC)[reply]
Support --Liuxinyu970226 (talk) 13:22, 28 November 2017 (UTC)[reply]
Support Stryn (talk) 15:59, 28 November 2017 (UTC)[reply]
Support This should use new technology instead of polling. Providing the number of edits and changes bytes may be useful. YFdyh000 (talk) 16:23, 28 November 2017 (UTC)[reply]
Support — Draceane ^talk_contrib. 18:47, 28 November 2017 (UTC)[reply]
Support Laboramus (talk) 20:47, 28 November 2017 (UTC)[reply]
Support — Luchesar • T/C 21:54, 28 November 2017 (UTC)[reply]
Support Thomas Obermair 4 (talk) 23:07, 28 November 2017 (UTC)[reply]
Support IKhitron (talk) 23:22, 28 November 2017 (UTC)[reply]
Support bspf (talk) 07:55, 29 November 2017 (UTC)[reply]
Support Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 11:16, 29 November 2017 (UTC)[reply]
Support Joshualouie711 (talk) 19:30, 29 November 2017 (UTC)[reply]
Support Ermahgerd9 (talk) 20:51, 29 November 2017 (UTC)[reply]
Support - Evad37 (talk) 00:48, 30 November 2017 (UTC)[reply]
Support Nocowardsoulismine (talk) 02:36, 30 November 2017 (UTC)[reply]
Support Jith12 (talk) 22:46, 30 November 2017 (UTC)[reply]
Support Daniel Case (talk) 03:23, 1 December 2017 (UTC)[reply]
Support Ynhockey (talk) 16:49, 1 December 2017 (UTC)[reply]
Support Something like this, well designed and unobtrusive, could add some interactivity between passive readers and the active contributor community. Many people still don't know that anyone can contribute. Ckoerner (talk) 21:55, 1 December 2017 (UTC)[reply]
Support SEMMENDINGER (talk) 23:51, 1 December 2017 (UTC)[reply]
Support ~Cybularny ^Speak? 12:52, 2 December 2017 (UTC)[reply]
Support. Definitely yes. Ented (talk) 15:01, 2 December 2017 (UTC)[reply]
Support Wostr (talk) 16:08, 2 December 2017 (UTC)[reply]
Support Maitake (talk) 16:34, 2 December 2017 (UTC)[reply]
Support Otapka (talk) 18:46, 2 December 2017 (UTC)[reply]
Support This would be extremely useful for the page I edit the most. TheNavigatrr (talk) 01:16, 4 December 2017 (UTC)[reply]
Support Yes please. Edit conflicts waste a stupid amount of editorial time. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 08:05, 4 December 2017 (UTC)[reply]
Support Pau Colominas (talk) 16:30, 4 December 2017 (UTC)[reply]
Support if I can opt out of the feature permanently, remove notifications on a case-by-case basis and there's no serious performance issue that will be caused by the feature. — Bilorv (talk) 01:48, 6 December 2017 (UTC)[reply]
Support Ruslik (talk) 16:51, 10 December 2017 (UTC)[reply]
Support Jack who built the house (talk) 22:35, 10 December 2017 (UTC)[reply]
Support This would also show readers that Wikipedia is actually edited by people. This encourages readers to become contributors. Syced (talk) 05:17, 11 December 2017 (UTC)[reply]

Open wiki links in new tab automatically

Edit proposal/discussion

Problem: (French) Ce serait bien que les wikiliens entraînent pour le visiteur l'ouverture d'un nouvel onglet dans son navigateur lorsqu'il clique dessus. Cela lui éviterai de perdre la page courante et d'utiliser le bouton de retour du navigateur. Autant faciliter la vie des internautes !
(English) It would be nice if wikilinks would open in a new tab in the browser. This will save us from losing the current page and using the browser's return button. Might as well make life easier for Internet users!

Who would benefit: Les utilisateurs de Wikipédia et des autres projets de la Wikimedia.

Proposed solution: Il faudrait concevoir une adaptation au langage Wiki de la balise HTML suivante : <a href="http://www.exemple.xx" target="_blank">Intitulé textuel</a>

More comments:

Phabricator tickets:

Proposer: David89 (talk) 01:26, 11 November 2017 (UTC)[reply]

Translations: none yet

Discussion

David89: (French) Il est toujours possible pour le lecteur d'ouvrir un lien dans un nouvel onglet en utilisant Clic droit> Ouvrir dans un nouvel onglet. Si chaque lien avait cette propriété html, tout le monde aurait des dizaines d'onglets à fermer.... Peut être que tu peut demander la création d'un gadget, que les lecteurs pourraient activer si ils veulent cette fonctionnalité, sans déranger tout le monde. --Framawiki (talk) 06:48, 11 November 2017 (UTC)[reply]
(English) it is always possible for the reader to open a link in a new tab by using Right Click > Open in a new tab. If each link had this html property, everyone would have dozens of tabs to close... maybe you can ask for the creation of a gadget, that readers could activate if they want this feature, without disturbing everyone.
I agree. We definitely cannot make all links open in new tabs, for everyone, always. We could introduce a preference, but we have enough of those already. I also believe a gadget or user script would be the best solution, and this would not be hard to implement. MusikAnimal (WMF) (talk) 23:11, 11 November 2017 (UTC)[reply]
On many projects, there is already a gadget for this. See "Open external links in a new tab or window" in w:en:Special:Preferences#mw-prefsection-gadgets, and the "exlinks" entry in Gadgets/wikipedia (plus variant gadgets with other names, in that list, such as "LiensExternes" - see w:fr:Spécial:Préférences#mw-prefsection-gadgets - "LiensExternes : ouvre les liens externes dans un nouvel onglet"). I don't think this needs any technical work, just local discussions on whether to make the gadget a default. Quiddity (WMF) (talk) 00:14, 21 November 2017 (UTC)[reply]
This is bad for web accessibility. --Izno (talk) 04:25, 21 November 2017 (UTC)[reply]
Just a comment on some of the suggestions below, that not everyone has a three-button mouse or one with a clickable wheel - Mac users, for example (though it's still easy to a open link in a new tab). Boing! said Zebedee (talk) 22:19, 2 December 2017 (UTC)[reply]

Voting

Oppose. The middle click on your mouse can be configured to do exactly that (if it isn't the default already), if not just hold down Ctrl when clicking. Then there's the gadget solutions mentioned above... MER-C (talk) 01:43, 28 November 2017 (UTC)[reply]
Oppose. Just middle click.Gareth (talk) 11:26, 28 November 2017 (UTC)[reply]
Oppose per above, the mouse wheel is also clickable. --Liuxinyu970226 (talk) 13:22, 28 November 2017 (UTC)[reply]
Oppose 2004 called, it wants it's target="_blank" discussion back. --TMg 16:29, 28 November 2017 (UTC)[reply]
Strong oppose Let the user do whatever they want: in most browsers: left click for same tab, middle click for new tab. Also target="_blank" is a serious security issue that is not yet addressed by all browsers — Arkanosis ^✉ 16:37, 28 November 2017 (UTC)[reply]
Support As a user preference - both for external links, and for internal links. Yes, I can right click and open in a new tab, but it is hard to do this when using a touchscreen rather than a mouse. AlasdairW (talk) 23:02, 28 November 2017 (UTC)[reply]
Support Thomas Obermair 4 (talk) 23:04, 28 November 2017 (UTC)[reply]
Oppose IKhitron (talk) 23:19, 28 November 2017 (UTC)[reply]
Oppose If there is one (1) thing that crashes my system a lot it's the opening of new tabs, I already have to be careful and forced reloads often make me lose a lot of prepared editing (which causes me to make numerous small edits instead of one big one like on a desktop 💻), this idea 💡 largely would only make it worse. I would support it if it's optional and then disabled by default. --Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 11:15, 29 November 2017 (UTC)[reply]
Oppose --Vachovec1 (talk) 18:01, 30 November 2017 (UTC)[reply]
Support As a preference though I'm used to "Right click and hit T on keyboard"(Chrome) to open links in new tab. (Laptop users may not have a middle button) Tigerzeng (talk) 16:05, 1 December 2017 (UTC)[reply]
- @Tigerzeng: You can connect a mouse to a laptop.Thank you --ديفيد عادل وهبة خليل 2 (talk) 12:24, 2 December 2017 (UTC)[reply]
  - @ديفيد عادل وهبة خليل 2: That's obviously not a good reason to oppose the proposal, THANKS!--Tigerzeng (talk) 13:30, 2 December 2017 (UTC)[reply]
    - @Tigerzeng: I see it as an unhelpful proposal (although most of my contributions are from a laptop). Thanks --ديفيد عادل وهبة خليل 2 (talk) 13:35, 2 December 2017 (UTC)[reply]
Oppose --ديفيد عادل وهبة خليل 2 (talk) 12:24, 2 December 2017 (UTC)[reply]
Oppose I'm using Ctrl + Left Click. --Termininja (talk) 16:19, 2 December 2017 (UTC)[reply]
Support I also support this as a preference / option, especially for folks who use an Apple mouse which does not have middle buttons FULBERT (talk) 19:11, 3 December 2017 (UTC)[reply]
Support Ciao • Bestoernesto • ✉ 03:02, 4 December 2017 (UTC)[reply]
Oppose Middle button click / Ctrl + left click exist! --Pau Colominas (talk) 16:31, 4 December 2017 (UTC)[reply]
Oppose Everyone who uses a web browser already knows how this works and can make their own choices.-Bryanrutherford0 (talk) 17:37, 5 December 2017 (UTC)[reply]
Oppose Most browsers let the user decide to open a link in a new tab if they want to. Almost no browser lets the user open a link in the current tab if the website wants it to open in a new tab. Don't make things easy for a few people at the cost of making them hard for most people. --Carnildo (talk) 23:26, 6 December 2017 (UTC)[reply]

Pop-up showing authorship info

Edit proposal/discussion

Problem: It is often difficult to assess Wikipedia articles. Some are the result of multiple authors collaborating, others are the efforts of one PR agent, an editor and an Arb joining forces to validate an essay on a CEO's activism, still others are the Herculean efforts of single accounts. Readers should be able to find this information quickly. Responsible scholarship gains authority (at least in the humanities) due to the reputation of its authors, and yet the history pages on Wikipedia do not give a global overview of the "table of authors" who wrote the article whose history they record typo by typo. Recently, questions have been raised about the WMF's compliance with a court decision requiring that covert advertising be clearly identified as such.

Who would benefit: Critical readers, the WMF

Proposed solution:

Add a pop-up version of the "Article Info" page at xtools to all visible pages on the project (or at least to all articles in mainspace). This tool is several clicks away from the reader at the moment. (view history > revision history statistics)
Improve the "Article Info" algorithm so that it discounts reverted text and reversions from the edit totals. (Cf. the graph for Donald Trump or Hillary Clinton to see more clearly why the resulting pie charts are skewed... basically, the top editors are those who revert page blankings).
develop color codes for degrees of collaboration that appear in the article itself.

This would probably not be enough to address the serious concerns raised about compliance with European Fair Trade Laws in OLG München · Urteil vom 10. Mai 2012 · Az. 29 U 515/12, but I believe it's a small step in the right direction.

More comments: I just learned that User:Doc James tried to get this done years ago and failed due to technical problems and a lack of coders able to make it work. How about we make it happen this time?

Phabricator tickets:

Proposer: SashiRolls (talk) 21:50, 10 November 2017 (UTC)[reply]

Translations: none yet

Discussion

It could definitely be rolled out as a gadget people can turn on. Here is the mockup from 2014[1]. Added the term "contributors" to the "byline" which when clicked on brings one to a break down of editors of an article. Doc James (talk · contribs · email) 05:39, 11 November 2017 (UTC)[reply]
- This sounds great. It would be wonderful if under the "Tools" left hand menu it was called "Who wrote this article?" and there was the percentage breakdown and optional authorial biographies. No Swan So Fine (talk) 13:04, 12 November 2017 (UTC)[reply]
See also the "WikiHistory" item from the 2017 WMDE Technical Wishes project. [2] As a similar request it was #4 in the survey. CKoerner (WMF) (talk) 22:02, 13 November 2017 (UTC)[reply]

Yes, two requests with over 60 supports each, it does look like German Wikipedia is leading the way on the question. Thanks for the info. SashiRolls (talk) 21:30, 15 November 2017 (UTC)[reply]

Re: "This tool is several clicks away from the reader at the moment. (view history > revision history statistics)". It's not quite what you're asking for, but just thought I'd mention that the XTools gadget makes the articleinfo page available with one click (a link under every page title). And perhaps it wouldn't be too hard to add the author list directly there. Sam Wilson 06:58, 15 November 2017 (UTC)[reply]

Aha! Thanks for pointing this out. So the technology exists that allows any reader to do the first step of what I'm asking, and using the author line for statistics and a link to authorship seems like a reasonable first step. Why isn't this standard? That's so much better! Failing that, a link on the sidebar to a (just the facts no promo) "reader's guide to wikipedia" would be useful so that first time visitors could learn about how to find author info, COI info, how to install the author-info gadget (not obvious for someone who hasn't been here for a while), where the disclaimers are, why they're important, etc. SashiRolls (talk) 21:18, 15 November 2017 (UTC)[reply]

Upon reflection, you can only install/activate a gadget if you create an account, so really none of this has any effect on the general reader who does not have an account (and the non-member reader ("client" of "knowledge as a service") is the target for the suggested improvement). SashiRolls (talk) 00:16, 21 November 2017 (UTC)[reply]

Improve the "Article Info" algorithm so that it discounts reverted text and reversions from the edit totals – It is doing this to some extent, but we're working to improve the logic, see phab:T179996. As Sam said above, there is a gadget that will give you some high-level information at the top of each page, with a link to the full statistics. This makes it one click away instead of two. Is that sufficient?
With T176912 we looked into reviving the WikiHistory gadget, which would give you "text shares" (authorship percentages) in real-time. However getting this information requires parsing every single revision within the article. It is not feasible to do this on every page you view, in real time. WikiHistory was able to do this because there was a bot that precomputed the data. In addition to significant maintenance burden, the downside to the bot was it had to be enabled for each wiki individually, and that was assuming that community would actually make use of it (it wouldn't make sense to run a bot no one is using). It requires considerable resources to precompute and maintain this data. In my opinion this is not a good system. We can get you improved data that will help with the issues you are facing, but it should remain an on-demand service, and not an automatic service.
The other thought is to build these stats directly into MediaWiki. For that I suppose we'd keep running totals as each revision is made, that way we can serve it to you very quickly. This would be a huge effort, and perhaps not worth the while given the size of the audience it would benefit versus development time. It would also most likely be bound by the upcoming revision refactor. In other words, I don't think implementing something like this in MediaWiki could happen in the short term.
I have never heard of the European ruling you speak of, but I will let the legal team know about it. MusikAnimal (WMF) (talk) 16:36, 15 November 2017 (UTC)[reply]

Yes I've thought about the problem and realize that it's pretty tricky. I was assuming the bot to establish authorial "share" (color coded collaboration as of ##date##) would run on the periodic dumps not on the live database. I recognize too that it's not very environmental of me to ask for calculated author info to be made readable & accurate. Just to be clear: RickinBaltimore really is not the primary author of the Donald Trump article. He just reverted a page blanking. Glad to see you've already caught this and are working on it. Thanks!

I notice volunteers get BY credit for text they copy from paid editors who cannot edit pages directly. The average reader will still not find accurate authorial info even with the gadget unless they also look at the talk page (on en-wiki). Another example: Kosmos Energy (talk page) Unlike with Krzanich, full page protection wasn't deemed necessary to keep mad vandals from messing up / reverting the PR agency's prose. Making that gadget standard would be a good thing to push for. I realize this problem of misattributed edits is due to the en.wiki policy of embedding the COI template among all the other templates on the talk page rather than being on the article page. When policy gives you bad data, there's not much the developers can do. Thanks very much for your response. You've made some great tools. SashiRolls (talk) 21:14, 15 November 2017 (UTC)[reply]

There is an old research project called WikiCredit on this topic. As you can see there, meaningfully quantifying authorship is not an easy problem. --Tgr (WMF) (talk) 01:53, 20 November 2017 (UTC)[reply]

Okay we know have something working on EN WP using a script thanks to user User:Wurgl.

The database is currently being build over the next few weeks. So for pages with lots of edits it can take up to 30 min to generate results. For short pages it works in seconds.

Copy and paste the following to here
mw.loader.load('//en.wikipedia.org/w/index.php?title=User:Wurgl/WikiHistory.js&action=raw&ctype=text/javascript'); Doc James (talk · contribs · email) 01:21, 27 November 2017 (UTC)[reply]

If the project is feasible, maybe a color aid could be implemented to show which text was added by which editors, such as Google Docs currently does, although I don't know the implications of this or how difficult it could be to apply in real time. --Jamez42 (talk) 13:06, 28 November 2017 (UTC)[reply]

To respond to TheDJ's oppose: while I understand that it may well be a technical challenge to generate accurate information, I do not believe that this suggestion caters first and foremost either to Wikipedians or to Sceptics, but to serious consumers of a collaborative reference work. It is entirely possible that it will become necessary in order for the projects to be legally compliant in some jurisdictions in the future, and would certainly be a significant help to anyone wishing both to assess trustworthiness & (possibly) to read other well-written articles by specific contributors. The point of suggesting a scroll-over pop-up in 1 & 2 was that it doesn't add anything more than the word "authors" to the screen. The idea of having "authors" on the lefthand sidebar is also more discrete than the line at the top of the page which has currently been proposed. The color coding I suggested for degrees of collaboration in 3 could be the background for the <span> containing the words "authors". Much less cluttery than an infobox for example (not that I have anything against infoboxes) SashiRolls (talk) 00:26, 30 November 2017 (UTC)[reply]
- For those interested in this problem, here is an interesting bot action that certainly seems to be obscuring editing history. For those who do not understand how a bot can author such prose, cf. this edit and the surrounding discussion at en.WIKITALK:COI. In a related discussion on that talk page, this 2017 Wishlist is mentioned (but not linked to). SashiRolls (talk) 22:39, 30 November 2017 (UTC)[reply]
Comment I share misgivings of User:SMcCandlish that this might lead to some non-healthy competition and WP:OWN-oriented approach to articles. I also do not like added clutter. On the other hand, I like the idea of some indicator of article trustworthiness and I trust more articles with a lot of authors, so seeing hat 90% of an article come from a single contributor, could be a warning about lack of vetting. However I would prefer that as an opt-in gadget. --Jarekt (talk) 13:49, 4 December 2017 (UTC)[reply]
- Yes, this is a relevant concern. The idea behind the color-coding was to mark primarily single voice articles as such (as potentially needing to be read with a grain of salt). This just makes visible outside what is already visible inside (COI editors may well already send their potential clients pages of links to the xtool profiles of their greatest hits). SashiRolls (talk) 02:35, 5 December 2017 (UTC)[reply]
Very neat that the WikiHistory gadget was revived! I doubt this proposal will make it to the top 10, but just so it's clear, I don't think WMF will build any kind of gadget like the WikiHistory one. We can however improve XTools authorship detection, and/or build another tool for this, as explained at Special:Diff/17426787. I'm sorry we didn't interject and ask the proposal be reworded, because I suspect people would have less concerns about WP:OWN if the authorship statistics were one at least click away, and not shown automatically atop every page. MusikAnimal (WMF) (talk) 18:10, 8 December 2017 (UTC)[reply]
- Was proposed as opt in. Do not think it is ready for widespread roll out. Other concern is that it may slow down page loading. Doc James (talk · contribs · email) 18:15, 8 December 2017 (UTC)[reply]

Voting

Support MichaelSchoenitzer (talk) 22:43, 27 November 2017 (UTC)[reply]
Support Jcornelius (talk) 10:00, 28 November 2017 (UTC)[reply]
Support HHill (talk) 11:39, 28 November 2017 (UTC)[reply]
Support Oscar_. (talk) · @ 11:48, 28 November 2017 (UTC)[reply]
Support Jamez42 (talk) 13:05, 28 November 2017 (UTC)[reply]
Support --Liuxinyu970226 (talk) 13:22, 28 November 2017 (UTC)[reply]
Support Ynhockey (talk) 20:33, 28 November 2017 (UTC)[reply]
Support Gripweed (talk) 21:31, 28 November 2017 (UTC)[reply]
Support Thomas Obermair 4 (talk) 23:05, 28 November 2017 (UTC)[reply]
Support Shizhao (talk) 03:26, 29 November 2017 (UTC)[reply]
Support bspf (talk) 07:53, 29 November 2017 (UTC)[reply]
Support Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 11:12, 29 November 2017 (UTC)[reply]
Oppose As proposed, I think this adds clutter that only wikipedians and sceptics will care about (at most) and that will interfere with the usability of the wiki. While the goal is lofty, the implementation idea does not seem scalable and practical to me. This seems to attempt to tackle a "Youtube adpocolypse" style problem, by throwing more information into people's face. The problem is not the lack of information (or in Youtube's case the usage of AI), it's the lack of verification before presenting things to users. Which is a fundamental part of Wikipedia and the Internet. Idea needs severe refinement in my opinion. —TheDJ (talk • contribs) 16:50, 29 November 2017 (UTC)[reply]
Support Joshualouie711 (talk) 19:31, 29 November 2017 (UTC)[reply]
Support Nocowardsoulismine (talk) 02:38, 30 November 2017 (UTC)[reply]
Strong support Credit matters. I am a commons contributor, and it is honestly a big part of why I continue to contribute. If I want to know who created an image that information is right in front of me. And websites that reuse my pictures can easily say "this is who created it". Wikipedia articles are far more collaborative in nature, so the site has always struggled with the question of crediting people. But something needs to be implemented; when I am reading an article, I want to know who the authors are. For inspiration one could look to GitHub's interface for displaying user contributions. And I like the gadget screenshot above; that's the kind of thing that would solve the problem. -- Thennicke (talk) 04:17, 30 November 2017 (UTC)[reply]
Support - yona B. (D) 08:34, 30 November 2017 (UTC)[reply]
Support Dromedar61 (talk) 21:40, 30 November 2017 (UTC)[reply]
Support Jith12 (talk) 22:49, 30 November 2017 (UTC)[reply]
Support This might be helpful for non-Wikipedian readers who want to get in touch with the putative authors of articles but don't know talk pages even exist. Daniel Case (talk) 03:24, 1 December 2017 (UTC)[reply]
Support However I wouldn't want it to turn into ownership of a page. SEMMENDINGER (talk) 23:52, 1 December 2017 (UTC)[reply]
Support Waldir (talk) 10:59, 3 December 2017 (UTC)[reply]
Oppose Panders to the egos of the worst element among real (i.e. non-vandal) editors: the WP:OWN-oriented, WP:VESTED-contributor crowd who are already way too much of a problem, frequently editwarring over trivia, blockading article improvements they don't personally agree with, and otherwise being massive pains to the rest of the project. If someone wants to build a gadget like this for their own amusement, have at it, but precisely 0 WMF cycles should be spent on this. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 08:10, 4 December 2017 (UTC)[reply]
Support Fixer88 (talk) 21:24, 4 December 2017 (UTC)[reply]
Support as an opt in gadget. Researchers request this on a regular bases. The user script might be sufficient but would be nice to make it easier to turn on. Doc James (talk · contribs · email) 03:20, 5 December 2017 (UTC)[reply]
Support NessieVL (talk) 19:55, 5 December 2017 (UTC)[reply]
Support Essential. Why has it never been a standard feature? Kudpung (talk) 21:17, 6 December 2017 (UTC)[reply]
Support Klaas `Z4␟` V: 22:44, 6 December 2017 (UTC)[reply]
Support PamD (talk) 10:22, 7 December 2017 (UTC)[reply]
Oppose Personaly, vandals could see these users and troll or even attack them. There's no necesity to show that specs. It could be dangeours.--VictorPines (talk) 19:28, 7 December 2017 (UTC)[reply]
Oppose the switching on of this functionality for all per TheDJ. Jack who built the house (talk) 22:34, 10 December 2017 (UTC)[reply]
Support Jnanaranjan sahu (talk) 06:44, 11 December 2017 (UTC)[reply]

Find a solution for the conflict between bulleted/numbered list and floating object

Edit proposal/discussion

Problem: A known CSS problem. If an image (or another floating object) is inserted left from the bulleted/numbered list, the indentation is screwed. The bullets/numbers are pushed out before the text block, too close to the image (floating object).

Who would benefit: Every reader.

Proposed solution: At least find a better workaround than the below mentioned template.

More comments: The English Wikipedia created en:Template:Flowlist which can be used to circumvent the problem, but the solution is far from ideal, because it has unwanted side effects, especially for the longer lists.

Phabricator tickets: T13782?

Proposer: Vachovec1 (talk) 19:31, 14 November 2017 (UTC)[reply]

Translations: none yet

Discussion

I've looked at this problem a few times (and contributed in the discussion that came up with the flowlist template), and it doesn't seem like HTML/CSS has a way to fix this. There's list-style-position inside, but that would significantly change rendering of multiline items, in undesirable ways. But always good to have another set of eyes double check that. —TheDJ (talk • contribs) 15:49, 29 November 2017 (UTC)[reply]

Voting

Support Tgr (talk) 07:53, 28 November 2017 (UTC)[reply]
Support --Liuxinyu970226 (talk) 13:23, 28 November 2017 (UTC)[reply]
Support Thomas Obermair 4 (talk) 23:05, 28 November 2017 (UTC)[reply]
Support PKM (talk) 05:37, 29 November 2017 (UTC)[reply]
Support Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 11:24, 29 November 2017 (UTC)[reply]
Support Force Radical (talk) 06:52, 30 November 2017 (UTC)[reply]
Support Danii.3 (talk) 13:06, 30 November 2017 (UTC)[reply]
Oppose What's wrong with just putting all the media on the right? It looks better anyway and is more readable. Daniel Case (talk) 03:26, 1 December 2017 (UTC)[reply]
Support Ynhockey (talk) 16:51, 1 December 2017 (UTC)[reply]
Support WhatamIdoing (talk) 19:40, 1 December 2017 (UTC)[reply]
Support JAn Dudík (talk) 22:00, 4 December 2017 (UTC)[reply]
Support enL3X1 ¡‹delayed reaction›¡ 16:50, 6 December 2017 (UTC)[reply]
Support Jack who built the house (talk) 22:45, 10 December 2017 (UTC)[reply]

Functional and beautiful math for everyone

Edit proposal/discussion

Problem: The current svg and png math rendering have a lot of bugs in average browsers, see mw:User_talk:Whatamidoing_(WMF)#w:de:WP:Umfragen/Konzept_für_mathematische_Formeln and some deficiencies due to the output being images rather than text-like. Only few browsers natively support MathML rendering.
Users should not have to use custom scripts or plugins in order to get the functionality they are used to from other websites, for example math.stackexchange or mathoverflow.

Who would benefit:

Proposed solution: Resurrect the MathJax display method that was ripped out because its implementation was "unmaintainable" (phab:T99369) and make it default for everyone. An example for a website that uses Media-Wiki and MathJax is scholarpedia.org (in an old version from 2013 that is still lacking the faster rendering options).

More comments:

Phabricator tickets: phab:T74553, phab:T130967, phab:T137788, phab:T135543, phab:T172865, phab:T172873, phab:T111712, phab:T50032, phab:T2798, phab:T7600, phab:T159735, phab:T166380.

Proposer: Debenben (talk) 20:18, 6 November 2017 (UTC)[reply]

Translations: none yet

Discussion

@Physikerwelt: Please consider adding any additional information or Phab tickets to this proposal. Whatamidoing (WMF) (talk) 18:18, 7 November 2017 (UTC)[reply]
Endorse. See my blog post from a couple years ago (or also this piece by someone else) for a more detailed look at how I think Wikipedia's math formatting has been going in the wrong direction and why this proposal would be an improvement. —David Eppstein (talk) 18:27, 7 November 2017 (UTC)[reply]
Endorse as the best compromise for vector math, as long as a PNG fallback is also supported. The last time MathJax was available on Wikipedia, it was unusably slow in rendering on some devices. Without caching, one had to pay that price every time the page was edited. I hope that Moore's law and/or improvements to the MathJax engine have improved the situation, but maintaining the PNG option would be prudent. --Mark viking (talk) 19:12, 7 November 2017 (UTC)[reply]
Comment. I am not sure how this relates to the proposal at issue, but I feel it's something that needs to be considered in any such discussion.
The most egregious issue concerning current mathematics formatting is the clash of typefaces in running text, between the sans fonts used by Wikipedia and the serif fonts used by <math> rendering and some templates, especially <math>. (I re-checked, and {{math}} is not as bad as I thought it was, but see en:e (mathematical constant) for how bad <math> can be when used in running text.)
This seems to be an issue with no very happy solution. Articles are going to be in sans; I kind of wish that weren't the case (see en:talk:Iago for one reason why), but I accept that that's a hard constraint. For mathematics, the ambiguity of sans is especially problematic, so we don't want to use it for displayed formulas. Personally I think the least bad solution is for math in running text to use a different typeface from math in displayed formulas, but there is a lot of resistance to that idea.
Anyway, as I say, I don't really know how the proposal would impact these considerations, but if we want math to be "beautiful", I think the issue must be considered. --Trovatore (talk) 20:36, 7 November 2017 (UTC)[reply]

I am not an expert and please also note, that the proposal is not about serif vs. sans-serif and not about removing any png or svg fallback. However as far as I can tell from my limited experience, MathJax has a good algorithm to handle both font support and slow browsers (you can for example go to math.stackexchange and right click on an equation to test different rendering options). From my point of view, the math-font in inline and display equations should always be the same such that people cannot confuse e.g.

\ell

and

l

, and it should always be a font with dedicated math support, such that e.g.

I

(I) and

l

(l) do not look the same. There are a few dedicated sans-serief math fonts in LaTeX [3] and some others that MathJax can load as webfonts. Like in LaTeX you can explicitly force the use of sans-serif with \sf{formula} e.g. on math.stackexchange (I hope people will not do this on a large scale in Wikipedia articles). I would also consider things like weight, size, baseline, median etc. more important than matching serif and sans-serif. I would only use sans-serif when wrapped in \text or when MathJax can find a perfectly matching dedicated sans-serif math font. Since MathJax aims to support also slow browsers and different fonts, I think they have good algorithms to find compromises when necessary.--Debenben (talk) 21:53, 7 November 2017 (UTC)[reply]

Yes, we should switch to MathJax as the default engine for logged-out readers. MathML is not a realistic solution, and seems to be a moribund standard at best. As a case study, there should be no reason our math rendering is worse than math.stackexchange.com, which manages to have relatively decent rendering. Our current system is much worse than theirs. — Carl (CBM · talk) 15:07, 8 November 2017 (UTC)[reply]
Endorse for the reasons already given above. As I see, this seems to be a logistic problem in the sense that the developers (for the math rendering part) are volunteers and they work for the projects that interest them. I can see that MathML can be exciting for various reasons. The unfortunate consequence is that “you fix it”: someone has to maintain the MathJax implementation. One solution is an external incentive: Wikimedia ‘’hires’’ someone whose job, among the others, is to maintain the MathJax support. —- Taku (talk) 19:15, 8 November 2017 (UTC)[reply]
Note that we do use MathJax we just convert it to SVG. We specifically removed MathJax JS rendering because the load that the additional javascript and font delivery that it required was immense (and most websites that use MathJax don't care about this because its the ONLY thing they do) and because it will always load after the page has loaded. We currently do not use MathML (even though the option is still called that it's not preferred in any of the browsers) for displaying, it's only present in hidden form to help with search machine indexing, or for those that want to use it as an alternative to SVG, by making use of a browser extension or something. There are some significant technical problems here (it's WHY MathJax has to exist in the first place) that are hard to overcome with current levels of browser and operating system support. It's closer than it was a couple of years ago, but fundamental problems still exist. —TheDJ (talk • contribs) 08:28, 9 November 2017 (UTC)[reply]
Also I note that exactly none of the tickets linked has anything to do with MathJax. They all concern either limitations of LateX, the latex math package or our security parser for the both of them, making them INPUT problems not OUTPUT problems. 1 issue concerns the SVG rendering, which is serverside. —TheDJ (talk • contribs) 08:36, 9 November 2017 (UTC)[reply]

I know that the developers and people maintaining the software will not be happy with MathJax, after all it is a dirty Java-Script-Hack, but the point is: It works and the tickets are only a small subset of issues which work on almost every other math-website but not in Wikipedia. For example: phab:T50032 try rendering non-ASCII-characters,

\mathrm {\AA}

(Å),

{\text{für alle}}

(für alle),

{\text{ഗ്ദ്ധ്രീ}}

(ഗ്ദ്ധ്രീ) on math.stackexchange or scholarpedia and compare it to the rendering on Wikipedia. For written documents all the problems are unheard of, no matter if you choose pdfLaTeX, XeLaTeX, LuaLaTeX ... it works perfectly. It might be that it does not work in a way that is easy to integrate into a website, but that is not a "limitation of LaTeX".--Debenben (talk) 14:06, 9 November 2017 (UTC)[reply]

And for those who don't care about language support, let me give some more examples: phab:T7600 referencing equations. I miss this feature a lot. phab:T159735 and phab:T166380 which break the mhchem package such that the chemistry project at the German Wikipedia advises to only use math and not chem. On chemistry.stackexchange it is working perfectly. And maybe an additional remark about "most websites that use MathJax don't care about [the additional server load etc.] because it is the ONLY thing they do" - Yes, websites like physics.stackexchange simply cannot afford to have a broken or ugly math rendering because there are plenty alternatives, even websites like quora.com do not mind the additional effort. For Wikipedia there is not much competition, but I am sure, the effect of the bad math rendering will kick in eventually and projects like Wikibooks or Wikiversity might feel it already.--Debenben (talk) 19:10, 9 November 2017 (UTC)[reply]

My point is, you are making incorrect connections between cause and effect. Just because other sites (that possibly use MathJax) don't validate arbitrary input of formulas is no reason to start doing the same on the 5th web property, where you don't even need an account to edit. That's dangerous (and simply not gonna happen). We had MathJax for a while, and those tickets were issues back then as well. I know, because I helped add MathJax and maintained it for a while. There are many problems here, and i'm telling you that MathJax is not some magic fairy dust that you can sprinkle to solve all of them. —TheDJ (talk • contribs) 21:27, 9 November 2017 (UTC)[reply]

And yet those other sites have working good math and we don't. You might consider that, if it does work for them, your reasoning for why it can't possibly work might be faulty. —David Eppstein (talk) 08:12, 10 November 2017 (UTC)[reply]

@TheDJ: I am grateful for your work and that of all the other volunteers who helped to integrate MathJax. What I am saying is: svg is a bad rendering in the first place. What you are saying is: Here at Wikipedia, we can even make it worse by adding a broken "validation" that destroys the LaTeX input before passing it to MathJax and having some server-side svg-issues.--Debenben (talk) 08:49, 10 November 2017 (UTC)[reply]

As always, there is no point in discussing this any further. It's like talking to people who diagnosed themselves by googling and now tell the doctor they can only be cured by being prescribed the one particular medicine, side effects be damned. I can't and it is not my intention to stop you from asking for your pillz, i was just trying to refine the proposal. But if no one cares, then it is clear that my assistance is not needed here. —TheDJ (talk • contribs) 11:13, 13 November 2017 (UTC)[reply]

Endorse. I don't know what all the technical issues are but on math.stackexchange.com MathJax works well and doesn't suffer from the problems found in Wikipedia articles. Currently we have notation whose font size doesn't match that of the surrounding text and can be two or three times as big, that often doesn't have the baseline in the right place, and that results in horrible misalignments. Michael Hardy (talk) 05:28, 13 November 2017 (UTC)[reply]

@TheDJ: well, if client-side MathJax rendering can't be resurrected, what can be done here? Are some tickets mentioned here solvable? I would also like to point to phab:T172864 which also refers to the math problems. --Vachovec1 (talk) 19:13, 13 November 2017 (UTC)[reply]

side remark: phab:T172864 from 2017 is actually only a reminder about w:de:Wikipedia:Technische Wünsche/Topwünsche/Schriftgröße mathematischer Formeln vereinheitlichen ("=unify font size of mathematical formulas") - status unclear, a top 10 wish of the German community from 2015 that mysteriously got linked to phab:T132607 (=improvement for <5% (?) of readers). On my home computer with a recent version of firefox, the MathML add-on and some extra fonts installed, the rendering is good, if I use MathJax with a userscript it is also good, this also looked good with the old MathJax rendering option, but that does not help the average reader and it does not help the editors who would like to write articles that are not completely broken or ugly in the default view. Another wish from 2015 that made it into the top 30 is just below: w:de:Wikipedia:Umfragen/Technische Wünsche 2015/Artikel#Barrierefreie Darstellung von mathematischen Formeln, the description sais: "use a system like MathJax to make mathematical formulas accessible". MathJax gets shipped with the accessibility explorer by default, which can be used to navigate through the formula with arrow keys and any average screenreader can read out the generated text piece by piece, just try it out - it works. Currently you need at least some very special software installed on your computer if you want to do something like that on Wikipedia and the template workarounds often used out of desperation e.g. on the English Wikipedia in order to not render inline-formulas completely ugly are most likely not accessible at all.

@TheDJ: What is your proposal then? I would be very happy if you have a better solution. I just do not know any other because every major math site uses MathJax and MathML is not a realistic option, see e.g. [4]: "When MathJax started, it was considered a temporary solution, to bridge the time until browsers implemented MathML alongside HTML5. Today, that moment seems further away than it was 5 years ago with the two leading browsers (Internet Explorer and Chrome or 55-75% of the market) having no plans to support MathML, even actively removing support for MathML or for plugins that could compensate."--Debenben (talk) 15:15, 15 November 2017 (UTC)[reply]

Fix the bugs, invest in helping the one volunteer who actually maintains all of this, re evaluate MathJax, and accept that sometime the web just cannot guarantee perfect typesetting yet, because that's simply not what it was ever designed for. —TheDJ (talk • contribs) 22:42, 15 November 2017 (UTC)[reply]

Agreed, that is why I put it here in the first place. MathJax works, but it needs infrastructure and maintenance especially with respect to security issues and it should not rely on Physikerwelt, currently the one volunteer all maths and science on Wikipedia relies on for keeping the current rendering system working at all.--Debenben (talk) 10:34, 16 November 2017 (UTC)[reply]

@TheDJ: Unless I completely missunderstood Denebens intentions, this proposal tries to bring math rendering high enough on the priority scale to go beyond an effort of lonely volunteers. That is, have paid programmers dedicate whatever effort is needed to fix the most blatant issues. This would be donation money well spent according to the intentions of the donors. While I certainly have an opinion on the proposed techniques, I don't care how type setting is achieved as long as formulas finally stop to stand out as sore thumb even with the most common set-ups.---<(kmk)>- (talk) 23:51, 27 November 2017 (UTC)[reply]

Yes, just to clarify: At the end I do not care about the technique used to achieve this. I am just pushing for MathJax and an HTML-based solution because I know that it works well on all major math-related websites an I know that it used to work well in Wikipedia from an editor and reader point of view. And last but not least, the 2015 and 2017 wishes were formulated without suggesting a particular technical solution and it seems like people do not understand what is meant by "unifying font size" or how this could be done.--Debenben (talk) 08:33, 28 November 2017 (UTC)[reply]

Voting

Support Debenben (talk) 18:13, 27 November 2017 (UTC)[reply]
Support Charly Whisky (talk) 20:37, 27 November 2017 (UTC)[reply]
Support Boehm (talk) 22:09, 27 November 2017 (UTC)[reply]
Support MichaelSchoenitzer (talk) 22:44, 27 November 2017 (UTC)[reply]
Support Rainald62 (talk) 23:31, 27 November 2017 (UTC)[reply]
Strong support It's about time to get formulas right. After all, articles on MINT topics are part of the core of a true encyclopedia. -<(kmk)>- (talk) 23:36, 27 November 2017 (UTC)[reply]
Support Jc86035 (talk) 02:08, 28 November 2017 (UTC)[reply]
Support Jenks24 (talk) 09:46, 28 November 2017 (UTC)[reply]
Support Dvorapa (talk) 10:01, 28 November 2017 (UTC)[reply]
Support β₁₆ - (talk) 11:45, 28 November 2017 (UTC)[reply]
Support --Liuxinyu970226 (talk) 13:23, 28 November 2017 (UTC)[reply]
Support Laboramus (talk) 20:46, 28 November 2017 (UTC)[reply]
Support Gripweed (talk) 21:31, 28 November 2017 (UTC)[reply]
Support Thomas Obermair 4 (talk) 23:05, 28 November 2017 (UTC)[reply]
Support Shizhao (talk) 03:26, 29 November 2017 (UTC)[reply]
Support Libcub (talk) 05:16, 29 November 2017 (UTC)[reply]
Support Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 11:23, 29 November 2017 (UTC)[reply]
Support Even though I have serious reservations with people's pixie dust expectations regarding 'MathJax', I do think that there are several issues with math that with some extra foundation support can be easily improved. Thus support general intent of request. —TheDJ (talk • contribs) 15:38, 29 November 2017 (UTC)[reply]
Support MathJax is used for beautiful math rendering in the HTML versions of some online scientific journals these days, it should certainly be adequate for wikipedia. ArthurPSmith (talk) 18:55, 29 November 2017 (UTC)[reply]
Support I think it's necesary. Sometimes, I want to introduce a simple math formula, but it's very hard to memorize tha codes. There should be a tool to make easily a Tex code.VictorPines (talk) 20:50, 29 November 2017 (UTC)[reply]
Support Meiloorun (talk) 23:50, 29 November 2017 (UTC)[reply]
Support Support the problem statement. Oppose the requirement for MathJax. Izno (talk) 04:08, 30 November 2017 (UTC)[reply]
Support Furfur (talk) 04:08, 30 November 2017 (UTC)[reply]
Support Ca2james (talk) 04:40, 30 November 2017 (UTC)[reply]
Support --L736E ^{tell me} 08:28, 30 November 2017 (UTC)[reply]
Support - yona B. (D) 08:35, 30 November 2017 (UTC)[reply]
Support At least solve the most outstanding bugs, please. Vachovec1 (talk) 18:02, 30 November 2017 (UTC)[reply]
Support --OrsolyaVirág (talk) 19:57, 30 November 2017 (UTC)[reply]
Support StarryGrandma (talk) 03:27, 1 December 2017 (UTC)[reply]
Support Hogne (talk) 09:49, 1 December 2017 (UTC)[reply]
Support Theklan (talk) 18:54, 1 December 2017 (UTC)[reply]
Support David Eppstein (talk) 20:06, 1 December 2017 (UTC)[reply]
Support --Wcherowi (talk) 23:59, 1 December 2017 (UTC)[reply]
Support ~Cybularny ^Speak? 12:53, 2 December 2017 (UTC)[reply]
Support Victorgrigas (talk) 20:12, 2 December 2017 (UTC)[reply]
Support Nabla (talk) 22:17, 2 December 2017 (UTC)[reply]
Support Waldir (talk) 11:01, 3 December 2017 (UTC)[reply]
Support Kusma (talk) 20:17, 3 December 2017 (UTC)[reply]
Support TheNavigatrr (talk) 01:17, 4 December 2017 (UTC)[reply]
Support Saung Tadashi (talk) 01:49, 4 December 2017 (UTC)[reply]
Support Ciao • Bestoernesto • ✉ 02:56, 4 December 2017 (UTC)[reply]
Support Taku (talk) 21:44, 4 December 2017 (UTC)[reply]
Support — Yerpo ^Eh? 19:37, 5 December 2017 (UTC)[reply]
Support B25es (talk) 12:58, 6 December 2017 (UTC)[reply]
Support --jdx ^Re: 20:38, 8 December 2017 (UTC)[reply]
Support Support the need for improvement to presentation of maths, this is desperately required. No view on particular tools. Mmitchell10 (talk) 11:54, 9 December 2017 (UTC)[reply]
Support Fano (talk) 12:00, 9 December 2017 (UTC)[reply]
Strong support I think we made a step forward, but more work is needed to complete the job and finally deliver Functional and beautiful math for everyone. To achive that we should use native rendering for browsers that do support HTML5 and make use of the best availible bridge technology for MathML disabled browsers. However, currently all new developments are blocked by https://phabricator.wikimedia.org/T74240, which can not be resolved by myself alone. --Physikerwelt (talk) 14:16, 9 December 2017 (UTC)[reply]
Support bdijkstra (talk) 22:27, 9 December 2017 (UTC)[reply]
Support Dispenser (talk) 04:00, 11 December 2017 (UTC)[reply]

Accessibility for colour blind readers

Edit proposal/discussion

**CVD simulation**
Normal CV

Protanpoia (~1% males)

Deuteranopia (~7% males)

Problem: There are templates which colour their different parts to be helpful for the readers, i.e. family trees coloured by gender. Such colouring may very well bother colour blind readers.

Who would benefit: Colour blind readers (1 in 12 men, 1 in 200 women)

Proposed solution: Colours generated by wiki code would be displayed differently (darker/brighter/simpler shades) for readers who clicked an accessibility button.

second proposition: Creating a tool that will read all templates and articles, categorising problematic articles and templates according to different problems (e.g. category:templatees with problematic red combination, category:templatees with too bright colours). After researching the problematic combination and individual colours, and creating the tool that combines the information each wiki can find it's way to solve the problems (e.g. W:HE:קטגוריה:שגיאות פרמטריות).

If accepted, a research of what colours are a problem needs to be done, and alternative colours need to be determined. Also the placing of the button needs to be determined.

Proposer: melo kol (talk) 11:03, 15 November 2017 (UTC)[reply]

Translations: none yet

Discussion

Automatic changing of colors may be problematic, as it would need to take into account all the colors as they're used in context rather than just changing each individual color. For example, changing green to blue for red/green colorblindness might work well to fix a template using red and green, but for a template using the three colors red, green, and blue that change might not work at all. Anomie (talk) 15:23, 15 November 2017 (UTC)[reply]
Shouldn't we discourage people from producing content like this in the first place ? Maybe have an evaluation option that alerts editors of mistakes like these ? —TheDJ (talk • contribs) 16:06, 15 November 2017 (UTC)[reply]
There are some older notes and sites linked at Accessibility#Colour-blind-friendly images. I agree with TheDJ that it would be best to solve this in the original material (whether templates/CSS/diagrams/maps/etc, and for both text-contrast issues as well as purely-graphical color usage) - the most scalable way to achieve this, is by improving the documentation for best practices (however that is not a software issue so is out-of-scope for this wishlist). An evaluation tool for editors would also be good (perhaps one of the existing external tools is sufficient?). melo kol, I recommend you rewrite this proposal, to be focused specifically on a single software-solvable problem, e.g. an evaluation tool that editors can use to find/fix problems. Thanks :) Quiddity (WMF) (talk) 20:30, 16 November 2017 (UTC)[reply]
U:Quiddity (WMF), i added a second proposition, though my offer was planned in the first place to solve the problems you and the DJ added, what i meant was to adjust all colours, more like darkening them (pink=>red) than switching them with a total contrast (green=>red). melo kol (talk) 15:34, 19 November 2017 (UTC)[reply]
I have grant proposal for this: Grants:IEG/Color blindness content checker.
What I have working for images is a CVD simulator (with two different implementations), a prototype for finding images with CVD issues, and pitching to people on my phone at Wikimania.
Regarding HTML colors, in the rehabilitating the Green on black skin, I experimented with an automated method using ComputedStyle() to find templates using black text on transparent backgrounds. --Dispenser (talk) 18:28, 20 November 2017 (UTC)[reply]

Voting

Support Jamez42 (talk) 13:13, 28 November 2017 (UTC)[reply]
Support --Liuxinyu970226 (talk) 13:23, 28 November 2017 (UTC)[reply]
Support Sannita - not just another it.wiki sysop 19:52, 28 November 2017 (UTC)[reply]
Support Gripweed (talk) 21:31, 28 November 2017 (UTC)[reply]
Support Thomas Obermair 4 (talk) 23:05, 28 November 2017 (UTC)[reply]
Support Libcub (talk) 05:17, 29 November 2017 (UTC)[reply]
Support bspf (talk) 07:53, 29 November 2017 (UTC)[reply]
Support Nothingserious (talk) 09:36, 29 November 2017 (UTC)[reply]
Support Donald Trung (Talk 🤳🏻) (My global lock 🔒) (My global unlock 🔓) 11:22, 29 November 2017 (UTC)[reply]
Support Ermahgerd9 (talk) 20:43, 29 November 2017 (UTC)[reply]
Support Nocowardsoulismine (talk) 02:29, 30 November 2017 (UTC)[reply]
Support - yona B. (D) 08:36, 30 November 2017 (UTC)[reply]
Support Danii.3 (talk) 13:06, 30 November 2017 (UTC)[reply]
Support Haytham^Abulela 18:37, 1 December 2017 (UTC)[reply]
Support Wostr (talk) 11:14, 2 December 2017 (UTC)[reply]
Support ديفيد عادل وهبة خليل 2 (talk) 12:31, 2 December 2017 (UTC)[reply]
Support ~Cybularny ^Speak? 12:53, 2 December 2017 (UTC)[reply]
Support Tom Ja (talk) 14:21, 2 December 2017 (UTC)[reply]
Support Maitake (talk) 16:37, 2 December 2017 (UTC)[reply]
Support Emir of Wikipedia (talk) 16:40, 2 December 2017 (UTC)[reply]
Support Otapka (talk) 18:52, 2 December 2017 (UTC)[reply]
Support --Jarekt (talk) 13:25, 4 December 2017 (UTC)[reply]
Support Ernestchuajiasheng (talk) 10:50, 5 December 2017 (UTC)[reply]
Support NessieVL (talk) 20:00, 5 December 2017 (UTC)[reply]
Support B25es (talk) 12:59, 6 December 2017 (UTC)[reply]
Support Carnildo (talk) 22:35, 6 December 2017 (UTC)[reply]
Support Klaas `Z4␟` V: 22:36, 6 December 2017 (UTC)[reply]
Support Richard Nevell (WMUK) (talk) 13:42, 8 December 2017 (UTC)[reply]
Support Ldorfman (talk) 00:40, 10 December 2017 (UTC)[reply]
Support F.trott (talk) 09:50, 11 December 2017 (UTC)[reply]
Support BugWarp (talk) 13:25, 11 December 2017 (UTC)[reply]