Dear all,
The improvements to the page editing interface by the experience team are great. I especially like the new insert link.
I was wondering, whether it is possible to have something similar for templates, maybe with following functionalities:
- suggestions for templates are listed while typing
- short descriptions from the template page are shown
- when a template is chosen, the user is asked for its parameters
With that the users would not need to remember all templates, their syntax to use, and their number of parameters.
Does anyone know whether that exists already or is planned? If not, how could that be implemented?
Regards,
Benedikt
--
Karlsruhe Institute of Technology (KIT)
Institute of Applied Informatics and Formal Description Methods (AIFB)
Benedikt Kämpgen
Research Associate
Kaiserstraße 12
Building 11.40
76131 Karlsruhe, Germany
Phone: +49 721 608-7946
Fax: +49 721 608-6580
Email: benedikt.kaempgen(a)kit.edu
Web: http://www.kit.edu/
KIT - University of the State of Baden-Wuerttemberg and
National Research Center of the Helmholtz Association
Hi, I checked the dumps of the Italian Wikipedia at
http://dumps.wikimedia.org/itwiki/
and I found there are 6 dumps available, the latest 2010-Jun-27, the
oldest 2010-Mar-02.
My question is: are older dumps stored somewhere? Is it possible to
get them? Even if this involves running some script on old database
dumps, that would be ok.
(I posted this question at
http://meta.wikimedia.org/wiki/Talk:Data_dumps#Oldest_Wikipedia_dump_availa…
as well.)
Thanks in advance!
--
--
Paolo Massa
Email: paolo AT gnuband DOT org
Blog: http://gnuband.org
This is a sorta-technical sorta-copyright issue. InstantCommons is
great stuff, it spreads free content with correct attribution in a
marvellous manner.
But Commons contains a certain number of non-free files, specifically
Wikimedia logos and so forth. I just noticed (on a wiki using
InstantCommons) that these are served up through it just the same.
Is there any relatively simple way to stop this happening? (Including
not caring.)
- d.
Whoops, didn't cc. The censorship discussion is around again, but this
question is about the feasibility (in terms of not melting the
servers) of users being able to block images from particular
categories.
---------- Forwarded message ----------
From: David Gerard <dgerard(a)gmail.com>
Date: 22 July 2010 21:01
Subject: Re: [Foundation-l] Discussion Questions for
Potentially-Objectionable Content
To: Wikimedia Foundation Mailing List <foundation-l(a)lists.wikimedia.org>
On 22 July 2010 20:10, Excirial <wp.excirial(a)gmail.com> wrote:
> I would, however, strongly support a system that gives users
> a choice to censor if they wish. It should be possible to categorize commons
> in such a way that certain images can be blocked. For example, a user might
> choose to block "images of Muhammad", while allowing surgery related images
> (Others might swap there if they wish).
This is a perennial proposal. It's an idea I like, as it puts control
in the hands of the viewer rather than third parties. All it requires
is someone to code something that passes muster as being unlikely to
melt the servers.
cc to wikitech-l - how feasible is something that allows users to stop
display of arbitrary image categories and/or subcategories?
- d.
I'm resurrecting this thread, because I really want to start using
this new class. There are still open questions, like do we want to
have a shortcut and how to name it. One reason for it is that name
Message for a class might conflict and thus we might want to rename it
to something else. My current preference would be i18n(), like this:
i18n( 'welcometo' $wgSitename)->text();
or if we don't have a wrapper, use this whatever the class name might be:
Message::key( 'welcometo', $wgSitename )->text();
Other suggestions in the past have been:
_ (Used by Gettext, objected because it's not clear what it does)
_m (no comments)
I really don't believe that chaining method calls is too hard to use
(or easy to misuse) for any of our developers. I recently noticed that
FreeCol game (written in Java) uses chaining for message system very
similar to this.
Yes, it is possible to use it in the wrong way, but I doubt that
anyone is going to do that by accident, given the good documentation
and plenty of correct examples. The few exception if any will be
noticed easily in code review and fixed.
The other objection I still remember was about the inconsistent form
of method names. If someone has suggestions for better naming scheme,
please tell about us. I'd also like to know if anyone objects just
because of that, even if they don't have suggestions for better names.
If you still object this change, please say it (again, if you have
said something in past I've forgotten). If I get no objections I
assume everyone can accept the new class.
Here's once more the reasons I want this system and how it is better
than the old one:
* Message objects make it easier to pass messages around
* The most used case is simple and obvious, rare cases less so (but
still not very hard)
* It is easy to do the right thing
* It actually works properly for i18n in the default cause (wfMsg doesn't)
* If we in the future require PHP 5.3 or something, automatic string
conversion can simplify the code even more
* Rawness is now feature of individual parameter, not all of them -
you can mix raw and nonraw now.
* Usually shorter syntax, sometimes longer (depending on the shortcut
we decide if any)
* Usually more readable
And one other comment to old discussion:
On 4 April 2010 20:43, Happy-melon <happy-melon(a)live.com> wrote:
> "Roan Kattouw" <roan.kattouw(a)gmail.com> wrote in message
> news:s2kf154f3a81004011326n7938f5b3i8d484f3d50f28fae@mail.gmail.com...
> >
> > This'd be very nice, and would kind of supersede the Status class
> > currently used to shove a message key and some params in so the callee
> > can either get it automatically processed by wfMsg() (UI functions) or
> > grab the raw message key + params and process that in their own way
> > (API). This would require the Message class have getters for both of
> > these though (does it currently?).
> >
> > Roan Kattouw (Catrope)
>
> As Roan says, a Message object essentially deprecates the (IMO pig-ugly)
> Status class, which is used erratically throughout the codebase as
> essentially a way to bundle up a message key, some parameters, and a success
> flag without converting to String too soon.
I don't think it replaces Status class, but just makes it a lot
cleaner with regards to message handling.
--
Niklas Laxström
Dear System Administrators on Wikitech-l,
I wish you a happy Sysadmin day! Your work is appreciated.
Here's a small cake:
()
||
(########)
(########)
Kind regards,
A User.
Ps.: If you have no idea what is going on, see http://sysadminday.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is a security and bugfix release of MediaWiki 1.16.0 and
MediaWiki 1.15.5. Download links are given at the end of this email.
A data leakage vulnerability was discovered, affecting MediaWiki 1.8
and later. Public caching headers were incorrectly set on API
responses containing private data. By means of a CSRF-style attack,
this can lead to the disclosure of various types of private data
stored on a wiki. All users are advised to upgrade. Full details can
be found at:
https://bugzilla.wikimedia.org/show_bug.cgi?id=24565
A cross-site scripting (XSS) vulnerability was discovered in
profileinfo.php. The vulnerability is only exposed when the script is
explicitly enabled in LocalSettings.php, with $wgEnableProfileInfo = true.
A register_globals arbitrary inclusion vulnerability was discovered in
the 1.16 beta release series, in MediaWikiParserTest.php. This
vulnerability does not affect any stable MediaWiki release. It only
affects wikis which have PHP's register_globals feature enabled,
despite our strong advice to the contrary. Apache installations with
AllowOverride enabled may be protected against this vulnerability,
since there is a .htaccess file with "Deny from all" in the relevant path.
In both releases, the interface text was updated with new translations
from translatewiki.net.
Full release notes for 1.15.5:
<http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_15_5/phase3/RELEASE-NO…>
Full release notes for 1.16.0:
<http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_16_0/phase3/RELEASE-NO…>
Upgrade FAQ:
http://www.mediawiki.org/wiki/Manual:FAQ#Upgrading
**********************************************************************
We are proud to announce the first stable release of the 1.16 series.
Selected changes that may be of interest since MediaWiki 1.15 are:
* Watchlists now have RSS/Atom feeds. RSS feeds generally are now
hidden, since Atom is a better protocol and is supported by virtually
all clients.
* It's now possible to block users from sending email via
Special:Emailuser.
* The maintenance script system was overhauled. Most maintenance
scripts now have a useful help page when you run them with --help.
* AdminSettings.php is no longer required in order to run maintenance
scripts. You can just set $wgDBadminuser and $wgDBadminpassword in
your LocalSettings.php instead.
* The preferences system was overhauled. Preferences are stored in a
more compact format. Changes to site default preferences will
automatically affect all users who have not chosen a different preference.
* Support for SQLite was improved. Some broken features were fixed,
and it now has an efficient full-text search.
* The user groups ACL system was improved by allowing rights to be
revoked, instead of just granted.
* A new localisation caching system was introduced, which will make
MediaWiki faster for almost everyone, especially when lots of
extensions are enabled.
By default, this new system makes a lot of database queries. If your
database is particularly slow, or if your system administrator limits
your query count, or if you want to squeeze as much performance as
possible out of Mediawiki, set $wgCacheDirectory to a writable path on
the local filesystem. Make sure you have the DBA extension for PHP
installed, this will improve performance further.
**********************************************************************
1.15.5
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.15/mediawiki-1.15.5.tar.gz
Patch to previous version (1.15.4), without interface text:
http://download.wikimedia.org/mediawiki/1.15/mediawiki-1.15.5.patch.gz
Interface text changes:
http://download.wikimedia.org/mediawiki/1.15/mediawiki-i18n-1.15.5.patch.gz
GPG signatures:
http://download.wikimedia.org/mediawiki/1.15/mediawiki-1.15.5.tar.gz.sighttp://download.wikimedia.org/mediawiki/1.15/mediawiki-1.15.5.patch.gz.sighttp://download.wikimedia.org/mediawiki/1.15/mediawiki-i18n-1.15.5.patch.gz…
Public keys:
https://secure.wikimedia.org/keys.html
**********************************************************************
1.16.0
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.0.tar.gz
Patch to previous version (1.16.0beta3), without interface text:
http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.0.patch.gz
Interface text changes:
http://download.wikimedia.org/mediawiki/1.16/mediawiki-i18n-1.16.0.patch.gz
GPG signatures:
http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.0.tar.gz.sighttp://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.0.patch.gz.sighttp://download.wikimedia.org/mediawiki/1.16/mediawiki-i18n-1.16.0.patch.gz…
Public keys:
https://secure.wikimedia.org/keys.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxP4e8ACgkQgkA+Wfn4zXkWIgCgmr9dHmPtQqk+2bdQaHkLGss3
7W8AoJqgkJsurVVzWFBkr3TgrswsWzcd
=L7ad
-----END PGP SIGNATURE-----
I'm new to the Mediawiki codebase, but after going to Wikimania, I've
been impressed with the need for more eyes on Code Review.
Since I'm still learning my way around, I won't be able to approve any
code (e.g. mark it “ok”) but I can offer feedback where it might be
helpful.
Right now, I'm focusing on Core, LiquidThreads and the
Usability Initiative extensions. If you have an extension that you'd
like feedback on, let me know and I'll have a look.
I do not pretend to have Tim's expertise, so this is not a substitute
for his review, but it could be a way to get some preliminary feedback
as well as helping me to become more familiar with various parts of
MediaWiki and its components and extensions.
Your friendly code gnome,
Mark.
--
http://hexmode.com/
Embrace Ignorance. Just don't get too attached.
Hi again
Last month, we discussed some of the comments we got from the German Central
Library for the Blind (DZB) about Vector's accessibility
<http://www.mediawiki.org/wiki/Accessibility>. I have received a second set of
comments, which I'd like you to have a look at. This time, the feedback comes
from a blind person actually using a screen reader (JAWS). So, here goes.
1) expansible menu items can not be identified as such. We talked about this
before, but did we come up with a good solution?
2) when the browser window is small (which a blind person would never know),
some tabs (like "history") get moved into a drop-down menu, glued to a
down-arrow icon. The menu drops down when the mouse is hovered over the icon.
This is totally inaccessible to blind people, the icon has no title or any other
indication what it does, there is no way to activate the drop-down. Actually, I
couldn't even fiond a way to navigate there using the keyboard.
3) the suggestions shown under the search field are not accessible via the
screen reader. it's not announced, and it does not get read.
4) Alt-Text for edit-buttons are read without spacing between them, they get
jammed together. It also does not becopme clear which elements are buittons,
which are links, etc. Blind people would probably not bother with toolbars
anyway and use wikitext directly, but they should be able to explore the
functionality and find their way around.
That's it for the second round of feedback. As to the results of the first
round... I'm inclined to turn each item into a feature request / bug report. Do
you think that's the way to go?
-- daniel
-------- Original-Nachricht --------
Betreff: AW: Usability von Wikipedia
Datum: Thu, 24 Jun 2010 15:57:56 +0200
Von: Brückner, Sebastian <Sebastian.Brueckner(a)dzb.de>
An: Daniel Kinzler <daniel.kinzler(a)wikimedia.de>, <maria.schiewe(a)wikimedia.de>
Referenzen: <4C1B6DBD.9020902(a)wikimedia.de>
Guten Tag zusammen.
Ich habe soeben mit einer blinden Kollegen die Bearbeiten-Seite eines
Wikipediaartikels unter die Lupe genommen und möchte meine Erkenntnisse mitteilen.
Die eingeklappten Ausklappmenüs der Navigation waren mit dem Screenreader Jaws10
lediglich als h5 und nicht als Link o.ä. zu erkennen. Nach deren Einblendung
waren die aufgeklappten Links aber an der korrekten Stelle zu finden und auch
bedienbar.
Der Link "Versionsgeschichte" wird bei zu kleinem Fenster durch ein
Aufklapppfeil ersetzt, dadurch war auch per Jaws nicht direkt anspringbar. Das
Aufklappicon wurde lediglich als "Nummernzeichen" erkannt, ohne weitere
Erklärung etc.
Die Vorschlagsliste des Suchfeldes war nicht erkennbar, also in irgendeiner
Weise angekündigt. Sie war zwar mit den Pfeiltasten bedienbar, aber Jaws las
nichts vor.
Die Buttons des Editors wurde nur teilweise erkannt, die Alternativtexte (oder
was genau das war) "Fett", "Kursiv" etc. wurden vorgelesen, allerdings ohne
Leerzeichen dazwischen.
Auch die meisten Funktionen unter Erweitert vorgelesen, allerdings hier auch
ohne jegliche Erklärung ob es sich um einen Link oder Button oder ähnliches handelt.
Auch mit Verrenkungen über virtuelle Cursoer etc. war es nur umständlich
möglich, diese WYSIWYG-Funktion zu nutzen. Vermutlich würden blinde Nutzer hier
eher plain (wiki)text eintippen.
So weit so gut :-)
Viele Grüße aus/nach Leipzig
Sebastian Brückner
---
Sebastian Brückner
BIK-Beratungsstelle Mitteldeutschland
in der
Deutsche Zentralbücherei für Blinde zu Leipzig
Telefon: (03 41) 71 13-180
Fax: (03 41) 71 13-125
E-Mail: brueckner(a)bik-online.info
Internet: www.bik-online.info
>-----Ursprüngliche Nachricht-----
>Von: Daniel Kinzler [mailto:daniel.kinzler@wikimedia.de]
>Gesendet: Freitag, 18. Juni 2010 15:00
>An: Brückner, Sebastian
>Cc: Maria Schiewe
>Betreff: Re: Usability von Wikipedia
>
>Guten Tag
>
>Brückner schrieb:
>> Hallo Herr Kinzler,
>>
>> wie im Gespräch am 11.06.2010 besprochen, habe ich einen
>Blick auf den neuen
>> Wikipedia-Skin geworfen.
>
>Oh super, vielen Dank!
>
>> 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.
>
>erfreulich.
>
>
>> 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.
>
>Das sollte problemlos möglich sein. Ich geb's mal weiter.
>
>> 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.
>
>Tab-Reihenfolge ist ja immer ein endloser Kampf. Und die
>linarisierung einer
>Seite im Inhalt und Navigation ist nicht trivial. Aber auch
>das geb ich mal
>weiter...
>
>> 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.
>
>Hm... gibt es da Erfahrungswerte, wie gut das funktioniert,
>und in wie weit alle
>Browser das mitmachen? display:none; ist ja "semantisch"
>durchaus das, was man
>haben will.
>
>Übrigens: wird die Seite ohne JavaScript geladen, ist immer
>alles "aufgeklappt".
>Ich frage mich, ob es ggf möglich wäre, mit JavaScript zumindest die
>gebräuchlichsten ScreenReader-Plugins zu erkennen und ggf
>einen speziellen Modus
>zu aktivieren, der z.B. das Einklappen von
>Navigationselementen unterbindet.
>Wäre das sinnvoll?
>
>> Zudem wurden Layouttabellen verwenden, es sind nur vier
>Zellen, was keine
>> große Barriere darstellt, allerdings wäre auch diese mit wenig CSS
>> vermeidbar.
>
>Hier ist das Problem, dass es sich um "Wiki-Text" handelt,
>also um gemeinsam
>gepflegte Inhalte die nicht Teil der Software sind. Das macht
>es schwieriger,
>technisch anspruchsvollere Lösungen umzusetzen und zu warten.
>
>Meiner Erfahrung nach ist es recht schwierig, ein brauchbares
>Tabellen-Layout
>mit CSS hin zu bekommen, so, dass es in allen Browsern
>funktioniert. Für die
>Hauptseite wäre das machbar, aber es werden schon an sehr
>vielen Tabellen fürs
>Layout verwendet.
>
>Eventuell könnte MediaWiki eine Funktion anbieten, die
>Wiki-Tabellen automatisch
>in divs konvertiert statt in eine HTML-Tabelle. Das wäre
>nützlich, aber leider
>nicht ganz einfach.
>
>> 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.
>
>Hier sehe ich keine gute Lösung... *gemeinsam* verlinken lässt
>die Wiki-Syntax
>nicht zu, und das Ergebnis sähe vermutlich auch nicht
>besonders aus. Sinnvoll
>wäre es, die Icons für Screenreader etc komplett zu verbergen.
>Aber ich weiß
>leider nicht, wie - außer mit einer Erkennung via JavaScript.
>
>> Auf einer Inhaltsseite (die von Leipzig) fielen mir
>ebenfalls Layouttabellen
>> auf, hier aber nur ein- oder zweizellig, aber grad deswegen
>eigentlich gut
>> ersetzbar.
>
>Ich nehme an, das bezieht sich auf die "Infobox" rechts und auf die
>Positionierung der Bilder. Das auf einer Seite zu ändern ist
>wohl kein Problem,
>leider haben wir eine Million davon... Da wären wir wieder bei
>der Idee,
>Layout-Tabellen automatisch in divs umzusetzen.
>
>> 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.
>
>Der "Vergößern"-Link ist in der Tat ärgerlich. Der könnte nach
>hinten. Das geb
>ich mal weiter. Warum die Alt-Attribute leer sind, ist mir
>nicht klar - das war
>auch nicht immer so, wenn ich mich recht entsinne. Allerdings
>ist nicht so klar,
>was die ideale Lösung wäre... es gibt zwei mögliche Inhalte: die
>Bildunterschrift (die ja ohnehin nochmal kommt) oder den
>Dateinahmen (der
>hoffentlich, aber nicht unbedingt, informativ und leserlich
>ist). Außerdem
>könnte man Statt dem alt-Attribute auch title= setzen - am
>Bild oder auch an
>dem Link, der das Bild umgibt. Da der Link auf die Detailseite
>des Bildes zeigt,
>scheint es mir durchaus sinnvoll, in dem Link das
>Title-Attribut auf den
>Dateinamen zu setzen.
>
>> 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.
>
>Das wäre super!
>
>Vielen dank erstmal so weit. Ich schreib gleich mal etwas an die
>Entwickler-Mailingliste.
>
>
>Gruß
>Daniel Kinzler
>
>--
>
>Daniel Kinzler
>Software Developer
>Wikimedia Deutschland
>
>Phone +49 30 219 158 260
>
>Stellen Sie sich eine Welt vor, in der jeder Mensch freien
>Zugang zu der
>Gesamtheit des Wissens der Menschheit hat. Helfen Sie uns dabei!
>http://spenden.wikimedia.de/
>
>****Unterstützen Sie Freies Wissen mit einer SMS. Senden Sie
>einfach WIKI
>an 81190. Mit 5 Euro sichern Sie so die Verfügbarkeit und
>Weiterentwicklung der Wikipedia.****
>
>Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
>Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
>unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das
>Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
>