Wikipedia Diskussion:Projektneuheiten/Archiv/2011

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Wikipedia Diskussion:Projektneuheiten/Archiv/2011#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Wikipedia_Diskussion:Projektneuheiten/Archiv/2011#Thema_1

"(Softwareneuheit) Für den Missbrauchsfilter wurden zwei neue Benutzerrechte eingeführt"

Steht noch unter Vorschau, gibts aber längst: Spezial:Gruppenrechte → Oversighter. Vergessen, das bei Live einzutragen? XenonX3 - (☎:±) 14:56, 4. Jan. 2011 (CET)

Ich habe die Vorschau mal angepasst. Der Umherirrende 15:45, 4. Jan. 2011 (CET)

Danke :) XenonX3 - (☎:±) 15:53, 4. Jan. 2011 (CET)

Kein Problem. Der Umherirrende 16:14, 4. Jan. 2011 (CET)

Ähem.. wann soll das denn live gegangen sein? rev:68584 gibt keine Hinweise darauf. — Raymond ^Disk. 16:11, 4. Jan. 2011 (CET)

Mit rev:71851. Siehe auch Server admin log. Der Umherirrende 16:14, 4. Jan. 2011 (CET)

Danke, das ist bei mir woh im Nach-Urlaub-Backlog-verarbeiten verloreren gegangen :-/ — Raymond ^Disk. 16:18, 4. Jan. 2011 (CET)

Liste der vor dem Hochladen geschützten Dateien

Seit dem 9. April 2010 ist es möglich Dateien vor dem erneuten Hochladen zu schützen. Kennt jemand eine Spezialseite, auf der alle diese geschützen Dateinamen aufgelistet werden? Oder ein API-Modul? Ich konnte nichts finden, aber ich denke, das eine solche Liste nicht schlecht wäre. Vielen Dank. Der Umherirrende 21:52, 4. Jan. 2011 (CET)

auf Spezial:Geschützte_Seiten fehlt in der Dropdownbox Hochladen. Das hat man beim ergänzen evtl übersehen. Hier ist eine Datei die geschützt ist: [1]. (Ohne Muster-Datei hätte ich das System nicht verstanden)

Und so geht es am Beispiel Commons: http://commons.wikimedia.org/w/index.php?title=Special%3AProtectedPages&namespace=6&type=upload&level=0&sizetype=min&size= [2] und hier die Hand voll Dateien in de: http://de.wikipedia.org/w/index.php?title=Spezial:Gesch%C3%BCtzte_Seiten&namespace=6&type=upload&level=0&sizetype=min --Steffen2 22:21, 4. Jan. 2011 (CET)

Danke für den Hinweis. An die Möglichkeit der URL-Manipulation hatte ich garnicht gedacht. Ich habe dafür mal Bug 26574 aufgemacht. Für den API-Teil habe ich Bug 26573 eröffnet. Der Umherirrende 17:12, 5. Jan. 2011 (CET)

Danke für die Bug-Eröffnung. Ich hatte gestern Abend bereits lokal etwas herumgepatcht, aber ganz so simpel wie zuerst gedacht ist die Lösung leider doch nicht :-( Siehe meinen Bugkommentar dazu.(nicht signierter Beitrag von Raymond (Diskussion | Beiträge) 17:27, 5. Jan. 2011)

Kein Problem. Schade, das die Lösung wohl nicht so einfach ist. Der Umherirrende 19:21, 5. Jan. 2011 (CET)

Anscheinend einfacher als ich dachte. Wurde heute Abend gefixt. Umso besser :) — Raymond ^Disk. 22:05, 5. Jan. 2011 (CET)

Das ging mal schnell. Kommt ja vielleicht noch mit 1.17, auch wenn ich es nicht dringend bräuchte. Stört aber nicht. Der Umherirrende 00:49, 6. Jan. 2011 (CET)

Umbrechen

Der kleine Edit-War für zwischendurch ist nett anzuschauen.

Es stimmt schon:

• Ein junger Baum wird vom Sturm umgebrochen.
• Eine Zeile, eine Seite wird umbrochen. Das ist nicht nur fachsprachlich richtig, sondern „umgebrochen“ wäre hier auch schlicht falsch.

Pech für das Wiktionary. Besser: umbrechen II. In: Digitales Wörterbuch der Deutschen Sprache.

Frühlingsgefühle für das Wochenende --Gräfin Typo 20:19, 8. Jan. 2011 (CET)

Unter wikt:umbrechen#Verb, untrennbar, Homograph steht doch alles richtig. --Fomafix 20:22, 8. Jan. 2011 (CET)

Ich entschuldige mich in aller Form beim Wiktionary. In einem Bearbeitungskommentar hatte jemand auf wikt verwiesen und unterstellt, das stünde dort nicht. Dies hätte ich nachprüfen müssen. --Gräfin Typo 20:52, 8. Jan. 2011 (CET)

Hatte nicht gescrollt. :-/ --Revo Echo der Stille 21:08, 8. Jan. 2011 (CET)

Commonslokalisierung

Und wo kann man das ganze abschalten und das Projekt immer in der Sprache sehen, die man auch ausgewählt hat? Hat mich schon immer geärgert, dass man von hier auf Bilder klickend die deutschen und nicht englischen Bedienelemente zu sehen bekam. Der erfahrene Benutzer weiß, wie er wo wann (?/&)uselang= verwenden will/kann. Grüße, —DerHexer (Disk., Bew.) 14:31, 4. Jan. 2011 (CET)

Hinweis auf eine verwandte Diskussion: WD:COMT#Sprache manuell einstellen trotz SUL --Leyo 14:39, 4. Jan. 2011 (CET)

Du meinst, bei uns das ?uselang=de aus den Bildlinks werfen? Denn das, was da auf commons läuft, stört und ja nur wenig... gilt ja (wie ich das sehe) gar nicht für angemeldete, oder? --Guandalug 14:45, 4. Jan. 2011 (CET)

Es zumindest bei uns abschaltbar machen. Wozu sucht man sich selbst in fremden Projekten Sprachen aus, wenn man doch in andere von hier aus geleitet wird? Vermutlich würde ein CSSs bei mir reichen, um die Links umzubiegen. Grüße, —DerHexer (Disk., Bew.) 14:57, 4. Jan. 2011 (CET)

Wie willst Du mit CSS Links umbiegen? --Fomafix 15:03, 4. Jan. 2011 (CET)

Hm, ja, muss wohl mit JS ran. xD —DerHexer (Disk., Bew.) 15:10, 4. Jan. 2011 (CET)

Wir übergeben an vielen Stellen uselang={{INT:Lang}} an Commons (MediaWiki:sharedupload-desc-here, Vorlage:Commons, …). Ist das für angemeldete und nicht angemeldete Benutzer so richtig? --Fomafix 14:54, 4. Jan. 2011 (CET)

Da kommt aus MediaWiki:Sharedupload-desc-here - da steht uselang={{INT:Lang}} drin. Ich hab das mal so gelöst:

jQuery(document).ready(function($){
 $('a[href*="uselang="]').each(function() { 
  this.href = this.href.replace(/uselang=[a-z_-]+&?/,''); 
 }); 
});

Damit wird in den Links ein '?uselang=de' rausgeworfen ;) --Guandalug 15:07, 4. Jan. 2011 (CET)

Mit der neuesten Version sollte der sogar mit mehreren Parametern zurechtkommen, solange uselang= der erste ist. Natürlich hierbei nur für '=de' - entsprechende Anpassungen möge jede User selbst.... Und ja, das gehört in die vector.js (ob es in Monobook funktioniert, weiss ich nicht - 's ist jQuery) --Guandalug 15:14, 4. Jan. 2011 (CET)

Vielen Dank dafür. :) --Rosentod 15:16, 4. Jan. 2011 (CET)

Vorsicht: Irgendwas spinnt da noch - bitte noch einen Augenblick mit der intensiven Nutzung warten, ich melde mich noch mal. Da gab es Seiteneffekte. --Guandalug 15:17, 4. Jan. 2011 (CET)

So. Nu ist ihm eigentlich auch die lokal eingestellte Sprache ziemlich egal ;) --Guandalug 15:33, 4. Jan. 2011 (CET)

Das eigentliche Problem ist, dass wir hier überhaupt nicht abfragen können, ob der Benutzer bei Commons angemeldet ist, oder nicht. Können wir durch die JavaScript-Lösung auf Commons inzwischen auf die Übergabe uselang={{INT:Lang}} verzichen? --Fomafix 15:21, 4. Jan. 2011 (CET)

Nein, können wir wohl noch nicht drauf verzichten, da auch die aktuelle Lösung eigentlich nur ein Hack um das Hauptproblem ist: MediaWiki erkennt immer noch nicht die Sprache aus der Browsereinstellung des Lesers :-( Also wird per JS-Hack das ?uselang=de permanent angehängt. Ich halte das für Otto-Normal-Bildersucher übrigens eine ganz tolle Lösung, damit findet für diesen der Sprachwirrwar ein Ende. — Raymond ^Disk. 15:30, 4. Jan. 2011 (CET)

Dem stimme ich zu, Raymond. Für Otto-Normaluser istd as eine geniale Sache - und die, die's wirklich stört, haben eine vector.js zur Verfügung. --Guandalug 15:34, 4. Jan. 2011 (CET)

Dafür werden die erfahrenen Benutzer, die sich ihre Sprachen selbst eingestellt haben, verwirrt … naja, übliche Foundationpolitik (die ja letztlich sich an den größeren Kreis richtet, aber den der erfahrenen Benutzer wie so oft nun schon ausblendet). Grüße, —DerHexer (Disk., Bew.) 15:48, 4. Jan. 2011 (CET)

(BK) Wenn Commons per JavaScript für nicht angemeldete Benutzer uselang hinzugefügt, dann sollen wir bei Commonslinks auch per JavaScript uselang hinzufügen und nicht fest in Vorlagen bzw. Systemnachrichten festlegen. --Fomafix 15:49, 4. Jan. 2011 (CET)

Also, in Vorlagen geht kein JavaScript.... und global mag ich zumindest das nicht coden ;) --Guandalug 15:50, 4. Jan. 2011 (CET)

@Hexer: Bei Gelegenheit habe ich ein wenig Mitleid mit dir *duck* Im übrigen ist das keine Foundation-Sache, sondern das hat sich ein Benutzer ausgedacht und realisiert, weil die Foundation es nicht auf die Reihe bekommen, Multilingualität serverseitig zu realisieren. — Raymond ^Disk. 16:14, 4. Jan. 2011 (CET)

Noch einmal: es ist durchaus nicht so, dass jemand der sich über einen deutschen Provider oder per Klick aus dewiki in Commons anwählt dort auch deutsch haben möchte. Ich verwende sehr viele Sprachen in diversen Projekten, und zwar bewußt und vor allem gezielt. Wenn dies jetzt noch für andere Projekte eingeführt werden sollte dann wäre es schon ein heftiger Mist. Oder muss ich dann ständig und für jedes Projekt nach irgendweiner js-Lösung suchen und die pflegen? -jkb- 16:56, 4. Jan. 2011 (CET)

(BK) Das übergebene uselang ist aber ebenfalls nur eine Notlösung, weil es keine saubere übergreifene Multilingualität gibt. Angemeldete Benutzer stört es und bisher hat es auch nur ein Klick weit gewirkt. Als angemeldeter und auch als unangemeldeter Benutzer ärgert es mich immer, wenn ich in einer fremdsprachigen Wikipedia nach Bildern stöbere und dann beim Weiterleiten auf Commons auch immer die fremde Sprache bekomme. Wenn ich als angemeldeter Benutzer die Sprache in den Einstellungen oder als unangemeldeter Benutzer per neuem JavaScript ein Cookie gesetzt habe, dann will ich diese Sprache auf den Commons auch immer haben. --Fomafix 17:09, 4. Jan. 2011 (CET)

Ich hab's grad erfolgreich mit der monobook.js getestet. --Eva K. ^ist böse 17:11, 4. Jan. 2011 (CET)

Danke, das beweist: Auch Monobook kann schon mit jQuery umgehen. Gut zu wissen :D --Guandalug 17:17, 4. Jan. 2011 (CET)

Die neue Bearbeitungsleiste funktioniert ja auch unter monobook, daher braucht es auch dort jQuery. Der Umherirrende 18:40, 4. Jan. 2011 (CET)

uselang={{INT:Lang}} funktioniert sowieso nicht ganz einheitlich. {{INT:Lang}} erzeugt de, mit als erzeugt es als, mit bar aber de. Unter Spezial:Präfixindex/MediaWiki:Lang sind nur ein paar Sprachen definiert. Wie gehört es denn richtig? --Fomafix

MediaWiki:Lang/bar existiert nicht, daher wird der fallback angenommen, und das ist de. {{INT:Lang}} ist ein Hack, daher müssen die Unterseiten für jede Sprache angelegt werden, da sie in MediaWiki nicht selber definiert sind. Die Probleme, die der Hack nach sich zieht, sind aber nicht so gravierend. Um es richtig zu machen, müsste sich ein Admin finden, der zu jeder Sprache, die es in MediaWiki gerade gibt, eine Seite anlegt und später auch neu hinzugekommende ergänzt. Die häufigsten sollten aber auch reichen (zum Beispiel die, die auf der Hauptseite stehen). Der Umherirrende 18:40, 4. Jan. 2011 (CET)

Hinweis auf eine verwandte Diskussion: Commons:Commons:Forum#Neues Gadget fuer automatische Uebersetzung --Leyo 11:00, 7. Jan. 2011 (CET)

Ich habe ein Problem mit dem Codeschnipsel von Guandalug oben. Es wird zwar "uselang=de" entfernt. Aber das Fragezeichen davor bleibt noch stehen. Wie muss ich den den Code

jQuery(document).ready(function($){
 $('a[href*="uselang="]').each(function() { 
  this.href = this.href.replace(/uselang=[a-z_-]+&?/,''); 
 }); 
});

anpassen, damit auch das Fragezeichen entfernt wird? --Ephraim33 15:40, 18. Jan. 2011 (CET)

Das Fragezeichen bleibt mit Absicht stehen (und stört nicht). Grund dafür: Stell dir ein '?uselang=de&dosomething=true' vor. Der Codeschnipsel von mit hinterlässt '?dosomething=true'. Man könnte jetzt (wie Wiegels unten - Danke) noch ergänzen, dass ein angehängtes Fragezeichen als einziger Rest entfernt wird... das hielt ich aber für wenig relevant (das Fragezeichen sollte ja in keinem Fall was kaputtmachen, so lese ich den RFC 3986) --Guandalug 16:07, 18. Jan. 2011 (CET)

Das Fragezeichen störte mich, weil dann ein Link auf Commons nicht lila angezeigt wird, obwohl ich ihn schon besucht habe. --Ephraim33 16:12, 18. Jan. 2011 (CET)

Okay, ist ein Grund ;) --Guandalug 16:13, 18. Jan. 2011 (CET)

 this.href = this.href.replace(/uselang=[a-z_-]+&?/, '').replace(/\?$/, '');

entfernt anschließend ein abschließendes Fragezeichen. --Wiegels „…“ 16:04, 18. Jan. 2011 (CET)

Danke, funktioniert. --Ephraim33 16:12, 18. Jan. 2011 (CET)

Bug 542

Der kommende Bug 542 entfernt title-Attribute von manchen a-Elementen. Das verhindert die Möglichkeit das title-Attribut als CSS-Selektor für Namensraumlinks zu verwenden:

a[title^="Wikipedia:"],
a[title^="WP:"] { background:#CFE3FF; } /* hellblau */

Gibt es dazu eine Alternative? --Fomafix 15:13, 31. Jan. 2011 (CET)

Kann man da nicht gleich mit a[href^=....] rumspielen? --Guandalug 15:42, 31. Jan. 2011 (CET)

Nein kann man nicht, wegen dem SSL-Server. Man muss auf JavaScript umsteigen. -- Prince Kassad 15:45, 31. Jan. 2011 (CET)

Das wage ich mal freundlich zu bezweifeln ;) --Guandalug 15:46, 31. Jan. 2011 (CET)

Und vielleicht mit erweiterte Suche?

a[href*="..."],...

Vielleicht auch nicht so eindeutig? -- Perhelion 15:48, 31. Jan. 2011 (CET)

Das Problem wäre, dass das auch auf Links wie Die Geschichte der Wikipedia: Illustrierter Roman in fünf Bänden oder OWP:FA zutreffen würde, und das ist nicht so toll. -- Prince Kassad 15:52, 31. Jan. 2011 (CET)

Genau. --Fomafix 15:53, 31. Jan. 2011 (CET)

(BK)Sind dann halt etwas andere Regeln. Auf dem Secure-Server enthält der Pfad zusätzlich '/wikipedia/de'. Entweder nimmt man also doppelte Regeln, oder man wählt einen anderen CSS-Selektor. Ungetestet:

a[href*="/wiki/Wikipedia:"],
a[href*="/wiki/WP:"] { background:#CFE3FF; } /* hellblau */

Das müsste auch auf Secure klappen. --Guandalug 15:54, 31. Jan. 2011 (CET)

Ja ich denke auch. -- Perhelion 15:56, 31. Jan. 2011 (CET)

Diese Selektoren treffen dann aber wieder nicht zu bei Links auf das Ziel: /w/index.php?title=Wikipedia:… --Fomafix 15:58, 31. Jan. 2011 (CET)

Aber das ist doch irrelevant, weil das jetzt schon nicht funktioniert, oder? -- Prince Kassad 16:08, 31. Jan. 2011 (CET)

Ja dann vielleicht einfach ergänzend:

a[href*="title=Wikipedia:"],a[href*="title=WP:"]

-- Perhelion 16:18, 31. Jan. 2011 (CET)

(BK) Die Links auf den Spezialseiten erzeugen solche title-Attribute bei Links der Form /w/index.php?title=Wikipedia:…. Aber ich sehe gerade auf translatewiki:, wo Bug 542 schon aktiv ist, dass diese title-Attribute dort weiterhin geliefert werden. --Fomafix 16:25, 31. Jan. 2011 (CET)

• Für http und https braucht man keine unterschiedlichen Selektoren, weil /wiki/Wikipedia: hinreichend charakteristisch ist, um das Link zu identifizieren.
• Im Gegenzug fällt der Aufwand für den Alias weg. Robuster wird es, weil die prinzipiell vorhandene case sensitivity bei href= wegfällt; insofern ist dies eine Verbesserung gegenüber title= und zukunftssicher.
• Soll auch noch index.php? abgefangen werden, wären es dann zwei Ausdrücke.
• Getestet gemäß meiner Seite.

Have a nice day. --PerfektesChaos 16:38, 31. Jan. 2011 (CET)

Nice, also ist Abkürzung (WP:) Quatsch? gn8 -- Perhelion 21:48, 31. Jan. 2011 (CET)

„Quatsch“ würde ich nicht formulieren wollen.

Ich kann mich durchaus daran erinnern, dass bei title= das irgendwann mal erforderlich war, also getestet werden musste auf WP: und auch wp: usw. Momentan ist title gerade so freundlich, die Umsetzung wp:→Wikipedia: bereits vorzunehmen. Es ist aber wohl schon sehr lange so, dass dies in der URL aufgelöst und mit einheitlicher Groß-/Kleinschreibung verwendet wird, href sich also sehr viel besser als Selektor eignet.

--PerfektesChaos 22:26, 31. Jan. 2011 (CET)

Update 8. Feb. - verbesserte BEO

Schade, dass dabei nicht die Bugs bugzilla:1492 / bugzilla:5875 berücksichtigt wurde, was ja wohl eine Möäglichkeit gewesen wäre: ich könnte dann nicht nur div. Namensräume einfärben (so habe ich es verstanden), sondern beispielsweise auch solche Seiten, die nur kurzfristig von Interesse sind, die ich dann immer streichen könnte. So muss man mühsam suchen und nach bspw. Benutzerdiskussionseiten suchen, die ich mir wg. einer Antwort auf BEO setzte, die da aber natürlich bleibt und herumgeistert. Schade. -jkb- 12:52, 1. Feb. 2011 (CET)

Schade ja. Aber es muss halt erst noch programmiert werden. Wie so viele Wünsche noch offen sind :-(

Live geht aber:

Jeder Eintrag auf der erweiterten Beobachtungsliste wird mit der CSS-Klasse des Namensraumes und den Seitennamens versehen. So kann sich jeder Benutzer Einträge auf der Beobachtungsliste individuell nach Namensräume und auch nach speziellen Seiten einfärben (rev:76342).

Das sollte deinem Wunsch recht nahe kommen. Für nur kurzfristige Einfärbungen ist zugegebenermaßen jedesmal die Bearbeitung deines CSS notwendig.

Im Prototyp-Wiki kannst du das auch schon ausprobieren. — Raymond ^Disk. 13:30, 1. Feb. 2011 (CET)

Danke. Das war ja nur so ein allgemeiner Säufzer :-). Ich schau mir den Link von dir an. Wenn ich da Probleme habe, weiß ich ja, wo ich vorsprechen kann :-))) -jkb- 13:44, 1. Feb. 2011 (CET)

Da aber rev:77012 live gehen wird, wird mein unter Benutzer:Schnark/js/watchlisttags beschriebenes Skript funktionieren (hoffe ich zumindest), das hilft dir vielleicht auch weiter. --Schnark 09:08, 2. Feb. 2011 (CET)

Ladegeschwindigkeit von CSS im Versionsunterschied

Hallo, auf dem release-de-Testwiki ist mir aufgefallen, dass das CSS für den diff enorm lange braucht, bis es erstmal zu sehen ist. Ich habe erst nur eine Tabelle ohne Farbe und einen (längeren) Moment später kommt die rote und grüne Farbe. Liegt das Problem bei mir? Ich nutze IE8 und finde das keine Verbesserung der Geschwindigkeit. Beispiellink 1.17/gleicher Diff hier. Meinungen willkommen. Danke. Der Umherirrende 22:17, 3. Feb. 2011 (CET)

