Wikitech-l August 2013

wikitech-l@lists.wikimedia.org

133 participants
130 discussions

Deploy schedule - Week of September 2nd, 2013
by Greg Grossmeier 30 Aug '13

30 Aug '13

Deployment Schedule and Highlights Week of September 2nd, 2013 Full schedule: https://wikitech.wikimedia.org/wiki/Deployments#Week_of_September_2nd == Monday == No deploys! US holiday! (Labor Day) == Tuesday == * E2: Deploying updates/bug fixes to Echo and PageTriage * MediaWiki Core: We'll be deploying 1.22wmf15 to all non-Wikipedia sites (Wiktionary, Wikisource, Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites) ** See the release notes here: https://www.mediawiki.org/wiki/MediaWiki_1.22/wmf15 == Wednesday == * Wikipedia Zero: Finalizing their intended code * MobileFrontEnd: Graciously moved to Wed to allow MWCore on Tuesday. * Gerrit: The machine that hosts Gerrit will be swapped for a much more powerful machine. This should not cause any issues to end users if things go to plan. == Thursday == * MediaWiki Core: Version 1.22wmf15 will be deployed to all Wikipedia language sites. * MediaWiki Core: The next release of MediaWiki, 1.22wmf16, will be deployed to the test wiki group (test.wikipedia, test2.wikipedia, test.wikidata, and mediawiki.org) * E3 is deploying bug fixes to GuidedTour and GettingStarted. == Friday == No deploys! It's Friday! Have a good weekend and let me know if you have any questions, Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

1 0

Pre-Release Announcement for MediaWiki 1.19.8, 1.20.7, and 1.21.2
by Chris Steipp 30 Aug '13

30 Aug '13

This is a notice that on Tuesday, September 3rd between 20:00-21:00 UTC (1-2pm PDT) Wikimedia Foundation will release security updates for current and supported branches of the MediaWiki software, as well as several extensions. Downloads and patches will be available at that time, with the git repositories updated later that afternoon.

1 0

List of projects "supported" by Wikimedia
by Quim Gil 30 Aug '13

30 Aug '13

Hi, in the context of the tech community metrics KPIs [1]... We need a list of OSS projects developed by the Wikimedia/MediaWiki community and deployed in Wikimedia servers + apps. There was none, so here is an attempt: https://wikitech.wikimedia.org/wiki/User:Qgil/Supported_projects Please have a look to see if there is something missing, or something that shouldn't be there. Feel free to edit directly or to comment at the related bug report: https://bugzilla.wikimedia.org/show_bug.cgi?id=53374 [1] https://www.mediawiki.org/wiki/Community_metrics#Key_performance_indicators -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

2 3

Slippy map embedded in geohack page not working in HTTPS mode
by Neil Harris 30 Aug '13

30 Aug '13

I've just noticed that the slippy map within the wmflabs GeoHack page does not work when accessed via HTTPS, and thought I should mention it here. For example, compare: http://tools.wmflabs.org/geohack/geohack.php?pagename=Foo&params=10_N_10_E with https://tools.wmflabs.org/geohack/geohack.php?pagename=Foo&params=10_N_10_E Could this be a mixed-content issue involving the script that drives the slippy map not using protocol-relative URLs, or the slippy map tile provider not responding to HTTPS? Neil

4 10

Browser tests for extensions
by Chris McMahon 29 Aug '13

29 Aug '13

