Wikitech-l March 2012

wikitech-l@lists.wikimedia.org

155 participants
200 discussions

MediaWiki 1.19.0beta2
by Sam Reed 09 May '14

09 May '14

I'm happy to announce the availability of the second beta release of the new MediaWiki 1.19 release series. Please try it out and let us know what you think. Don't run it on any wikis that you really care about, unless you are both very brave and very confident in your MediaWiki administration skills. MediaWiki 1.19 is a large release that contains many new features and bug fixes. This is a summary of the major changes of interest to users. You can consult the RELEASE-NOTES-1.19 file for the full list of changes in this version. Five security issues were discovered. It was discovered that the api had a cross-site request forgery (CSRF) vulnerability in the block/unblock modules. It was possible for a user account with the block privileges to block or unblock another user without providing a token. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34212 It was discovered that the resource loader can leak certain kinds of private data across domain origin boundaries, by providing the data as an executable JavaScript file. In MediaWiki 1.18 and later, this includes the leaking of CSRF protection tokens. This allows compromise of the wiki's user accounts, say by changing the user's email address and then requesting a password reset. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=34907 Jan Schejbal of Hatforce.com discovered a cross-site request forgery (CSRF) vulnerability in Special:Upload. Modern browsers (since at least as early as December 2010) are able to post file uploads without user interaction, violating previous security assumptions within MediaWiki. Depending on the wiki's configuration, this vulnerability could lead to further compromise, especially on private wikis where the set of allowed file types is broader than on public wikis. Note that CSRF allows compromise of a wiki from an external website even if the wiki is behind a firewall. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35317 George Argyros and Aggelos Kiayias reported that the method used to generate password reset tokens is not sufficiently secure. Instead we use various more secure random number generators, depending on what is available on the platform. Windows users are strongly advised to install either the openssl extension or the mcrypt extension for PHP so that MediaWiki can take advantage of the cryptographic random number facility provided by Windows. Any extension developers using mt_rand() to generate random numbers in contexts where security is required are encouraged to instead make use of the MWCryptRand class introduced with this release. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35078 A long-standing bug in the wikitext parser (bug 22555) was discovered to have security implications. In the presence of the popular CharInsert extension, it leads to cross-site scripting (XSS). XSS may be possible with other extensions or perhaps even the MediaWiki core alone, although this is not confirmed at this time. A denial-of-service attack (infinite loop) is also possible regardless of configuration. For more details, see https://bugzilla.wikimedia.org/show_bug.cgi?id=35315 ********************************************************************* What's new? ********************************************************************* MediaWiki 1.19 brings the usual host of various bugfixes and new features. Comprehensive list of what's new is in the release notes. * Bumped MySQL version requirement to 5.0.2. * Disable the partial HTML and MathML rendering options for Math, and render as PNG by default. * MathML mode was so incomplete most people thought it simply didn't work. * New skins/common/*.css files usable by skins instead of having to copy piles of generic styles from MonoBook or Vector's css. * The default user signature now contains a talk link in addition to the user link. * Searching blocked usernames in block log is now clearer. * Better timezone recognition in user preferences. * Extensions can now participate in the extraction of titles from URL paths. * The command-line installer supports various RDBMSes better. * The interwiki links table can now be accessed also when the interwiki cache is used (used in the API and the Interwiki extension). Internationalization - -------------------- * More gender support (for instance in user lists). * Add languages: Canadian English. * Language converter improved, e.g. it now works depending on the page content language. * Time and number-formatting magic words also now depend on the page content language. * Bidirectional support further improved after 1.18. Release notes - ------------- Full release notes: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob_plain;f=RE LEASE-NOTES-1.19;hb=1.19.0beta2 https://www.mediawiki.org/wiki/Release_notes/1.19 Co-inciding with these security releases, the MediaWiki source code repository has moved from SVN (at https://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3) to Git (https://gerrit.wikimedia.org/gitweb/mediawiki/core.git). So the relevant commits for these releases will not be appearing in our SVN repository. If you use SVN checkouts of MediaWiki for version control, you need to migrate these to Git. If you up are using tarballs, there should be no change in the process for you. Please note that any WMF-deployed extensions have also been migrated to Git also, along with some other non WMF-maintained ones. Please bear with us, some of the Git related links for this release may not work instantly, but should later on. To do a simple Git clone, the command is: git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git More information is available at https://www.mediawiki.org/wiki/Git For more help, please visit the #mediawiki IRC channel on freenode.net irc://irc.freenode.net/mediawiki or email The MediaWiki-l mailing list at mediawiki-l(a)lists.wikimedia.org. ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.tar.gz Patch to previous version (1.19.0beta1), without interface text: http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.patch.gz Interface text changes: http://download.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.0beta2.patc h.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.tar.gz.si g http://download.wikimedia.org/mediawiki/1.19/mediawiki-1.19.0beta2.patch.gz. sig http://download.wikimedia.org/mediawiki/1.19/mediawiki-i18n-1.19.0beta2.patc h.gz.sig Public keys: https://secure.wikimedia.org/keys.html

5 5

MediaWiki to Latex Converter
by Hugo Vincent 18 Jun '12

18 Jun '12

Hi everyone, I recently set up a MediaWiki (http://server.bluewatersys.com/w90n740/) and I need to extra the content from it and convert it into LaTeX syntax for printed documentation. I have googled for a suitable OSS solution but nothing was apparent. I would prefer a script written in Python, but any recommendations would be very welcome. Do you know of anything suitable? Kind Regards, Hugo Vincent, Bluewater Systems.

6 13

Database dump of Bugzilla
by John Du Hart 21 May '12

21 May '12

I'm currently investigating alternative bug tracker and project management software for MediaWiki. To do that I'll be installing some different software on the Labs and importing existing bugs for evaluation by the development team and users. The following software is planned for test: - JIRA <http://www.atlassian.com/software/jira/overview> + Greenhopper + Bonfire - YouTrack <http://www.jetbrains.com/youtrack/> - The Bug Genie <http://www.thebuggenie.com/index.php> - Redmine <http://www.redmine.org/> - ChiliProject <https://www.chiliproject.org/> If you have any suggestions for this list I'd be glad to hear it. Of course, this goes back to the original request. To do this I need a dump of the current Bugzilla install. Is it possible for me to get this and under what conditions? Thank you. -- John

18 43

Report on WebFonts deployment
by Siebrand Mazeland (WMF) 07 May '12

07 May '12

Dear all, My apologies up front for the long e-mail that follows. In this e-mail you will find a comprehensive status overview of the recent WebFonts deployment. On Monday December 12 at 18:00 UTC we deployed the extension WebFonts[1] to 40 wikis in 11 Indic languages and Wikimedia Incubator -- all wikis in Assamese, Bengali, Gujarati, Hindi, Kannada, Marathi, Nepali, Oriya, (Eastern) Punjabi, Sankrit and Telugu have WebFonts now. WebFonts was not deployed on Malayalam and Tamil projects. The reason for this was that community members had requested us not to. We are confident that in time, the communities will request that WebFonts is enabled on their projects. WebFonts aims to resolve the issue that users see incomplete web pages, because the fonts to properly render the page is not present in the local system by downloading the font through the browser. One of our great challenges developing this functionality is the multitude of scripts and the low availability of freely licensed fonts that may be modified and redistributed. Over the past few months we have tried to build out a collection of fonts in the extension mainly for Indic languages, and we have performed many tests. We have solicited community involvement through messaging in village pumps, e-mails on mailing lists, blog posts on personal blogs as well as on the Wikimedia Foundation blog, at developer events, through personal e-mails and through our bug tracker, and gotten some feedback, although unfortunately not for all the languages we would like to have gotten it for. We will of course continue our efforts in this area. Next to the community involvement, we have had a two day session with the Red Hat Localisation team in Pune, India. Since the deployment, we have been criticised for not communicating enough -- or not through the right channels, not with the right people, not in time, or too soon, or not with the right messages. I'm not really sure how to respond to that, except for uttering a general "mea culpa, mea maxima culpa". We are working really hard in continuously improving the work that we do, and the way that we do it. We make mistakes, we are human after all, and when we become aware of our mistakes, we will do everything in our power to make it better. With our team we support the mission of the Wikimedia Foundation to "imagine a world in which every single human being can freely share in the sum of all knowledge." I care about that -- a lot. We all care, and I am pretty certain that we're not ignorant, dismissive or incapable. I acknowledge that we as the Localisation team are a relatively new entity within the MediaWiki development community and within the Wikimedia Foundation, with a very wide scope, and that we are dealing with a lot of technical details on which we are simply not able to assess the final quality; there are after all 7.500 languages in this world of over 7 billion people that we theoretically all cover, some 350 of those languages are supported in MediaWiki, and 280 within Wikimedia. I accept that we cannot keep everybody happy -- doesn't keep us from trying, though. I want to try and work with as many people as possible in a constructive way. With these numbers, that's not always easy to coordinate. To channel the input on languages, we have set up "Language Support Teams"[2]. We do not yet have a language support team for every language. Please sign up if you care about the technical facilitation of your language in the Wikimedia movement. Let's use the mediawiki-i18n mailing list[3] to have constructive discussions about language support. Let's use the #mediawiki-i18n IRC channel[4] on Freenode to have real-time discussions. Let's use bugzilla.wikimedia.org to report bugs[5]. Link [5] explains the bug reporting procedure. If you already know how, report issues quickly using this link: http://ur1.ca/6ov9a . Since the deployment, we have been made aware of about 17 issues. Some very serious in nature, others not requiring immediate attention. Yesterday an issue with web fonts not loading in Firefox was resolved in the infrastructure. Today around 15:30 UTC, we have deployed fixes for an additional hand full of issues[6]: functionality disabled in IE6, IE8 on Windows XP, selection buttons not working properly in IE7 and hiding the Samyak fonts in the font selector. During our current sprint, we are working on a framework for multi-lingual and localised user documentation as well as feature based feedback functionality for WebFonts, Narayam and Translate. In the future we will also explore what is known as "dark launch" by some, a kind of hidden live deployment of a feature, only usable be for example manipulating a URL. This would allow us to deploy a feature in a live environment, without having the "full deployment" impact. Thanks for reading through this. I am looking forward to working with you! Please read on for details on all the issues that were reported on WebFonts recently. Cheers! Siebrand Mazeland Product Manager Localisation Wikimedia Foundation ======================================= Links ======================================= [1] https://www.mediawiki.org/wiki/Extension:WebFonts [2] https://translatewiki.net/wiki/Language_support_team [3] https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n [4] https://translatewiki.net/wiki/Special:WebChat [5] https://www.mediawiki.org/wiki/Bugzilla [6] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106204 ======================================= Open issues ======================================= https://bugzilla.wikimedia.org/33004 -- Old cached pages do not have web fonts enabled Priority: HIGH -------------------------------------------------------------------------------------- Wikimedia is able to serve this many pages with relative few servers because of very aggressive caching strategies, especially for anonymous users. WebFonts requires the addition of JavaScript for anonymous users, which is not being done for pages that are in the squid cache at the moment WebFonts was enabled. All squid cache objects for wikis on which WebFonts was deployed need to be purged. An internal RT ticket created for the Wikimedia Operations team to get anonymous squid caches purged. This may take up to a week or longer to be resolved. https://bugzilla.wikimedia.org/33018 -- Firefox 5 on Windows XP has script time-outs Priority: MEDIUM -------------------------------------------------------------------------------------- The Localisation team has tested this report, and was not yet able to confirm the observation. The reason for using a non-recent version of Firefox for the report was the alleged lower memory usage. Brion noted that Mozilla has been actively working on lowering memory usage over the last year, so the reporter may be better off with the current versions than the old ones. https://bugzilla.wikimedia.org/33110 -- Google Crome on Windows XP dispays gibberish Priority: LOW -------------------------------------------------------------------------------------- Observed very rarely on a page on Wikimedia Incubator, and we have not been able to reproduce this observation, let alone reproduce it reliably. A screenshot is present in the bug report. Except for reporting upstream, no action is being taken on this issue at this point in time. https://bugzilla.wikimedia.org/33054 -- Hinting issues in Lohit fonts Priority: MEDIUM -------------------------------------------------------------------------------------- Confirmed in Windows XP. We can do something to the font by adding hinting, but this is a lot of work if it needs to be done manually. The stem of the Lohit glyphs could do with more width and darkness. This may not be desirable for platforms (Linux) which render it perfectly, because it already has hinting and anti-aliasing on an operating system level. Same goes got Windows 7. https://bugzilla.wikimedia.org/33100 -- Page crashes on Webkit browsers with WebFonts enabled. Priority: MEDIUM (could be HIGH if we find many occurances) -------------------------------------------------------------------------------------- A page in Nepali Wikipedia makes a tab on Mac OS X 10.7.2 with Google Crome crash. This behaviour was also reported for Mac OS X 10.7.2 (11C74) with Safari 5.1.1 (7534.51.22, r102522) [This is a webkit nightly build] by thedj. This is most probably related to the WebFonts code, because if, as a logged in user, web fonts is disabled in preferences, the page does not crash Chrome. Developer Derk-Jan Hartman was asked to report this bug in the WebKit. Please make us aware of any additional pages that would cause this behaviour in any wiki. https://bugzilla.wikimedia.org/33102 -- OSX 10.7.2/Opera 11.60 has no fallback for Latin characters Priority: MEDIUM -------------------------------------------------------------------------------------- This is a bug that needs to be reported upstream. No technical measures have been taken so far to mitigate this issue. One of the Localisation team members has been in contact with a high level executive of Opera, and will contact that person again. We're going to wait for a few days for an outcome -- if there is no expectation of a relatively quick fix, we might disable WebFonts for Opera completely. Opera unfortunately does not have a public bug tracker. https://bugzilla.wikimedia.org/33027 -- Narayam and WebFonts both loading slows down page Priority: MEDIUM -------------------------------------------------------------------------------------- The reporter claims that the functionality is quicker on translatewiki.netthan it is in Wikimedia wikis. A commenter states that more functionality usually means more code, means more data that needs to be transferred, and without changing bandwidth, that causes longer load times. This currently isn't our highest priority, but eventually we will look into this a little deeper. We're inviting volunteers to do some of the data gathering and analysis for us. What is needed in our opinion is insight in the data volume added by WebFonts, as well as an assessment of the code quality with regards to size optimisation. All referenced properly, of course :). There are alternate EOT conversion tools that have a good compression ratio. Needs to be explored, but EOT is not required for modern browsers since they started using WOFF fonts which are compressed OpenType fonts. https://bugzilla.wikimedia.org/33085 -- Integration of updated Lohit-Tamil Font Priority: MEDIUM -------------------------------------------------------------------------------------- Request to update WebFonts with a font that is updated upstream. This is something the Localisation team checks regularly. Will probably be closed this week, pending issues the have a higher priority. https://bugzilla.wikimedia.org/32942 -- Provide help page and bug report link for WebFonts Priority: HIGH -------------------------------------------------------------------------------------- More recently developed tools by the Wikimedia Foundation have often included feedback mechanisms. The Localisation team plans on implementing these for the functionality of the WebFonts, Narayam and Translate extension. Besides that, we also want to provide multi-lingual and localised documentation. This needs some thinking and some work to provide in a structured and navigable way. We'll keep you posted. It will most probably involve translatable *user* documentation on MediaWiki.org and hopefully it is possible to have one feedback location per feature across the multiple Wikimedia wikis -- this is something we're going to contact the ArticleFeedback and MoodBar teams for. ======================================= Closed issues ======================================= https://bugzilla.wikimedia.org/33025 -- When changing to a non-default web font, the content does not -------------------------------------------------------------------------------------- This issue was a side effect of a feature to allow multiple web fonts to be used using the "lang" attribute. It was resolved in https://www.mediawiki.org/wiki/Special:Code/MediaWiki/105980 and has been deployed. https://bugzilla.wikimedia.org/33034 -- Web fonts not loading in Firefox -------------------------------------------------------------------------------------- Duplicate reports were 33038 and 33044. This issue originated from http://www.w3.org/TR/css3-fonts/#same-origin-restriction. Almost all browsers except for Firefox ignore that specification. A fix was designed and deployed: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106092, https://gerrit.wikimedia.org/r/1501. Thanks to Roan, Brion and Ryan for their help. https://bugzilla.wikimedia.org/32775 -- Gibberish in Internet Explorer 8 on Windows XP -------------------------------------------------------------------------------------- This is an unexplained phenomenon only observed in Internet Explorer on Windows XP. It is also hard to reproduce. One of the developers was able to make something somewhat reproducible on a clean, fully patched installation of Windows XP with Internet Explorer 8. See bug report for details. Based on these observations we think it is a bad idea to keep supporting WebFonts in Internet Explorer 8 on Windows XP and we have disabled it in https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106172. This fix has been deployed. https://bugzilla.wikimedia.org/33096 -- Internet Explorer 6 does not have font fallback -------------------------------------------------------------------------------------- IE6 not having font fallback causes Latin characters to display as squares when a web font is loaded that does not contain glyphs for the Latin script. A screenshot is available at http://media.crossbrowsertesting.com/users/34057/screenshots/window/z669002…. Based on this observation, we think it is a bad idea to keep supporting WebFonts in Internet Explorer 6 and we have disabled it in https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106172. This fix has been deployed. https://bugzilla.wikimedia.org/33024 -- WebFonts menu buttons not working in IE7 -------------------------------------------------------------------------------------- This was caused by the JavaScript $( '<input type="radio" />' ) . attr( "name" ,"font"); not working in IE6 and IE7. Updating name attributes once they have been created is not possible. We think there may be more occurances of this in our code (one occurance in jQuery has already been identified: resources/jquery/jquery.validate.js:59). A fix was made in https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106175. This fix has been deployed. https://bugzilla.wikimedia.org/33040 -- Overlap in Samyak font for Hindi and Sanskrit -------------------------------------------------------------------------------------- This issue occurs in Windows XP and Windows 7 (possibly also in Windows Vista) when using Google Chrome. It is not observed when using Chrome with Mac OS X 10.7.2 or several Linux distributions (Debian and Fedora). Samyak Devanagari is available as a non-default web font in Hindi, Marathi, and Sanskrit. Samyak Gujarati is available for Gujarati as a non-default font. This font needs to be corrected. The maintainers will be notified of the observed issues, and mean while, the fonts will be removed from the WebFonts selection list (but can still be used using the font-family property. A fix was made in https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106179. This fix has been deployed. https://bugzilla.wikimedia.org/33039 -- Overlap in Madan font for Nepali -------------------------------------------------------------------------------------- This report was invalid. The reporter was not aware of the correct glyph for the Nepali script. Comments on this bug report resulted in two odd observations (Crome crash, Opera font fallback), that have been split off into separate bug reports: https://bugzilla.wikimedia.org/33100 and https://bugzilla.wikimedia.org/33102. https://bugzilla.wikimedia.org/33095 -- WebFonts menu can expand off the screen -------------------------------------------------------------------------------------- If the translations for "Select font" and "Login / Register" are really short, like in http://mr.wiktionary.org, expanding the WebFonts menu for anonymous users will display a menu that is partially off the screen. It was resolved in http://www.mediawiki.org/wiki/Special:Code/MediaWiki/106186, http://www.mediawiki.org/wiki/Special:Code/MediaWiki/106197, http://www.mediawiki.org/wiki/Special:Code/MediaWiki/106201, http://www.mediawiki.org/wiki/Special:Code/MediaWiki/106202. These revisions also depend on a few small UI changes of both WebFonts and Narayam, and will be deployed on December 19, 2011. <no bugzilla report> -- WebFonts menu expands under the control for customised input method in IE6 on transliteration -------------------------------------------------------------------------------------- There are issues with the z index in IE6. Because of https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106172, WebFonts is no longer available in IE6, so this issue is obsolete. Observing that the Hindi projects Wikipedia and Wiktionary are using an custom input methods tool, we would like to invite them to test Narayam which contains many input methods in a MediaWiki extension. We are very open to having the Hindi input method InScript tested and add a transliteration input method with some community representatives, as we have done with other Indic languages. We hope this will eventually lead to Narayam being adopted by the Hindi community, and the custom input method being abandoned.

13 15

OAuth
by Petr Bena 30 Apr '12

30 Apr '12

Hi, it's been almost 4 years since we came with the idea of implementing an OAuth to mediawiki. I think it's time to start. Question now is if it should be a part of core or extension for mediawiki. I myself would rather make it as extension, since there is probably no use for most of installations, except for large wikis. Quote: OAuth provides a standard protocol to negotiate secure access tokens and to provide third-party tools (web or client) with granular access to private resources. This protocol does not reveal usernames or passwords to the third-party tool. Offering OAuth based authorization on Mediawiki wiki's will increase the reusability of its data and spur the creation of an ecosystem of app's around Mediawiki. Is there anyone who is willing to help with this? If there is no one interested in this, or no comments, I would start a new extension called OAuth, which only purpose would be to enable this feature in mediawiki.

12 27

Cutting MediaWiki loose from wikitext
by Daniel Kinzler 30 Apr '12

30 Apr '12

Hi all. I have a bold proposal (read: evil plan). To put it briefly: I want to remove the assumption that MediaWiki pages contain always wikitext. Instead, I propose a pluggable handler system for different types of content, similar to what we have for file uploads. So, I propose to associate a "content model" identifier with each page, and have handlers for each model that provide serialization, rendering, an editor, etc. The background is that the Wikidata project needs a way to store structured data (JSON) on wiki pages instead of wikitext. Having a pluggable system would solve that problem along with several others, like doing away with the special cases for JS/CSS, the ability to maintain categories etc separate from body text, manage Gadgets sanely on a wiki page, or several other things (see the link below). I have described my plans in more detail on meta: http://meta.wikimedia.org/wiki/Wikidata/Notes/ContentHandler A very rough prototype is in a dev branch here: http://svn.wikimedia.org/svnroot/mediawiki/branches/Wikidata/phase3/ Please let me know what you think (here on the list, preferably, not on the talk page there, at least for now). Note that we *definitely* need this ability for Wikidata. We could do it differently, but I think this would be the cleanest solution, and would have a lot of mid- and long term benefits, even if it's a short term pain. I'm presenting my plan here to find out if I'm on the right track, and whether it is feasible to put this on the road map for 1.20. It would be my (and the Wikidata team's) priority to implement this and see it through before Wikimania. I'm convinced we have the manpower to get it done. Cheers, Daniel

8 16

Hackathon Berlin 2012
by Thomas Gries 24 Apr '12

24 Apr '12

Suggestion: git workshop and tutorial @ Hackathon Berlin 2012

7 8

Please register for the Berlin hackathon - June 1-3, 2012
by Sumana Harihareswara 19 Apr '12

19 Apr '12

I invite you to the yearly Berlin hackathon. It's 1-3 June and registration is now open. If you need financial assistance or help with hotel/hostel, just mention it in the registration form. https://wmberlin.eventbrite.com/ This is the premier event for the MediaWiki and Wikimedia technical community. We'll be hacking, designing, and socialising, primarily talking about Gadgets, the switch to Lua, Wikidata, and Wikimedia Labs. Our goals for the event are to bring 100-150 people together, with lots of people who have not attended such events before. User scripts, gadgets, API use, Toolserver, Wikimedia Labs, mobile, structured data, templates -- if you are into any of these things, we want you to come! Details: https://www.mediawiki.org/wiki/Berlin_Hackathon_2012 Thanks to Wikimedia Germany for hosting and coordinating this event. (Venue still to be determined.) -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation

1 1

migration guide
by Stéphane ANCELOT 18 Apr '12

18 Apr '12

Hi ! I thank you all everybody for your nice job, mediawiki is a great platform. However, as you may know, we are some people to develop , contribute to some extensions, and every time I migrate my wiki setup to a new version, that looks like a nightmare !!! (mostly for the last 1.18.1). I have either to upgrade extensions or dive into php code to make it running with the new mediawiki release. But this time, with 1.18.1 I am worried, because I do not have an in deep knowledge of the mediawiki process. So, the next time, a release is delivered, please provide with it a migration guide for extensions !!!!! This will permit every developer to maintain in a fast and efficient way, most extensions !! And since we are all very good developers, I am pretty sure some people will be able to provide a helpful migrating utility (when only function name changes apply) .... Today, I am not able to participate or migrate the CKeditor to the 1.18.1 Release . Regards . S.Ancelot

3 2

MathJax scalable math rendering update for 1.19
by Brion Vibber 16 Apr '12

16 Apr '12

In the last few days I've updated the Math extension's experimental MathJax support to where it can actually be enabled by individual users. If all goes well with review I'd love to get this deployed soon so the math-heads can turn it on and check for lingering incompatibilities... MathJax [http://www.mathjax.org/] is a client-side JavaScript library for parsing TeX or MathML code and rendering it in just about any modern browser -- it even works back to IE 6! -- using webfonts and HTML/CSS, MathML, or SVG as available. Here's a sample page on a test wiki, copied from en.wikipedia: http://leuksman.com/mw/index.php/Alpha_compositing This update to the extension builds on Nageh's work setting up an earlier version of MathJax as a user script, plus some help from the MathJax devs on their mailing list. Thanks guys! Big advantages of this over our current server-side math rendering: * font size & baseline match up with surrounding text for inline equations! * subpixel antialiasing or high-dpi displays allow math to render more sharply at default size * scalable -- you can zoom in your browser and things stay sharp * printable -- printed output also stays sharp (some browsers have font issues with some modes; to be experimented with) * in-browser zoom & copy-paste helpers And of course: * a strong open-source community maintaining it, who are happy to help us with integration and any needed fixes * it's not ocaml ;) The additions to Math extension add a third 'MathJax' rendering mode which users can opt in to at Special:Preferences. This replaces the older HTML and MathML rendering modes that we already disabled in 1.19. In the future when we've worked out the kinks, we can turn that into the default, and continue to use it as a fallback renderer for non-JavaScript browsers. (A nicer math edit/preview tool would be awesome too, especially for confirming that things work in both renderers in the future!) Revs that'll need to be reviewed & deployed: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/mathjax WikiProject:Mathematics talk page section: https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Mathematics#mathJa… -- brion

7 8

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l March 2012