Beide Links gehen bei mir etwa gleich (sehr) schnell. Firefox 3.6.13 -- tsor 22:29, 3. Feb. 2011 (CET)

Ich seh im Prototypen-Wiki auch erstmal schwarzweißes Wiki-Markup. Allerdings ist auch in der normalen Wikipedia das CSS-Laden nicht gerade blitzschnell. --YMS 22:33, 3. Feb. 2011 (CET)

Ich habe den Effekt bisweilen im Translatewiki beobachtet. Und zwar immer dann, wenn sich das CSS/JS verändert hat und vom Server neu geladen werden muss. Alle weiteren Seitenaufrufe sind schnell, ohne diesen Effekt, vermutlich weil das CSS/JS dann schon aus dem Browsercache kommt. — Raymond ^Disk. 07:57, 4. Feb. 2011 (CET)

Was ist eigentlich mit den Benutzern, die JavaScript deaktiviert haben? Bekommen die in Zukunft auch kein CSS mehr? --Schnark 10:14, 4. Feb. 2011 (CET)

Ich vermute eher, das einem das aktuell nicht auffällt, da das diff.css vor der diff-table geladen wird und somit die Tabelle direkt mit Farbe vom Browser erstellt werden kann. In der neuen Version aber wird das diff.css erst am Ende der Seite geladen, somit ist die Tabelle bereits vorhanden und wird nachträglich eingefärbt. Da die Seite hinter den Beispiellink sehr lang ist, wird das diff.css erst "sehr spät" vom Browser erkannt und verarbeitet. Der Umherirrende 15:57, 4. Feb. 2011 (CET)

Also ich aber heute Mittag provokativ nachgefragt, ob JavaScript nun neuerdings Vorraussetzung vor ein ordentliches Layout sein soll. Bisher natürlich keine Antwort erhalten, aber ich finde das schon sehr unschön beim MW 1.17-Diff. Merlissimo 16:06, 4. Feb. 2011 (CET)

Da anderes CSS ja auch ohne JavaScript eingebunden werden kann, liegt es hier wahrscheinlich daran, dass man unbedingt CSS und JS gleichzeitig laden will, aber das JavaScript ist nur für uralte Fireföxe gedacht, die – sofern sich mal jemand um die TODO-Kommentare kümmert – sowieso gar kein JavaScript mehr bekommen. Mir persönlich kann das egal sein, ich habe JavaScript eingeschaltet und einen aktuellen Firefox, aber stellenweise erscheint mir der RessourceLoader doch noch etwas unfertig. --Schnark 09:41, 5. Feb. 2011 (CET)

Beobachtungsliste

Weiß jemand, ob die Legende oben auf der Beobachtungsliste in MediaWiki 1.17 mit Absicht entfernt wurde? --Schnark 09:39, 7. Feb. 2011 (CET)

rev:73316 --Fomafix 09:57, 7. Feb. 2011 (CET)

Korrekturen am Update

• Davon wird es sicher mehr geben, hier das erste: kann man die mühsam versteckten Optionen "Zurück zur alten Oberfläche" und "Naue Funktionen" im Vektor wieder loswerden? Sie sind da. -jkb- 14:14, 8. Feb. 2011 (CET)

Ganz brav. Schon wieder verschwunden :-) -jkb- 14:22, 8. Feb. 2011 (CET)

(BK) Das sollte eigentlich komplett abgeschaltet sein/werden. Die Funktion ist obsolet geworden. — Raymond ^Disk. 14:24, 8. Feb. 2011 (CET)

Ist das Update nun online oder nicht? --Stefan 18:23, 8. Feb. 2011 (CET)

wechselt ständig. Aktuell ist Spezial:Version, oder schau auf #wikimedia-tech vorbei, da merkt man den stressfaktor. -- ✓ ^Bergi 18:29, 8. Feb. 2011 (CET)

Testwiki

In der test.WP wird ebenfalls Version 1.16 angezeigt, dort scheint die Änderung also auch rückgängig gemacht worden zu sein. --Morten Haan Wikipedia ist für Leser da 21:51, 8. Feb. 2011 (CET)

Oha selbst dort, das lässt nichts Gutes ahnen. -- 77.179.223.70 22:03, 8. Feb. 2011 (CET)

JavaScript may break on your wiki: Fix it before that happens

Siehe diese Mail. Sind wir vorbereitet? Grüße, --Church of emacs D B 13:58, 12. Feb. 2011 (CET)

Abwärtskompatibilität ist so ein schönes Wort … Wir werden es wohl sehen, ich denke aber, das auch einige Benutzerskripte abrauchen, wo die Benutzer selber nicht wissen, was zu tuen ist. Die werden dann wohl auf WP:FzW aufschlagen. Der Umherirrende 14:06, 12. Feb. 2011 (CET)

Sollten wir eine zentrale Seite einrichten, vllt. als Unterseite von WP:Skin, auf der Skripthilfe gegeben werden kann? Schon jetzt laufen derartige Anfragen entweder auf FzW oder WVW auf, vielleicht wäre es auch ohne MW-Update sinnvoll. Wie man aber an der Usability-Hilfe gesehen hat, dürfte eine derartige Seite durchaus gebraucht werden. Zusätzlich wäre eine deutsche Übersetzung und ausführliche Dokumentation der JavaScript Deprecations hilfreich, von denen bislang wohl nur Entwickler was gehört haben. -- ✓ ^Bergi 18:25, 12. Feb. 2011 (CET)

Ich verweise mal auf das Archiv: 1, 2, 3. Im Besonderen möchte ich zitieren: „Das Hauptproblem dürfte bei PDDs Monobook liegen.... das verlässt sich auf die Anwesenheit der wikibits.js - Funktionen UND darauf, dass es schon zur Ladezeit der Seite ausgeführt wird ..... das wird lustig. --Guandalug 09:37, 22. Okt. 2010 (CEST)“ Auch meine 20, 30 Skripts werden wohl kaputtgehen, wie dies auf metawiki schon der Fall mit einem wichtigen Skript war. “Fix it before that happens” ist ein toller Spruch, vielleicht hätte man auch die Güte, uns zu sagen, wie wir nun ohne Hooks Events ausführen sollen (oder am besten gleich selbst korrigieren). 9_9 Ich reg mich nicht mehr über so wenig Fingerspitzengefühl gegenüber den Mitarbeitern auf … Grüße, —DerHexer (Disk., Bew.) 18:46, 12. Feb. 2011 (CET)

Danke, dass du mich zitierst, DerHexer, dann brauch ich's selber nicht. Wenn ich die temporären Fehler während des letzten Update-Versuch betrachte, dann bedeutet das Update, dass wir am 16. vermutlich erst mal $alles umstricken können. Bei mir hakte ja schon ein Gadget, weil addOnloadHook() nicht existierte. Ja, das geht inzwischen über jQuery.documentReady() (oder wie das grad heisszt)) aber umschreiben muss man's. --Guandalug 22:09, 13. Feb. 2011 (CET)

Kann bestätigen, dass auf meta meine Skripte nicht mehr laufen. ;o) Hast du vielleicht einen Link zum Umgeschriebenen, dass man sich das mal angucken und dann adaptieren kann? Danke und Grüße, —DerHexer (Disk., Bew.) 22:21, 13. Feb. 2011 (CET)

1.  Pro Die angesprochene „Zentrale Seite“ wäre fürs Erste die sinnvollste Maßnahme. (Wobei es jetzt schon genug ungelöste JS-Bugs gibt) Wer würde die jetzt wo anlegen? -- Perhelion 20:11, 12. Feb. 2011 (CET)

Ohne Hook werden hier nahezu alle JavaScripte kaputt gehen. Wieso führt man eine solche Änderung durch?! Yellowcard 22:24, 13. Feb. 2011 (CET)

Da gibt es grundsätzlich eigentlich nur zwei Möglichkeiten: Weil es entweder den eigenen Extensions nützt oder man nur an den Leser und nicht an den Mitarbeiter denkt. Hier also letzteres: Der RessourceLoader lädt JavaScripte nur dann, wenn der Leser sie auch braucht. Dass alle bisher geschriebenen Programme, dazu gehören auch meine 20, 30 Stück, größtenteils mit Hooks arbeiten und man damit viel Arbeit kaputtmacht, ohne selbst eine einfache Möglichkeit zu bieten, dies beheben zu können, ignoriert man da geflissentlich und warnt halt nur davor, dass man alles kaputtmacht. Grüße, —DerHexer (Disk., Bew.) 22:30, 13. Feb. 2011 (CET)

Dankenswerter Weise wurde ja ein Migration Guide veröffentlicht. De facto steht dort aber rein gar nichts drin. Wie kann ich denn nun ein Script, das einen onLoadHook benötigt, mit möglichst wenig Arbeit umschreiben, sodass es auch weiterhin funktioniert? Und, um es mal aus dem anderen Blickwinkel zu betrachten: Wer genau entscheidet, dass für de.wp diese Extension livegeschaltet wird? Wer ist da die verantwortliche Person? Yellowcard 22:35, 13. Feb. 2011 (CET)

Hinweise zum Umschreiben von Scripten (alte Funktion -> zukünftige Funktion) gibt's unter mw:ResourceLoader/JavaScript Deprecations. --YMS 22:54, 13. Feb. 2011 (CET)

(An niemanden speziell gerichtet) Ich kann nur jedem empfehlen, der ein Problem mit der Umstellung hat, eine Mail an Wikitech-l zu schreiben. Auf dieser Diskussionsseite wehzuklagen (wenn auch berechtigt), wird den Sysadmins die Problematik nicht klar machen. Grüße, --Church of emacs D B 23:30, 13. Feb. 2011 (CET)

Ich fände es mal nett, wenn die Kommunikation nicht abgeschlossen auf einer Mailingliste stattfände sondern zumindest eine Kontaktseite im Wiki eingerichtet würde.. Nicht jeder hat beispielsweise eine zum pseudonymen Benutzernamen passende E-Mailadresse und ist schon dadurch reichlich behindert. Viele Grüße --Saibo (Δ) 23:37, 13. Feb. 2011 (CET)

Naja, eine solche E-Mail-Adresse ist ja in zwei Minuten eingerichtet. Darin sehe ich eine wesentlich geringere Hürde als in der Sprachbarriere. Mailinglisten sind übrigens nichts neues, sondern waren von Beginn der Wikipedia an eine Kommunikationsplattform. Grüße, --Church of emacs D B 23:43, 13. Feb. 2011 (CET)

Wäre es für eine gewisse Übergangszeit nicht sinnvoll, addonloadhook als lokale Funktion in die Common.js zu schreiben, um wenigstens für dieses Problem etwas mehr Zeit zur Behebung zu haben? --Steef ³⁸⁹ 00:52, 14. Feb. 2011 (CET)

addOnloadHook ist – zumindest wenn alles so funktioniert, wie die Programmierer sich das vorstellen – auch weiterhin vorhanden und funktioniert. Der einzige Unterschied ist, dass die Funktion in Zukunft das tun wird, was der Name sagt, nämlich die angegebene Funktion nach dem Laden der Seite ausführen (und nicht mehr nach dem Einlesen des body. Wer's nicht glaubt, kann sich in simple: das Gadget HighlightAdmins aktivieren, das verwendet neben addOnloadHook sogar noch document.write – und funktioniert weiterhin. --Schnark 09:32, 14. Feb. 2011 (CET)

1. Für alle gängigen Benutzer-Funktionen wie addOnloadHook() steht (übergangsweise) die alte oder eine Ersatz-Implementierung zur Verfügung. Dies läuft unter dem Sichwort "legacy"; siehe etwa mediawiki.legacy.wikibits in Zeile 615.
2. Dies müsste ggf. für die de.WP auf PHP-Ebene durch Steuerparameter geeignet konfiguriert werden, beispielsweise durch Raymond. So gibt es einen PHP-Schalter LEGACY_GLOBALS, der aber bereits in der für uns benötigten Weise voreingestellt ist.
3. 99% aller Skript-Aktivitäten, die ich in unseren Benutzerskripten gesehen habe, müssten damit abgedeckt sein. Nur wer explizit auf den Zeitablauf des tatsächlichen Ladens angewiesen ist, könnte Umstellungsbedarf haben. Da der Zeitpunkt aber nach hinten rückt und dann nicht nur das DOM, sondern nun zusätzlich auch die Ressourcen (Bildchen) bekannt sind, geht dem Benutzer-Skript keine Information verloren. Das Problem wäre also nicht "Funktioniert gar nicht", sondern allenfalls "Funktioniert verlangsamt", weil bisher parallel ablaufende Aktivitäten künftig nacheinander gestartet werden oder überflüssige Ressourcen vom Server geladen wurden.
4. Die Ansage "Don't wait until your wiki's JavaScript is all broken" ist deshalb wohl etwas arg alarmistisch formuliert, aber das ist mitunter erforderlich, um in trägen Projekten (nicht der de.WP) Verantwortliche aufzuwecken.
5. Die Vokabel "deprecated" bedeutet lediglich, dass damit gekennzeichnete Variable und Funktionen bei künftigen Neuentwicklungen nicht mehr verwendet werden sollen. mw:ResourceLoader/JavaScript Deprecations gibt an, was und wie auch im Zuge von Überarbeitungen zu ersetzen wäre.

Take it easy --PerfektesChaos 12:21, 14. Feb. 2011 (CET)

Test

Hallo, ich habe mal unter test2:User:✓/monobook.js ein Mess-Skript geschrieben. Opera: Cache gelöscht, Dragonfly-Netzwerk mitgelesen: die Seite braucht 847ms, weitere 2197ms für CSS und Co. Die Ausgabe sieht folgendermaßen aus:

13s, 552ms: Browser-Userscript beginnt zu laufen; $/jQuery:undefined, mw:undefined, addOnloadHook:undefined ;-)
14s, 488ms: WP-Userscript beginnt zu laufen; jQuery und mediaWiki-Objekte sind initialisiert; addOnloadHook kann gesetzt werden
14s, 644ms: DOMContentLoaded aus Browserscript schlägt an
14s, 650ms: jQuery.ready aus WPscript schlägt an
14s, 651ms: DOMContentLoaded aus WPscript schlägt an
14s, 651ms: window.onload (bzw. entsprechendes Event) aus Browserscript schlägt an
14s, 652ms: addOnloadHook aus WPscript schlägt an

Ich denke, wir haben nur wenig zu befürchten. Genial ist mediaWiki.user.options, ich denke das eröffnet uns neue Möglichkeiten der Personalisierung. Schade ist natürlich, dass Userscripte erst nach dem RessourceLoader ausgeführt werden können, sodass man benötigte Systemnachrichten oder gar JS-Module nicht in einem Aufzug mitladen kann. Was ich leider nicht ausprobieren konnte waren Mediawiki:Common.js und Gadgets, die gibt es im Testwiki nämlich nicht (und ich bin kein Admin).
meint -- ✓ ^Bergi 21:31, 15. Feb. 2011 (CET)

Monobook-Einstellungen

Hallo! Ich hoffe, dass ich hier mit meiner Frage richtig bin, ansonsten würde ich mich über einen kurzen Hinweis, wohin ich laufen müsste, freuen. Gibt es eine Möglichkeit, die Einstellungen, die man den der persönlichen monobook.js-Datei gemacht hat (insbesondere zum Editieren), auch weiterhin verfügbar zu haben? Momentan erhalte ich statt meiner persönlichen Einstellungen für Monobook, obwohl Monobook aktiviert ist, nur die Editierzeile von der Vector-Version. Viele Grüße --Angela H. 12:47, 16. Feb. 2011 (CET)

Vielleicht hilft schon WP:FZW#Bearbeitungswerkzeuge verschwunden. -- Rosenzweig δ 12:51, 16. Feb. 2011 (CET)

Danke für die blitzschnelle Antwort. Hmm, hier funktioniert es schon. (Habe das Häckchen entfernt. ;-)) Aber was macht man in Projekten, wo es so eine Auswahl gar nicht gibt? Naja, ich werde mich erst mal gedulden, vielleicht hilft ja auch die Bug-Meldung auf die Dauer… Viele Grüße --Angela H. 12:59, 16. Feb. 2011 (CET)

Ups, habe gerade im falschen Tab gesucht. Nun geht's auch da. :-)) Viele Grüße --Angela H. 13:05, 16. Feb. 2011 (CET)

Seitenlayout

Hallo. Ich empfinde es als störend, dass auf dieser Seite abweichend vom sonst üblichen Vorgehen, die Einträge chronologisch rückläufig sind. Es wäre doch viel übersichtlicher, wenn man beim Durchlesen der Seite zuerst die bereits aktiven Neuheiten in zeitlicher Folge, dann die Vorschau auf die nahe Zukunft und am Ende die weitergehenden Zukunftsaussichten vor sich hätte. Ich schlage daher vor, die Einträge umzusortieren. Meinungen dazu ? ÅñŧóñŜûŝî (Ð) 16:15, 16. Feb. 2011 (CET)

"Neuestes oben" halte ich bei solchen Seiten in der Regel für besser. So ist man schneller bei den letzten Änderungen, die einen in der Regel interessieren. Siehe zum Beispiel auch das Server-Admin-Log. Von mir ein Danke, Nein zum Vorschlag. --Guandalug 16:20, 16. Feb. 2011 (CET)

Helferlein exportieren

Zu den Neuerungen von Version 1.17, die jetzt offensichtlich funktioniert, gehört der Helferlein-Export: „Helferlein können jetzt auf Knopfdruck exportiert werden, um sie anschließend in andere Wikis zu importieren“. Wo finde ich denn die Knöpfe? Auf der Einstellungen-Seite sehe ich keine Veränderung. Auf der als Beispiel genannten Translatewiki-Seite steht was von Herunterladen und Import, wofür man aber bestimmte Rechte braucht. Haben normale Benutzer keine Möglichkeit? --MSchnitzler2000 01:52, 17. Feb. 2011 (CET)

Exportieren kann man die Dinger auf Spezial:Helferlein. Man bekommt man eine xml-Datei, die man im Zielwiki importieren kann. Dafür braucht man im Zielwiki aber Adminrechte (bzw. das Import-Recht), da man die Datei dann per Spezial:Importieren importieren muss. XenonX3 - (☎:±) 01:59, 17. Feb. 2011 (CET)

Ok, also nix für normale Benutzer. Dann hatte ich die Ankündigung falsch verstanden. --MSchnitzler2000 02:12, 17. Feb. 2011 (CET)

Was heißt normal: den ersten Schritt, nämlich die Datei zu exportieren, kann hier nach wie vor jeder machen; es geht nur um das importieren im Ziel-Wiki, wo man die Import-Rechte benötigt; wenn es allerdeings "deine" Wiki ist, dann hast du sie im Prinzip automatisch (ebenfalls nach wie vor, es funktionierte schon mit anderen Dateien so). -jkb- 08:22, 17. Feb. 2011 (CET)

Kurze Frage

War das auch schon vor 1.17 so, dass in den Einstellungen unter "Bearbeiten" der neue Editbereich und die Tabellenhelfer als "Beta" aufgeführt werden? Dachte, das sei mitlerweile "final" und eine Eigenschaft vom Vectorskin. --Stefan 09:41, 17. Feb. 2011 (CET)

Nee, das kam zwar mit Vector, war aber früher schon Beta. --Guandalug 09:44, 17. Feb. 2011 (CET)

Aber ich dachte, mit Vector als Standard hat die Beta-Phase für alle neuen "großen" Features der Usability Offensive geendet? Wieso sind die Teile dann immernoch als Beta markiert? --Stefan 17:41, 17. Feb. 2011 (CET)

Perpetual Beta. Merlissimo 17:51, 17. Feb. 2011 (CET)

bugzilla:26750 --Schnark 09:27, 18. Feb. 2011 (CET)

Galerien - Ausdruckproblem

Hallo, nach der gestrigen (oder vorgestrigen) Layoutumstellung werden die Galerien zwar ganz normal angezeigt, beim Ausdruck (Druckversion) werden die Bilder jedoch nicht mehr nebeneinander (früher höchstens vier nebeneinander) sondern untereinander dargestellt. Dies dürfte benutzerunfreundlich sein, da vielfach Artikel auch ausgedruckt werden und dies nun zu einem schlechten Layout beim Druck bzw. auch Papier-Mehrverbrauch führt. --Oltau ^☎ 20:31, 17. Feb. 2011 (CET)

Da fehlt im print.css vermutlich eine kleine Definition für das Nebeneinander der Bilder..... --Guandalug 20:43, 17. Feb. 2011 (CET)

Yo, ich habe mal Bug 27506 dazu aufgemacht: <gallery> is printed in 1 file per row (defekt signierter Beitrag von Raymond (Diskussion | Beiträge) 21:08, 17. Feb. 2011 (CET))

Ein weiteres Problem ist jetzt, dass durch die 100%ige Breite der Galerie die Überschrift, die durch den Parameter caption erzeugt wurde, 100% breit ist, wenn jedoch nur drei Bilder in der Galerie sind, hängt die Überschrift mittig über leerem Raum und die Bilder links am Rand. (z.B. hier) - Inkowik (Re) 15:40, 18. Feb. 2011 (CET)

Dafür gibt es Bug 27540. Der Umherirrende 18:22, 18. Feb. 2011 (CET)

gelöschte versionen (erl.)

ich hab bei den benutzerbeitägen eine checkbox "nur gelöschte Versionen". wie alle anderen nicht-admins auch, kann ich die nicht gebrauchen. --Akkakk 14:55, 18. Feb. 2011 (CET)

Ist mir bisher nicht aufgefallen. Aber, soll das so sein, dass der mir alle Edits von mir anzeigt, die Geoversightet wurden? Umweltschutz – _[D¦B] 15:05, 18. Feb. 2011 (CET)