When we began creating cross-browser regression tests using Selenium, we kept them all in a repository named '/qa/browsertests'. We created regression tests for features across all WMF development teams and Platform functions, from the appearance of Preferences to navigating UploadWizard to ArticleFeedback and PageTriage to MobileFrontend to UniversalLanguageSelector etc. etc. etc. We run these tests against some combinations of environments in beta labs cluster, test2wiki, and production. There will probably always be a need for a grab-bag repo of general cross-browser regression tests, but managing tests in this way has some drawbacks: * builds run for all features at the same time, regardless of the development process for each feature * failed builds can be caused by any feature, and it takes some effort to find the source of any failed build We have taken some steps recently to improve how we manage and run these tests. In particular, we have begun moving certain browser tests out of the /qa/browsertests repo and into the repos of the particular extensions or features being tested. From there, we are running individual builds for those features in the appropriate test environments. Our first model for doing this was MobileFrontend. The browser tests for MobileFrontend have resided in /MobileFrontend/tests/acceptance for some time now, and building from that repo has proven quite effective. Not long ago Nik Everett created an extensive set of browser tests for CirrusSearch and very quickly put them under /CirrusSearch/tests/browser. Work on CirrusSearch is proceeding quickly and these tests fail often for now, so it is nice to have them in a repo where they can be examined outside of the main /qa/browsertest builds. Back in May of this year we created a number of browser tests for the UniversalLanguageSelector with help from Runa Bhattacharjee and Niklas Laxström, and Amir Aharoni has been doing work on those in the time since. Recently at the request of the Language team we moved the ULS browser tests to the repo at UniversalLanguageSelector/tests/browser, and we're running those in their own build as well. Finally, we have been creating some browser tests for VisualEditor that will be particularly useful for cross-browser acceptance testing and regression testing. Of course the tests are valuable right now as well, they help us identify important issues like https://bugzilla.wikimedia.org/show_bug.cgi?id=53360. These tests today reside under VisualEditor/modules/ve-mw/test/browser. Rachel Thomas, our intern with the Outreach Program for Women has contributed a number of VisualEditor browser tests.

1 0

MediaWiki Language Extension Bundle 2013.08 release
by Kartik Mistry 29 Aug '13

29 Aug '13

