Wikitech-l February 2012

wikitech-l@lists.wikimedia.org

135 participants
154 discussions

Bugzilla: Adding Huggle and other wiki-related projects
by mah＠wikimedia.org 27 Feb '12

27 Feb '12

This past Friday, at the request of Michael Movchin, I added a Huggle product to Bugzilla. Michael and Petr Bena are working on a web version of Huggle that can be used if you don't have access to Windows (which, having not used Huggle at all, is where I understand Huggle currently runs). I'd like to add more of these sort of tools to Bugzilla, just as we have a lot of MediaWiki extensions in Bugzilla, since I think this could encourage cross pollination between the WMF projects and people who are interested in things that aren't core to WMF. -- Mark A. Hershberger Bugmeister Wikimedia Foundation mah(a)wikimedia.org

4 3

Images in wikipedia
by nischay nahata 27 Feb '12

27 Feb '12

When using wikipedia and clicking on an image it opens up on a new page. Wouldn't it be nice if it just scaled-up on the same page using JS. Is there an extension there for this? and if yes why not implemented on wikipedia? -- With Regards Nischay Nahata B.tech 3rd year Department of Information Technology NITK,Surathkal irc-nick nischayn22

5 5

Re: [Wikitech-l] [Mediawiki-l] authentication on Wikipedia via user_name OR user_email
by Nicolas Brouard INED 27 Feb '12

27 Feb '12

