Wikitech-l March 2015

wikitech-l@lists.wikimedia.org

116 participants
90 discussions

[hackathon] Wikimedia Hackathon Lyon : Scholarship deadline
by Alex Cella 19 Mar '15

19 Mar '15

Hey all! In the name of Wikimedia France, I express to all attendees our deepest gratitude to see so much motivation for the hackathon! On the other hand, I'd like to remind all of you that you can apply for a scholarship til the 31st of March. Follow the link to apply: https://dons.wikimedia.fr/civicrm/event/register?reset=1&id=8 Don't miss the deadline! :) Best regards, Alex. *Alexandre Cella* ASSISTANT LEVÉE DE FOND ET MÉCÉNAT FUNDRAISING AND SPONSORSHIP ASSISTANT *WIKIMEDIA FRANCE* +33 6 18 16 16 19 www.wikimedia.fr 40 rue de Cléry, 75002 Paris *Vos dons réguliers aident à faire fonctionner Wikipédia ! Soutenez Wikimédia France aujourd'hui* : https://dons.wikimedia.fr

1 0

Maps
by Max Semenik 19 Mar '15

19 Mar '15

Hi, just a quick note: as part of general search and discovery work, me and Yuri are resurrecting the project to have OpenStreetMap in Wikimedia starting in April. Because the initial part of this work will include researching options which will influence precise goals and this is yet to be done, we still can't commit to a precise timeline, but as a ballpark estimate I personally want to aim for serving PNG tiles at a reasonable, though not necessarily "dynamic maps on every WP page" scale by the end of Q4. Vector/multilingual maps would be the next stage. We will be mostly using Phabricator for planning, https://phabricator.wikimedia.org/tag/openstreetmap/ is my first pass on the outline of things to be done. Your comments and suggestions would be highly appreciated, please share your thoughts, ideas of projects that might use these maps, or just merciless critique! :D -- Best regards, Max Semenik ([[User:MaxSem]])

9 12

RFC meeting this week
by Tim Starling 18 Mar '15

18 Mar '15

In the next RFC meeting we will discuss the following RFC: * Master & slave datacenter strategy for MediaWiki <https://www.mediawiki.org/wiki/Requests_for_comment/Master_%26_slave_datace…> The meeting will be on the IRC channel #wikimedia-office on chat.freenode.net at the following time: * UTC: Wednesday 21:00 * US PDT: Wednesday 14:00 * Europe CET: Wednesday 22:00 * Australia AEDT: Thursday 08:00 -- Tim Starling

1 0

Our CAPTCHA is very unfriendly
by Jon Harald Søby 18 Mar '15

18 Mar '15

Hi all, My apologies if this is the wrong place to start a discussion on this, but it's a better place than nowhere. I recently took part in two very different Wikipedia workshops -- one in Uganda for schoolchildren aged 14-17, and one Bodø, Norway, for GLAM people aged 35-55. One glaringly obvious barrier of entry that was common for both groups is that the CAPTCHA we use is too freaking hard. The main concern is obviously that it is really hard to read, but there are also some other issues, namely that all the fields in the user registration form (except for the username) are wiped if you enter the CAPTCHA incorrectly. So when you make a mistake, not only do you have to re-type a whole new CAPTCHA (where you may make another mistake), you also have to re-type the password twice *and* your e-mail address. This takes a long time, especially if you're not a fast typer (which was the case for the first group), or if you are on a tablet or phone (which was the case for some in the second group). So I would like to start a discussion about changing to a CAPTCHA that is more user-friendly, and hopefully one that isn't as English/Latin-alphabet-centric as the one we currently use. If Ugandan children and old Norwegian people, which all use the Latin alphabet, have such problems deciphering the CAPTCHA, what about people speaking languages that don't use the Latin alphabet? I would prefer something more simplistic, like some sort of math or image-based CAPTCHA, instead of the current CAPTCHA we use. -- mvh Jon Harald Søby <http://meta.wikimedia.org/wiki/User:Jon_Harald_S%C3%B8by>

28 68

Improving static analysis tools for MediaWiki.
by Krys Nu 18 Mar '15

18 Mar '15

Hello, I wish to express my interest in working on the above mentioned project. I have the required technical skill -PHP- and I am willing tread new grounds. I would love to discuss more about the project, what is really expected of the student, to establish some measurable goals before getting myself soak into the community. Thanks Tahirih Natang

