For anyone who's not on the other list :)
---------- Forwarded message ----------
From: Sam Reed <tehreedy(a)gmail.com>
Date: Tue, Jun 22, 2010 at 8:47 AM
Subject: [Mediawiki-l] JetBrains PHPStorm License for MediaWiki Developers
To: mediawiki-l(a)lists.wikimedia.org
Hi all,
I know we quite often get asked what IDE to use for PHP, and there's
mixed reviews and results. And not many solutions
As such, JetBrains have recently released PHPStorm [1], and offer an
"open source license" (free license for open source projects, and I
have applied for and received one for the MediaWiki team. It's valid
for unlimited users, so any developer can have one.
>From this end, I've got a couple of queries. How can I distribute it
(to those who want it)? Obviously, I can't just post it on a wiki
page. Maybe OTRS or something? (To make it manageable)
Also, they've requested we put a banner/similar onto a page. They
suggested I think, the Developer Hub [2]. Is this ok with people?
Something along the lines of an acknowledgement, and a logo, but I'll
get them to clarify it.
People can email me for a copy of the license, till we get something
"more manageable", and I'll distribute it from there. I'd be
interested to see peoples views overall. I know their ReSharper and
dotTrace are very well recieved (of which I agree) in the .NET
community, so this should hopefully be of similar calibre.
Thanks
Sam
[1] http://www.jetbrains.com/phpstorm/index.html
[2] http://www.mediawiki.org/wiki/Developer_hub
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Hi,
I'm trying to run action=query in Python with a POST request, but for some
reason it only works with a GET.
This works fine (GET):
>>> req = urllib2.Request('
http://en.wikipedia.org/w/api.php?action=query&titles=The_Matrix&export&for…
')
>>> f = urllib2.urlopen(req, None, 300)
>>> print f.read()
...full page output...
This doesn't work (POST):
>>> req = urllib2.Request('http://en.wikipedia.org/w/api.php',
'action=query&titles=The_Matrix&export&format=txt')
>>> f = urllib2.urlopen(req, None, 300)
>>> print f.read()
Array
(
[query] => Array
(
[normalized] => Array
(
[0] => Array
(
[from] => The_Matrix
[to] => The Matrix
)
)
[pages] => Array
(
[30007] => Array
(
[pageid] => 30007
[ns] => 0
[title] => The Matrix
)
)
)
)
Does anyone know what I'm doing wrong here?
Thanks in advance!
Hi all
Today I got a review of Vector's accessibility from an employee of the German
Central Library for the Blind (Deutsche Zentralbücherei für Blinde, DZB). This
is by no means a full evaluation, just the result of having a casual look. I
visited them with Till and Maria of Wikimedia Germany a week ago, and Sebastian
Brückner kindly agreed to take a peek.
At the bottom is the full mail in German, but I'll try to give a quick summary
of the main points in English here:
1) CSS uses a:hover but is missing a:focus; Thus, there's no highlighting when
navigating links with the keyboard. This should be trivial to fix - or are there
any problems with this?
2) The tab order is inconvenient. IE8 und FF3.6 show first the search box, then
the show/hide toggles from the sidebar, then content, then the top bar, and only
then the actual navigation items from the sidebar. This is probably because the
toggles get inserted by JS, i guess. Opera 10 goes to searchm then the toggles,
then back to search. That's bad.
3) hidden (collapsed) menus use display:none. This makes them inaccessible to
screen readers, etc. Alternative ways for hiding them might be better - such as
setting the hight to 0. Has this been tried?
Also, would it be possible to detect at least the most popular screen reader
plugins with JS, so a special mode could be triggered for the visually impaired?
4) Tables are used for layout a lot. This is mostly true for content, especially
for Infoboxes, Navigation boxes, etc. This is quite bad for screen readers. It's
going to be very hard though to get wiki editors to use proper css based code
for table layouts.
Perhaps it would be possible to make {|...|} generate a div-based layout using
some magic word or option? This would be so easy with a real parser :) But
doTableStuff() looks fairly sane, so perhaps it could be done.
5) In image thumbnail boxes, the "zoom" link is before the caption, so people
have to skip over it every time. Perhaps it could be moved after the caption.
6) Image thumbnails have an empty alt attribute. This seems like a bug to me -
was it always like this? I suggest to use the image's file name in the
alt-attribute of the img tag, and also as the title of the link that wraps the
thumbnail. After all, the target of that link is indeed the description of the
image file. Could we just implement this, or are there any problems I didn't
think of?
While there are some tricky issues (like the tables), most of the above should
be fairly easy to fix. And would improve the experience for people with bad
vision quite a lot. I'd volunteer to implement at least the easy changes, but
it would be good to have some feedback first. So, what do you think?
-- daniel
-------- Original-Nachricht --------
Betreff: Usability von Wikipedia
Datum: Fri, 18 Jun 2010 13:16:49 +0200
Von: Brückner, Sebastian <Sebastian.Brueckner(a)dzb.de>
An: <daniel.kinzler(a)wikimedia.de>
Hallo Herr Kinzler,
wie im Gespräch am 11.06.2010 besprochen, habe ich einen Blick auf den neuen
Wikipedia-Skin geworfen.
Dabei sind mir einige verbesserungswürdige Punkte aufgefallen, teilweise sind
(vermutlich) auch nicht viel Handgriffe zu tun.
Positiv hervorzuheben ist der hohe Kontrast der Überschriften, Links und Texte
sowie die Skalierbarkeit der Seite, ohne das Überlappungen oder Abschneidungen
auftreten.
Ein schnell zu erledigender Punkt wäre die Ergänzung von a:focus zu a:hover im
CSS, da bei Tastaturbedienung keinerlei Fokushervorhebung auftrat. Bei
Mausbedienung wird hingegen eine Unterstreichung bei den Links hinzugefügt.
Hinderlich oder irritierend könnte die "ungewöhnliche" Tab-Reihenfolge sein. Im
IE8 und FF3.6 werden zuerst das Suchfeld, dann die 3-4 Aufklapplinks der
Navigation, der Inhaltsbereich, der Header und anschließend erst die restlichen
Navigationlinks und der Footer angesprungen. Im Opera 10 konnte ich hingegen nur
die Suche und die Aufklapplinks antabben.
Auf der Startseite fiel mir auf, dass die unaufgeklappten Links mit
display:none; versteckt werden, damit sind sie allerdings auch für
Screenreadernutzer nicht auffindbar. Lösungsmöglichkeit wären z.B. die
Positionierung außerhalb des sichtbaren Bereichs oder die Höhe auf 0 setzen.
Zudem wurden Layouttabellen verwenden, es sind nur vier Zellen, was keine große
Barriere darstellt, allerdings wäre auch diese mit wenig CSS vermeidbar.
Ebenso ließen sich die doppelten Links vermeiden, die durch die getrennte
Verlinkung von Icons und Texten auftritt. En masse tritt dies bei den
Portallinks und Schwesterprojekten der Startseite auf.
Auf einer Inhaltsseite (die von Leipzig) fielen mir ebenfalls Layouttabellen
auf, hier aber nur ein- oder zweizellig, aber grad deswegen eigentlich gut
ersetzbar.
Sämtliche Thumbnails an der rechten Seite des Inhaltsbereichs enthielten leere
alt-Attribute. Das ist schon mal besser als gar keine, allerdings übergehen
manche Screenreader solche Grafiken dann. Da nach der Grafik auch erst der
vergrößern-Link folgt, ist der "Weg" zur Bildunterschrift doch länger als nötig.
Vllt. könnte man hier die Reihenfolge optimieren oder die Bildunterschrift als
Alternativtext vergeben, was aber natürlich zu ebenso unschönen Dopplungen
führen kann.
Ich hoffe dass es sich nicht allzu schlecht anhört, denke aber das einige Punkte
schnell behoben werden können.
Eine Begutachtung der Bearbeiten-Seite war mir aus Zeitgründen noch nicht
möglich, dass würde ich Anfang/Mitte nächster Woche nachholen. Dann auch gern
mit einem blinden Kollegen aus unserem Haus.
Für Rückfragen und Anmerkungen stehe ich natürlich gern zur Verfügung.
Mit wochenendlichen Grüßen
Sebastian Brückner
---
Sebastian Brückner
Deutsche Zentralbücherei für Blinde zu Leipzig
Informatik
Telefon: (03 41) 71 13-180
Fax: (03 41) 71 13-125
E-Mail: sebastian.brueckner(a)dzb.de
--
--
Diese e-mail wurde auf Spam und Viren mit Astaro Security Gateway geprueft.
Hello,
There are quite a few parsers seems fit my purpose
(http://www.mediawiki.org/wiki/Alternative_parsers).
Before I try all of them, in your quick opinion, which one is stable
enough/recommended to parse wiki markup to HTML?
Thanks.
Hello to all!
I have posted here [1] a proposal about adding two fields in the
interwiki table (API URL and DB name).
One of the goals is to simplify interwiki transclusion, but those
field might be useful for other interwiki applications.
Could you please read it and let me know about your remarks and
suggestions, on this list and/or on the talk page?
Thanks in advance
[1] http://www.mediawiki.org/wiki/User:Peter17/Reasonably_efficient_interwiki_t…
--
Peter Potrowl
http://www.mediawiki.org/wiki/User:Peter17
Imagine an article with many revisions and pending changes enabled:
A, B, C, D, E, F, G...
A is an approved edit. B,C,D,E,F,G are all pending edits.
B is horrible vandalism that the subsequent edits did not fix.
You are a reviewer, you go to review page by clicking a pending review
link. On the review page you can accept— thus putting the horrible
vandalism on the site. Or you can "reject" which throws out the all
the good edits of C,D,E,F,G by reverting it to A.
To quote someone from IRC: "this seems like its going to make vandals
even more effective because all they have to do is make one edit in a
string of ten good ones, and then the entire set has to be thrown out"
But that isn't true at all. You're not confined to the review page,
you simply go to the edit history, click undo on B, and then approve
your own edit (it won't be auto-approved because G wasn't approved).
Tada.
This completely non-obvious to people, because the only options on the
review page are accept or reject, and it's already causing confusion.
This is a direct result of the late in the process addition of the
review button, — trying to fit the round-peg of a revision reviewing
system (which we can't have because of the fundamental incompatibility
with single linear editing history) in to presentation-flagging system
square hole that we actually have.
I don't know how to fix this. We could remove the reject button to
make it more clear that you use the normal editing functions (with
their full power) to reject. But I must admit that the easy rollback
button is handy there. Alternatively we could put a small chunk of
the edit history on the review page, showing the individual edits
which comprise the span-diff (bonus points for color-coding if someone
wants to make a real programming project out of it) along with the
undo links and such.
In the meantime I expect enwp will edit the message text to direct
people to the history page for more sophisticated editing activities.
(Thanks to Risker for pointing out how surprising the pending review
page was for this activity)
At the moment, logins to enwiki from nightshade.toolserver.org are
throwing up a CAPTCHA. This is easy to check by loading
http://en.wikipedia.org/wiki/Special:UserLogin in w3m or another
browser from that host. Logins from willow.toolserver.org do not
require a CAPTCHA at the moment.
The CAPTCHA requirement makes it impossible for bots to log in via the
API. The fundamental problem is that bots are run automatically, of
course. But the API also does not report the CAPTCHA requirement at
all, so bot developers are given a "WrongPass" error that they have to
investigate to find that a CAPTCHA is the problem.
This CAPTCHA situation has happened before, most likely due to some
erroneous bot on toolserver triggering it. But individual bot
operators cannot fix it, and so to them it has the same effect as a
toolserver outage. Moreover, whatever bot operator caused it probably
has no way to know it was them.
It seems like this may take collaboration between toolserver and
wikimedia to fix, but probably the fix will involve at least some
change on the wikimedia side. So I have filed a bug at
https://bugzilla.wikimedia.org/show_bug.cgi?id=23982 to coordinate
discussion there.
- Carl
Hi,
I hope this is the correct list to post for problems with XML dumps of
wikipedia.
There seems to be a problem with the dump for the French wiki.
The database dump progress
page<http://dumps.wikimedia.org/backup-index.html>reports at the end :
2010-06-14 17:49:00 frwiki (new): missing status record
The date/time is continuously updating but no new dump has been available
for 74 days.
Can someone fix this problem ?
Thanks in advance
Nico
Hi all
Some months ago, Wikimedia Germany contracted Hallo Welt to write a handler for
TIFF files. The extension is now complete, and the commons community would like
to have it enabled.
It would be great if some of you could have a look at the code. I have filed a
request on bugzilla for review & enabling in May
<https://bugzilla.wikimedia.org/show_bug.cgi?id=23258>. If you have comments or
ideas, please comment there. I will help with fixing any remaining issues, so
this can go live soon.
Thanks
Daniel