jetzt gefunden, und sie funktioniert bei mir aber (bei meinen eigenen wie bei fremden Edits). -jkb- 15:10, 18. Feb. 2011 (CET)

Es werden einzelne Versionslöschungen gefilter (also durch Admins und/oder Oversighter, alles was durchgestrichen ist). Der Umherirrende 18:19, 18. Feb. 2011 (CET)

Beispiel: [3]. XenonX3 - (☎:±) 18:25, 18. Feb. 2011 (CET)

Da von den Benutzerbeiträgen die Rede ist: Beispiel. Der Umherirrende 18:27, 18. Feb. 2011 (CET)

ah, ok. so gesehen macht das sinn--Akkakk 18:40, 18. Feb. 2011 (CET)

ResourceLoader generiert Syntaxfehler

Der neue ResourceLoader generiert Syntaxfehler bei der Standardeinstellung debug=false. Mit debug=true funktioniert es.

debug=true enthält:

    w (1,'http://commons.wikimedia.org/wiki/Special:Upload','C-Up',qbtarget,'Commons-Upload');
    w (1,'http://toolserver.org/~daniel/WikiSense/CommonsClash.php?wikilang=de&wikifam=.wikipedia.org&order=img_name&max=200&format=html','C-C',qbtarget,'CommonsClash');

debug=false enthält:

    w (1,'http:
w(1,'http://toolserver.org/~daniel/WikiSense/CommonsClash.php?wikilang=de&wikifam=.wikipedia.org&order=img_name&max=200&format=html','C-C',qbtarget,'CommonsClash');

Wo liegt hier der Fehler? Ich vermute der ResourceLoader-Parser hat hier innen und außen der Anführungszeichen verwechselt. --Fomafix 11:27, 18. Feb. 2011 (CET)

Mit genau diesem Beispiel schon als bugzilla:27528 gemeldet. Die Italiener freuen sich auch über die grandiose Syntax-Kenntnis des verwendeten Javascript-Minimierers. --Schnark 11:36, 18. Feb. 2011 (CET)

Ich vermute, dass der Fehler bereits mit rev:82384 korrigiert ist. Hoffentlich geht das bald live. --Fomafix 13:07, 18. Feb. 2011 (CET)

Der fix sollte wirken.

• Die Benutzer-Zeile, die offenbar den Syntaxfehler ausgelöst hatte (reworkhelper), scheint mit ihren gemischten Anführungszeichen jetzt hoffentlich abgefangen zu werden.
  • Bisher war in der folgenden Zeile das Apostroph noch der vorangegangenen Zeile zugeordnet worden; http:// stand damit nicht auf Zeichenketten-Ebene und die // wurden offenbar als Kommentar-Beginn interpretiert.

Mahlzeit --PerfektesChaos 13:30, 18. Feb. 2011 (CET)

Da gibt noch einige Probleme: rev:82399 --Fomafix 15:14, 18. Feb. 2011 (CET)

Tim hats repariert (rev:82402). — ^PDD — 15:40, 18. Feb. 2011 (CET)

Ich hatte das schon am frühen Morgen bemerkt. Tim hatte sich dem angenommen und ein wenig bei mir rumgespielt [4]. Es konnte auf den Testfall print JavaScriptDistiller::stripWhiteSpace("/**/\n// '/'\n'//'\n") reduziert werden. Das ganze hier nochmal zur Verdeutlichung, weil in den Bugreports, die später kamen, die Entwickler die Ursache nicht nochmal genauer erwähnt haben. Merlissimo 05:12, 19. Feb. 2011 (CET)

UTF?

Ich kann es vorne nicht finden. Hat man irgendwelche Fixes mit der Darstellung der UTF-Zeichen gemacht? Konkret (vermutlich) singhalesisch. Auf der Oldwikisource ist jede Menge von Seiten wie auch Useraccounts, die bislang mit Fragezeichen dargestellt wurden (habe eben kein singhalesisch implementiert), mit komischen größeren Quadraten dargestellt, die jeweil vier kleine Buchstaben enthalten wie OD D4, OD C0 usw. Beispiele: Heutige recent changes, ein user, ein Artikel. Geil, ne? -jkb- 12:23, 20. Feb. 2011 (CET)

Könnte es sein, dass du deinen Browser upgedated hast?

Das Quadrat, in dem vier bzw. fünf Hexcodes für das im Font unbekannte Unicode-Zeichen miniaturisiert dargestellt werden, ist seit langer Zeit eine Hilfestellung durch Firefox. Du kannst dann im Unicode-Block Singhalesisch nachschlagen, was das bedeutet, und dir auch einen kurzen koreanischen oder japanischen Text zusammenreimen.

Dagegen ist ein nichtssagendes Fragezeichen, ◊, ⎕ oder � eher typisch für den IE. Du weißt dann nur, dass dort ein Zeichen steht, dass du nicht lesen kannst, aber nicht welches.

Schönen Sonntag --PerfektesChaos 12:39, 20. Feb. 2011 (CET)

Aha. Vor knapp einer Woche von FF 1... auf FF 3.6... umgestiegen. Klar, danke. -jkb- 12:43, 20. Feb. 2011 (CET)

Kleiner Tipp am Rande: Das war aber sehr überfällig - Version 1.xx ist ja schon uralt. Du bist also ziemlich lange Zeit mit groben Sicherheitslücken unterwegs gewesen. Das nur als persönlichen Tipp. :) Viele Grüße --Saibo (Δ) 16:53, 20. Feb. 2011 (CET)

J. Ich verpasste eben den Zeitpunkt, als man die alte Version noch updaten konnte, danach gab's nur die Möglichkeit, es zu deinstallieren und die neue neu zu installieren. Nun hat aber auf vielen Seiten nicht mehr richtig funktionieren wollen also musste ich... Sonst habe ich natürlich aktuelle Virenwächter, Firewall usw. immer gehabt. Gruß -jkb- 17:00, 20. Feb. 2011 (CET)

Die helfen aber nur bedingt, wenn der Browser löcher hat (durch die man ihn sogar fernsteuern kann).

Außerdem haben neuere Browser-Versionen natürlich auch zahlreiche sinnvolle neue Funktionen (eben diese UTF-Geschichte hier z. B.) und unterstützen auch besser die aktuellen Webstandards. Es ist also schon sinnvoll, immer baldmöglichst auf die jeweils aktuellste Version umzusteigen, auch wenn man dafür manchmal eine Neu-Installation durchführen muss (was jetzt aber kein so besonders großer Aufwand ist). -- Chaddy · D – DÜP – 20:29, 20. Feb. 2011 (CET)

Skript-Anpassungen

Nach dem Update auf 1.17 wurden ja offenbar auch einige lokale Skript-Anpassungen nötig. Da wir in der bairischen Wikipedia (so wies aussieht) niemanden haben, der sich damit auskennt, fände ichs nett, wenn jemand sich Zeit nehmen könnte, und dort die entsprechenden Anpassungen vornehmen könnte (z. B. wär es schön, wenn Funktionsseiten wieder einen blauen Hintergrund hätten). Der zentrale Diskussionsort dort ist der Stammtisch, falls Fragen bzgl. der Anpassungen aufkommen sollten. Schonmal danke im Voraus und ich hoffe, das macht nicht allzu viel Mühe... -- Chaddy · D – DÜP – 22:30, 20. Feb. 2011 (CET)
Ach ja, natürlich gibt es dann Probleme mit den Rechten, da Skripte ja nur von Admins bearbeitet werden können... Ich oder andere dortige Admins werden natürlich dabei helfen. (Wieso kümmert sich eigentlich niemand von den Entwicklern darum, das wär doch eigentlich deren Job...) -- Chaddy · D – DÜP – 22:36, 20. Feb. 2011 (CET)

preload kommt nicht mit gallery zurecht (erl.)

Hier klicken... dann sollte eigentlich das als Text der Iinhalt von Benutzer:Saibo/eigene_Spielwiese/preload ins Editfenster kommen. Statt dessen kommt aber "?UNIQ48072f919fca33e-gallery-00000002-QINU?". Dieser Preload-Text wurde seit Jahren in der Fotowerkstatt benutzt... Habe mir dort als Workaround die gallery-Tags in Vorlagen gepackt: Wikipedia:Fotowerkstatt/preload. Softwarefehler? Viele Grüße --Saibo (Δ) 22:56, 17. Feb. 2011 (CET)

Evtl. das gleiche: Bug 27467 - preload can leave UNIQ (pre-tag im preload text). Viele Grüße --Saibo (Δ) 23:49, 17. Feb. 2011 (CET)

Ist das gleiche, da gallery und pre vom parser ähnlich behandelt werden. Der Umherirrende 18:23, 18. Feb. 2011 (CET)

Der Fix ist seit heute live. Viele Grüße --Saibo (Δ) 22:30, 23. Feb. 2011 (CET)

Automatisches Scrolling beim Bearbeiten im IE8

Guten Abend zusammen, ich mache euch auch mal hier auf diese Diskussion aufmerksam. Wikipedia:Fragen_zur_Wikipedia#Seit_dem_Update_auf_der_Version_1.17_-_Bearbeitungsfenster_spinnt mfg und schönen Abend noch --Crazy1880 20:09, 20. Feb. 2011 (CET)

Sollte inzwischen repariert sein (bugzilla:27496). — ^PDD — 01:21, 22. Feb. 2011 (CET)

Bitte zu beachten, dass in Abschnitt Wikipedia:Fragen_zur_Wikipedia#Seit_dem_Update_auf_der_Version_1.17_-_Bearbeitungsfenster_spinnt noch ein Punkt offen ist, der nirgendwo sonst behandelt wird. Könntet Ihr da bitte mal draufschauen? Grüße --RonaldH 10:17, 24. Feb. 2011 (CET)

Sichten für Nichtsichter

Nach dem letzten Update ist wohl auch der Sichten-Link für alle sichtbar, s. Diskussion darüber auf WP:FzW#Spezial:Letzte Änderungen. -jkb- 07:22, 24. Feb. 2011 (CET)

Job Queue

War die Anzahl der ausstehenden Aufträge nicht mal auf Spezial:Statistik vermerkt? Irgendwie vermisse ich gerade die Anzeige um grob abschätzen zu können, wie lange eine Vorlagenänderung dauert. Ich habe es nur noch über die Api gefunden. Merlissimo 12:21, 24. Feb. 2011 (CET)

Das ist korrekt. Entfernung war beabsichtigt, siehe bugzilla:27584. --Guandalug 12:27, 24. Feb. 2011 (CET)

HTML5

Wie umseitig berichtet, wurde HTML5 wieder deaktiviert, da Twinkle nicht mehr funktioniert. Gerüchteweise basiert Twinkle immer noch auf fehleranfälliges Screenscrapping statt die API zu nutzen. Sind noch mehr Tools dieser Art bekannt? — Raymond ^Disk. 15:04, 24. Feb. 2011 (CET)

Ist das nicht "etwas" veraltet? Meines Wissens arbeitet der Python-Bot inzwischen im Rewrite-Branch mit der API - keine Ahnung, wie viele da noch den alten mit Screenscrapper einsetzen.... --Guandalug 15:06, 24. Feb. 2011 (CET)

Der ArchivBot benutzte immer die index.php. Sebmol hat vor langer Zeit mehrmals gesagt, dass er irgendwann umstellen wollte, aber dann keine Zeit gehabt. Erst vor kurzem gab es dann einen Hinweis in einer Antwort, dass er api-Probleme habe. Was er aber als API bezeichnet war mir nicht ganz klar, weil es bei MW keine Umstellung in dem betroffenen Bereich gab. Falls HTML5 nochmal kommt, sollte man ihn besser drauf hinweisen. Merlissimo 15:18, 24. Feb. 2011 (CET)

Der ArchivBot benutzt index.php "nur" zum Bearbeiten. Das sollte aber unabhängig von HTML5 funktionieren. Oder übersehe ich etwas Offensichtliches? sebmol ^{? !} 19:30, 24. Feb. 2011 (CET)

Könnte weiterhin funktionieren ... solange keiner das Edit-Formular ändert. Gesichert ist das nicht... --Guandalug 21:38, 24. Feb. 2011 (CET)

Seit wann kümmert man sich um Drittanwendungen? Haben die auf en.wp so laut geschriehen, das man auf die hört? Hatten wir in der Vergangenheit sicher auch an der ein oder anderen Stelle gut gebrauchen können. Durch die Entfernung von action=raw bei Spezial:Statistik gibt es auch einige Aufschreie, die scheinen dann nicht laut genug gewesen zu sein, zum Glück. Der Umherirrende 18:11, 24. Feb. 2011 (CET)

Statt action=raw kann man auch die API benutzen. Ich nehme an, ähnliches wird bald auch (wieder) für enWP und Twinkle gelten. HTML5 hatte halt noch weitere Probleme verursacht (zhWP und IE8, wenn ich das richtig lesen - das ist dann schon nicht mehr Drittanwendung). --Guandalug 18:50, 24. Feb. 2011 (CET)

Ja, kann man. Aber einige Dritt-Statistik-Anwendungen die Daten über Wikipedia erheben sind halt mit 1.17 auf die Schnauze gefallen und da hat keiner etwas rückgängig gemacht.

Wenn auf zh.wp Probleme gab, ist das natürlich klar, aber es hörte sich eher so an, das es (hauptsächlich) wegen Twinkle so war. Daher schrieb ich das. Der Umherirrende 19:05, 24. Feb. 2011 (CET)

Ja, das hat Raymond etwas provokant ausgedrückt ;) Sein Revertkommentar umseitig (der vermutlich ein Zitat darstellt) legte die Rangfolge allerdings auf zhWiki, und nebenbei ham sich Twikleuser beschwert ... --Guandalug 19:22, 24. Feb. 2011 (CET)

Ich und provokant? Nie nich... Es hat sich übrigens herausgestellt, dass die Probleme im zhwiki nichts mit HTML5 zu tun haben. Relevante Probleme mit HTML5 werden aktuell unter Bugzilla:27478 gesammelt. Die Cite-Anwendung scheint ein Problemkandidat zu sein. — Raymond ^Disk. 19:43, 24. Feb. 2011 (CET)

So langsam komme ich auch dahinter. Scheint also noch Bug 27672 und Bug 27677 dazu zugehören. Der Umherirrende 20:20, 24. Feb. 2011 (CET)

Warum, um alles in der Welt, versucht ihr, hier einen unfertigen Standard zu berücksichtigen ? Meine Devise: Finger weg von einem noch in der Entwicklung befindlichen Standard! Es können sich z.B. noch Änderungen ergeben, welche Tags welche Attribute und/oder welche Werte haben können. Solange das nicht klar ist, kann jede Berücksichtigung durch spätere Änderungen des Standards zum Unsinn werden. Bitte nicht auf Sand bauen. Außerdem: Welcher Browser soll denn einen noch unfertigen Standard können ? ÅñŧóñŜûŝî (Ð) 21:35, 24. Feb. 2011 (CET)

Was heisst denn hier 'ihr'? Meinst du, wir wollen das? Wir reden hier über eine Änderung, die kommen wird. --Guandalug 21:37, 24. Feb. 2011 (CET)

Ich hatte bisher den Eindruck, dass hier bevorzugt Softwarefreunde dieses Feature kaum erwarten können. Daher "Ihr". Wenn der Eindruck falsch ist, dann habe ich kein Problem, das einzuräumen. Zum Thema: Klar wird sie kommen. Soweit ich gelesen habe, frühestens im Mai. Sobald der Standard als Version publiziert ist, kann und sollte man darauf reagieren, aber nicht vorher. ÅñŧóñŜûŝî (Ð) 18:06, 25. Feb. 2011 (CET)

Mir ist die verwendete HTML-Version herzlich egal. Funktionieren soll es ;) --Guandalug 20:42, 25. Feb. 2011 (CET)

Kackbalken

Hallo! Habe ich das recht in Erinnerung, dass der Kackbalken wieder seine ursprüngliche Farbe erhalten sollte? Gruß --Sir James 18:16, 1. Feb. 2011 (CET)

im monobook hat er ;) ...Sicherlich ^{Post / FB} 18:35, 1. Feb. 2011 (CET)

War und ist bei mir immer hellblau. Das war in modern noch nie anders ;-). Merlissimo 18:42, 1. Feb. 2011 (CET)

ich bild mir ein, dass es in vector anfangs auch kack-farben war :D ...Sicherlich ^{Post / FB} 01:21, 2. Feb. 2011 (CET)

Keine Einbildung, ruhig schlafen heute :-) - es war kackig, und zwar ziemlich lange. -jkb- 01:25, 2. Feb. 2011 (CET)

auf dem weg ins land der träume; vielleicht meinte ja Merlissimo gar nicht das "moderne" vector sondern das eher exotische Modern? - na wie auch immer; ich werd auch ohne antwort auf die frage ruhig schlafen können ^^ ...Sicherlich ^{Post / FB} 01:39, 2. Feb. 2011 (CET)

Du hast es erfasst. War mir noch gar nicht klar, dass dies missverständlich sein kann und sich nicht auf's Modern-Skin beziehen konnte. Merlissimo 01:45, 2. Feb. 2011 (CET)

Sicherlich lässt ausrichten: schnarch, schnarch, ... -jkb- 01:48, 2. Feb. 2011 (CET)

ich schnarche gar nicht! ^^ ...Sicherlich ^{Post / FB} 10:28, 2. Feb. 2011 (CET)

 /* Alte Variante für den Kackbalken */
.usermessage {
	background-color: #ffce7b;
	border-color: #ffa500;
}

Das ist scheinbar nur in de:Wiki so. -- Perhelion 09:25, 2. Feb. 2011 (CET)

Auf de.wp wurde die Änderung vorgezogen. Der Umherirrende 21:29, 3. Feb. 2011 (CET)

Der ist bald wieder kackbraun..... is nicht wahr. Gut dass ich meine CSS-Anpassungen nicht rausgenommen habe :D --Guandalug 15:15, 17. Feb. 2011 (CET)

Nun ist er seit ein paar Tagen -auch ohne Gefummel meinerseits- wieder hübsch kackbraun. Alles wird gut. Danke & Gruß --Sir James 08:23, 24. Feb. 2011 (CET)

Dabei fällt mir ein: wer hat eigentlich das hübsche Wort Kackbalken erfunden? Gruß --Sir James 05:00, 27. Feb. 2011 (CET)

Interwikilinks in Diffs

sind ja bekanntlich nach nem Update für die Gesichteten Versionen unter den Artikel gewandert, statt wie beim normalen Artikelabruf in der Sidebar zu landen. Nun ist mir aufgefallen, dass sie in zahlreichen WP's wieder erfolgreich dort platziert werden, wo sie hingehören: in die Sidebar. (nl, zh, cs, en, fr, es, pt, it, ...) Zum Vergleich: Bei uns nich, pl, ru, ... Was ist der Trick? Können wir das auch? --91.64.234.195 19:48, 24. Feb. 2011 (CET)

Bei de und den anderen Wikis sind FlaggedRevs aktiv. Dabei wird der Artikelinhalt mit Kategorien und Interwikilinks per Ajax-Request nachgeladen. Die Einbindung der Interwikilinks in den Skin ist (noch) nicht umgesetzt. --Fomafix 19:59, 24. Feb. 2011 (CET)

Auch en ist betroffen. Man muss nur einen von en:Special:StablePages nehmen. Der Umherirrende 20:16, 24. Feb. 2011 (CET)

Okay gut, also Eigentor :( Anschlussfrage: Wird irgendwo dran gearbeitet, gibts einen Bug dazu? Wird das erst gefixt, wenn (falls) en:WP irgendwann (flächendeckend) Gesichtete Versionen einführt? --91.64.234.195 20:18, 24. Feb. 2011 (CET)

Warum um Himmels Willen gehört Diff nachladen zur FlaggedRevs-Extension? -- ✓ ^Bergi 14:29, 25. Feb. 2011 (CET)

Weil das in FlaggedRevs implementiert ist, siehe Wikipedia:Projektneuheiten/Archiv/2010-2#24. November. Der Umherirrende 16:33, 25. Feb. 2011 (CET)

Das weiß ich ja, für mich gehört das halt bloß nicht wirklich zusammen (außer dass sich beide mit Versionsverwaltung beschäftigen).

@IP: Bug 26163 kritisierte schon, dass IWs und Kats überhaupt nicht geladen wurden, von daher schon eine Verbesserung. Etwas allgemeiner gehalten ist Bug 26175. Man könnte natürlich auch anregen, Kats und IWs gleich zusammen mit dem Diff zu laden (Hauptgrund war ja schnellere Anzeige dessen durch Verringerung des Übertragungsvolumens). M.W. müsste die Seite auch nicht doppeltes gerendert werden, da das eh eigene Datenbanktabellen sind. -- ✓ ^Bergi 15:52, 26. Feb. 2011 (CET)

Ah, das war eine rhetorische Frage, dann hatte ich das wohl nicht richtig aufgefasst. Ob man so etwas aber auch in Core-MediaWiki haben möchte, ist so die Frage. Man könnte auch den Diff mit Javascript laden, aber ich weiß nicht, ob das etwas bringt (ist bei dem Nachladen ja auch umstritten). Der Umherirrende 16:13, 26. Feb. 2011 (CET)

Zumindest enthält extensions/FlaggedRevs/client/flaggedrevs.js als Kommentar: TODO: move this crap to core or something. --Schnark 09:09, 28. Feb. 2011 (CET)

Eigene CSS

Es wäre besser gewesen, wenn die Dateiliste (Spzialseite) die Benutzer-CSS berücksichtigen würde. Damit könnte man dann die Fehler kompensieren und z.B. gewünschte Spaltenbreiten angeben. Klassen und IDs sind ja bereits vorhanden. ÅñŧóñŜûŝî (Ð) 15:19, 17. Feb. 2011 (CET)

Sorry, ich verstehe gerade nur Bahnhof. Von welchem Benutzer-CSS, welchen Fehlern, redest du? — Raymond ^Disk. 18:55, 17. Feb. 2011 (CET)

Er meint Benutzer:Antonsusi/Common.css (oder dergleichen), um persönlich umformatieren zu können. Meines Wissens funktioniert das auf manchen (?) Spezialseiten - allerdings zum Beispiel nicht auf Spezial:Einstellungen (ist auch besser so). --Guandalug 18:58, 17. Feb. 2011 (CET)

Auf Spezial:Dateien gibt es Benutzer-CSS, aber aufgrund der vielen einzelnen Dateien die heruntergeladen werden, sieht man das erst sehr spät … Die Möglichkeit, die Tabellenspalten einzeln zu formatieren, gibt es aktuell nicht. Der Umherirrende 19:31, 17. Feb. 2011 (CET)

Die td-Elemente (nicht th-Elemente) jeder Spalte haben eigene CSS-Klassen, sodass diese sich einzeln formatieren lassen. --Wiegels „…“ 19:46, 17. Feb. 2011 (CET)

Stimmt, soweit hatte ich garnicht geschaut. Die tr haben sogar ein leeres class-Attribute, sieht ja sehr unsauber aus der HTML-Quelltext. Der Umherirrende 19:58, 17. Feb. 2011 (CET)

Das leere class-Attribut habe ich soeben mit rev:82391 entfernt. Dabei ist mir aufgefallen, dass im Eingabeformular sich zweimal eine Tabelle öffnet. Kümmer ich mich gleich drum. — Raymond ^Disk. 12:26, 18. Feb. 2011 (CET)

Danke. Ist schön, wenn du Sachen auf indirektem Zuruf machst ;-). Der Umherirrende 19:26, 19. Feb. 2011 (CET)