3 2

Application period for GSoC and Outreachy now open!
by Niharika Kohli 17 Mar '15

17 Mar '15

Google Summer of Code 2015 and Outreachy Round 10 have kicked off. We have already received a few proposals and a lot of projects have received tremendous interest. But some of these projects still lack mentors and we're hoping you might be interested in being one. 1. Cross-wiki watchlists[1]: A standalone cross-wiki watchlist web app has been proposed by Sitic. A prototype can be found at [2]. Missing mentors. 2. One stop translation[3]: Proposal by Phoneix303 for improving search for translation messages. 3. Show edits made on Commons on Watchlist[4]: Needs mentors. 4. Adding new datatypes in Wikidata[5]: Needs mentors and discussion. 5. Automatic analysis of Commons images for color-blind[6]: Needs discussion and mentors. 6. Adding user preference to deactivate/delete account[7]: Needs discussion and mentors. Your feedback on these is would be very helpful in pushing them forward. All projects in the pipeline can be found at [8]. [1]: https://phabricator.wikimedia.org/T92955 [2]: https://tools.wmflabs.org/watchr/ [3]: https://phabricator.wikimedia.org/T92929 [4]: https://phabricator.wikimedia.org/T91192 [5]: https://phabricator.wikimedia.org/T91505 [6]: https://phabricator.wikimedia.org/T59806 [7]: https://phabricator.wikimedia.org/T34815 [8]: https://phabricator.wikimedia.org/project/board/1042/ Thank you. Niharika.

1 0

Tor proxy with blinded tokens
by Chris Steipp 17 Mar '15

17 Mar '15

Jacob Applebaum made another remark about editing Wikipedia via tor this morning. Since it's been a couple months since the last tor bashing thread, I wanted to throw out a slightly more modest proposal to see what people think. This is getting some interest from a few people: https://zyan.scripts.mit.edu/blog/rate-limiting-anonymous-accounts/ Which lays out a way for twitter to use an external, trusted identity provider to verify identifies / throttle requested, and then create an account in a way that neither twitter or the identity provider can link the account to the request (as long as you mitigate timing attacks). What if we turn this around a bit and let the wiki establish identity and throttle, and open up an editing proxy that is accessible via tor which consumes the identities? Basically: * Established wiki user who wants to use tor makes a blinded request (maybe public, maybe a private queue for some group with appropriate rights) for a tor-based account creation token. * User gets that blinded token signed if they're in good standing, and are limited to some number (3 total, not less than 6 months since the last request, or something like that). * User creates an account on the editing proxy via tor, and gives their unblinded token to the proxy. The proxy creates an account for them, and allows edits via OAuth token using that new account. If the use turns it to be a spammer: * The anonymous account can be blocked like a normal account. The user is throttled on how many requests for accounts they can make. * If the proxy generates to much spam, a steward can revoke the key, and we all go home to think up the next experiment. To make this happen, we need: * a light editing proxy (I already have a couple of those as demo OAuth apps) which is run by a *non-wmf* entity * something for normal users to download and run that does the blinding for them * work out how to address timing attacks if the volume of requestors is low enough that we can correlate request to first edit by the proxy. Anyone interested in helping? Is this conservative enough for those worried about the flood of tor spam, while being simple enough that the average editor would be able to understand and go through the process?

14 29

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org
by Florian Schmidt 17 Mar '15

17 Mar '15