Hello, I would like to announce the release of MediaWiki language extension bundle 2013.08 * https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2013.08.tar… * sha256sum: 21b3abf3a8e19d0c746d41d246e4bc8883d0f5e179d894e1720500031c621f2c Quick links: * Installation instructions are at https://www.mediawiki.org/wiki/MLEB * Announcements of new releases will be posted to a mailing list: https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n * Report bugs to https://bugzilla.wikimedia.org * Talk with us at #mediawiki-i18n @ freenode Release notes for each extension are below. Kartik Mistry == Babel, CLDR and LocalisationUpdate == * Only localisation updates. == Translate == === Noteworthy changes === * Initial translation area height is increased. With a higher translation area it provides more space for suggestions. * Bug 47861: Allow text selection in page mode of Special:Translate so that parts of original message can be copied and pasted. * Bug 46875: The tooltip highlighting the proofread action now appears less often in incorrect places. * Bug 36692: On language stats and message group stats, rows can no longer get stuck in highlighted state. * On translation pages, a "Translate" tab is shown instead of "Edit" tab to improve usability and discoverability of the translation functionality. * Bug 49850: The page mode of Special:Translate parsed incorrectly some square brackets as external links. Now it checks for supported protocol before turning it into a link. * Bug 52623: Discard changes button now works as expected in Google Chrome. * Map 'be-tarask' language to 'be' language in Yandex machine translation suggestion. * Bug 52272: Assistant languages suggestions ('In other languages') are no longer stripped of newlines. * A step forwards for arbitrary source language for translatable pages was taken. Translate now extension now respects the page soure language returned by MediaWiki. There is still no user interface to set the page source language. * Bug 49326: Add "notify translators" link after marking page for translation when TranslationNotifications is installed. * Loading of message content now works correctly. It was broken with namespaces which did not force capitalization of the first letter. * Bug 52216: Special:AggregateGroups has now better group selector which supports search. === Changes relevant to API users and developers === * Check for and disallow dynamic groups in ApiQueryMessageGroupStats. * Reimplement beforeSubmit, afterSubmit and afterRegisterFeatures hooks to support them in the new TUX editor. == UniversalLanguageSelector == === Noteworthy changes === * Added support for event logging. To use it you need to install the EventLogging extension. The support is considered to be experimental. To enable event logging, add following lines to your LocalSettings.php: require_once "$IP/extensions/EventLogging/EventLogging.php"; $wgMainCacheType = CACHE_MEMCACHED; $wgMemCachedServers = array( '127.0.0.1:11211' ); $wgEventLoggingBaseUri = 'http://localhost:8080/event.gif'; $wgEventLoggingFile = '/var/log/mediawiki/events.log'; To learn more about setting up EventLogging extention, see: [1] https://github.com/wikimedia/mediawiki-extensions-EventLogging/blob/master/… [2] https://www.mediawiki.org/wiki/Extension:EventLogging * The libraries are loaded on demand, when they are actually used for reducing traffic. * Language settings are closed when clicked outside ULS langauge selection window. * Bug 50564: When the user makes changes in multiple modules and clicks the Cancel button or closes the language settings after that, cancel the changes in all the modules. * Bug 50562: Canceling font change doesn't work for system font. * Internal code changes to improve performance and make loading faster. * Top position the ULS for IME menu with reference to the input field instead of ... menu item to fix weird positioning at some places. * Bug 51923: Use no-repeat follow url for background images to remove possible duplicate images * Fix wrong language comparison in webfonts so that expliticit fontfamily style are not added to child elements. * Use events instead of callbacks for success or no results in the ULS search box. This allows extension users to bind for this event and reduces callbacks. * Use mw.hook for notifying cancel of settings window to modules. * Documentation fixes. === Browser Blacklisting === * Currently, Internet Explorer < 7 is blacklisted for MediaWiki version 1.22 and Internet Explorer 6 and 7 are explicitly blacklisted for MediaWiki before version 1.22 === Fonts === * Added Gentium font for Latin languages rich with diacritics like IPA, Vietnamese and Polytonic Greek. * Added Junicode font for Old English. * Added Phetsarath font for Lao. * Added lklug font for Sinhala. * Added the Nuosu SIL font for the Yi language. * Added Xerxes for for Old Persian. * Added Shapour font for Pahlavi script. * Added Nazli as a serif font for Persian script. === Input methods === * Bug fixes in Gujarati Phonetic, Gujarati Inscript 2, Punjabi Phonetic and Oriya keyboards that didn't allow typing some characters. * Added Kyrgyz Cyrillic keyboard. * Added IPA X-SAMPA layout. * Fixed the IPA-SIL layout: use the "modifier letter apostrophe" for ejective consonants. * Fixes ZWNJ character issues for Hindi and Marathi input methods. * Updated Javanese keyboard. * Removed outdated Myanmar keyboard. -- Kartik Mistry | IRC: kart_ {0x1f1f, kartikm}.wordpress.com

2 1

New search backend live on mediawiki.org
by Nikolas Everett 29 Aug '13

29 Aug '13

Today we threw the big lever and turned on our new search backend at mediawiki.org. It isn't the default yet but it is just about ready for you to try. Here is what is we think we've improved: 1. Templates are now expanded during search so: 1a. You can search for text included in templates 1b. You can search for categories included in templates 2. The search engine is updated very quickly after articles change. 3. A few funky things around intitle and incategory: 3a. You can combine them with a regular query (incategory:kings peaceful) 3b. You can use prefix searches with them (incategory:norma*) 3c. You can use them everywhere in the query (roger incategory:normans) What we think we've made worse and we're working on fixing: 1. Because we're expanding templates some things that probably shouldn't be searched are being searched. We've fixed a few of these issues but I wouldn't be surprised if more come up. We opened Bug 53426 regarding audio tags. 2. The relative weighting of matches is going to be different. We're still fine tuning this and we'd appreciate any anecdotes describing search results that seem out of order. 3. We don't currently index headings beyond the article title in any special way. We'll be fixing that soon. (Bug 53481) 4. Searching for file names or clusters of punctuation characters doesn't work as well as it used to. It still works reasonably well if you surround your query in quotes but it isn't as good as it was. (Bugs 53013 and 52948) 5. "Did you mean" suggestions currently aren't highlighted at all and sometimes we'll suggest things that aren't actually better. (Bugs 52286 and 52860) 6. incategory:"category with spaces" isn't working. (Bug 53415) What we've changed that you probably don't care about: 1. Updating search in bulk is much more slow then before. This is the cost of expanding templates. 2. Search is now backed by a horizontally scalable search backend that is being actively developed (Elasticsearch) so we're in a much better place to expand on the new solution as time goes on. Neat stuff if you run your own MediaWiki: CirrusSearch is much easier to install than our current search infrastructure. So what will you notice? Nothing! That is because while the new search backend (CirrusSearch) is indexing we've left the current search infrastructure as the default while we work on our list of bugs. You can see the results from CirrusSearch by performing your search as normal and adding "&srbackend=CirrusSearch" to the url parameters. If you notice any problems with CirrusSearch please file bugs directly for it: https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions… Nik Everett

