Wikitech-l April 2011

wikitech-l@lists.wikimedia.org

99 participants
90 discussions

Wanted: Google Search Appliance (GSA) as Mediawiki search engine - is there a working Mediawiki extension ?
by Thomas Gries 14 Apr '11

14 Apr '11

I am looking for a _working_ extension for integrating a GSA [1] as search engine for MediaWikis. Two extensions have been found, but are not working: i) http://code.google.com/p/mediawiki-gsa-engine/ Mediawiki search engine for Google search appliance integration. This SearchEngine class allows mediawiki to use a Google search appliance for searches. ii) http://code.google.com/p/mediawiki-gsa-interwiki/ Search plugin for MediaWiki that uses Google Search Appliance (GSA) for results. This project is an enhancement of the mediawiki-gsa-mediawiki project. It fixes a couple issues experienced with that plugin and adds support for searching multiple wikis... Has someone a _working_ extension, which can also be found their way to http://www.mediawiki.org/wiki/Category:Search_extensions ? P.S. Regarding sitemap generation, MediaWiki comes already with this tool [2] which allows the gsa to index the Mediawiki. [1] http://www.google.com/enterprise/search/gsa.html [2] http://www.mediawiki.org/wiki/Manual:GenerateSitemap.php Sitemaps are files that make it more efficient for search engine robots (like googlebot) to crawl a website (so long as the bot supports the sitemap protocol.)

1 0

Change in Bugzilla's defaults
by mhershberger＠wikimedia.org 13 Apr '11

13 Apr '11

Until today, an advanced query in our Bugzilla's installation defaulted to returning bugs marked “WONTFIX” and “LATER”. Rob and I agreed that we didn't think this wasn't the behavior most people want so I changed it to remove those resolutions from the defaults. Another change I made was to adjust the default priority to “Low” from “Normal” so that most bugs don't end up in the priority level that I want to use for “This should be fixed by next release”. Perhaps many new bugs should be a priority, but I'd like there to be more than just one person complaining before the priority is raised. Finally, I changed the default severity to “Normal” from “Enhancement”. “Enhancement” is used for feature requests and most things coming into Bz are not feature requests, but are actual bugs. Just wanted you guys to have a heads-up in case you thought something was amiss. Mark.

6 6

Call for UI bugs
by mhershberger＠wikimedia.org 13 Apr '11

13 Apr '11

