Wikimedia Meta-Wiki

Community Wishlist Survey 2017/Reading

< Community Wishlist Survey 2017
Community Wishlist Survey 2017
Reading
13 proposals, 229 contributors



Download as eBook on WikiBooks

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

Discussion

edit

Voting

edit

A new wiki skin developed specifically with readers in mind

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

Discussion

edit

Voting

edit

Simple diff

 
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

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

edit

Make Wikimedia accessible via Tor and/or I2P

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

Discussion

edit
  • 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]

Voting

edit

Night-mode for read articles?

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

Discussion

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

Voting

edit

Further develop the Timeless skin

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

Discussion

edit

Voting

edit

Make language conversion work in the Electron Pdfs Service

  • 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

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

edit

Visually indicate if a page has been edited since loaded

  • 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

Voting

edit
  • 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:

Discussion

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

edit

Pop-up showing authorship info

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


 
Example

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

Voting

edit

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

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

Discussion

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

edit

Functional and beautiful math for everyone

  • 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)[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.   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)[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,   (Å),   (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)[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

edit

Accessibility for colour blind readers

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.

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

edit
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2017/Reading&oldid=23947741"