Gerne. Und achja, die doppelte Tabelle in seit gestern Abend wech und heute livegegangen. — Raymond ^Disk. 21:08, 19. Feb. 2011 (CET)

Also ich kann auf Spezial:Dateien keine Berücksichtigung des eigenen CSS feststellen. Auch nicht nach dem Leeren des Cache und mehreren Tagen. Offensichtlich überschreibt die WP-SW bei der Erstellung der Tabelle die Usereinstellungen. Einen Typo würde ich auch ausschließen. ÅñŧóñŜûŝî (Ð) 17:28, 28. Feb. 2011 (CET)

Hallo Antonsusi, ersetze doch mal in Zeile 61 die öffnende Klammer durch ein Komma und trage .TablePager th, .TablePager td { background-color: #FFFFCC; } ein. --Wiegels „…“ 18:09, 28. Feb. 2011 (CET)

Meinst du sowas ? Das hat nicht funktioniert. Ich kann es mir nur durch Skripte erklären. ÅñŧóñŜûŝî (Ð) 18:29, 28. Feb. 2011 (CET)

Zwölf Zeilen vorher (Zeile 61) liegt noch ein Syntaxfehler vor. Vielleicht liegt es daran? --Wiegels „…“ 18:41, 28. Feb. 2011 (CET)

Volltreffer. Das war es. Vier Augen sehen mehr als zwei. Womit auch klar ist, warum das "Zebra" nicht laufen wollte (ich hatte vermutet, dass mein Opera das nicht drauf hat...) Danke. ÅñŧóñŜûŝî (Ð) 19:32, 28. Feb. 2011 (CET)

kbd

Seit dem großen Update ist ja <kbd>...</kbd> erlaubt. Gerade ist mir Translatewiki:MediaWiki:Mwe-embedplayer-fullscreen-tip aufgefallen: Macht es Sinn, die F11 als <kbd>F11</kbd> zu schreiben? Mit oder ohne zusätzlichem <b>...</b>.

Zusatzfrage: Macht es Sinn, in der shared.css ein bestimmtes Style aufzunehmen? — Raymond ^Disk. 23:38, 27. Feb. 2011 (CET)

1. Ich würde jedem Autor zu {{Taste|F11}} → F11 raten.
2. <kbd> kenne ich seit 1995; bei der damaligen Verwendung von HTML hatte es noch Sinn; man warf notfalls einen Blick in den Quellcode. Heute würde ich nichts anderes erwarten als <code> – aber wenn sich jemand die Mühe machen will: Wie wäre es mit blassgrauem Hintergrund und/oder mittelgrauem border, erinnernd an eine Tastatur?

Das Link ist wohl immer noch hi; gute Nacht --PerfektesChaos 00:19, 28. Feb. 2011 (CET)

Nachtrag: Vorlage:Taste ist <kbd> – vielleicht den style für alle kbd so wie jetzt in Taste, und dafür Vorlage:Taste stillos?

--PerfektesChaos 00:24, 28. Feb. 2011 (CET)

kbd enthält nicht nur die Beschriftung der Tasten: http://www.w3.org/TR/html5/text-level-semantics.html#the-kbd-element -- [Fomafix] 08:20, 28. Feb. 2011 (CET)

Sorry, meine Frage war missverständlich formuliert. Sie bezog sich nicht auf die hiesige Wikipedia, sondern auf den MediaWiki-Code und das Translatewiki. Hier lesen viele HTML/CSS-Experten mit und ich erhoffe mir von diesen Vorschläge, ob ich kbd und ein Styling in den MediaWiki-Code aufnehmen soll. — Raymond ^Disk. 08:35, 28. Feb. 2011 (CET)

Guten Morgen; nach drüberschlafen:

… was auf die funktionelle Identität von <kbd> und Vorlage:Taste hinausliefe. In diesem Fall fände ich <kbd> als neues Syntaxelement entbehrlich, ansonsten wäre <kbd> funktionsgleich mit <code> – wie das früher üblich war, Standard ist und auch keine Bereicherung wäre.

Wenn es hingegen einen Unterschied geben soll, Taste für Einzeltasten, <kbd> für das Ausfüllen von Formularfeldern (etwas wie Eingabetext oder so):

KBD { background-color: #DDD;
      border-style: solid;
      border-color: #BBB #888 #888 #BBB;
      border-width: 1px 2px 2px 1px;
      width: 100%;
      padding: 0 1.5em 0 0.4em;
      font-family: monospace;
    }

Früher wurde (selten) <kbd> für shell-Input verwendet und in monospace, aber die Zeiten können sich ja weiterentwickeln und Proportionalschrift mit oder ohne Serifen wäre heute vertrauter.

Zusammengefasst: Einführen nur, wenn es etwas optisch Neues gibt und man das zu brauchen meint.

--PerfektesChaos 09:35, 28. Feb. 2011 (CET)

Und zu den anderen Projekten: Template:Key press ist bereits vertraut und gibt es schon überall; neues semantisches Syntaxelement nur, wenn das Ergebnis auch optisch unterscheidbar dargestellt würde. --PerfektesChaos 09:42, 28. Feb. 2011 (CET)

Der Spezifikation (von Fomafix verlinkt) zufolge müsste die Vorlage:Taste eher ein mehrfach geschachteltes kbd enthalten. Oer der User gibt das äußere kbd von Hand ein, sprich <kbd>{{Taste|shift}}+{{Taste|F3}}</kbd>. Mit dem samp-Element will ich mich jetzt gar nicht rumschlagen… Möglich wäre aber die Vorlage umzuprogrammieren, dass sie mehrere Inputs aufnehmen kann ({{Taste|shift|F3}}). Dann könnte ich mir für kbd [>] kbd { } durchaus ein tastenähnliches Aussehen im Core-CSS vorstellen; vielleicht Taste oder Taste.

Ich verwende bei mir für Buttons und Tasten Styles wie hier zu sehen. Vielleicht gefällt das ja? --Steevie schimpfe hier :-) 20:08, 28. Feb. 2011 (CET)

• Bliebe die ursprüngliche Frage, ob man <kbd> überhaupt im Wikitext möchte.
• Anfang der 1990er wurde HTML viel für IT genutzt, <kbd> und <samp> kamen in HTML2 (RFC 1866 5.7.1.4) und sahen auch nicht anders aus als <tt> und <code>.
• Anfang dieses Jahrtausends hieß es, man solle lieber <code class="example> und <code class="kbd> verwenden, letzteres auch individuell ausdifferenziert als <code class="shell-input> und <code class="form-input>. <kbd> und <samp> sollten langfristig deprecated werden; zuviele und zu spezielle Syntaxelemente. Das ist wie mit unseren Inklusionisten und Exklusionisten.
• Wikis haben drei Möglichkeiten:
  1. class und style in <span> oder <code>.
  2. <kbd>.....</kbd> als zusätzliches Syntaxelement im Wikitext.
  3. Vorlage:Formularfeld plus ggf. Vorlage:Benutzereingabe analog Template:Inputbox – wäre mein persönlicher Favorit, siehe dort für Parameter. Vorlage:Taste mag innerhalb dieses Rahmens auftauchen können, der die Höhe des größten Elements umschließt. Die semantische Information kann innerhalb der Vorlage durch das HTML-<kbd> diskret gegeben werden wie bereits in Vorlage:Taste.
• Ob und welches Wiki all dies benötigt, ist eine andere Frage; Wikipedias sicherlich; auch translatewiki? <kbd> würde semantischen Mehrwert eröffnen; ist der populär?

--PerfektesChaos 09:17, 1. Mär. 2011 (CET)

Unicode-based collation algorithm

• (Konfigurationsänderung) Für die Kategoriensortierung wird nun UCA (Unicode-based collation algorithm) verwendet. Alle Buchstaben werden zuvor in Großbuchstaben konvertiert.

der uca hat einige parameter. welche werden denn hier verwendet? welche auswirkungen hat das auf WP:SORT? --Akkakk 01:44, 9. Mär. 2011 (CET)

InitialiseSettings spricht von Uppercase statt UCA. Der Unterschied:

* Available values are:
 *
 *   - uppercase: Converts the category name to upper case, and sorts by that.
 *
 *   - uca-default: Provides access to the Unicode Collation Algorithm with
 *     the default element table. This is a compromise collation which sorts
 *     all languages in a mediocre way. However, it is better than "uppercase".
 * To use the uca-default collation, you must have PHP's intl extension
 * installed. See http://php.net/manual/en/intl.setup.php . The details of the
 * resulting collation will depend on the version of ICU installed on the
 * server.
 *
 * After you change this, you must run maintenance/updateCollation.php to fix
 * the sort keys in the database.

— Raymond ^Disk. 07:48, 9. Mär. 2011 (CET)

Ist damit zu rechnen, dass man uns in naher Zukunft irgendeinen Algorithmus aktiviert, der ein manuelles Ersetzen von akzentuierten Buchstaben überflüssig macht? Immerhin, uppercase funktioniert wie erwartet und ist auch schon hilfreich, aber das wäre die beste Änderung seit Vector (SCNR). --Schnark 09:44, 9. Mär. 2011 (CET)

Die aktuelle Einstellung soll temporär sein und wird sich nochmal ändern. Auf die Frage, wie lange temporär ist, bekam ich gestern keine Antwort. Merlissimo 11:22, 9. Mär. 2011 (CET)

Also so nach dem Motto: Sobald die Kategorien-Seiten den Inhalt wieder vernünftig anzeigen, ändern wir die Einstellung und lassen das Wartunsskript noch mal drüberlaufen, damit wir den Spaß mit doppelten Buchstaben noch ein weiteres Mal erleben dürfen. Aber ich verstehe doch hoffentlich zumindest richtig, dass uns die Unabhängigkeit von Groß- und Kleinschreibung auch in Zukunft erhalten bleiben wird? --Schnark 11:58, 9. Mär. 2011 (CET)

So ungefähr... Und ich würde mich nicht drauf verlassen ;) --Guandalug 11:59, 9. Mär. 2011 (CET)

Soeben frisch von Roan kommentiert: $wgCategoryCollation is currently set to 'uppercase' on WMF. I couldn't set it to 'uca-default' because the intl extension for PHP isn't installed on our servers. I hear this is not very easy to do until we upgrade the Apaches to lucid, but maybe Tim knows a way around that. I'm also not entirely sure Tim wanted to deploy uca-default WMF-wide; he seemed to indicate that but didn't go into detail. I'll try to get hold of him and ask him about both of those things. . — Raymond ^Disk. 15:07, 9. Mär. 2011 (CET)

SVGEdit

Ist eine Implementierung auch hier irgendwann einmal vorgesehen? --Leyo 11:29, 9. Mär. 2011 (CET)

Es sieht ja nichtmal so aus, als sei das auf commons aktiv. Das soll eine extension sein - die sieht man normalerweise auf Special:Version, da wird SVG nicht erwähnt. Daher... --Guandalug 11:34, 9. Mär. 2011 (CET)

Nun, SVGEdit wurde von Brion geschrieben. Und Brion kommt in Kürze als Angestellter der WMF zurück nach Hause. Ich würde ziemlich große Stücke darauf wetten, dass wir die Extension mittelfristig erhalten, zumindest Commons. — Raymond ^Disk. 14:13, 9. Mär. 2011 (CET)

Danke für die Antworten. Dann kann man ja hoffen… Wie AnonMoos würde ich mich speziell über eine Diff-Funktion freuen. --Leyo 14:23, 9. Mär. 2011 (CET)

Hoffentlich wird es ein brauchbares Tool. Wichtig wäre, dass Quelltexte vor dem Speichern durch den gleichen - mangelhaften - Renderer geschickt werden wie später und man beim Betrachten des Ergebnisses das Speichern noch abbrechen kann und zweitens - im Verhältnis zu Inkscape - weniger Spielerei und mehr Seriösität geboten wird. ÅñŧóñŜûŝî (Ð) 16:45, 9. Mär. 2011 (CET)

8. März

(Livehack) Die Option „Seiten auf meiner Beobachtungsliste“ der Spezialseite Seiten mit ungesichteten Versionen wurde aus Performancegründen per Livepatch abgeschaltet. (Livehack) Die Anzeige, dass es ungesichtete Bearbeitungen auf der Beobachtungsliste gibt, wurde aus Performancegründen per Livepatch abgeschaltet. Also bei mir funktioniert das (wieder?) --PaterMcFly Diskussion ^Beiträge 13:47, 13. Mär. 2011 (CET)

Wurde anscheinend gestern wieder aktiviert. --Steef ³⁸⁹ 14:51, 13. Mär. 2011 (CET)

Exclude me from feature experiments

Könnte das mal bitte jemand übersetzen? Die Option gibts neuerdings in den persönlichen Einstellungen unter Aussehen, Erweiterte Optionen ganz unten. -- Chaddy · D – DÜP – 17:48, 16. Mär. 2011 (CET)

Ach ja, mein Übersetzungsvorschlag lautet übrigens: „Verschone mich von Funktions-Experimenten.“ SCNR -- Chaddy · D – DÜP – 17:52, 16. Mär. 2011 (CET)

:-) -jkb- 17:54, 16. Mär. 2011 (CET)

"Verschone mich von experimentellen Funktionen" ? --Guandalug

Eigentlich heißt "exclude" ja ausnehmen oder ausschließen (verschonen heißt "spare"). ;)

Wörtlich übersetzt wäre allerdings tatsächlich "Funktions-Experimente" richtig. Klingt aber wirklich schlechter als "experimentelle Funktionen".

Also von mir aus kann der Satz "Nehme mich von experimentellen Funktionen aus" heißen.-- Chaddy · D – DÜP – 18:09, 16. Mär. 2011 (CET)

'Verschone' klingt aber besser... und bei dem Leid, was die anrichten.... ;) (Ansonsten weiss ich wohl um die Ungenauigkeit meiner Übersetzung) --Guandalug 18:49, 16. Mär. 2011 (CET)

In dem Zusammenhang vielleicht eher „Erspare mir das Erscheinungsbild betreffende Experimente“. Grüße -- Density 18:53, 16. Mär. 2011 (CET)

Auch nicht schlecht, stimmt. --Guandalug 18:58, 16. Mär. 2011 (CET)

Anderer Vorschlag: „Lass den Scheiß!“ --ireas :disk: :bew: 19:06, 16. Mär. 2011 (CET)

Sachlich: "Experimentelle Funktionen deaktiveren"; Inhatlich: "Überraschende Funktionsänderungen unterdrücken". Merlissimo 19:13, 16. Mär. 2011 (CET)

Aufgrund der vielen Vorschläge habe ich eine neue Variante getetxtet (auch wenn Chaddys erster Vorschlag wohl am passendsten wäre). M.W. geht es dabei durchaus um Experimente mit den Usern, z.B. (zufällig) die angezeigten Interwikilinks nur auf vom Browser akzeptierte Sprachen zu beschränken. Auch dürfte es sich nicht nur ums Erscheinungsbild drehen, sondern auch das Verhalten von Funktionen (insbesondere Wikieditor) ändern. Korrigiert mich wenn ihr anderes vermutet -- ✓ ^Bergi 14:46, 17. Mär. 2011 (CET)

Siehe auch techblog. Der Umherirrende 19:59, 17. Mär. 2011 (CET)

Das ist im Translatewiki bereits übersetzt. Es gibt aber einen komischen Bug bei der Vektor-Extension (nein, damit ist nicht der Skin gemeint), so dass das nächtliche LocalizationUpdate nicht greift. Roan weiß Bescheid und will sich kurzfristig drum kümmern. Bitte nicht lokal übersetzen. Danke. — Raymond ^Disk. 20:34, 16. Mär. 2011 (CET)

Helferlein funktionieren nicht mehr.

Nach einigen Versuchen muss ich feststellen, dass seit gestern die Helferlein (Gadgets): „Bearbeiten-Links Links“, „Bearbeiten-Links Rechts“ nicht mher funktionieren und beim „Vorlagen-Meister“ das Layout total zerschossen ist. Wurde irgendwas an Mediawiki geändert. Evtl. betrifft es auch andere Gadgets. XV HTV 1352 09:31, 24. Mär. 2011 (CET)

Hast du eventuell auf Firefox 4 aktualisiert? Gerüchteweise mag der manche JavaScripts anscheinend nicht mehr.... (ich bin selbst noch nicht zum Testen gekommen) --Guandalug 09:37, 24. Mär. 2011 (CET)

Oh, gut das ich das hier lese :-) -jkb- 09:45, 24. Mär. 2011 (CET)

Das Helferlein Bearbeiten-Links Rechts kannst du eigentlich deaktivieren, offenbar wird mittlerweile auch ohne Gadget der Bearbeiten-Link direkt rechts neben der Überschrift angezeigt. Mit Gadget (ich hatte es bis eben auch aktiviert) wird allerdings seit gestern (?) der Link ohne Leeraum an die Überschrift gesetzt. Gruß --Schniggendiller Diskussion 09:54, 24. Mär. 2011 (CET)

Ich habe zwar auf FF4 aktualisiert, aber bei FF 3.6.13 (anderer Rechner), IE 8, IE 9, Opera 11 und Chrome 10 sieht es genauso aus. Bei mir stehen die Bearbeiten-Links jetzt ganz rechts, egal welche Variante ich wähle. Achja, ich nutze Monobook. XV HTV 1352 09:57, 24. Mär. 2011 (CET)

Okay, das sind ja zum Test wichtige Informationen (auch das mit Monobook). Muss man nachher mal sehen..... --Guandalug 10:02, 24. Mär. 2011 (CET)

Scheint am ResourceLoader zu hakeln, siehe auch FzW bzw. bugzilla:28215 --Guandalug 11:58, 24. Mär. 2011 (CET)