I fully upport and welcome this, but at least for Project:Support_desk you should communicate this on this LQT board, too, that it will be converted (if you didn't do hat already, i haven't looked now, because LQT ist terrible on mobile :P). There are probably very active supporters, who haven't subscribed this list, but they should have the possibility to post their needs and opinions about that. Best, Florian Gesendet mit meinem HTC ----- Reply message ----- Von: "Nick Wilson (Quiddity)" <nwilson(a)wikimedia.org> An: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org> Betreff: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org Datum: Di., März 17, 2015 01:51 LiquidThreads (LQT) has not been well-supported in a long time. Flow is in active development, and more real-world use-cases will help focus attention on the higher-priority features that are needed. To that end, LQT pages at mediawiki.org will start being converted to Flow in the next couple of weeks. There are about 1,600 existing LQT pages on Mediawiki, and the three most active pages are VisualEditor/Feedback, Project:Support_desk, and Help_talk:CirrusSearch.[1] The Collaboration team has been running test conversions of those three pages, and fixing issues that have come up. Those fixes are almost complete, and the team will be ready to start converting LQT threads to Flow topics soon. (If you’re interested in the progress, check out phab:T90788[2] and linked tasks.) The latest set is visible at a labs test server.[3] See an example topic comparison here: Flow vs LQT.[4]) The VisualEditor/Feedback page will be converted first (per James' request), around the middle of next week. We’ll pause to assess any high-priority changes required. After that, we will start converting more pages. This process may take a couple of weeks to fully run. The last page to be converted will be Project:Support_desk, as that is the largest and most active LQT Board. LQT Threads that are currently on your watchlist, will still be watchlisted as Flow Topics. New Topics created at Flow Boards on your watchlist will appear in your Echo notifications, and you can choose whether or not to watchlist them. The LQT namespaces will continue to exist. Links to posts/topics will redirect appropriately, and the LQT history will remain available at the original location, as well as being mirrored in the Flow history. There’s a queue of new features in Flow that will be shipped over the next month or so: * Table of Contents is done * Category support for Flow Header and Topics is done * VE with editing toolbar coming last week of March (phab:T90763) [5] * Editing other people’s comments coming last week of March (phab:T91086) * Ability to change the width & side rail in progress, probably out in April (phab:T88114]) * Search is in progress (no ETA yet) (phab:T76823) * The ability to choose which Flow notifications end up in Echo, watchlist, or both, and other more powerful options, will be coming up next (no ETA yet) That being said -- there are some LiquidThreads features that don’t exist in Flow yet. We’d like to hear which features you use on the current LQT boards, and that you’re concerned about losing in the Flow conversion. At the same time, we’d like further suggestions on how we could improve upon that (or other) features from LQT. Please give us feedback at https://www.mediawiki.org/wiki/Topic:Sdoatsbslsafx6lw to keep it centralized, and test freely at the sandbox.[6] Much thanks, on behalf of the Collaboration Team, Quiddity (WMF) [1] https://www.mediawiki.org/wiki/VisualEditor/Feedback and https://www.mediawiki.org/wiki/Help_talk:CirrusSearch and https://www.mediawiki.org/wiki/Project:Support_desk [2] https://phabricator.wikimedia.org/T90788 [3] http://flow-tests.wmflabs.org/wiki/Testwiki:Support_desk and http://flow-tests.wmflabs.org/wiki/VisualEditor/Feedback [4] http://flow-tests.wmflabs.org/wiki/Topic:Qmkwqmp0wfcazy9c and https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Error_creating_t… [5] https://phabricator.wikimedia.org/T90763 , https://phabricator.wikimedia.org/T91086 , https://phabricator.wikimedia.org/T88114 , https://phabricator.wikimedia.org/T76823 [6] https://www.mediawiki.org/wiki/Talk:Sandbox -- Nick Wilson (Quiddity) Community Liaison Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

2 1

Proposal for Outreachy program 2015
by Divya 17 Mar '15

17 Mar '15

Hi All, I am Dibya Singh and I am applying for FOSS Outreachy 10. I have selected a project from #possible-tech-projects list named One stop translation to improve consistency for translation. I have been in contact with mentor Niklas Laxström and Federico Leva alias for understanding the project in depth. I have drafted a rough proposal based on my interaction with the product as a user. Please find link for my proposal. Please give your valuable feedback. https://phabricator.wikimedia.org/T92929 Link for my mediawiki user page can be found here <https://www.mediawiki.org/wiki/User:Phoenix303> Regards, Dibya Singh

1 0

MediaWiki tests will verify the completeness of $wgAvailableRights
by hoo 16 Mar '15

16 Mar '15

Hi Everyone, just wanted to quickly let you know that MediaWiki will verify that extensions register all rights they define in $wgAvailableRights (or using the "UserGetAllRights" hook). To make sure your extension complies with that just add all the rights your extension defines to $wgAvailableRights (which is a simple string[] of theses user rights). This test will be introduced with https://gerrit.wikimedia.org/r/192087 Cheers, Marius

1 1

← Newer
1
2
3
4
5
6
7
8
9
Older →

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 2015