2017 Community Wishlist Survey/Reading

From Meta, a Wikimedia project coordination wiki
Jump to: navigation, search

2017 Community Wishlist Survey

Reading
13 proposals, 38 contributors

Go-previous.svg Programs and events  •  Search Go-next.svg

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.
  • Proposed solution: post "variant" parameter from printable mode?
  • More comments:

Discussion[edit]

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.

Discussion[edit]

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:
  1. 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)
  2. 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).
  3. 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:

Discussion[edit]

  • 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)
    • 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)
  • 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)
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)
  • 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)
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)
  • 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)
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)

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)

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 then 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?

Discussion[edit]

Translation in proper Devanagari script

Edit proposal/discussion

  • Problem: improper pronunciation and translation in Devanagari
  • Who would benefit: Hindi and Sanskrit speakers
  • Proposed solution: improving the pronunciation by breaking words into sounds example शनिः श्+अ+न+ि+ः by this we can understand and pronounce words in Sanskrit easily
  • More comments: please add more Indian literature in context of Wikipedia
  • Phabricator tickets:

Discussion[edit]

I suppose it should be achievable by using a font that do not compose on user's end?C933103 (talk) 00:03, 13 November 2017 (UTC)

@07Kaustubh: It's not clear what is being asked for. Can you tell us where this pronounciation will be added? Adding Indian literature is something that will go on Wikisource and not Wikipedia. -- NKohli (WMF) (talk) 20:03, 16 November 2017 (UTC)

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:

Discussion[edit]

  • @Physikerwelt: Please consider adding any additional information or Phab tickets to this proposal. Whatamidoing (WMF) (talk) 18:18, 7 November 2017 (UTC)
  • 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)
  • 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)
  • 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)
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. and , and it should always be a font with dedicated math support, such that e.g. (I) and (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)
  • 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)
  • 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)
  • 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 (talkcontribs) 08:28, 9 November 2017 (UTC)
  • 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 (talkcontribs) 08:36, 9 November 2017 (UTC)
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, (Å), (für alle), (ഗ്ദ്ധ്രീ) 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)
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)
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 (talkcontribs) 21:27, 9 November 2017 (UTC)
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)
@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)
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 (talkcontribs) 11:13, 13 November 2017 (UTC)
  • 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)

@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)

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)
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 (talkcontribs) 22:42, 15 November 2017 (UTC)
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)

Accessibility for colour blind readers

Edit proposal/discussion

  • 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.
  • Proposed solution: Colours generated by wiki code would be displayed differently 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.

Discussion[edit]

  • 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)
  • 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 (talkcontribs) 16:06, 15 November 2017 (UTC)
  • 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)
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)

Download as eBook on WikiBooks

Edit proposal/discussion

  • Problem: users want to read the WikiBooks in eBook format
  • Who would benefit: all users
  • More comments:
  • Phabricator tickets:

Discussion[edit]

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)

Discussion[edit]

  • 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. 14:42, 18 November 2017 (UTC)
  • 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)
    • 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)
      • What problems? --Izno (talk) 03:32, 20 November 2017 (UTC)
    • MinervaNeue is a reader-centric skin, although heavily optimized for mobile devices. (random example) --Tgr (WMF) (talk) 02:17, 20 November 2017 (UTC)

Head line numbering

Edit proposal/discussion

  • Problem: Tables of contents of lengthy articles have automatically numbered entries (such as 1, 1.1, 1.1.1, 1.1.2, 1.1.3, 1.2, 1.3, 2, 2.1, ...) automatically taken from the (sub)headlines of the article itself. But the headlines in the articles themselves don't have the automatically assigned numbers. Thus, for finding, e.g., "1.3.7" from the table of content, you can't go by the numbers, you must go by the content. Possible, but awkward
  • Who would benefit: All readers
  • Proposed solution: Add the numbers used in the table of content also to the headlines in the article.
  • More comments: Am I the first to propose this? Haven't seen it before.
  • Phabricator tickets:

Discussion[edit]

I am absolutely sure that a gadget already exists for this. --AKlapper (WMF) (talk) 19:22, 10 November 2017 (UTC)
I'd be happy to learn what/where/how this gadget is. Seems to be "a lttle bit hidden". But even if an optional gadget exists, I consider it better making it standard. Proper headline numbering supports keeping the orientation and navigating within the article. Best regards --Pfeiffer3f (talk) 08:49, 12 November 2017 (UTC)
This already exists. Go to Special:Preferences#mw-prefsection-rendering, scroll down to the "Advanced options" box, and check "Auto-number headings". Anomie (talk) 17:45, 13 November 2017 (UTC)
Ah, OK, I see, thank you. It does what I mean. Is there a reason why it is not default? I consider it preferable and would assume "it costs nothing" and I see no other disadvantages. Vice versa, the present default (having the numbering in the table of content, but not in the text itself) makes no real sense to me. But maybe there is s.th. I am not aware of. Best regards --Pfeiffer3f (talk) 10:55, 14 November 2017 (UTC)
The big disadvantage is that it breaks with reading and provides no value for most of our readers. It's a valid preference to have but I don't this it should be enabled by default. Max Semenik (talk) 18:30, 15 November 2017 (UTC)

Simple diff

Edit proposal/discussion

Normal diff - text and markup
Simple diff - text only, no markup
  • 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:

Discussion[edit]

  • 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)
  • What about changes in files, references, tables and templates? --Vachovec1 (talk) 19:13, 12 November 2017 (UTC)
    • 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)
  • 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)
  • Is this basically mw:VisualEditor/Diffs? Anomie (talk) 17:42, 13 November 2017 (UTC)
    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)
    It looks like the current beta isn't very good with a complex edit like that. Anomie (talk) 14:39, 14 November 2017 (UTC)
    • 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)
  • 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)
    • Yes, that's exactly what I thought. --Vachovec1 (talk) 11:23, 14 November 2017 (UTC)

A notice: there is a very similar proposal in the section Editing, namely Support multiple diff variants. --Vachovec1 (talk) 14:45, 15 November 2017 (UTC)

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.
  • Proposer: Venca24 (talk) 09:43, 16 November 2017 (UTC)

Discussion[edit]

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).
  • Phabricator tickets:
  • Proposer: Jc86035 (talk) 02:02, 20 November 2017 (UTC)

Discussion[edit]