Ja habe ich gesehen. :-( XV HTV 1352 13:17, 24. Mär. 2011 (CET)

Hey, sei froh - dann ist der Bug wenigstens zentral und muss nicht hier an X Stellen lokal repariert werden :D --Guandalug 13:19, 24. Mär. 2011 (CET)

Da hätte ich aber die Hoffnung, dass das Problem zeitnah gelöst wird. XV HTV 1352 16:37, 24. Mär. 2011 (CET)

Wieso führen die Entwickler eigentlich eine so grundlegende Software-Neuheit wie den ResourceLoader ein, ohne ihn vorher mit der neuesten Browser-Generation zu testen (der FF4 war da schon als Beta erhältlich und es war abzusehen, dass er wenige Wochen später final sein würde)? -- Chaddy · D – DÜP – 17:27, 24. Mär. 2011 (CET)

Wie ich oben schon testete hat der FF 4 nix mit dem ResourceLoader zu tun. Es fallen halt zufällig zwei Ereignisse zusammen. XV HTV 1352 18:16, 24. Mär. 2011 (CET)

Ack. Die FF4 - Klamotte ist unabhängig, ein Bugfix für FF4 anzufangen lohnt aber erst, wenn der Ressourceloader wieder tut (damit man nicht an falschen Symptomen rumdoktort) --Guandalug 18:18, 24. Mär. 2011 (CET)

So es klappt alles wieder in FF4 (meinem leib & magen browser). XV HTV 1352 19:51, 24. Mär. 2011 (CET)

Und bei IE 9, GC 10 und O11 auch. XV HTV 1352 19:54, 24. Mär. 2011 (CET)

Dateiupload sperren kaputt?

Moin, ich wollte gerade Datei:Logo.gif vor dem erneuten Upload schützen. Allerdings war im Schutzinterface nur die Auswahlmöglichkeit "Erstellen" vorhanden, nicht wie sonst "Erstellen" und "Hochladen". Ist durch das Update was kaputtgegangen? XenonX3 - (☎:±) 00:57, 25. Feb. 2011 (CET)

Scheint so. Ich habe dazu Bug 27700 aufgemacht. — Raymond ^Disk. 09:17, 25. Feb. 2011 (CET)

Ist noch kaputt! Zwar ist jetzt die Auswahlmöglichkeit wieder da, aber die Einstellung des Hochladeschutzes wird dann nicht übernommen. Beispiele: [5] und [6]. XenonX3 - (☎:±) 22:56, 7. Mär. 2011 (CET)

Hat das jemals funktioniert? Ich bin im Hochladen-Bereich nicht so aktiv, daher meine Frage. Hast du vielleicht einen Dateinamen (hier oder Commons), wo ein solcher Schutz aktiv ist? Danke. Der Umherirrende 21:40, 12. Mär. 2011 (CET)

Mit Bug 28166 (ist auch live) wurde erstmal behoben, das create=sysop beim upload garnicht mehr funktioniert hat. Ich bezweifle immer noch, das upload=sysop auf nicht vorhandenen Seiten früher funktioniert hat, da der Wert garnicht in der Datenbank gespeichert wird bzw. werden kann. Der Umherirrende 18:01, 26. Mär. 2011 (CET)

Hm, lässt sich nicht herausfinden. Geschützte Titel lässt sich nicht so genau filtern und Geschützte Seiten zeigt ja nur existierende Dateien. XenonX3 - (☎:±) 18:05, 26. Mär. 2011 (CET)

Title-Tag bei Links

Seit Version 1.17 wird als „Bugfix“ das Title-Tag eines Links nicht mehr ausgefüllt, wenn Linkziel und Linktext identisch sind. Ich bin kein Freund dieser Änderung, weil sie meiner Meinung nach zu Inkonsistenzen in der Benutzerführung führt (es gibt unterschiedliche Resultate, wenn man die gleiche Aktion „führe Maus über Link“ durchführt). Dennoch möchte ich auf einen Fehler in diesem Bugfix hinweisen: Wenn der Link mit der class="stub" ausgeliefert wird, wird generell auch das Title-Tag gesetzt. Falls er noch nicht im Bugtracker vermerkt ist, bitte ich um eine dortige Meldung. --32X 13:58, 16. Apr. 2011 (CEST)

Bug 27527 gibts bereits. -- ✓ ^Bergi 22:30, 16. Apr. 2011 (CEST)

Extra-Editbuttons

Gibt es jemand, der die Aufrufreihenfolge – insbesondere im Zusammenhang mit Gadgets – so gut verstanden hat, dass er bestätigen oder verneinen kann, dass rev:86603 das MediaWiki:Gadget-Extra-Editbuttons.js unrettbar kaputt macht? --Schnark 09:14, 23. Apr. 2011 (CEST)

Ja und ja. In meiner vorherigen Antwort bezog ich mich nicht auf rev:86603, das hatte ich überlesen. Jetzt habe ich Bug 28681 angelegt. -- ✓ ^Bergi 16:05, 24. Apr. 2011 (CEST)

Das Problem wurde mit rev:86942 behoben. — Raymond ^Disk. 17:49, 26. Apr. 2011 (CEST)

Sicher? Damit das Gadget etwas an den Buttons verändern kann, muss es dies vor dem jQuery-ready-Event tun, andererseits muss es warten, bis die monobook.js/… des Benutzers geladen ist, um zu wissen, was es genau tun soll. Das ist – wenn überhaupt – ein sehr schmaler Zeitraum, bei dem ich mir nicht einmal sicher bin, dass man ihn überhaupt mit irgendeiner Methode sicher treffen kann. --Schnark 09:34, 28. Apr. 2011 (CEST)

Jein. Ich habe mal translatewiki:MediaWiki:Gadget-editbuttons.js erstellt (dort darf man als normaler Benutzer Systemnachrichten bearbeiten :-), du kannst es in den Einstellungen aktivieren und testen. Bei mir funktionierts, ich habe versucht alle Funktionalität aufrecht zu erhalten (und Kaputtgegangenes zu reparieren).

Allerdings arbeitet das Gadget folgendermaßen:

1. das inline-Skript fügt per addButton die Standardbuttons hinzu
2. mw.toolbar.buttons wird vom Gadget wieder geleert (und gespeichert)
3. der onready-init fügt keine Buttons in die Toolbar ein, es seie denn ein Userscript setzt mwCustomEditButtons
4. der Gadget-Listener wird aktiv, wertet die Config aus, füllt mw.toolbar.buttons und löst einfach nochmal mw.toolbar.init aus.

Die im Bug geforderte onloadHook Funktionalität bzw. das ans-Ende-Schieben des Einfügens gabs leider nicht.
meint -- ✓ ^Bergi 13:46, 29. Apr. 2011 (CEST)

Hübsch! Insbesondere kann man jetzt sogar den Code verstehen, der die vom Benutzer unerwünschten Buttons entfernt. Wenn du jetzt noch das indexOf durch $.inArray ersetzt, sollte es sogar im IE 7 funktionieren. --Schnark 09:16, 30. Apr. 2011 (CEST)

Ja, das davor war anscheinend eine selbstimplementierte splice-Methode mit ständigem Nach-Vorne-Sortieren. $.inArray ist eingebaut, das Tabellen-Popup funktioniert auch wieder. Nimmt das eigentlich keiner her oder warum ist das auf de noch nicht lokalisiert? -- ✓ ^Bergi 18:51, 30. Apr. 2011 (CEST)

Unterschied zwischen Versionen

Gab es heute ein Update der Vorschau "Unterschied zwischen Versionen" einer Seite? Der Diff-Abschnitt sieht jetzt in Schriftgrad und Formatierung völlig anders und unübersichtlich aus. -- Der Tom 09:47, 5. Mai 2011 (CEST)

Weiter gehts unter "Fragen zu Wikipedia. --Der Tom 12:22, 5. Mai 2011 (CEST)

Weiter gehts unter "Fragen zu Wikipedia. ?? Hallo Tom, meine obere Bearbeitungswerkzeugleiste über dem Textfeld im Bearbeitungsfenster ist bei mir nicht mehr vorhanden !? Woran liegt das ??? Gruß vom Elkawe

Einstellungen korrigieren und Cache neu laden. -- ✓ ^Bergi 13:18, 5. Mai 2011 (CEST)

danke für die Antwort, allerdings durch Einstellungen durchsehen und jeweils speichern, will es leider nicht klappen. Was müsste ich denn eventuell korrigieren ? (schreibt der Elkawe)

Bei mir ist die Leiste auch oft verschwunden, wenn ich aber oft genug auf Aktualisieren gehe (natürlich vor dem Post ;-)), kommt die Leiste irgendwann. Die zu korrigierenden Einstellungen weiß ich auch nicht, jedenfalls erscheint unten links der Fehlerbutton. Nervig... --Der Tom 16:53, 5. Mai 2011 (CEST)

Was denn für ein Fehlerbutton? Wessen Browsers oder auf der Seite?

Die Bearbeitungs-Einstellungen wären „⧼tog-showtoolbar⧽“ zu aktivieren und die beiden „⧼prefs-beta⧽“ (insb. „Bearbeiten-Werkzeugleiste aktivieren“) zu deaktivieren. -- ✓ ^Bergi 17:51, 5. Mai 2011 (CEST)

Neuerungen?

Hallo zusammen, gab es irgendwie wieder Neuerungen?

1. "Größe der Seite bzw. des bearbeiteten Abschnitts" wird jetzt immer angezeigt
2. "Beim Sichten auf rückgängig" kann man jetzt auch zur Diskussionsseite kommen.
3. "<gadget-section-Bearbeitungswerkzeuge>" steht jetzt zudem in den eigenen Einstellungen unter "Helferlein"

Gab es da irgendetwas? mfg --Crazy1880 11:20, 9. Mai 2011 (CEST)

Hallo,

1. basiert auf diesen Wunsch

2. kann ich gerade nicht nachvollziehen

3. hängt vermutlich mit einem Fehler im Cache der Systemtexte zusammen, in Variation heute bereits gemeldet. Das gab es letzte Woche auch schon einmal. — Raymond ^Disk. 11:41, 9. Mai 2011 (CEST)

Arbeiten die Entwickler eigentlich schon an dem Cache-Problem bzw. gibts da schon irgendwelche Erklärungen im Techblog etc? Dass Nutzer Systemnachrichten purgen müssen um ein funktionierendes System zu bekommen darf nicht vorkommen. -- ✓ ^Bergi 12:45, 9. Mai 2011 (CEST)

Erklärung gibt es bisher keine. Letzte Woche schien es ein kaputter Server zu sein. Ich habe soeben im techchat nachgefragt. — Raymond ^Disk. 12:59, 9. Mai 2011 (CEST)

Scheint als Bug 28892 notiert zu sein. Ursache und Lösung aktuell noch unbekannt. Der Umherirrende 20:25, 9. Mai 2011 (CEST)

Automatische Links

Seit wann gibt es denn die automatischen Weblinks im Text?? -- Perhelion 23:25, 9. Mai 2011 (CEST)

Seitdem du irgendein Addon installiert haben musst. Ich hatte das letztens auch mal, das war dann eine Zusatzfunktion eines Firefox-Addons. Mir fällt leider nicht mehr ein, welches es war. XenonX3 - (☎:±) 23:51, 9. Mai 2011 (CEST)

Oha, das wäre einfach, ich habe nur 3 Addons (Plugins nur Flash)

• Deutsches Wörterbuch für Ispell, Myspell und Hunspell nach den neuen Rechtschreibregeln
• Adblock Plus
• NoScript

Die sollten dafür eigentlich nicht in Frage kommen, hier ein Bsp. (UserScript kann es auch nicht sein): in RFC 4944 festgelegt. Um genau zu sein, ist der Weblink auch im IE(9 unangemeldet) -- Perhelion 00:01, 10. Mai 2011 (CEST)

Hmm, tritt das in allen Artikeln auf? Und wenn nicht, hast du mal einen Artikel, wo es auftritt? XenonX3 - (☎:±) 00:08, 10. Mai 2011 (CEST)

Jap 6LoWPAN

Das wird dann wie bei den ISBN-Nummern irgendwo in Mediawiki eingebaut sein, ich weiß aber nicht, ob und wie man das beeinflussen kann. XenonX3 - (☎:±) 00:49, 10. Mai 2011 (CEST)

ein <nowiki />, zum beispiel zwischen RFC/ISBN und der zahl hilft. --Akkakk 01:06, 10. Mai 2011 (CEST)

Ihr diskutiert hier nicht zufälllig über die drei Magic Words ISBN, RFC und PMID? Sie sind in Hilfe:Variablen #Magic Words erläutert und die RFC-Verlinkung existiert seit knapp zehn Jahren (die Original-Entwickler unserer Software wollten direkten Zugriff auf die RFC). Das <nowiki /> in 6LoWPAN zwischen RFC und 4944 ist gaga; natürlich soll es an der Stelle ein Link auf RFC 4944 geben. --PerfektesChaos 08:01, 10. Mai 2011 (CEST)

Oh doch so einfach Vorlage:Smiley/Wartung/xd , dank (und sorry) -- Perhelion 12:45, 10. Mai 2011 (CEST)

Höhenangabe bei kleinen SVGs

Wenn man SVGs deren Basisgröße kleiner ist als die angegebene Höhe (zB [[Datei:AB-AS.svg|x30px]]: ) werden diese nicht vergrößert, alle anderen Varianten ([[Datei:AB-AS.svg|30px]]: und [[Datei:AB-AS.svg|30x30px]]: ) funktionieren einwandfrei. Vielleicht täusche ich mich, aber denke das hat bis vor kurzem funktioniert... Sind euch Konfigurationsänderungen bekannt? LG --AleXXw •שלום!•disk 20:38, 11. Mai 2011 (CEST)

Bug 28940. -- ✓ ^Bergi 21:35, 11. Mai 2011 (CEST)

Danke! --AleXXw •שלום!•disk 21:36, 11. Mai 2011 (CEST)

notiz am rande ...

hmm:

„Der täglich erstellte Dump der Trunk-Version enthält jetzt auch das i18n-Unterverzeichnis mit den Übersetzungen der Botkommentare aus translatewiki. Die zunächst für die Rewrite-Branch eingeführte Auslagerung der Kommentare aus den Bot-Scripten sind damit auch für eine Reihe von Botscripten der Trunk-Version über den Dump des Frameworks verfügbar.“

also wenn man mit dem satz zu geißler in die schlichtung gekommen wäre ... ;-) —Pill (Kontakt) 21:40, 22. Mai 2011 (CEST)

(Softwareverschlechterung) Auf WMF-Wikis können die Benutzerbeiträge nicht länger nach Namensräume gefiltert werden

Das ist doch hoffentlich bloß ein verspäteter April-Scherz, oder? -- Chaddy · D – DÜP – 21:17, 14. Mai 2011 (CEST)

Mit monobook nicht nachvollziehbar. Erst Vorder- und danach Rückseite lesen... --Steef ³⁸⁹ 21:49, 14. Mai 2011 (CEST)

Diese Änderung ist noch nicht live. --Stepro 21:53, 14. Mai 2011 (CEST)

Das ist allerdings in der Tat ein sehr schlechter Scherz. Kann man diesen Unfug noch irgendwie stoppen oder zumindest eine nachvollziehbare Erklärung für die Funktionseinschränkung nachlesen? --Stepro 21:53, 14. Mai 2011 (CEST)

Sieht nach einem Performance-Problem aus. Mal schaun ob Raymond etwas erreicht. --Steef ³⁸⁹ 22:32, 14. Mai 2011 (CEST)

Langsam kann mans mit den Performance-Problemen auch etwas übertreiben. Dass eher unbedeutende Spezialseiten deswegen nicht mehr aktualisiert werden ist ja noch verschmerzbar, aber das hier geht jetzt zu weit. Wo fließen denn die ganzen Spenden-Gelder hin, die doch eigentlich auch für die Verbesserung der Server-Hardware verwendet werden sollen? Und wo kann man dagegen Protest einlegen? -- Chaddy · D – DÜP – 22:49, 14. Mai 2011 (CEST)

Gibt es hier jetzt neues? -- Chaddy · D – DÜP – 22:50, 26. Mai 2011 (CEST)

FF-Update

Da hier ja eher die techn. Experten sind, mal der Hinweis auf meine Frage auf FzW. Vielleicht weiß ja jemand von Euch eine Lösung. --Stepro 13:08, 27. Mai 2011 (CEST)

GeSHi

Hallo, eine Frage zum Update: Was ist denn der Unterschied (beim Highlighten) zwischen ecmascript und javascript? -- ✓ ^Bergi 20:36, 14. Mai 2011 (CEST)

Der einleitende Kommentar in [7] sollte dir weiterhelfen, der Diff zu [8] zeigt, dass Selected colors to match my web site color chart der Hauptunterschied ist. --Schnark 11:16, 28. Mai 2011 (CEST)

Neue Werkstatt zum Thema CSS+JS

Hallo,
weil hier vermutlich viele „Skriptbastler“ (wie Raymond sie liebevoll zu titulieren pflegt) mitlesen:
Eine neue Werkstatt zum Thema CSS+JS wird demnächst eröffnet: Wikipedia:Technik: Skin/Werkstatt.
Eine Mitarbeiterliste gibt es nicht; einfach beobachten. Wer eine Anfrage sieht und dabei helfen mag und kann, möge dies tun.
--PerfektesChaos 09:19, 1. Jul. 2011 (CEST)

Vorschau auf Version 1.19: (Softwareneuheit) Automatisch vergebene Benutzerrechte werden jetzt im Rechte-Logbuch aufgeführt

Das ham wir ja schon mit den automatisch vergebenen Sichterrechten. Oder wird es bald Logbucheinträge für Autoconfirmed-Vergabe geben? XenonX3 - (☎:✉) 18:04, 15. Jul. 2011 (CEST)

Gibt es das schon für automatisch vergebene Sichterrechte? Ist mir noch nicht untergekommen und ich dachte, es ist vor allem dafür da (weil es ein und derselbe Entwickler ist). Es dürfte aber danach auch für autoconfirmed-Vergabe einen Logeintrag erzeugen. Dies ist hier vielleicht nicht so wichtig, weil man die 4 Tage noch selber ausrechnen kann, aber auf en.wp muss man beispielsweise auch noch 10 (sichtbare?) Bearbeitungen getätigt haben, da kann es schon helfen, glaube ich. Der Umherirrende 18:30, 15. Jul. 2011 (CEST)

Gibt es das schon für automatisch vergebene Sichterrechte? → [9]. Keine Ahnung seit wann, aber ja ;) XenonX3 - (☎:✉) 18:42, 15. Jul. 2011 (CEST)

Ah, da ist die Meldung nicht eindeutig genug. Die Benutzergruppe "Sichter" ist eine Benutzergruppe die Benutzer an andere oder automatisch an sich vergeben können. Ja, die sind auch jetzt schon geloggt, hatte ich nur nicht dran gedacht. Ich hatte an die Benutzergruppe "Automatische Sichter" gedacht, da dieses, wie die Benutzergruppe "automatisch bestätigter Benutzer", eine Benutzergruppe ist, die nur von der Software vergeben (und auch wieder entzogen) wird. Die Meldung hier bezieht sich genau auf solche Benutzergruppen, die intern auch implizite Benutzergruppen genannt werden. Für solche Benutzergruppen gibt es auch keine Mitgliederlisten unter Spezial:Benutzer. Ich habe gerade nur keine Idee, wie man das besser beschreiben kann, aber Raymond (oder ein anderer) ist da vermutlicher kreativer und kann vielleicht auch sagen, ob ich das richtig aufgefasst habe, oder nicht. Der Umherirrende 18:54, 15. Jul. 2011 (CEST)

Wenn ich es jetzt richtig verstanden habe, müsste es "Automatisch vergebene implizite Benutzerrechte werden jetzt im Rechte-Logbuch aufgeführt" heißen? XenonX3 - (☎:✉) 12:57, 18. Jul. 2011 (CEST)

Ja, so habe ich das verstanden. Wäre aber gut, wenn Raymond oder jemand anders das kurz bestätigen könnte. Schau ich mir am Wochenende ansonsten mal genauer an. Der Umherirrende 20:14, 18. Jul. 2011 (CEST)

Müsste es nicht eher "Automatisch vergebene implizite Benutzergruppen" heißen? --Schnark 09:34, 19. Jul. 2011 (CEST)

Die Formulierungen sind alle nicht ganz sauber. Eigentlich werden weder Benutzergruppen noch Rechte vergeben, sondern ein Benutzerkonto wird einer Benutzergruppe (Sichter, Admins, etc.) zugeteilt. Im Jargon wird es nur Benutzerrechte vergeben genannt. XenonX3 - (☎:✉) 14:14, 19. Jul. 2011 (CEST)

Ich kann erstmal sagen, das es keine Flutung der Logs/RC mit autoconfirmed gibt, ist aber möglich, wenn gewünscht. Aktuell stehen die Informationen für "autoconfirmed" (und eventuell weitere) in der Variable $wgAutopromote. In Zukunft gibt es auch noch die Variable $wgAutopromoteOnce. Die dort enthaltenden Benutzergruppen werden maximal einmal vergeben und enthalten dann einen Logbucheintrag und optional einen RC-Eintrag. Dies hat den Vorteil, das beispielsweise Extensions wie FlaggedRevs einen Logbucheintrag für automatische Sichter erstellen können. Dann kann jeder sehen, das dieser Benutzer der impliziten Benutzergruppe angehört oder nicht. Ich habe die Vorderseite entsprechend angepasst und hoffe, dass es jetzt verständlicher ist. Der Umherirrende 21:39, 23. Jul. 2011 (CEST)

Angedrohte Umstellung Secure-Server

Für die vorgesehene Umstellung könnte vielleicht irgendwo gesammelt werden, was am Tag X getan werden muss oder was bereits jetzt vorbereitend in Ruhe angegangen werden kann.

Mir fiel grad auf:

• Vorbeugende Ergänzung von MediaWiki:Common.css

    div#content a.external[href^="https://de.wikipedia.org"],
    #mw_content a.external[href^="https://de.wikipedia.org"],

und Entfernung von secure.wikimedia nach einigen Wochen robuster Einführung.

VG --PerfektesChaos 14:26, 20. Jul. 2011 (CEST)

Der Abschnitt "Stay on the secure server as much as possible" in MediaWiki:Common.js entfällt nach der Umstellung komplett, kann aber während der Umstellungsphase unverändert drin bleiben, da er einfach nicht mehr aktiv wird.

Im Abschnitt "Lokaler Bilddiskussionsseitenlink eines Commonsbildes verweist nach Commons" wird eine https-URL von Commons genutzt. Diese müsste dann geändert werden. Hier kann vielleicht auch kompatibler Code eingebaut werden, müsste mal jemand drüber nachdenken. Der Umherirrende 21:00, 23. Jul. 2011 (CEST)

Anmeldeversuche mit falschem Passwort

Hallo zusammen, zum heutigen Update wären mehr Antworten sinnvoll. Wie oft darf man sich falsch anmelden und wie lange ist die Wartezeit. Gibt es eine völlige Sperre? Und diese Antworten sollten wir dann verpacken und in Hilfe:Benutzerkonto anlegen (weiterleitung von Hilfe:Anmeldung) einbauen. Vielen Dank für die Antworten --Crazy1880 14:28, 23. Jul. 2011 (CEST)

Das wird anscheinend über die Variable $wgPasswordAttemptThrottle festgelegt. Ob die auf WMF überhaupt aktiviert ist weiß ich nicht, auf http://noc.wikimedia.org/ hab ich dazu nichts gefunden. --✓ ^Bergi 18:16, 23. Jul. 2011 (CEST)

Für API-Logins (also unsere Bots) gilt das aber schon länger, da sagt die API auch, wie lange man jetzt warten soll. Ist eine mit der Anzahl der Fehlversuche steigende Zeit. --Guandalug 18:30, 23. Jul. 2011 (CEST)

Der Standard laut mw:Manual:$wgPasswordAttemptThrottle ist 5 Versuche in 5 Minuten, da der Standard auf WMF-Wikis anscheind nicht überschrieben wird, scheint es auch hier erstmal so zu sein. Der Umherirrende 19:28, 23. Jul. 2011 (CEST)

Ich habe es mal korrigiert, es betrifft nur Spezial:Passwort ändern. Spezial:Anmelden war vorher schon so. Vielleicht sollte man aber hier noch eine andere Nachricht verwenden, aber das nur nebenbei. Der Umherirrende 19:38, 23. Jul. 2011 (CEST)

