# Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 36496 - (make-mathjax-default) Set $wgDefaultUserOptions['math']=2 on Wikimedia wikis (i.e. enable MathJax by default)  Summary: (make-mathjax-default) Set$wgDefaultUserOptions['math']=2 on Wikimedia wikis (i.e. enable MathJax b...
 Status: Product: RESOLVED INVALID Wikimedia Unclassified Component: Site requests (Other open bugs) unspecified All All Normal enhancement with 3 votes (vote) --- Nobody - You can work on this! 35186 5856 31406 35038 35190 35191 35498 36059 38751 63882 3840 32096 35200 Show dependency tree / graph

 Reported: 2012-05-03 19:37 UTC by Helder 2014-11-17 10:35 UTC (History) 15 users (show) amir.aharoni b bugzilla+org.wikimedia erik federicoleva he7d3r+bugs jforrester ltrlg.wp mah nsoranzo peter.krautzberger physik raylton.sousa rich wikimedia.bugs --- --- ---

Attachments

 Helder 2012-05-03 19:37:43 UTC From bug 31406 comment 0: > A lot of work has gone into making it possible to use MathJax to view > TeX on Wikipedia. Probably more than 20,000 article use TeX (or > whichever variant of TeX Wikipedia uses). I have corresponded with > Robert Miner, MathJax Project Director and Vice President or Research > and Development at Design Science, Inc. about the fact that MathJax > could now be used. I told him that possibly in coming months MathJax > would be adopted as the default means of viewing TeX on Wikipedia. As I understand it, Michael Hardy was proposing MathJax as the **default** math mode, but since setting $wgMathUseMathJax = true on Wikimedia wikis doesn't imply that it would be the default mode, I'm opening this bug to track what still needs to be done. This will also helps to separate the blockers of a "experimental deployment" (which is already done) and the blockers of a "full deployment" of MathJax on WMF wikis. If I understood it correctly, this would be the new setting:$wgDefaultUserOptions['math'] = 2; Fell free to move some blockers/dependencies from bug 31406 to this one as needed. Helder 2012-05-03 19:49:41 UTC PS: Remember that when MW 1.19 went live, it caused the default option "HTML if very simple or else PNG" to be replaced by "Always render PNG", and there were complains about that because the old default was better than PNG in some sense. So this bug would be the way to "restore" the previous "better than PNG" default. Helder 2012-05-03 19:52:32 UTC * Adding (open) bugs which are currently marked as blockers for bug 31406 * Removing "shell" keyword for now, since the blockers would need to be fixed first Erik Moeller 2012-05-09 00:11:05 UTC I don't think that this is likely to happen in the near future. MathJax is significantly slower to render even on high end computers and would likely cause unacceptable slowness on math-intense pages for users of low-end machines. I'm inclined to close this as WONTFIX for the time being. I'd suggest looking into ways to expose the MathJax user preference a bit more so that math-interested users can discover it more easily. For example, we could integrate the right-click menu that MathJax exposes with the PNG rendering mode. Nemo 2013-06-07 08:11:03 UTC (In reply to comment #3) > I don't think that this is likely to happen in the near future. MathJax is > significantly slower to render even on high end computers and would likely > cause unacceptable slowness on math-intense pages for users of low-end > machines. Just to mention one of the blocker bugs, it also has no localisation (bug 35038). > I'm inclined to close this as WONTFIX for the time being. I'd suggest looking > into ways to expose the MathJax user preference a bit more so that > math-interested users can discover it more easily. For example, we could > integrate the right-click menu that MathJax exposes with the PNG rendering > mode. Closing this per Erik (blocker bugs are easily overlooked, status is clearer to readers). Reopening is cheap when issues are solved. Richard Morris 2013-07-14 06:52:05 UTC So we have a problem. We need to discuss maths on our talk page. Its a central part of building the encyclopedia. Now Flow is going to be introduced for our talk pages which will not allow standard wikicode as only the VisualEditor is allowed. Hence the VE must have math support, that is Bug 43058 must be fixed. Now a maths visual editor is a herculanean task but central to that is a render. MathJax could potentially do it, texvc cannot as you would have generate a new image on the fly with each key stroke. Any other system is just going to be an ugly kludge. In reply to Erik's comment. You have a tradeoff between the time it take javascript to render, with the time it takes to download all the images for the equations. It can take a considerable time to download a maths heavy page like Help:Formula. I would say they just about balance each other. physikerwelt 2013-07-14 08:51:56 UTC I think it is really important to have a stable, secure, and long term supported way of math rendering. As I'm working on integrating LaTeXML a rendering engine that converts tex to MathML I was running into a couple of issues. First, Wikipedia uses texvc and not tex, therefore I had to create a list of special user defined commands. MathJax has this list as well. To my mind it's a suboptiomal solution especially with regard to long term support. I propose to come up with a grammar that can be used by a wide audience (e.g. antlr) and convert that into native php code. This grammar converts texvc to tex and eliminates all commands that are not allowed. Second, there are some security aspects, i.e. that someone could put code that is a potential security risk for the visitors. Texvc eliminates this security risk by returning pictures only. On the other side as texvc is a potential security risk for the server, since the rendering must take place on the same machine as the core server works. LaTeXML can use a separate server, but if there is an attack to the network the traffic could be redirected to another server. Therefore the output of LaTeXML must be checked again before returning it to the users browser. If the users browser supports mathml only bugs in the browsers mathml implementation can be a security risk. If not MathJaX is needed to convert MathML to whatever, which comes along with all the Javascript issues. As a result I think that it would be good to seperate the tasks somehow. The Wikimedia Math extension php code should convert texvc to tex and ensure that only valid tex is passed to the rendering engine. Than a standard rendering engine can be used and the final result can be validated according to standard methods. e.g. validate MathML out against the W3C MathML scheme. In summer 2012 I proposed the LaTeXML render at CICM 2012, now it's avalible as opt-in[1]. [1] http://arxiv.org/abs/1304.5475 physikerwelt 2013-07-14 09:04:22 UTC PS: There is a demo at http://demo.formulasearchengine.com you can click on http://demo.formulasearchengine.com/index.php/Special:Random to get a random page of the english wikipedia... the pages are not cached so it might take about 20 seconds, especially if images has to be loaded from commons Peter Krautzberger 2013-07-15 18:03:09 UTC @Richard, the GSoC project for a math-editor component is coming along nicely. The approach is along the lines of the wyiswhat editor http://oerpub.github.io/Aloha-Editor/. The OERpub folks have done some testing (with regular school teachers) see http://kefletcher.blogspot.com/2013/05/testing-editor-designs.html. @Martin I think texvc's restricted TeX fits very well within the concept of Wikitext and texvc has (unfortunatly) proven to be "stable, secure and long term supported". Of course I'm biased, but I think MathJax solves the issues you describe (well except the ominous "along with all the JS issues" -- not sure what you're referring to). If all you're after is MathML and SVG output, then the MathJax-driven VE plugin could easily produce those as well. This is getting off topic, but I would add: we need more rather than less client-side rendering of scientific content. Server side rendering is inherently static, in fact, MathML (which is really just the math equivalent of text) feels a lot like HTML 1 at this point -- barely acceptable, static rendering in the browser. E.g., mathapedia and mathbox show what the future of math on the web might be. Richard Morris 2013-07-15 18:24:46 UTC I think physikerwelt idea of semantic processing of mathematics is a nice idea and fit with the foundations wider goals. However it a bit off topic for this bug. I've created a new bug 51381 which the details where it can be explored in more details. physikerwelt 2013-07-15 20:53:29 UTC (In reply to comment #9) > I think physikerwelt idea of semantic processing of mathematics is a nice > idea > and fit with the foundations wider goals. However it a bit off topic for this > bug. I've created a new bug 51381 which the details where it can be explored > in > more details. Thanks... sorry for the off topic... if I just said use \$wgDefaultUserOptions['math'] = 7 that would be somehow pointless. By the way 2 is html (deprecated) and mathjax is 6. 7 includes 6 since you it can be combined with MathJax (as you can see in the demo) but it must not. The advantage to use MathJax based on MathML is that it is reasonably fast. (To my mind that's not the case if you use MathJax without MathML). Furthermore you can display MathML without a need of JavaScript support. A visual editor that is based on MathML would be easier to implement and handle than one that is based on TeX. But I would double think about doing so, since than the Tex source is gone. (OK the same holds for the visual editor in general.) To stick to the topic, which is not visual editor: I fully support the initiative to switch the rendering mode. However, I think we should find a well defined process for doing so. One opportunity could be: 1. Collect the alternatives 2. Compare and benchmark them 3. Discuss the results 4. Make a decision (Maybe even vote oOo) This sounds a bit lengthy... but due to the fact that this bug is open for more than a year now... that might be really quick. Peter Krautzberger 2013-07-15 21:08:36 UTC A first good step might be to resolve bug 48036 (opt-in for unregistered visitors). That way, people can vote with their feet. physikerwelt 2014-10-19 18:23:10 UTC In the meantime the situation has changed. So it might be better to create a new bug instead of updating this.

 Note You need to log in before you can comment on or make changes to this bug.