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.)
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.
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.
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
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.
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
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)
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
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.
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