Thanks to Platonides for his comment and also to Olivier (the author of the Realnames extension) who told me to forward the following patch to wikitech-l (which I just subscribed to) for advices, comments and critics. I was just wondering if this small patch in User.php (function idFromName) was enough in most cases: $dbr = wfGetDB( DB_SLAVE ); $s = $dbr->selectRow( 'user', array( 'user_id' ), array( 'user_name' => $nt->getText() ), __METHOD__ ); if ( $s === false ) { //Start Patch $result = null; $stwo = $dbr->selectRow( 'user', array( 'user_id' ), array( 'user_email' => $nt->getText() ), __METHOD__ ); if ( $stwo === false ) { $result = null; }else { $result = $stwo->user_id; } //End patch } else { $result = $s->user_id; } Then, just try to enter your e-mail on a standard wiki in place of your username and you will be authenticated to the first ID (and user_name) having your e-mail. The importance of e-mails as a simple way to authenticate on modern sites can't be ignored. If you want to enter your standard username for authentication you can do it too. But if your username is not a Roman but an Arabic, Thai, Japanese etc. username or even a French username with accents and if you decided to have authorship recognized in your own language and not only in a English transliterated way, you can also do it with as standard mediawiki installation. But if you are working with somebody who has an English keyboard only, the copy-paste of your Unicode username may be tedious and you would prefer to enter your e-mail address. The modified Login form could be: Username (or e-mail address): |___________________| Password: |___________________| If someone could test this patch above and report the security issues as well as performances, it could be great for us. We are managing Demopaedia.org and are willing to open the site to professional demographers (being already subscribed to a national or international union for the scientific study of population). We will not use various LDAP authentication processes but use local standard mediawiki databases. The usual way to be authenticated is the e-mail and password, and we want to keep this option. If you look (for example) at the work of Mikael, his work is authored in Cyrillic: Михаил Денисенко on http://ru-ii.demopaedia.org/w/index.php?title=90&action=history, other Russian authors use the transliteration. It is a question of taste. If Mikael is traveling and doesn't have a Cyrillic keyboard, he would be pleased to enter his email to authenticate. The password to be entered is the password linked with his username. For people having multiple usernames (pseudos) with the same e-mail but different passwords for each, a better patch could be to test the password entered and to link with the unique username. But I am not an expert in mediawiki and php and don't know how to get the password within the function idFromName. I understand that e-mails should not be revealed and the above patch satisfies this condition. Comments, advices, critics, code are welcome. Nicolas Le 15 févr. 2012 à 23:57, Platonides a écrit : > On 13/02/12 19:56, Nicolas Brouard INED wrote: >> Thanks John for your comment. It would mean that people logging with an email will have a default account (lowest ID with the same email or whatever rule). >> >> For authorship Wikimedia doesn't encourage multiple account names (multiple (>3?) pseudos are blamed). And usually, for a corporate wiki you don't have multiple accounts. If you decide to change your name for any reason (divorce for example) you are supposed to have a (new) unique name. You usually can also have email aliases. >> >> And if you want to log on a specific account name, you can copy and paste your account name (if your keyboard doesn't allow you to enter your real, not transliterated, name). >> >> Thus, I am not sure that it is strong objection for corporate wikis at least. >> >> PS: I am trying to understand how to have a working MyAuthPlugin.php and to get the email in authenticate but it requires time and I haven't found so many examples on the Web. >> >> Any hint or comment is welcome. >> >> Nicolas > > I don't think you can do that with just an auth plugin. You would need > to modify the SpecialUserLogin code to look for that email. > > PS: What's the big issue with copy&paste or transliteration? Doesn't > your users have a keyboard layout able to type *their own name*? > I understand the issue when a third party needs to enter them, but eg. > Russian people usually have/can switch to a cyrillic keyboard layout. > > > _______________________________________________ > MediaWiki-l mailing list > MediaWiki-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l Nicolas Brouard INED brouard(a)ined.fr

7 13

IIS Test Environment (Short URLs)
by Daniel Friesen 27 Feb '12

27 Feb '12

I've finished Nginx and Lighttpd support for the short URL building tool (http://shorturls.redwerks.org/) and I also have unfinished support for thumbnail handlers on the alpha (http://shorturls.jade.redwerks.org/). I am wondering if anyone has spare resources they can use to give me a temporary test environment for IIS with administrator privileges. Essentially I want to setup IIS, install MediaWiki on it, and then configure short urls on it determining the best way to do it as I have done for both Nginx and Lighttpd. Then after that implement support for it into the short URL builder and then re-configure the server and wiki to make sure the config works. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

3 2

Bugzilla Weekly Report
by reporter 27 Feb '12

27 Feb '12

MediaWiki Bugzilla Report for February 20, 2012 - February 27, 2012 Status changes this week Bugs NEW : 395 Bugs ASSIGNED : 70 Bugs REOPENED : 33 Bugs RESOLVED : 599 Total bugs still open: 7206 Resolutions for the week: Bugs marked FIXED : 407 Bugs marked REMIND : 0 Bugs marked INVALID : 45 Bugs marked DUPLICATE : 72 Bugs marked WONTFIX : 39 Bugs marked WORKSFORME : 38 Bugs marked LATER : 7 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component Application 34 Generic 7 Site requests 6 Semantic MediaWiki 5 Javascript 5 New Bugs Per Product MediaWiki 32 Wikimedia 19 MediaWiki extensions 47 Security 1 Wikimedia Labs 3 Top 5 Bug Resolvers hashar [AT] free.fr 29 sam [AT] reedyboy.net 20 mah [AT] everybody.org 20 jrobson [AT] wikimedia.org 7 brion [AT] wikimedia.org 6

1 0

Extension:RSS version 2.10 solves the problem "Error parsing XML for RSS"
by Thomas Gries 27 Feb '12

27 Feb '12

I found and fixed many problems with this extension, see https://www.mediawiki.org/wiki/Extension:RSS and especially https://www.mediawiki.org/wiki/Special:Code/MediaWiki/112465 Main reasons (since years) were: not respecting xml namespaces and not respecting rss feed url redirect(s). A parameter for the number of redirects (zero by default) has been added.

1 0

Git/Gerrit: workflow for casual, one-off pushes?
by Sumana Harihareswara 26 Feb '12

26 Feb '12

Right now, in order to submit a diff, [[Git/Workflow]] suggests that you get a Gerrit account before you clone. How do we enable much more casual committers? I want experienced developers to be able to randomly fork and request pulls without having to get an account. If the answer is "for now, link to your fork in a Bugzilla comment and mark it 'patch' 'need-review'," that's adequate (because we let people get Bugzilla accounts without waiting for a gatekeeper), but if there's a better way I'd like to know it so I can update docs. Also asked at https://www.mediawiki.org/wiki/Git/Conversion/issues#What.27s_the_workflow_… -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation

3 3

Status of 1.19 bugs
by mah＠wikimedia.org 25 Feb '12

25 Feb '12

During the triage yesterday, we sorted out the bugs marked as 1.19 regressions and scheduled them to be fixed before the roll outs on Monday or Wednesday. Anyone who is interested in the results of the triage should check the etherpad: http://etherpad.wikimedia.org/119triage Today, a 1.19 regression with ProofreadPage was reported. Since we didn't discuss this one yesterday, I'm going to post it here. Side-by-side functionality broken in Chrome and possibly some Internet Explorer http://bugzilla.wikimedia.org/34706 Following the update to 1.19wmf1 English Wikisource has a break in the side by side viewing of text and image. This basically prevents all use of affected browsers from this functionality. -- Mark A. Hershberger Bugmeister Wikimedia Foundation mah(a)wikimedia.org

1 0

How to get a uploaded files path
by Johannes Weberhofer 25 Feb '12

25 Feb '12

Hi, can someone give me an idea, how I can determine a uploaded file's real path, when I only have the filename? I have written some code but there could also be a API call available. Best regards, Johannes -- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna

8 12

Git, Gerrit, and You! or, Gerrit training available starting Monday 27 February
by Sumana Harihareswara 24 Feb '12

24 Feb '12

Before the March 3rd migration of MediaWiki core + WMF-deployed extensions to git, we want all MediaWiki developers to feel comfortable with Git, git-review, and Gerrit. So I'm scheduling the first in some one-hour interactive training sessions where you can learn the new MediaWiki development workflow. I can lead a couple of these on Monday and Tuesday, 27 and 28 February. If you're interested, please mark down times that you're available in this poll: http://www.doodle.com/9r5nb33u8cu4ap6y I intend on running these sessions via Google+ Hangout (you don't have to enable your webcam or audio) so you'll see my screen as I show you the steps. If you prefer not to use G+, then please let me know and I'll separately schedule some IRC trainings, or find another screensharing solution. While it's nice if you can come to a training, I aim to also make sure comprehensive documentation is at https://www.mediawiki.org/wiki/Git/Workflow by sometime this Friday. And then, after I've gotten the ball rolling, I hope other new experts will take the lead and start teaching. -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation

1 1

← Newer
1
2
3
4
5
6
7
...
16
Older →

Jump to page:

2026

2025

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 February 2012