Mobile View

Was genau hat sich denn da geändert? Zurzeit wirkt das wie ein Proxy fürs alte Format, und das es jetzt in PHP geschrieben ist interessiert doch den Anwender einen Dreck. Und ein echtes Beispiel :-) Wobei das hier aber geht. --✓ ^Bergi 17:21, 31. Jul. 2011 (CEST)

Das eine wurde als Mobile Ansicht und das andere als Mobile Version übersetzt ;-) Ich denke mal, es war erstmal das Ziel ein gleichwertige Oberfläche zu schaffen und dann kann man sich anschließend um Verbesserungen kümmern. Vielleicht skaliert die neue Version auch besser, so dass weniger Serverlast verursacht wird oder sie ist besser wartbar. Die Gründe für eine Neu-Implementierung könnten man noch aufzeigen. Aber im neuen habe ich erstmal einen JavaScript-Fehler (IE8). Der Umherirrende 17:30, 31. Jul. 2011 (CEST)

Naja, besser wartbar ist sie auf alle Fälle da die Entwickler eher PHP verstehen und korrigieren könnnen… Ich hätte nur gehofft, dass mit der Neuimplementierung von Null angefangen wird und die Altlasten entsorgt statt portiert werden :-( --✓ ^Bergi 17:39, 31. Jul. 2011 (CEST)

Das Recht, Dateien zu verschieben, wurde normalen Benutzern gegeben - betrifft uns nicht, oder?

Versionsvergleich Das Recht, Dateien zu verschieben, wurde normalen Benutzern gegeben (Bug 27132, rev:93871).

So wie ich das verstehe, betrifft das wohl nur die Defaultsettings von Mediawiki, oder? Die werden ja wohl bei unserern Installationen hoffentlich nicht angewandt - sonst könnte plötzlich jeder Benutzer Dateien herumschieben, was ja offensichtlich (restriktive Vergabe des Benutzerrechts in Commons) nicht gewollt ist. Viele Grüße --Saibo (Δ) 21:25, 14. Aug. 2011 (CEST)

Ich sehe keinerlei Probleme darin, dieses Recht allen Benutzern zu geben. Artikel können auch von jedem (4 Tage nach der Anmeldung) verschoben werden. Ich wüsste nicht, wieso bei Dateien anders verfahren werden sollte. -- Chaddy · D – DÜP – 00:36, 15. Aug. 2011 (CEST)

Ich sehe Probleme. Gegenfrage: Was spricht gegen die Nutzung von Vorlage:Datei umbenennen? --Leyo 00:43, 15. Aug. 2011 (CEST)

Arbeitsentlastung für die Admins und das Wikiprnzip sprechen dafür, die Verschiebefunktion für alle zugänglich zu machen. Missbrauchen kann man auch andere Rechte (z. B. das Verschieben von Artikeln), das darf kein Argument sein, das Wikiprinzip (eines der wichtigsten Grundprinzipien) zu beschneiden.

Die Vorlage ist nur ein Notbehelf, da die Funktion bislang ja nur Admins haben. Die Vorlage wird man aber natürlich auch in Zukunft brauchen, da Admins und ganz frische Nutzer ja nicht verschieben können (wenn die Kritieren dieselben sind wie bei Artikelverschiebungen).

Und welche Probleme siehst du? -- Chaddy · D – DÜP – 00:48, 15. Aug. 2011 (CEST)

Wenn es keine Probleme gäbe, wieso ist es in Commons dann so, dass die Rechte nicht jedem gegeben werden? Ein Problem, was ich sehe, ist dass bei Verfügbarkeit für fast alle es wohl eher zu "den Name finde ich so ein wenig besser"-Verschiebungen kommt. Ansonsten eben das Problem, dass externe Verlinkungen von Thumbs brechen (natürlich deutlich weniger ein Problem als auf Commons). Dateieinbindungen per Redir in Artikel gehen zwar, sind aber verwirrend (beim Mouseover über den Thumb kommt ein anderer Name, als im Quelltext steht) und nicht jeder wird die Einbindungen ändern. Und wenn, dann sind es fast unnötige Edits in Artikeln die Beos & Co. belasten. Nundenn - es sind zugegebenermaßen wirklich keine großen Probleme - aber ebenso stellt sich halt auch die Frage, was es bringt diese Nachteile auf sich zu nehmen. Viele Grüße --Saibo (Δ) 02:53, 15. Aug. 2011 (CEST)

@Chaddy: Wir brauchen das Recht in der DE-WP schlicht nicht, weil der Bedarf an Dateiverschiebungen hier sehr gering ist. Unter den letzten 5000 Verschiebungen waren gerade mal 61 Dateiverschiebungen. Das sind 0,01%. Das kriegen die Admins problemlos bewältigt. Ich würde sogar so weit gehen zu behaupten, dass die Dateiverschiebungen den wenigsten Aufwand unter den Adminaufgaben machen. XenonX3 - (☎:✉) 18:31, 15. Aug. 2011 (CEST)

Und das rechtfertigt die Untergrabung des Wiki-Prinzips? -- Chaddy · D – DÜP – 19:30, 15. Aug. 2011 (CEST)

Ich hatte gestern mal gefragt und nach der Auskunft sollen sich die Einstellungen nicht ändern, siehe rev:93871#c20783. Der Umherirrende 17:50, 15. Aug. 2011 (CEST)

@XenonX3, räusper, 61 Dateiverschiebungen von in Summe 5000 macht einen Prozentsatz von 1,22% aus.
Wobei ich sonst zustimme: Bis auf die wenigen Dateigruppen die auf de-wp verbleiben sollten (Logos, etc..) besteht auf commons die Option, bei Bedarf das Filemove-Flag setzen zu lassen um dann in Folge selbst Dateien verschieben zu können - aus meiner Erfahrung wird diese Funktion allerdings wirklich nur sehr selten benötigt, da die zulässigen Verschiebegründe auch stark limitiert sind. - also man könnte auch sehr gut ohne leben und das nur mit Vorlagen erledigen.--wdwd 20:23, 15. Aug. 2011 (CEST)

Huch, was hab ich denn da gerechnet? XenonX3 - (☎:✉) 20:29, 15. Aug. 2011 (CEST)

×100 vergessen. Viele Grüße --Saibo (Δ) 03:42, 16. Aug. 2011 (CEST)

@Chaddy: Ist denn durch Angemeldeter Benutzer, Autoconfirmed, Sichterrecht, Adminrecht das reine Wikiprinzip nicht schon deutlich "untergraben"? Im reinen Wikiprinzip dürfte ja wohl jeder alles. Ich weiß ja nicht... Wie auch immer - die Softwareänderung wird für uns nichts ändern. Chaddy, wenn du eine Ausweitung des Filemove-Rechts gerne haben möchtest, dann wohl über MB/wasauchimmer. Viele Grüße --Saibo (Δ) 03:42, 16. Aug. 2011 (CEST)

Wikianarchie wär auch lustig, ja...^^

Sensible Funktionen wie Artikel löschen, Benutzer sperren usw. sind schon zu Recht nicht für alle verfügbar. Das wär dann doch etwas zu viel des Guten. Aber Dateien verschieben ist jetzt nichts sonderlich sensibles... -- Chaddy · D – DÜP – 04:09, 16. Aug. 2011 (CEST)

Vorschau auf Version 1.19

Umseitig heißt es im Abschnitt #Vorschau auf Version 1.19 „Mit rev:92477/rev:92476 wurde der Entwicklungszweig für Version 1.18 erstellt“. Sollte da nicht 1.19 stehen? (Die Links habe ich angeklickt, werde aber auch nicht schlau daraus ...). Gruß --Schniggendiller Diskussion 14:45, 20. Aug. 2011 (CEST)

Nein, es darf nicht 1.19 heißen, man könnte den Satz aber vermutlich umschreiben.

Hintergrund: Mit rev:92477/rev:92476 wurde der aktuelle Software-Stand kopiert und als Version 1.18 bezeichnet. Dieses kopieren dient dazu, auf einer sehr stabilen Basis die abschließenden Tests durchzuführen und die Fehler einzeln zu beheben, um dann anschließend das gesamte Paket zur Verfügung zu stellen. Durch das Erstellen von 1.18 (der Kopie) sind weiteren Änderungen an MediaWiki dort nicht mehr enthalten, sie kommen voraussichtlich mit 1.19, daher ein neuer Abschnitt auf der Seite. Natürlich ist es immer noch möglich etwas in 1.18 zu ändern, beispielsweise die Fehlerbehebungen oder wichtiger Ergänzungen etc. Raymond hat das aber alles im Blick und kopiert die Abschnitte entsprechend. Der Umherirrende 19:59, 24. Aug. 2011 (CEST)

Diskussionen bei Redlinks

Die wurden verändert, &section=new wurde angehängt. -- ianusius ✆ Disk. ✪ (Art.) 09:00, 26. Aug. 2011 (CEST)

Das ist eine lokale Anpassung die schon länger aktiv ist. Sie soll dazu beitragen, das auf nicht existierenden Diskussionsseiten im Artikelnamensraum der erste Abschnitt auch mit einer Überschrift begonnen wird, damit man später einen besseren Überblick hat. Der Umherirrende 15:54, 26. Aug. 2011 (CEST)

Okay, danke. Hatte ich noch nie bemerkt … -- ianusius ✆ Disk. ✪ (Art.) 10:59, 27. Aug. 2011 (CEST)

Blauer Spezialseitenlink

Ich hätte da mal eine Frage, weil ich nicht selber drauf komme: Warum ist der erste Link bereits blau, obwohl er nicht funktioniert? Es sollten doch nur existierende Seiten einen blauen Link bekommen, soweit ich weiß sollte das auch bei Spezialseiten so sein.

• Spezial:Permanenter Link
• Spezial:Permalink

Wird hier der Name der Spezialseite mit dem Inhalt von MediaWiki:Permalink verwechselt? Wenn jemand Ideen hat, wäre ich dankbar. Der Umherirrende 21:11, 7. Sep. 2011 (CEST)

MessagesDe.php kennt den Alias schon, warum auch immer. --Schnark 10:29, 8. Sep. 2011 (CEST)

Das erklärt einiges und war von mir garnicht erwartet, da ich dachte, dass der Alias erst vor einer Woche vergeben wurde. Aber im Dezember 2010, war er auch schonmal gesetzt worden und wurde später komplett überschrieben, was mir nicht aufgefallen war. Danke für deine Hilfe. Der Umherirrende 18:13, 8. Sep. 2011 (CEST)

Nur damit sicher keiner wundert, warum das jetzt nicht mehr blau ist: Es wurde mit rev:96617 korrigiert. Der Umherirrende 21:20, 9. Sep. 2011 (CEST)

rev:82511

Haltet ihr das für nennenswert und wenn ja, hat jemand einen guten Satz, den man auf die Vorderseite schreiben kann? Man sollte dann auch erwähnen, das sich solche Fälle erst mit einem Purge oder einer Bearbeitung beheben werden. Siehe auch Wikipedia:Fragen zur Wikipedia#Dunkelrote Links im Artikel. Danke. Der Umherirrende 19:44, 14. Sep. 2011 (CEST)

Tabellensortierung in 1.18

Hält es jemand für meldenswert, dass das Beispiel Hilfe:Tabellen für Fortgeschrittene#Eine beliebige Zeile nicht sortieren in http://test2.wikipedia.org/ nicht mehr funktioniert? Auf m:Help:Sorting finde ich keine Dokumentation, dass das funktionieren soll, außerdem kann ich mir keine sinnvolle Anwendung vorstellen. --Schnark 12:11, 20. Sep. 2011 (CEST)

Was ich mir als Anwendung vorstellen könnte wäre eine Wiederholung der Überschriftszeile bei sehr langen Tabellen --87.78.153.180 12:31, 20. Sep. 2011 (CEST)

N'Abend zusammen, die ganze Editbar sieht anders aus (ist die alte aus dem Monobook). Kommt diese wieder zurück oder bleibt die Neue??? --84.134.60.70 18:47, 20. Sep. 2011 (CEST)

@87.78.x.x: Wenn du so schnell eine Anwendung nennen kannst, dann ist es ein meldenswerter Bug, ich kümmere mich drum.

@84.134.x.x: Dieses Problem kann ich nicht nachvollziehen (Browser?, Fehlermeldungen in der Fehlerkonsole?), dafür kann ich als angemeldeter Benutzer die neue Leiste nicht mehr deaktivieren, und ich glaube, dass hier einige sehr ärgerlich werden, wenn das so live geht. --Schnark 09:19, 21. Sep. 2011 (CEST)

Zum Leiste nicht mehr deaktivieren können habe ich soeben Bug 31069 - WikiEditor cannot be disabled on 1.18wmf1 / test2.wikipedia.org eröffnet. — Raymond ^Disk. 15:16, 21. Sep. 2011 (CEST)

Fixed mit rev:97733 durch Roan. — Raymond ^Disk. 15:58, 21. Sep. 2011 (CEST)

Wenn du versprichst, das nächste Mal die Suchfunktion von Bugzilla zu benutzen, dann verspreche ich, das nächste Mal dazuzusagen, dass ich den Bug selber melde. :-) --Schnark 09:50, 22. Sep. 2011 (CEST)

Ich habe gesucht *mit dem Fuß aufstampf*, aber nur nach "enhanced", "WikiEditor" und "toolbar". Und diese Stichwörter tauchten in deiner Summary nicht auf :P. Ich verspreche aber, dass ich demnächst noch gründlicher suchen werde. — Raymond ^Disk. 10:12, 22. Sep. 2011 (CEST)

Ich hätte natürlich eine sprechendere Summary verwenden sollen, aber beim Update auf 1.17 gab es mit der Vector-Extension mehr oder weniger das gleiche Problem, nur dass da alle Einstellungen ignoriert wurden, sodass damals die Summary angemessen war. Und weil mir mein Browser ebendiese gestern wieder anbot, und man ja faul ist … --Schnark 10:26, 22. Sep. 2011 (CEST)

Variablen in Weiterleitungen, aufgeblähte Versionsgeschichten

Hallo, wie kommt es, dass Weiterleitungen nicht mehr funktionieren, wenn sie Variablen enthalten (die Variablen funktionieren normal) und sich dann wie ein normaler Link auf einer Seite verhalten, man sich also per Hand weiterklicken muss? (siehe meine Disk.) Sonst wäre die tägliche Aktualisierung der Weiterleitung komplett überflüssig und würde viele unnötige Versionen ersparen. Das gilt auch für diese, jene und die Weiterleitung und ähnliche denkbare Fälle, wo die Versionsgeschichten völlig unnötig aufgebläht werden. Gibt es dazu bereits eine (alte) Bugmeldung, ist das schon in der Mache und eine Änderung geplant? --Geitost 21:11, 20. Sep. 2011 (CEST)

Dazu gab es schon viele Bugmeldungen, Bsp: bugzilla:1575, bugzilla:6196. Da Bug 1575 mit WONTFIX gekennzeichnet ist, wird sich daran wohl nichts ändern. -- chatter^Disk 22:33, 20. Sep. 2011 (CEST)

Danke, hab mir das grad mal alles durchgesehen, was es da schon so gab. Warum machen wir es hier dann nicht einfach auch so wie in der estnischen WP bei et:Kasutaja:Peep/Liivakast (s. Bug 6196), statt immer längere Versionsgeschichten zu produzieren? Einen Klick wird man schon noch hinbekommen. Wurde das überhaupt mal irgendwann diskutiert? Ich halte das so für überflüssig. --Geitost 23:26, 20. Sep. 2011 (CEST)

Das ist eben ziemlich kompliziert. Eine WL ist keine normale Seite, sondern wird - sobald sie den entsprechenden Code enthält - als Weiterleitung in die Datenbank einsortiert. Zusätzlich werden noch Kats und IWs aus dem Quelltext gezogen. Das sorgt für schnelles Weiterleiten. Die Seitenansicht wird erst geparst, also das ganze Auswerten von VP (wozu die Variabelen gehören), wenn du sie per ?redirect=no aufrufst. -- ✓ ^Bergi 14:53, 21. Sep. 2011 (CEST)

Babelerweiterung - Kategorie

Die Babelbox verlinkt auf Kategorie:Babel - Benutzer nach Sprache. Dies sollte auf Kategorie:Benutzer nach Sprache geändert werden.

Gruß --Steef ³⁸⁹ 16:09, 21. Sep. 2011 (CEST)

Müsste MediaWiki:Babel-footer-url sein. --Steef ³⁸⁹ 16:11, 21. Sep. 2011 (CEST)

Genau. Soeben angelegt. Die fehlende Übersetzung des Textes wurde im Translatewiki eingegeben und erscheint automatisch heute Nacht. — Raymond ^Disk. 16:12, 21. Sep. 2011 (CEST)

Babelerweiterung

Babel – Benutzerinformationen
Diese Person hat eine Seite bei WikiQuote. Diese Person besitzt ein globales Benutzerkonto SUL mit Hauptsitz auf Wikipedia (de). Zugesicherte Identität: {{{1}}} ist eine SHA-2-Zusicherung der tatsächlichen Identität dieses Benutzers. Egyp Ich kann ägyptische Hieroglyphen lesen. Diese Vorlage ist ein Babelbaustein. Versionen Quelltext Aussehen {{User fr|mw=m}} fr Cet utilisateur a pour langue maternelle le français. {{User fr|mw=w}} fr Cette utilisatrice a pour langue maternelle le français. {{User fr|mw=1}} fr J’ai pour langue maternelle le français.
Benutzer nach Sprache

Ist das eigentlich ein Scherz oder nur ein Alleingang eines sich profilieren wollenden WMFlers? War die letzte Diskussion zu dem Thema tatsächlich die von 2008 auf Meta? Ehrlich gesagt habe ich kaum eine so schwach programmierte Extension gesehen. Es lässt sich allerhand Unsinn damit anstellen, wie rechts demonstriert, die gesubstete Version hat kein CSS mehr, wie kann man den gender-Parameter füllen? Zudem funktioniert der Cross-Namespace-Trick nicht mehr (wir müssten MediaWiki:babel-template auf User $1 setzen). Hätte es da #forargs nicht eher getan? Die unbegrenzte for-Schleife sieht mir ziemlich DOS-anfällig aus, insbesondere weil x-beliebige Nutzer ja neue Vorlagen erstellen können.

Mein Fazit: Für kleinere Wikis, die den Vorlagen-/Kategorienzoo nicht alleine warten können und denen die Extension nun die Bot-Arbeit abnimmer, meinetwegen. Aber für den Großteil der Wikis ist es in der derzeitigen, unausgereiften Version ziemlicher Unsinn. Mag mir da jemand zustimmen und einen Protest-Bug eröffnen? -- ✓ ^Bergi 20:49, 21. Sep. 2011 (CEST)

Nein, von einem ehrenamtlichen Programmierer. Schon seit Jahren im Translatewiki im Einsatz. Und nun durch Roan für die WMF reviewed und deployed. Pro möglichem Fehler bitte einen präzisen Bug eröffnen. Allgemein gehaltene Protest-Bugs sind nicht wirklich hilfreich. — Raymond ^Disk. 23:17, 21. Sep. 2011 (CEST)

MediaWiki:Babel-template auf "User $1" zu setzen, scheint mir nicht zu klappen, da hier erst eine normale Existenzprüfung des Titels wie bei Wikilinks gemacht wird, und da muss ein Namensraum angegeben werden. #ifexist wird vermutlich auch nicht funktionieren. Zu den Vorlagenparameter: Das ist irgendwie wirklich schlecht, aber es funktioniert ;-)

Babel – Benutzerinformationen
Ich besitze eine Seite bei WikiQuote. Diese Person besitzt ein globales Benutzerkonto SUL mit Hauptsitz auf Wikipedia (SUL parameter). Zugesicherte Identität: SUL parameter ist eine SHA-2-Zusicherung der tatsächlichen Identität dieses Benutzers. Egyp Ich kann ägyptische Hieroglyphen lesen. Diese Vorlage ist ein Babelbaustein. Versionen Quelltext Aussehen {{User fr|mw=m}} fr Cet utilisateur a pour langue maternelle le français. {{User fr|mw=w}} fr Cette utilisatrice a pour langue maternelle le français. {{User fr|mw=1}} fr J’ai pour langue maternelle le français. de-N Dieser Benutzer spricht Deutsch als Muttersprache.
Benutzer nach Sprache

Parameter müssen vor Vorlage kommen, zu der sie gehören. Der Umherirrende 19:33, 23. Sep. 2011 (CEST)

Protokoll

Wurde https jetzt auf de.WP schon aktiviert? Zumindest ist sind {{SERVER}} und v.a. die Javascript-Variable wgServer jetzt schon protokolllos: „//de.wikipedia.org“. Hatte meine lokalen Skripte etwas verwirrt :-) Sollte man imho ins Log aufnehmen, hat jemand eine Revisionsnummer? -- ✓ ^Bergi 19:15, 27. Sep. 2011 (CEST)

Wikitech, https funktioniert bei mir noch nicht. //de.wikipedia.org wird aber schon entsprechend erkannt. Der Umherirrende 19:42, 27. Sep. 2011 (CEST)

https ist auch noch nicht angeschaltet. – Giftpflanze 19:57, 27. Sep. 2011 (CEST)

(BK)

Das war wohl nur ein kurzer Ruckler (hoffentlich).

• Ich gucke oben auf ein gewohntes {{SERVER}} mit Protokoll, und wgServer hat auch Protokoll. Heute abend wackelte irgendwas einige Male, und dann brachten auch noch Übersetzungswünsche für Fundraising die Abarbeitung zum Abschmieren.
• Wenn das bei Javascript-Variablen die Zukunft sein sollte, dann würde man allerdings ein -zigtausendfaches Problem haben: mw.loader.load() erwartet zurzeit eine vollständige URL ab http(s) – und wird in vielen (auch MW-)Skripten mit einer aus aneinandergereihten Variablen gebildeten URL aufgerufen.