5 6

HTTPS enabled for all logged-in users
by Greg Grossmeier 28 Aug '13

28 Aug '13

== HTTPS enabled by default for logged-in users on Wikimedia sites == Today, August 28, the Wikimedia Foundation is making a change to the software that powers the Wikimedia projects: By default, all logged-in users will now be using HTTPS to access Wikimedia sites. What this does is encrypt the connection between the Wikimedia servers and the user's browser so that the information sent between the two is not readable by anyone else. This is in response to the recent concerns over the privacy and security of our user community, and we explained the rationale for this change in our post about the future of HTTPS at Wikimedia[0]. ===What this means for you === How this works is simple: If a user wants to log in, they will be redirected to use HTTPS for the login, thus keeping their username and password secure. After they are logged in, they stay on the HTTPS version of the Wikimedia site they are using. === Excluded Countries === Some users live in areas where HTTPS is not an easy option, most times because of explicit blocking by a government. At the request of these communities, we have made an explicit exclusion for users from those affected countries. Simply put, users from China and Iran will not be required to use HTTPS for logging in, nor for viewing any Wikimedia project site ===Disabling=== Are you having a slow or unreliable experience while browsing Wikimedia sites over HTTPS? Then you can turn HTTPS off in your user preferences, under the "User profile" tab: Uncheck "Always use a secure connection when logged in". You will need to log out and log in again for the preference to take effect. But remember, you will still need to log in using the secure HTTPS process. ===HELP!=== For further details, please see the HTTPS[1] page on Meta-Wiki, which is available in several languages. Are you unable to log in and edit a Wikimedia wiki after this change? Please contact the Wikimedia Foundation Operations team via any means you find comfortable, including this blog post's comments section, on IRC in the #wikimedia-operations channel, or via the https(a)wikimedia.org email address. Greg Grossmeier [0] http://blog.wikimedia.org/2013/08/01/future-https-wikimedia-projects/ [1] http://meta.wikimedia.org/wiki/HTTPS -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

4 3

WMFs stance on non-GPL code
by Jeroen De Dauw 28 Aug '13

28 Aug '13

Hey, I'm curious what the stance of WMF is on BSD, MIT and MPL licensed code. In particular, could such code be deployed on WMF servers? Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 --

17 21

Extension OpenID: new version 3.40 published
by Thomas Gries 28 Aug '13

28 Aug '13

Today, I published a new version of the extension OpenID. - adds the long-wanted option for Admins to pin logins to a single (fixed, or "forced") OpenID Provider. - defines parameters of OpenID provider/s in an array. Parameters are no longer hard-coded on several places like in the CSS. - fixes other minor problems. The extension has been tested with mediawiki core and PHP 5.5.+ (previous PHP versions 5.3.+ and 5.4.+ do also work). Homepage https://www.mediawiki.org/wiki/Extension:OpenID Commit message of https://gerrit.wikimedia.org/r/#/c/55287/73 CHANGES https://git.wikimedia.org/raw/mediawiki%2Fextensions%2FOpenID/ea5677c252c73… README https://git.wikimedia.org/raw/mediawiki%2Fextensions%2FOpenID/ea5677c252c73… If you have to report bugs: https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions…

1 0

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 August 2013