This coming week, I'd like to focus on any User Interface bugs. One of the lessons I learned from this last triage, though, is that we want to keep the bug reports current. With the introduction of ResourceLoader, this shouldn't be any trouble, but I want to make it clear that I will remove bugs from triage that haven't seen any activity for over 6 months. To help with find bugs that I would consider prime candidates for triage, I've created two queries. The first (http://hexm.de/1y) will find unassigned, open bugs that have been filed against MediaWiki in the past 6 months. About 200 bugs show up. The second query (http://hexm.de/1z) will find open bugs against MediaWiki modules created in the past 6 months that are, by default, assigned to wikimedia.org email addresses — with those assigned to wikibugs removed. The idea behind this query is to find bugs on MediaWiki modules that the WMF Features team is responsible for. This query finds about 100 bugs. >From this pile of 300 bugs, I need to find about 30 bugs for Monday's triage meeting. Since I expect the Features team from WMF to have a higher turnout at this meeting, I'm trying to find bugs that are relevant to their recent work — bugs that they can fix now. I'll be going through these lists myself and putting the keyword “triage” on bugs that I think should go into the meeting. But you can get involved, too, if you see a bug from those two lists that I haven't marked for triage and you think it should really be considered, feel free to put the keyword “triage” on it yourself. Next week, I'll publish the results of the triage and open a new call for bugs. Mark.

5 7

Bug priorities (Re: Change in Bugzilla's defaults)
by Rob Lanphier 13 Apr '11

13 Apr '11

On Wed, Apr 13, 2011 at 12:44 PM, Krinkle <krinklemail(a)gmail.com> wrote: > I agree. Defaulting new bugs to a low priority doesn't seem very > friendly > to new users. They don't know (and shouldn't have to know) what the > bugmeister's organization is. I thought about replying with a similar response, but then I realized that if Mark stays on top of incoming bugs (which is his job), he'll be able to bump bugs up to normal as they come in, which should actually make those people good, and provide some automatic positive reinforcement for filing important bugs. I suspect most people won't even notice that the bug defaults to "low", and they'll be able to fix it if they disagree. I suppose the best thing would be to have a blank priority (or "triage" as OQ suggests), so that we could query for the bugs that haven't been explicitly prioritized, but I don't know if that's possible. This isn't so narrowly focused on the bugmeister as it is starting to pay attention to the priority field as a community. All priorities should have a meaning for us. We can debate about what is "correct", but here's what my thinking is: 1. "Highest" - this means a bug that someone is either working on *right now*, or at least should be working on right now. No developer should have more than one "highest" priority bug, and anything marked "highest" priority shouldn't stay unassigned for more than a week. 2. "High" - this means that a bug is in the relatively-small pool of bugs that will likely get bumped to "highest" priority. Bugs at this priority should, at a minimum, be blockers for the next release of the software. 3. "Normal" - these are bugs that really should get fixed for the next release of the software. They aren't necessarily blockers, and we may grit our teeth and have a release or two with this bug, but there's no way we should go two releases with a "normal" priority bug. 4. "Low" - these are bugs that we won't actively manage. They may be important to some people, and someone may get around to fixing the problem, but no developer is committed to working on a fix 5. "Lowest" - these are bugs that pretty much everyone agrees aren't terribly important (including the reporter). I'm not wedded to these exact definitions, but I'm pretty wedded to the idea that we should agree on something. I don't think we should consider it "normal" to have bugs go for years without activity. >From a practical perspective, many more bugs than are being marked as "normal" are actually "normal" by this standard. Most of the bugs in our database are probably "low" priority in the sense that we just can't get around to fixing all of them. I can see the argument for making the most common case the default (though I share others uneasiness with doing so). Rob

4 3

Centralize PHP (and other) minimum requirements / Move Defines.php up the call stack
by Krinkle 13 Apr '11

13 Apr '11

Right now there's a few points: * Minimum php versions are all over the source code, putting it in DefaultSettings.php or Defines.php would make be a good start, that way all hardcoded uses of the versions after those are loaded can be centralized. However there are many php-versions compared before those are included as well ( all (web) entry points and other files parsed before the inclusion of DefaultSettings and/or Defines). So a better solution would be to get those versions available right at the beginning of the web entry points. Possible solutions: 1) Instead of putting the define() or $wg...= in DefaultSettings.php / Defines.php, create namethisfile.php and put them in there and include it in the all entry points. This seems like a simple and quick solution but introduces yet another always-included file and puts them far away from other global variables and defines. 2) Put it in Defines.php * make it independant (ie. only defines(), nothing else, as the filename suggests) * and move it up the call stack Things like inclusion of UtfNormalDefines could be put in the places where Defines.php is currenty included[1] and assignment of the $wgFeedClasses variable shouldn't be in Defines.php anyway. 3) Just put them in DefaultSettings.php and Defines.php and replace all uses with the globals where they are hardcoded and available. Any uses before this file is loaded (entry points) can hard code it The third solution is basically what I was going to do, and can be safely done. But before I do so I'd like to know if the solutions that cover all scenarios are do-able. -- Krinkle [1] UtfNormalDefines.php may not have to be moved though, looks good on second thought. It's included everywhere anyway so it doesn't save load by loading it later or earlier.

4 3

Re: [Wikitech-l] Registration open for the Hackathon in Berlin, May 13-15
by Sumana Harihareswara 13 Apr '11

13 Apr '11

Thanks for correcting my error, Danese! Sorry. I should instead say: if Carrie says to do something, then yes, you need to do it. :-) -Sumana On 04/13/2011 04:18 PM, Danese Cooper wrote: > Not quite right, Sumana...the folks Carrie wrote to over the weekend need to > make sure they are registered. I thought I'd done it, but the registration > site couldn't find me....:-(. It takes no time, but you're not *really* > registered until you get the email receipt from the registration server. > > D > > On Wed, Apr 13, 2011 at 1:12 PM, Sumana Harihareswara<sumanah(a)panix.com>wrote: > >> On 04/09/2011 02:11 PM, Neil Kandalgaonkar wrote: >>> I assume those of us who thought they registered via the WMF (but >>> apparently didn't) don't need to do anything? >> Yeah, don't worry about it, Carrie at WMF& Cornelius from WMDE are >> taking care of it. >> >> -Sumana >> >> _______________________________________________ >> Wikitech-l mailing list >> Wikitech-l(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

1 0

Registration open for the Hackathon in Berlin, May 13-15
by Daniel Kinzler 13 Apr '11

13 Apr '11

Hi all! Wikimedia Germany invites anyone interested in improving MediaWiki to come and join us at or third developer meet-up. Like the last two years, it's going to be awesome! Unlike the last two years, there will be more hacking and less talking - it'll be a Hackathon, not a BarCamp. We'll meet on May 13 to 15, in Berlin, on the 4th floor of the betahaus coworking space <http://betahaus.de/>. There will not be an entrance fee, but registration is mandatory and now open: <http://de.amiando.com/hackathon2011>. Registration will close on April 10. If you like to attend, please register in time! More information can be found at <http://www.mediawiki.org/wiki/Berlin_Hackathon_2011>. The Berlin Hackathon 2011 is an opportunity for MediaWiki hackers to come together, squash bugs and write crazy new features. Our main focus this time around will probably be: * Improving usability / accessibility * Interactive Maps * Fixing the parser * WMF Ops (new data center, virtualization) * Supporting the Wiki Loves Monuments image hunt * Squashing bugs If you have different ideas, please let us know: <http://www.mediawiki.org/wiki/Berlin_Hackathon_2011#Topics> The Hackathon will be hosting the Language committee and Wiki loves Monuments group. There is a limited number of seats reserved for these groups and if you belong to one of them, you should receive an invitation code soon. If you have any doubts or questions, contact us at <hackathon(a)wikimedia.de>. We’re excited to see you in Berlin, your Hackathon Team Daniel Kinzler (Program Coordinator) Nicole Ebber (Logistics) Cornelius Kibelka (Assistant)

3 3

Syntax-highlighting JS & CSS code editor gadget embedding Ace
by Brion Vibber 13 Apr '11

13 Apr '11

While pondering some directions for rapid prototyping of new UI stuff, I found myself lamenting the difficulty of editing JS and CSS code for user/site scripts and gadgets: * lots of little things to separately click and edit for gadgets * no syntax highlighting in the edit box * no indication of obvious syntax errors, leading to frequent edit->preview cycles (especially if you have to turn the gadget back off to edit successfully!) * no automatic indentation! * can't use the tab key Naturally, I thought it might be wise to start doing something about it. I've made a small gadget script which hooks into editing of JS and CSS pages, and embeds the ACE code editor (http://ace.ajax.org -- a component of the Cloud9 IDE, formerly Skywriter formerly Mozilla Bespin). This doesn't fix the usability issues in Special:Gadgets, but it's a heck of a lot more pleasant to edit the gadget's JS and CSS once you get there. :) The gadget is available on www.mediawiki.org on the 'Gadgets' tab of preferences. Note that I'm currently loading the ACE JavaScript from toolserver.org, so you may see a mixed-mode content warning if you're editing via secure.wikimedia.org. (Probably an easy fix.) Go try it out! http://www.mediawiki.org/wiki/MediaWiki:Gadget-CodeEditor.js IE 8 kind of explodes and I haven't had a chance to test IE9 yet, but it seems pretty consistently nice on current Firefox and Chrome and (barring some cut-n-paste troubles) Opera. I'd really love to be able to use more content-specific editing tools like this, and using Gadgets is a good way to make this sort of tool available for testing in a real environment -- especially once we devise some ways to share gadgets across all sites more easily. I'll be similarly Gadget-izing the SVG-Edit widget that I've previously done as an extension so folks can play with it while it's still experimental, but we'll want to integrate them better as time goes on. -- brion

6 8

Report on Monday's Bug Triage meeting
by mhershberger＠wikimedia.org 13 Apr '11

13 Apr '11

TL;DR Many older parser bugs were pushed to the new parser. However, several, mostly newer, bugs were assigned to be worked on now. To contribute to the new call for bugs, read <http://hexm.de/20>. This past Monday, I held a bug triage meeting with WMF developers to cover Parser bugs that I and other participants on this list had marked for triage. There were 27 bugs in total. Because of the open-ended nature of the call for bugs, we ended up with a fair number of “oldie-but-goodie” bugs. With Brion's parser rewrite currently being planned, this meant that a fair number of bugs were easy to shrug off. If we've lived with the pain so far, the rationale is, why go through they horrible pain of fixing it in the current parser when a more maintainable parser is just around the corner. Still, it was helpful to look at these older bugs to see the sort of problems that need to be addressed in the parser rewrite. The bugs that we decided it would be better to address in the new parser were the following: Preceding text and single apostrophes are not included in links http://bugzilla.wikimedia.org/468 Incorrect parsing of table headings and cells on the same line http://bugzilla.wikimedia.org/549 [[#foo|]], [[/bar|]] should be equivalent to [[#foo|foo]], [[/bar|bar]] (new use of "pipe trick") http://bugzilla.wikimedia.org/845 Newline as list item terminator is troublesome http://bugzilla.wikimedia.org/1115 pre over multiple lines in lists http://bugzilla.wikimedia.org/1581 Need method for multiparagraph list items, continuing numbered lists, and assigning specific numbers to list items http://bugzilla.wikimedia.org/1584 Allow one blank line in list environments http://bugzilla.wikimedia.org/9342 Automatic nbsp is inserted even into XHTML attributes, including style http://bugzilla.wikimedia.org/3158 The newline added to a template, magic word, variable, or parser function that returns line-start wikicode formatting (*#:;) causes unexpected parsing http://bugzilla.wikimedia.org/12974 Leading spaces in <pre> block render incorrectly when block preceded by another <pre> http://bugzilla.wikimedia.org/3230 Blank lines at the top of an article should be ignored http://bugzilla.wikimedia.org/4161 Single newlines sometimes create paragraphs http://bugzilla.wikimedia.org/9207 Block element written inline splits multiline paragraphs http://bugzilla.wikimedia.org/5718 Linebreaks are mishandled in <blockquote> and <li> http://bugzilla.wikimedia.org/6200 Multiline tags in lists should be output more intelligently http://bugzilla.wikimedia.org/9996 Bold/italic markup handled differently depending on leading whitespace http://bugzilla.wikimedia.org/18765 post expand size counted multiple times for nested transclusions http://bugzilla.wikimedia.org/13260 Additionally, Brion punted this bug to the new rich text editor he has planned since the problem is seen mostly in copy-and-pasted URLs: External URL syntax cannot handle square brackets http://bugzilla.wikimedia.org/3695 One bug was dismissed as WONTFIX with the justification that the reporter had a certain behavior in mind for the behavior of the parser when he wrote ''''lots of quotes'''' but that while the parser acted consistently, it didn't act in his preferred manner Single quote inside triple quote bold (''') parsing error http://bugzilla.wikimedia.org/13227 Still, all was not lost. For example, Neil saw this ancient bug as an opportunity to get closer to the gnarly internals of MediaWiki. tilde signatures inside nowiki tags sometimes get expanded (<includeonly><nowiki>~~~~</nowiki></includeonly>) http://bugzilla.wikimedia.org/93 Sam saw this bug and decided it looked like it would be easy to test and apply the included patch: Transcluded special pages expose strip markers when they output parsed messages http://bugzilla.wikimedia.org/16129 Finally, Tim saw these two relatively recent bugs and decided he would investigate them further and hopefully fix them: DOM preprocessor barfs on headings inserted by parser functions http://bugzilla.wikimedia.org/21844 {{fullurl:}} does not urlencode passed querystring http://bugzilla.wikimedia.org/27972 To see the notes from the Bug Triage (thanks, Sumana!) visit http://etherpad.wikimedia.org/BugTriage. Please see my earlier email to the list (http://hexm.de/20) if you'd like to contribute to this coming week's triage. Mark.

1 0

ShortURL for Non Latin Mediawiki sites
by Srikanth Lakshmanan 13 Apr '11

13 Apr '11

Hi all, Sharing of URLs of non latin wiki's werent really easy and when copy pasting we get the unicode numerals in the URL like http://ta.wikipedia.org/wiki/%E0%AE%B5%E0%AE%BF%E0%AE%95%E0%AF%8D%E0%AE%95%… en:User:Mountain had come up with a shortify project[1] and thanks to Yuvipanda its now live on Tamil Wikipedia. All pages have a link on the right side of article title. http://tawp.in/r/262 is the same link and is being displayed there. The feedback from the community is to have this hosted by Wikimedia itself as it would be more reliable than individual running it. So there came the idea of a mediawiki extension and hence Shorturl extension[2] was born by some really quick work by Yuvipanda.Its live here[3].(See the toolbox for short URL) While this may be a small thing, it does help non latin wiki's a lot.Having it in the extension form is more reliable even though the URL length goes up, but still its worthy.The URL length can be shortened with mod_rewrite rules on. I would ideally like this to be used across non latin wikimedia properties as it helps these projects(like echoed here[4]). Please let me know how to do this. Bugs on wikimedia bugzilla will do? Feedback appreciated. [1] https://github.com/mountain/shortify [2] http://www.mediawiki.org/wiki/Extension:ShortUrl [3] http://wiki.busroutes.in/wiki/Chennai [4] http://lists.wikimedia.org/pipermail/wikimediaindia-l/2011-March/002699.html <http://lists.wikimedia.org/pipermail/wikimediaindia-l/2011-March/002699.html> Regards Srikanth.L

7 9

← 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 April 2011