Gelassen einen schönen Abend wünschend --PerfektesChaos 20:54, 27. Sep. 2011 (CEST)

<quetsch>mw.loader.load akzeptiert inzwischen auch protokollrelative URLs, das wurde auch auf 1.17wmf1 zurückportiert, sodass es schon jetzt funktioniert. --Schnark 12:20, 28. Sep. 2011 (CEST) </quetsch>

Na immerhin, das wollte ich noch überprüfen. Nur Abgleiche mit URLs dürften nicht funktionieren, ein paar hat Krinkle schon behoben. Sonst noch: MediaWiki Diskussion:Common.css#Protokollrelative URLs und Bug 29497. -- ✓ ^Bergi 17:00, 28. Sep. 2011 (CEST)

Von heute Abend aus #wikitech:

	<anneoka>	19:50 logmsgbot: catrope synchronized wmf-config/InitialiseSettings.php 'Here goes... Set $wgServer protocol-relative on all wikis, and enable $wmgHTTPSExperiment on all wikis'
	<Ryan_Lane>	yeah. that enables the support needed for https
	<anneoka>	ah, so :)
	<Ryan_Lane>	but we haven't turned on https yet

Termin für die allgemeine Anschaltung habe ich noch nicht herausgefunden. — Raymond ^Disk. 20:45, 27. Sep. 2011 (CEST)

Ja, stimmt, die Aktivierung von https ist eigentlich unabhängig von protokollrelativen URIs und leicht überprüfbar auch noch nicht erfolgt. -- ✓ ^Bergi 17:00, 28. Sep. 2011 (CEST)

Babel-Extension: Kategorisierung der Seiten

Ich hatte mal Vorlage:Babel-Kategorisierung geschrieben und in alle Sprachvorlagen eingebaut, damit es eine einheitliche Kategorisierung der Sprachvorlagen, und bei Verwendung auch der Benutzerseiten, gibt. Die Babel-Extension aber kategorisiert jede Seite, wenn der Standardtext dran kommt, dabei ist es egal, ob Benutzerseite, Benuzterunterseite, Projektseite etc. was nicht so schön ist. Zumindestens wurden die Standardkategorien richtig gesetzt.

Testen kann man es mit einem Sprachcode zu dem wir nichts haben:

{{#babel:ace|ace-5|ace-4|ace-3|ace-2|ace-1}}

Ich wollte es nur mal notiert haben, so schön ist das nicht, finde ich. Wenn jemand etwas einfällt, nur zu. Der Umherirrende 20:15, 23. Sep. 2011 (CEST)

Ich hatte Sargoth schon versprochen mir den ganzen Kram in den nächsten Tage anzusehen. Vor allem Kategorienseitenheader usw. müssten wohl erst noch lokal angepasst werden.

Zudem existieren doch einige -0 Kategorien. In der Babel-Extension ist das für dewiki deaktiviert. Da müsste man mal eine Statistik über den Ist-zustand mache, ob man das aktiviert sollte oder nicht.

Ich hatte mir auch schon den Quelltext angesehen, ob man dort nicht die Vorlagennameninterpretationsweise einbauen kann. Ohne die Benutzerunterseitenbabels wird dieses System auf dewiki wohl kaum in der Breite akzeptiert werden.

Der Neutrum-Gender ist für de war bisher "Diese Person". Nun ist im translatewiki "Der Benutzer" eingetragen. von mir aus ok - wollte es nur erwähnen. Merlissimo 21:20, 23. Sep. 2011 (CEST)

Hallo Leute! Ja, es wäre praktisch, wenn über das neue, softwareseitige Babel-System eingebundene Babel-Türme immer genau wie die alten kategorisieren würden, also genau so, wie die Vorlage Babel-Kategorisierung es vorsieht. Aber es wäre schon ein Fortschritt, wenn Benutzerseiten nur noch in die spezielle Kategorie für die jeweiligen Sprachkenntnisse, z.B. ace-2, und nicht noch zusätzlich in die Dachkategorie einsortiert würden. Denn unsere alten Babel-Vorlagen kategorisieren ja auch so und es vermeidet unübersichtlichen Kategoriesalat auf den Benutzerseiten. In der niederländischen, der französischen und der italienischen Wikipedia läuft die Kategorisierung der Benutzerseiten nach Sprachen ja genau so wie bei uns, das softwareseitige Babel-System kategorisiert per Standardeinstellungen jedoch wie in der englischen Wikipedia. Soweit ich das verstanden habe, kann man das neue, softwareseitige Babel-System einfach zur alten Kategorisierung anweisen, indem man in der Datei LocalSettings.php die Variable $wgBabelMainCategory auf false setzt. Ich habe aber keine Ahnung, wie man das macht. Wahrscheinlich braucht man dafür mindestens Adminrechte. MfG Stefan Knauf 01:50, 30. Sep. 2011 (CEST)

Ich denke mal, das muss ein Serveradmin machen, da reichen Admin-Rechte also bei weitem nicht. -- Chaddy · D – DÜP – 02:09, 30. Sep. 2011 (CEST)

Sichten bei SSL-Verbindung gestört?

Moinsen! Hab soeben versucht auf Reichsparteitagsgelände eine IP- und eine eigene Änderung zu sichten. Wenn ich dies per SSL (also mit diesem Link) probierte tat sich nix, außer dass oben der Seite so ein Kasten wie bei der Sitenotice, allerdings ohne Inhalt, aufging. Ohne SSL hats dann funktioniert. Genauso bei Prinzipien Objektorientierten Designs. Geht das noch wem anders so? --Gnu1742 12:34, 29. Sep. 2011 (CEST)

Kann ich bestätigen: Sichten per SSL-Verbindung scheint momentan nicht möglich zu sein; der Klick auf die Schaltfläche bewirkt eine Inaktivierung der Schaltfläche, aber auch Minuten später tut sich da nix mehr. Ob man über Diff sichtet (Schaltfläche oben) oder nur die Version selbst (Schaltfläche unten), macht keinen Unterschied. Hmm ... Gruß --Schniggendiller Diskussion 17:03, 29. Sep. 2011 (CEST)

Kann ich nicht nachvollziehen, bei mir funktioniert es. --Steef ³⁸⁹ 17:26, 29. Sep. 2011 (CEST)

Guten Abend, das Problem tritt bei mir im Internet Explorer 7 bei Windows XP auf. Der IE 8 auf dem gleichen System funktioniert. --Crazy1880 18:14, 29. Sep. 2011 (CEST)

Übertrag von WP:Fragen zur Wikipedia. Vielleicht kann jemand von euch mal schauen, ob er etwas findet. Danke --Crazy1880 18:17, 29. Sep. 2011 (CEST)

Versionsnummer von MediaWiki

Die Hauptversionsnummer von MediaWiki ist schon lange Zeit die 1. Wann gibt es zur Abwechslung mal die 2? Immerhin wir die Software fleißig weiterentwickelt. --109.75.18.242 15:37, 29. Sep. 2011 (CEST)

Über die Versionsnummerierung von Software gibt es viele verschiedene Ansichten. Eine Änderung der Hauptnummer indiziert jedoch meist äußerst signifikante Änderung am Programm. Dies war bisher vermutlich nicht gegeben.--Trockennasenaffe 15:45, 29. Sep. 2011 (CEST)

„Eine Änderung der Hauptnummer indiziert jedoch meist äußerst signifikante Änderung am Programm.“ - Außer beim Firefox neuerdings.^^ -- Chaddy · D – DÜP – 18:39, 29. Sep. 2011 (CEST)

mw:MediaWiki 2.0 --Schnark 09:13, 30. Sep. 2011 (CEST)

Gadget PB und 1.18 (?)

Könnte jemand, der sich auskennt, hier schauen? Danke, -jkb- 12:26, 28. Sep. 2011 (CEST)

Das hängt mit der Umstellung auf protokollrelative URL um. Im Script wird wgServer +... mit document.URL verglichen (also //de.wikipedia.org/... mit http://de.wikipedia.org/). Temporärer Workaround bis es ein Admin ändert: mit secure funktioniert es, solange noch nicht auf https://de.wikipedia.org umgestellt ist. --Steef ³⁸⁹ 12:56, 28. Sep. 2011 (CEST)

stimmt, als Ausweg OK, und danke. -jkb- 13:00, 28. Sep. 2011 (CEST)

Zitat aus der aktuellen Version von WP:JS:

• „Um abzufragen, in welchem Projekt ein Skript zurzeit aktiv ist, sollte jedoch nicht die gelegentlich wechselnde URL benutzt werden, sondern die wesentlich stabilere wgDBname.“

Sonnigen Tag --PerfektesChaos 10:30, 3. Okt. 2011 (CEST)

Scheint schon fixed zu sein - das kommt von Parallelldiskussionen... --Saibo (Δ) 16:44, 3. Okt. 2011 (CEST)

Parallelldiskussionen schaden in dem Fall nicht nicht; hier ist schon ein passender Ort, um ein Auge drauf zu haben … programmierende Admins könnten dann mal die vorbereitete Liste aus dem Archiv ziehen. Weiterin:

• MediaWiki:Gadget-revisionjumper.js in den ersten Zeilen starke Vereinfachung möglich
• MediaWiki:Gadget-rightsfilter.js
• MediaWiki:Gadget-WikiMiniAtlas.js Meta-URL ist schon tot, wgServer auch inzwischen ohne Protokoll, geht jetzt viel einfacher
• MediaWiki:Gadget-wikEd.js

Da die neue URL ja nicht gleich wieder in die Knie ging, wird’s wohl dabei bleiben; wer weiß, wie lange die alte secure-Adresse noch live ist. Angenehme Woche --PerfektesChaos 18:02, 3. Okt. 2011 (CEST)

hiddenStructure

Hallo. Ich habe gelesen, daß mit der Version 1.18 die alte CSS-Klasse hiddenStructure endlich verschwinden soll. Gibt es eine Möglichkeit alle betroffenen Vorlagen mit dieser Klasse zu finden? Leider werden manchmal neue Vorlage mit dieser Klasse in der Esperantowikipedia angelegt. Läßt sich dagegen eventuell ein Mißbrauchsfilter definieren? Wenn ja, wie? Gruß --Tlustulimu 16:43, 3. Okt. 2011 (CEST)

Finden: Per Volltextsuche vielleicht? Missbrauchsfilter ist, denke ich, nicht nötig, denn wenn die Klasse nicht mehr existiert und jmd mit jener eine Vorlage anlegt, sieht er ja gleich, dass etwas nicht stimmt. Viele Grüße --Saibo (Δ) 16:52, 3. Okt. 2011 (CEST)

Danke, Saibo. Ich habe denn mal per Volltextsuche die betreffenden Vorlagen gefunden und sie gleich geändert. Eine konnte ich dort sogar problemlos löschen, weil sie nicht verwendet wurde und nur die entfernte Klasse enthielt. Gruß --Tlustulimu 18:31, 3. Okt. 2011 (CEST)

Achja, falls du dich wunderst wieso die bereinigte Vorlage immernoch aufgeführt wird: die Volltextsuche wird nur ca. alle 24h aktualisiert. Viele Grüße --Saibo (Δ) 19:53, 3. Okt. 2011 (CEST)

Datenschutz beim Sichten?

bugzilla:25295 und die Vorderseite hier ("Beim Sichten von Artikeln wird angezeigt, ob bereits ein anderer Sichter mit dem Sichten angefangen hat. Benutzername und Uhrzeit wird dargestellt") meint ja wohl hoffentlich nicht, dass andere Leute sehen, dass man gerade eine Seite mit ungesichteter Version besucht, oder? Weiß jemand genaueres? Viele Grüße --Saibo (Δ) 23:35, 2. Okt. 2011 (CEST)

Ja, das war so, wurde nach Protesten aber rückgängig gemacht. Ich finde auf die Schnelle den Bug dazu nicht. Jetzt kann der Sichter pro Sichtung diese Information freigeben, aber standardmäßig wird diese Information nicht mehr verbreitet. — Raymond ^Disk. 23:58, 2. Okt. 2011 (CEST)

Jein, bugzilla:31093 ist zwar FIXED, aber rev:97886 noch nicht live. Insofern wäre ich dafür, MediaWiki:Revreview-poss-conflict-p und MediaWiki:Revreview-poss-conflict-c in den wichtigsten Sprachen lokal zu überschreiben, bis das live ist. --Schnark 09:09, 3. Okt. 2011 (CEST)

"In den wichtigsten Sprachen" - das hieße aber, dass ich nur auf aramisch zu wechseln brauche, um die eventuell schützenswerte Info doch zu sehen? --Saibo (Δ) 16:49, 3. Okt. 2011 (CEST)

Ja, weil der Parameter bei denen noch sichtbar ist. Der Umherirrende 19:53, 3. Okt. 2011 (CEST)

Nicht mehr nötig, da mit rev:98807 die Änderung in den Code für den WMF-Cluster eingebaut wurde. Damit ist sichergestellt, dass bei einer Liveschaltung auch kein Benutzername beim Sichten unfreiwillig bekanntgegeben wird. — Raymond ^Disk. 23:02, 3. Okt. 2011 (CEST)

Wunderbar. Aramäisch/Arabisch wäre übrigens gar nicht nötig gewesen, da es auch eine API gibt, hätte man nur XML verstehen müssen. --Schnark 09:25, 4. Okt. 2011 (CEST)

Es soll Leute geben, die auf Alt-Aramäisch flüssiger plaudern als sie XML lesen können … Sonne für alle! --PerfektesChaos 10:58, 4. Okt. 2011 (CEST)

Ja, aber der ist nicht wieder aufgestellt worden ;-) --Mogelzahn 16:14, 4. Okt. 2011 (CEST)

PHP Update

dewiki wurde schon auch aktualisiert, aber ahnscheinend sind immer noch nicht alle Server fertig. Spezial:Version zeigt die meiste Zeit 5.3.2-2wm1 an, je nachdem welcher Server die Anfrage bearbeitet. Im IRC wurde gesagt, dass das Update der Server gerade in Arbeit ist, das war um ca. 4 Uhr. Wahrscheinlich werden die restlichen heute Nacht umgestellt. (Mediawiki 1.18 sollte ja auch schon bei allen Wikis aktiv sein :) ). -- chatter^Disk 12:46, 5. Okt. 2011 (CEST)

Signatur-Icon in erweiterter Toolbar

Eigentlich sollte es ja ab sofort möglich sein, bei Verwendung der (neuen) Werkzeugleiste in seinen Einstellungen auszuwählen, dass man das Signatur-Icon immer sehen will. Offensichtlich fehlt aber in der Konfigurationsdatei der Eintrag, der diese Einstellung tatsächlich dem Benutzer zugänglich macht. Meint ihr, dass diese Seite reicht, um einen "community consensus" herzustellen, und wenn ja, seid ihr überhaupt dafür? Ich jedenfalls fände es gut, wenn diese Einstellung möglich wäre, auch wenn ich sie selbst nicht brauche. --Schnark 09:57, 7. Okt. 2011 (CEST)

API, $wgMiserMode und veränderte Zahl der Resultate

Wenn man bisher mit &eunamespace=0&eulimit=100 im ANR 100 Links abgefragt hatte, bekam man 100 Fundstellen (globale Existenz vorausgesetzt).

Umseitig heißt es unter Version 1.18 API:

• exturlusage module does not respect $wgMiserMode (Bug 27717, rev:83394).

Jetzt ist das Verhalten: Es werden offenbar 100 Seiten gefunden, in denen euquery zutrifft, und anschließend daraus diejenigen gefiltert, für die eunamespace=0 greift. Je nachdem, was auf den anderen Seiten steht, bekommt man 30, 70 oder 5 Resultate. api.php schreibt dazu: NOTE: Due to $wgMiserMode, using this may result in fewer than "eulimit" results returned before continuing; in extreme cases, zero results may be returned.

Fragen:

1. Auf was haben wir $wgMiserMode eingestellt?
2. Wollen wir das?

Schönes Wochenende --PerfektesChaos 12:49, 8. Okt. 2011 (CEST)

MiserMode ist (auf allen WMF-Wikis?) an und wir können das nicht entscheiden, da es eine Entscheidung der Server-Admins ist. Das ist ein Performance-Problem, siehe auch den Hinweis auf Spezial:Weblink-Suche. Die gleichen Performance-Probleme die dazu führten, dass die Namensraum-Abfrage von Spezial:Beiträge kurzzeitig verschwunden war, da hat man es aber geschafft, sie wieder zu überreden. Das wird bei der Weblink-Suche wohl nicht so einfach werden, weil es dort schon lange so ist. MiserMode kannst du aber mit meta=siteinfo abfragen: misermode=""

Die Änderung sollte aber nicht bedeuten, das man etwas am Client ändern muss, sondern es bedeutet nur, das der Client eventuell mehr Requests ausführen muss, um die gleiche Menge zurückzubekommen. Der Umherirrende 13:18, 8. Okt. 2011 (CEST)

Naja, solange der Client ein Tool von mir ist, rödelt er halt ein paar Mal öfter mit dem euoffset, bis ich meine gewünschten 100.000 Fundstellen beisammen habe … für menschliche Bediener als „Klienten“, die über manuelle Abfrage und zusammengebaute URL Artikel und ihre Weblinks zu pflegen versuchen, kann das ein ganz schöner Rückschritt sein. Ich frage mich, ob das Performance-Problem wirklich so gravierend ist; und ob nicht beispielsweise in der Spezialseite als Volksausgabe die Namespace-Einschränkung und damit die 500 beim ersten Zugriff bestehen bleiben könnte, während im Expertenmodus bei api.php so lange gesucht wird, bis die maximal 500 im gewünschten namespace beieinander sind. Durch entsprechend viele aufeinanderfolgende Einzelabrufe wird die Serverlast auch nicht geringer. Aber da mögen andere weiter dran knabbern; ich wollte pflichtschuldigst meine Beobachtung melden und mich orientieren. Liebe Grüße --PerfektesChaos 14:22, 8. Okt. 2011 (CEST)

Es kann schon ein Rückschritt sein, das stimmt. Ob die API ein Expertenmodus ist, möchte ich nicht bewerten, aber da immer mehr damit gemacht wird, fällt ein solcher Unterschied schon auf, es bringt ja auch nichts, wenn jemand auf Basis der API und JavaScript eine neue Spezialseite baut, um den Namensraumfilter zu umgehen. Daher kann ich verstehen, wenn man die Möglichkeiten, die beide Wege bietet, mit dem gleichen Einschränkungen versieht. Schwierig zu sagen, was richtig ist.

Diese Art der Einschränkung gibt es aber bereits seit längerem für cmnamespace=. Der Umherirrende 15:41, 8. Okt. 2011 (CEST)

erweiterte References-Syntax für Mehrspaltigkeit

…soll unter Wikipedia:Umfragen/Multicol#technische Umsetzung diskutiert werden. Ich hoffe, hier erreiche ich das interessierte Publikum, das nicht anfängt zu streiten ob Mehrspaltigkeit überhaupt gewollt ist, sondern sich konstruktiv beteiligen kann (sowie meinem Bugreport folgen kann). -- ✓ ^Bergi 23:25, 10. Okt. 2011 (CEST)

Latex

Hallo, was wurde denn heute an Latex geändert, so dass manche Artikel nun voll mit Fehlern sind? Zum Beispiel sind im Artikel Lebesgue-Integral nun vier Fehler. Ist bekannt, ob das korrigiert wird, oder muss das evtl. manuell repariert werden? Grüße --Christian1985 (Diskussion) 00:14, 7. Okt. 2011 (CEST)

Ich finde da keine Fehler. Bug schon behoben? --morre.meyer 09:38, 19. Okt. 2011 (CEST)

Wurde schon behoben und an anderen Stellen ausführlicher diskutiert. --Schnark 10:15, 19. Okt. 2011 (CEST)

Teilweise wurden die Artikel per Hand verbessert, sodass der Fehler verschwand, teilweise wurde das TeX-Modul geupdated. Aber es gibt wohl noch Ausdrücke, die das Latex-Modul früher akzeptiert hat und heute nicht mehr. --Christian1985 (Diskussion) 13:35, 19. Okt. 2011 (CEST)

Hast du Beispiele parat? --morre.meyer 10:51, 20. Okt. 2011 (CEST)

bugzilla:31442 enthält sowohl Beispiele als auch Hintergründe. --Schnark 11:00, 20. Okt. 2011 (CEST)

Das klassische Beispiel in Wikipedia ist \dot \vec v. Das wurde früher akzeptiert, zur Zeit wird es aber nicht mehr akzeptiert. --Christian1985 (Diskussion) 11:35, 20. Okt. 2011 (CEST)

Wikidiff2

Und was hat sich dabei geändert? Kriegt Otto-Normaluser was davon zu sehen oder wurde nur der Algorithmus optimiert? Konnte leider in der Doku nichts dazu finden. -- ✓ ^Bergi 22:24, 2. Nov. 2011 (CET)

Soweit ich das gelesen habe, hat man ein bugfix aus dem Februar (2011) jetzt kompiliert. Die Übersetzung war wohl noch nicht auf allen Servern angekommen. Der Quellcode ist offensichtlich seit 7 Monaten unverändert und mir recht gut bekannt. --PerfektesChaos 23:45, 2. Nov. 2011 (CET)

Der Quelltext ist nun „kompakter“. Bislang konnte man die Tabellen aus der Diff-Ansicht sich im Quelltext ansehen, um auch einzelne geänderte Leer- und Satzzeichen im Direktvergleich sehen zu können. Jetzt ist die Tabelle eine lange Zeile. :/ --32X 00:20, 3. Nov. 2011 (CET)

Mit (leerzeichenfreien) Vorlagenergänzungen kommt der neue Diff ebenfalls schlechter klar: Ergänzung der Vorlage:Normdaten um einen Parameter bring viel Farbe. --32X 09:39, 3. Nov. 2011 (CET)

OK, danke. -- ✓ ^Bergi 18:50, 3. Nov. 2011 (CET)

Soweit ich weiß, war das vorher aber auch schon so, da sich am Algorithmus nichts geändert hat, sondern nur an der Ausgabe, siehe rev:80621. Der Umherirrende 18:59, 3. Nov. 2011 (CET)

Die Tabelle ist jetzt wieder mehrzeilig (jedoch kompakter), dafür wird ein Wort selbst dann als geändert markiert, wenn nur zwei folgende Leerzeichen zu einem reduziert wurden. (Früher wurden Leerzeichenänderungen ignoriert, es wurde lediglich angezeigt, dass sich überhaupt etwas geändert hat.) Inzwischen wird man regelrecht gezwungen, bei jedem zweiten Diff auch den HTML-Quelltext zu vergleichen, weil übermäßig viel markiert wird. Ich bin mit der Gesamtsituation unzufrieden. --32X 23:31, 5. Nov. 2011 (CET)

Ja, es wird jetzt jeweils das Wort davor und danach mit markiert, das ermöglich es zwar, Leerzeichenänderungen besser zu sehen, aber dafür werden andere Änderungen schwer zu erkennen. So viele Änderungen gab es dort nicht, aber ich kann trotzdem nicht sagen, ob das jetzt Absicht war, oder nicht. Der Umherirrende 23:45, 5. Nov. 2011 (CET)

Die Lösung in der engl. Wp gefällt mir sehr gut, Beispiel. --tsor 10:07, 3. Nov. 2011 (CET)

Nur damit ich geistig noch folgen kann: Die en.WP und andere verwenden ein anderes CSS mit bold; was aber nichts mit dem diff-Algorithmus zu tun hat.

Sonnigen Herbst --PerfektesChaos 10:36, 3. Nov. 2011 (CET)

Mit 1.19 werden sich die Farben ändern, damit auch Rot-Grün-Sehschwache direkt damit klar kommen. Ich finde die neue Farbwahl garnicht mal so schlecht. Der Umherirrende 18:36, 3. Nov. 2011 (CET)

Ist das alte-Farben™-Gadget schon vorbereitet? :-) -- ✓ ^Bergi 18:50, 3. Nov. 2011 (CET)

Man gewöhnt sich dran ;-) Man kann natürlich auch schonmal das "alte" CSS als Kopiervorlage auf einer Seite vorbereiten, dann ist es schneller verfügbar, wenn der große Aufschrei komm … Der Umherirrende 18:59, 3. Nov. 2011 (CET)

Kategorienbaum

Bei Kategorie:Person nach Geburtsjahrhundert und Kategorie:Person nach Todesjahrhundert stimmt nun die Anzeige der Seitenanzahl nicht. Andim 00:31, 16. Nov. 2011 (CET)

Das Problem liegt darin, dass nun als Seitenzahl die Summe der Anzahl der Unterkategorien und der Anzahl der direkt einkategorisierten Artikel genommen wird. Früher wurde als Seitenanzahl nur die Anzahl der direkt einkategorisierten Artikel genommen. Andim 00:34, 16. Nov. 2011 (CET)

Na ja, das ist auch genau das, was in der zugehörigen Tabelle zu stehen scheint..... --Guandalug 00:48, 16. Nov. 2011 (CET)

Siehe dazu auch Wikipedia:Fragen_zur_Wikipedia#Fehler_in_Kategorien --Guandalug 09:48, 16. Nov. 2011 (CET)

neues Projekt http://nso.wikipedia.org/wiki/Letlakala_la_Pele

Wirft Fehlermeldung:

Unstub loop detected on call of $wgLang->getCode from MessageCache::get
Backtrace:
#0 /usr/local/apache/common-local/php-1.18/includes/StubObject.php(57): StubObject->_unstub('getCode', 5)
#1 /usr/local/apache/common-local/php-1.18/includes/StubObject.php(147): StubObject->_call('getCode', Array)
#2 [internal function]: StubUserLang->__call('getCode', Array)
#3 /usr/local/apache/common-local/php-1.18/includes/cache/MessageCache.php(611): StubUserLang->getCode()
#4 /usr/local/apache/common-local/php-1.18/includes/GlobalFunctions.php(1339): MessageCache->get('gadgets-definit...', true, false)
#5 /usr/local/apache/common-local/php-1.18/extensions/Gadgets/Gadgets_body.php(510): wfEmptyMsg('gadgets-definit...', '<gadgets-def...')
#6 /usr/local/apache/common-local/php-1.18/extensions/Gadgets/Gadgets_body.php(38): Gadget::loadStructuredList()
#7 [internal function]: GadgetHooks::userGetDefaultOptions(Array)
#8 /usr/local/apache/common-local/php-1.18/includes/Hooks.php(216): call_user_func_array('GadgetHooks::us...', Array)
#9 /usr/local/apache/common-local/php-1.18/includes/GlobalFunctions.php(3621): Hooks::run('UserGetDefaultO...', Array)
#10 /usr/local/apache/common-local/php-1.18/includes/User.php(1211): wfRunHooks('UserGetDefaultO...', Array)
#11 /usr/local/apache/common-local/php-1.18/includes/User.php(2131): User::getDefaultOptions()
#12 /usr/local/apache/common-local/php-1.18/includes/RequestContext.php(213): User->getOption('language')
#13 /usr/local/apache/common-local/php-1.18/includes/StubObject.php(151): RequestContext->getLang()
#14 /usr/local/apache/common-local/php-1.18/includes/StubObject.php(103): StubUserLang->_newObject()
#15 /usr/local/apache/common-local/php-1.18/includes/StubObject.php(57): StubObject->_unstub('getCode', 5)
#16 /usr/local/apache/common-local/php-1.18/includes/StubObject.php(147): StubObject->_call('getCode', Array)
#17 [internal function]: StubUserLang->__call('getCode', Array)
#18 /usr/local/apache/common-local/php-1.18/includes/cache/MessageCache.php(611): StubUserLang->getCode()
#19 /usr/local/apache/common-local/php-1.18/includes/GlobalFunctions.php(1173): MessageCache->get('titleblacklist-...', true, false)
#20 /usr/local/apache/common-local/php-1.18/includes/GlobalFunctions.php(1242): wfMsgGetKey('titleblacklist-...')
#21 /usr/local/apache/common-local/php-1.18/extensions/TitleBlacklist/TitleBlacklist.hooks.php(85): wfMsgWikiHtml('titleblacklist-...', '.* <noedit> # T...', 'Conny')
#22 /usr/local/apache/common-local/php-1.18/extensions/TitleBlacklist/TitleBlacklist.hooks.php(106): TitleBlacklistHooks::acceptNewUserName('Conny', Object(User),)
#23 [internal function]: TitleBlacklistHooks::centralAuthAutoCreate(Object(User), 'Conny')
#24 /usr/local/apache/common-local/php-1.18/includes/Hooks.php(216): call_user_func_array('TitleBlacklistH...', Array)
#25 /usr/local/apache/common-local/php-1.18/includes/GlobalFunctions.php(3621): Hooks::run('CentralAuthAuto...', Array)
#26 /usr/local/apache/common-local/php-1.18/extensions/CentralAuth/CentralAuthHooks.php(469): wfRunHooks('CentralAuthAuto...', Array)
#27 /usr/local/apache/common-local/php-1.18/extensions/CentralAuth/CentralAuthHooks.php(253): CentralAuthHooks::attemptAddUser(Object(User), 'Conny')
#28 [internal function]: CentralAuthHooks::onUserLoadFromSession(Object(User), NULL)
#29 /usr/local/apache/common-local/php-1.18/includes/Hooks.php(216): call_user_func_array('CentralAuthHook...', Array)
#30 /usr/local/apache/common-local/php-1.18/includes/GlobalFunctions.php(3621): Hooks::run('UserLoadFromSes...', Array)
#31 /usr/local/apache/common-local/php-1.18/includes/User.php(930): wfRunHooks('UserLoadFromSes...', Array)
#32 /usr/local/apache/common-local/php-1.18/includes/User.php(272): User->loadFromSession()
#33 /usr/local/apache/common-local/php-1.18/includes/User.php(3928): User->load()
#34 /usr/local/apache/common-local/php-1.18/includes/User.php(2125): User->loadOptions()
#35 /usr/local/apache/common-local/php-1.18/includes/RequestContext.php(213): User->getOption('language')
#36 /usr/local/apache/common-local/php-1.18/includes/StubObject.php(151): RequestContext->getLang()
#37 /usr/local/apache/common-local/php-1.18/includes/StubObject.php(103): StubUserLang->_newObject()
#38 /usr/local/apache/common-local/php-1.18/includes/StubObject.php(57): StubObject->_unstub('getCode', 5)
#39 /usr/local/apache/common-local/php-1.18/includes/StubObject.php(147): StubObject->_call('getCode', Array)
#40 [internal function]: StubUserLang->__call('getCode', Array)
#41 /usr/local/apache/common-local/php-1.18/includes/cache/MessageCache.php(611): StubUserLang->getCode()
#42 /usr/local/apache/common-local/php-1.18/includes/GlobalFunctions.php(1173): MessageCache->get('pagetitle', true, false)
#43 /usr/local/apache/common-local/php-1.18/includes/GlobalFunctions.php(1153): wfMsgGetKey('pagetitle', true, false, true)
#44 /usr/local/apache/common-local/php-1.18/includes/GlobalFunctions.php(1071): wfMsgReal('pagetitle', Array)
#45 /usr/local/apache/common-local/php-1.18/includes/OutputPage.php(773): wfMsg('pagetitle', 'Letlakala la Pe...')
#46 /usr/local/apache/common-local/php-1.18/includes/Article.php(369): OutputPage->setPageTitle('Letlakala la Pe...')
#47 /usr/local/apache/common-local/php-1.18/includes/Wiki.php(468): Article->view()
#48 /usr/local/apache/common-local/php-1.18/includes/Wiki.php(239): MediaWiki->performAction(Object(Article))
#49 /usr/local/apache/common-local/php-1.18/includes/Wiki.php(624): MediaWiki->performRequest()
#50 /usr/local/apache/common-local/php-1.18/includes/Wiki.php(531): MediaWiki->main()
#51 /usr/local/apache/common-local/php-1.18/index.php(57): MediaWiki->run()
#52 /usr/local/apache/common-local/live-1.5/index.php(3): require('/usr/local/apac...')
#53 {main}

Conny 08:45, 5. Nov. 2011 (CET).

Ich glaube, das ist Bug 31419. Der Umherirrende 12:09, 14. Nov. 2011 (CET)

Sollte behoben sein. Der Umherirrende 22:37, 22. Nov. 2011 (CET)

Dieser Abschnitt kann archiviert werden. Der Umherirrende 22:37, 22. Nov. 2011 (CET)

Bug 31865

Wenn ich Bug 31865 mit dem neuen Element <dws> richtig verstehe, dann ist das neben Kommentaren <!--…--> eine weitere Möglichkeit um Whitespaces zu unterdrücken. Das erinnert mich etwas an die C++-Kommentare /*…*/ und //. Allerdings frage ich mich nach dem Sinn dieser grauslichen Erweiterung. <dws> ist zwar zwei Zeichen kürzer als <!--…-->, aber sehr unverständlich. Wir haben schon eine verkorkste Syntax; die muss nicht noch unverständlicher gemacht werden. Meiner Meinung nach ist diese Erweiterung nicht sinnvoll. --Fomafix 15:05, 22. Nov. 2011 (CET)

Das bleibt abzuwarten / auzutesten. Ich vermute mal, dass man mit dws auch etwas schöner aussehende Vorlagen bekommen kann (der Vorlagenparser ist ein Gräuel). Aber ohne testcase.... und ich bastel jetzt keinen ;D --Guandalug 15:17, 22. Nov. 2011 (CET)

Finde ich auch, gerade in Hinsicht auf Neulinge. Vor allem ein explizit ungeschlossenens Tag… wo wir doch eh schon so viel Verwirrung zwischen HTML- und Extension-Tags haben. Da wäre ein Escaping a la

<viel Code>\
<direkt angeschlossener Code>

noch verständlicher gewesen – Javascript erlaubt so beispielsweise multi-line-strings. Aber nur mit < Beginnendes kann halt im Parser-Core ausgewertet werden. -- ✓ ^Bergi 15:22, 22. Nov. 2011 (CET)

Hat sich ja fürs Erste erledigt, das Thema... :D --Guandalug 08:55, 23. Nov. 2011 (CET)

Diff

Gegenüber dem Stand von Ende Oktober hat sich bei mir die Diff deutlich verschlechtert: Es werden teilweise Text-/Codeteile rot eingefärbt, die gleich geblieben sind. Hat das damit zu tun:

Es wurde eine neue Version von wikidiff2, dem Modul, das die Versionsunterschiede anzeigt, installiert (Bug 27720).

? --Leyo 19:56, 22. Nov. 2011 (CET)

Ja, es wird jetzt auch das Wort vor oder nach Satz-/Sonderzeichen mit markiert. Das macht zwar die Zeichen besser lesbar, aber im großen und ganzen, die Versionsunterschiede schwer lesbar. Vergleiche Wikipedia Diskussion:Projektneuheiten/Archiv/2011#Wikidiff2. Der Umherirrende 20:02, 22. Nov. 2011 (CET)

Ich bin auch sehr unzufrieden mit wikidiff2. Dass die angrenzenden Worte bis zum nächsten Leerzeichen markiert werden ist unnötig und störend. --Fomafix 20:09, 22. Nov. 2011 (CET)

Ich dachte, es handle sich um einen irrtümlicherweise miteingeführten Bug, nicht um ein Feature. :-( --Leyo 00:26, 23. Nov. 2011 (CET)

Ihr dürft alle für Bug 32601 voten :-) Volle Zustimmung. -- ✓ ^Bergi 01:35, 23. Nov. 2011 (CET)

quetsch Gern auch mit Verweis auf Bugzilla:29385 #c3 … LG --PerfektesChaos 16:07, 23. Nov. 2011 (CET)

Ich habe ein besonders schlimmes Beispiel kreiert. --Leyo 16:00, 23. Nov. 2011 (CET)

Is ja gruselig.... --Guandalug 16:02, 23. Nov. 2011 (CET)

Hier ist auch ein grausames. --Guandalug 22:05, 24. Nov. 2011 (CET)

Das kommt aber durch die Zeilenverschiebung, die nicht immer optimal erkannt wird und war schon immer so, meine ich. Der Umherirrende 22:12, 24. Nov. 2011 (CET)

Das hätte aber besser werden sollen können müssen.... :D --Guandalug 22:34, 24. Nov. 2011 (CET)

Berichtigung der externallinks-Tabelle für protokoll-relative Weblinks

Weiß jemand, ob das Maintenance-Skript für das Berichtigen der externallinks-Tabelle für protokoll-relative Weblinks läuft oder gelaufen ist? Im "normalen" Betrieb werden sich die Weblinks nicht "vermehren". Nur neue (und geänderte) protokoll-relative Weblinks werden direkt mit zwei Datenbankzeilen eingetragen. Dies ist interessant zu wissen, um die Ergebnisse auf Spezial:Weblink-Suche (und mit der API) einschätzen zu können. Vielen Dank. Der Umherirrende 20:37, 25. Nov. 2011 (CET)

Links auf eigenen Server mit absoluter Url

Links auf den eigenen Server werden (bekanntlich) nicht in der externallinks-Tabelle gespeichert. Seit dem der Server aber protokoll-relativ ist, werden die absoluten Urls dort wieder gespeichert, weil sie nicht als gleich erkannt werden. Ist das ein Bug oder ein Feature? Ich bin mir nicht sicher, es kann einerseits nützlich sein, um sie zu ändern, anderseits kann es auch verwirrend sein, weil man auch die protokoll-relativen Urls dort erwarten könnte. Was meint ihr? Der Umherirrende 20:42, 25. Nov. 2011 (CET)

Möglicherweise BREAKING CHANGE: Änderung am IRC-Feed für MediaWiki 1.19: Lokalisierter Name fürs Logbuch

Mit rev:97711 wurde am IRC-Feed etwas geändert: Logbucheinträge erhalten mit MediaWiki 1.19 den lokalisierten Namen des Logbuchs. Ich möchte alle Nutzer des Feeds bitten, zu prüfen, ob dies Auswirkungen auf ihre Tools/Programme hat und wenn ja, diese zu beheben.
Ich möchte alle bitten, diese Information zu verteilen, damit möglichst alle IRC-Feed-Nutzer dadrüber bescheid wissen und etwas unternehmen können, bevor die Änderung live ist und die Tools/Programme stehen/falsche Informationen ausgeben. Vielen Dank. Der Umherirrende 13:32, 27. Nov. 2011 (CET)

Igitt...... Wer denkt sich SOWAS aus? Ich will einen komplett unlokalisierten Feed...... --Guandalug 13:36, 27. Nov. 2011 (CET)

Ich ;-) Der Namensraum im Feed ist bereits lokalisiert, daher sollte meiner Meinung nach auch der Name der Spezialseite lokalisiert werden. Zu sehen ist es beispielsweise hier, wo aktuell "Spezial:Log/move" für jede Verschiebung steht, anstatt "Spezial:Logbuch/move". Was du möchtest, ist so etwas wie mw:Extension:XMLRC. Der Umherirrende 13:43, 27. Nov. 2011 (CET)

Vor allem darf man die lokalisierten Sachen nicht einfach hart auf z.B. de umcoden, sondern muss sie aus der api entnehmen. Denn die Übersetzungen könnten sich dann dank translatewiki theoretisch täglich ändern. Namensräume ändern sich seltener.

Es gibt einige irc-Bots die nur Statistiken erheben und bisher keine weitere Mediawiki-Schnittstelle nutzen. Für die wird das dann etwas mehr Aufwand, weil die api-Unterstützung neu implementiert werden muss.Merlissimo 13:47, 27. Nov. 2011 (CET)

Ist das XML-Teil endlich "stable"? Lang nicht mehr nachgesehen..... Ich weiss alleine 2 Java-Programme, die ich dann mal anfassen muss. *seufz* --Guandalug 13:49, 27. Nov. 2011 (CET)

Spezial:ApiSandbox

Achtung! Das ist eine ziemlich reale "Spielwiese". :D Alle Aktionen werden dann auch wirklich ausgeführt (so hab ich mich aus Versehen selbst mit E-Mails vollgespammt und in bar-WP, wo ich Admin-Rechte habe, den armen User:Test unbeschränkt gesperrt^^). Sollte man vielleicht dazuschreiben, weil "Sandbox" klingt klingt halt recht ungefährlich und einladend... ;) -- Chaddy · D – DÜP – 22:39, 30. Nov. 2011 (CET)

Hab unter MediaWiki:Apisb-intro mal eine rudimentäre Warnung verfasst. Bitte noch verbessern. --Tobias D B 22:53, 30. Nov. 2011 (CET)

Hattest du das Feld token ausgefüllt? Dann ist klar, das es funktioniert hat. Das "Sandbo"x bezieht sich auch auf das Zusammenbasteln der Abfrage. Bei den action-Modulen ist das er weniger notwendig. Für query-Module hingegen könnte es eine Erleichtung sein. Der Umherirrende 21:04, 2. Dez. 2011 (CET)

Diff-Ansicht färbt viel zu viel rot seit Version 1.18

Wie wird man die seit der jüngsten Versionsumstellung unbrauchbar gewordene Diff-Ansicht wieder los? So ganz allein scheine ich mit dieser Ansicht nicht zu sein, unter Wikipedia:Verbesserungsvorschläge, wo ich das angesprochen habe, scheint aber kaum jemand mitzulesen. --TMg 16:31, 18. Dez. 2011 (CET)

Guckst du ins Archiv. --Steef ³⁸⁹ 17:58, 18. Dez. 2011 (CET)

Noch mehr eingeschlafene Diskussionen. Die Bugmeldungen werden alle auf WONTFIX gesetzt. Und nun? Muss ich mir doch mein eigenes cleanDiff.js schreiben? --TMg 19:12, 18. Dez. 2011 (CET)

Fragt sich, wie man bei den Entwicklern etwas Druck aufsetzt. Bringt eine Umfrage etwas? --Leyo 00:27, 19. Dez. 2011 (CET)

Mein cleanDiff.js funktioniert und darf gern von jedem mitbenutzt werden, den das genauso stört wie mich. Es ist fast lächerlich, wie wenig Codezeilen und Zeit es mich gekostet hat, die kaputten roten Markierungen zu reparieren und den Diff dabei sogar besser zu machen als den alten, indem er Leerzeichen markiert, wenn das sinnvoll ist. Warum solche Details sonst kaum jemanden zu stören scheinen, kann ich nur vermuten. Wahrscheinlich verwenden alle, die Einfluss darauf hätten, WikEd und scheren sich nicht um die Werkzeuge der „normalen“ Benutzer. Deswegen ist an dieser Stelle für mich auch EOD. --TMg 03:18, 19. Dez. 2011 (CET)

Unbedingt jedem zu empfehlen. --Thot 1 16:58, 23. Dez. 2011 (CET)

Vielen Dank TMg. Ich habe es auch gleich installiert. --Mogelzahn 15:39, 25. Dez. 2011 (CET)

Kennt jemand ein ähnliches Script auf Commons oder andern Wikipedias? Dann könnte die Weiterentwicklung ggf. koordiniert werden. --Leyo 14:49, 6. Jan. 2012 (CET)

Mit Bug 33331 und rev:107135 gab es inzwischen eine Änderung an wikidiff2. Wahrscheinlich behebt das die ärgerliche Darstellungen beim Versionsvergleich. Leider ist diese Änderung noch nicht live. --Fomafix 15:39, 6. Jan. 2012 (CET)