Wikipedia Diskussion:Technik/Skin/Gadgets/uploadtools

Diese Seite wird wenig beobachtet.

Änderungswünsche müssen ohnehin auf Wikipedia:Technik/Skin/MediaWiki/Änderungen vorgestellt und erörtert werden.

Neue Angelegenheiten bitte primär dort vorschlagen, oder auf eine neue Angelegenheit hier hinweisen.

Reupload → keine Infovorlage bitte

Entsprechend Leyos sinnvollen Wunsch (Wikipedia:Administratoren/Anfragen/Archiv/2011/Juli#Vorschau_beim_Hochladen) sollte bei URLparameter &wpForReUpload=1 nicht die Vorlage Information eingesetzt werden. ... so als TODO ;) Viele Grüße --Saibo (Δ) 19:35, 4. Aug. 2011 (CEST)

Vorschlag (zu Teilen sogar getestet): Den ganzen Inhalt ersetzen durch

/**
  * Lädt die Informationsvorlage beim Hochladen direkt im Beschreibungsfeld
  * und ermöglicht eine Vorschau der Beschreibung auf [[Spezial:Hochladen]]
  * wird in [[MediaWiki:Common.js]] eingebunden
  * Code von [[Benutzer:Schnark]]
  * <nowiki>
  */
 $(document).ready(function(){
  var $editbox = $('#wpUploadDescription');
  if ($editbox.length != 1) return; // exits silently if not exactly one #wpUploadDescription is found
  var parseAsSummary; // Fallunterscheidung für Vorschaufunktion
  if (mw.util.getParamValue('wpForReUpload') != '1') { // Kein Upload von neuer Dateiversion?
     parseAsSummary = false; // bei Upload der ersten Dateiversion wird eingegebener Text auf der Seite erscheinen

     if (typeof wikEd != 'undefined' && wikEd.useWikEd) {  // if WikEd is active
        wikEd.UpdateTextarea(); // transfer WikEd to $editbox
     }

     if ($editbox.val() === '') {
        $editbox.val('{{Information\n' +
                     '|Beschreibung     = \n' +
                     '|Quelle           = \n' +
                     '|Urheber          = \n' +
                     '|Datum            = \n' +
                     '|Genehmigung      = \n' +
                     '|Andere Versionen = \n' +
                     '|Anmerkungen      = \n' +
                     '}}');
     }

     if (typeof wikEd != 'undefined' && wikEd.useWikEd) {  // if WikEd is active
        wikEd.UpdateFrame(); // transfer $editbox to WikEd
     }
  } else {
     parseAsSummary = true; // bei Upload von neuer Dateiversion wird eingegebener Text nur im Log erscheinen
  }

  if (!mw.config.get('wgEnableAPI')) return;
  var previewText = 'Vorschau';
  if ($('#mw-description-preview').length === 0) {
     $('#mw-htmlform-description').before($(mw.html.element('div', {id: 'mw-description-preview'})));
  }
  $('input[name="wpUpload"]').after($(mw.html.element('input', {value: previewText, type: 'button'})).click(function(){
    if (typeof wikEd != 'undefined'&& wikEd.useWikEd) {  // if WikEd is active
       wikEd.UpdateTextarea(); // transfer WikEd to $editbox
    }
    var param = {action: 'parse',
                 title: 'Datei:' + ($('#wpDestFile').val() || 'Beispiel.jpg'), //Titel, Datei:Beispiel.jpg als Standard
                 prop: 'text|categories|langlinks', //categories und langlinks noch nicht verwendet
                 pst: '',
                 format: 'json'};
    param[ parseAsSummary ? 'summary' : 'text' ] = $editbox.val(); //Inhalt des Eingabefeldes entweder als Kommentar oder als Text parsen
    $.getJSON(mw.util.wikiScript('api'), param, function (json) {
       var content = parseAsSummary ? 'parsedsummary' : 'text'; //Geparster Inhalt entweder in parsedsummary oder in text
       if (!json || !json.parse || !json.parse[content] || !json.parse[content]['*']) return;
       var html = '<p><strong>' + previewText + ':</strong><p>' + json.parse[content]['*'];
       $('#mw-description-preview').html(html);
    }); //getJSON
  })); //click
 }); //ready
//</nowiki>

Vielleicht findet sich sogar noch jemand, der die Kategorien mit einbaut und es schafft die Vorschau so hervorzuheben, wie du es wolltest. --Schnark 11:28, 6. Aug. 2011 (CEST)

Super, danke Schnark! :) Ich habe es eben mal mit Adblock (Originalscript blockiert) und Firebug (das neue per Konsole geladen) getestet. Wie hattest du es getestet?

1. Das (mw.util.getParamValue('wpForReUpload') == '1') return; verhindert, dass es eine Vorschau bei einem Reupload gibt. Nicht so sinnvoll. Überhaupt: ist das vorzeitige Herausspringen mit return nicht schlechter Programmierstil? ;) Lieber einfache If-Blöcke, oder nicht?

warum? ich denke der teil des codes, wo wirklich was passiert verdient es, so lesbar wie möglich gehalten zu werden. -- ∂ 23:08, 9. Aug. 2011 (CEST)

weil er dadurch eben nicht lesbar ist - finde ich. Fehlt ja nur noch, dass GOTOs enthalten wären. ;) Aber soll mir recht egal sein. --Saibo (Δ) 00:42, 10. Aug. 2011 (CEST)

Da ich vier returns verwendet habe, würden ifs die maximale Einrücktiefe um vier Stufen erhöhen, ich glaube nicht, dass das zur Lesbarkeit beiträgt. --Schnark 09:31, 10. Aug. 2011 (CEST)

Ist vielleicht Geschmackssache. --Saibo (Δ) 12:11, 10. Aug. 2011 (CEST)

2. und " }); //ready" verstehe ich nicht. Es gibt doch gar kein ".ready", oder wo versteckt es sich?

3. Für was ist "'Beispiel.jpg'" im Code?

4. Es passiert aber nur dann, wenn ich WikEd aktiviert habe. Zur Not bei Aktivsein von WIkEd die Vorschau ausschalten? Vielleicht liegt es natürlich auch daran, dass jetzt beim Testen WIkEd zuerst geladen wurde?! Verhalten:

Wenn ich die Infovorlage einsetzten lasse und dann "Test Hallo!" ins Textfeld schreibe und dann Vorschau drücke, dann zeigt er mir trotzdem die Vorschau einer leeren Infovorlage. Die wird wohl im Hintergrund in das Textfeld eingesetzt, aber WIkEd übernimmt sie nicht und zeigt sie daher nicht an.

Wenn ich die Infovorlage aus dem Script herauslösche, sie also nicht einsetzen lasse, dann etwas ins textfeld tippe und Vorschau drücke, dann bleibt die Vorschau leer. Es scheint also wirklich, dass die Vorschau ein anderes Textfeld nimmt, als jenes, was WikEd anzeigt.

Viele Grüße --Saibo (Δ) 22:51, 9. Aug. 2011 (CEST)

1. Wenn ich es richtig sehe, wird doch beim Reupload der ganze Kram, den man in die Textbox eintippt, nur in die Zusammenfassungszeile übernommen. Wozu braucht man da eine Vorschau? Mehr als interne Links funktioniert sowieso nicht, außerdem kann die API nur eine Textvorschau (in der alles andere wie externe Links etc. auch funktioniert) erzeugen, keine Vorschau für Zusammenfassungszeilen.

2. Meine Faulheit: $(function () { ist die Abkürzung für jQuery(document).ready(function () {.

3. Wenn man noch keinen Dateinamen eingegeben hat, würde ansonsten Datei: als Titel übergeben, was der API nicht wirklich gefällt, so bekommt sie Datei:Beispiel.jpg. Solange man in der Beschreibung kein {{PAGENAME}} etc. verwendet, ist das eigentlich völlig egal.

4. Immer dieser wikEd. Ich habe noch eine Zeile eingefügt, allerdings wird das bei deiner Testmethode wohl immer noch nicht funktionieren. Im Realbetrieb müsste sich das Skript jetzt aber mit wikEd vertragen. --Schnark 09:31, 10. Aug. 2011 (CEST)

1: Ja, es wird nur ins Log aufgenommen. Da man da aber nichts mehr ändern kann, fände ich eine Vorschau selbst für die internen Links sinnvoll.

2: Ich fände es unfaul schöner, weil leichter lesbar für jmd. der kein Jqueryprofi ist. ;-)

3: Dann kann das ja kurz als Kommentar hintendran.

4. Danke! Wie könnte ich denn sonst dieses Script testen (ohne eigene Mediawikiinstallation)? Ich teste heute abend und baue dann evtl. ein. Und teste dann auch mal IE (leider dann erst im Livebetrieb - aber ist ja nur das lokale Uploadform). Viele Grüße --Saibo (Δ) 12:11, 10. Aug. 2011 (CEST)

1. Wenn ich mal dazu komme, mache ich einen Bug auf, damit die Programmierer der API beibringen eine Vorschau für Zusammenfassungszeilen zu erzeugen, aber allzu schnell kannst du nicht damit rechnen, dass das möglich ist.

2. + 3. habs im Code geändert

4. Mutig sein, das Skript einfach ändern, falls Fehler auftreten, diese notieren und sofort revertieren. So häufig lädt hier auch niemand Bilder hoch, dass du befürchten müsstest, irgendjemand dadurch zu behindern. --Schnark 12:26, 10. Aug. 2011 (CEST)

4: Hmm - blöd. Klar, hier bei dem Script ist der potentielle Schaden durch die nicht so häufige Verwendung nicht sehr groß - aber entspricht irgendwie nicht meinem Qualitätsgedanken. ;)

5: Müsste man nicht vielleicht noch "wikEd.UpdateFrame()" nach dem Einfügen der Infovorlage aufrufen, falls WikEd aktiv ist (für den Fall, dass er vor diesem Script aktiv wurde? Oder kann das nicht passieren (so wie jetzt in meiner Testumgebung)? Ich habe es nun einfach mal hier oben in den Vorschlag eingebaut.

Schön ist das aber halt nicht... Blöd, dass das mit WikEd so umständlich ist.

6: wikEd.useWikEd == true Habe ich mal noch in die WikEdAbfrage eingebaut - sonst gehts nicht richtig, wenn WikEd zwar an, daber deaktiviert ist.

7: Was hältst du davon (Vorschlag oben)? Viele Grüße --Saibo (Δ) 23:26, 10. Aug. 2011 (CEST)

1. Wenn ich mich nicht auf die Dokumentation verlassen hätte, dann hätte ich schon früher herausgefunden, dass das bereits jetzt schon geht. Ich habe Code eingebaut, damit beim Reupload der Inhalt als Zusammenfassung geparst wird.

5. Ich habe keine Ahnung, zu welchem Zeitpunkt wikEd aktiv wird, prinzipiell schadet es nichts, den Inhalt immer hin und her zu übertragen, du darfst allerdings nicht blind auf wikEd zugreifen, da du sonst einen ReferenceError erhältst, wenn ein Benutzer wikEd nicht verwendet. Lesenswert in diesem Zusammenhang ist mw:JSPERF#Null or undefined (der Rest der Seite ist auch interessant).

6. Ja, du hast recht; nur ist == true völlig redundant.

7. Ich habe den Code entsprechend meinen Bemerkungen angepasst und sehe keine weiteren Probleme mehr.

--Schnark 09:57, 11. Aug. 2011 (CEST)

1. Super - geht mit und ohne WikEd und interpretiert richtigerweise externe Links und Vorlagen nicht.

5. Danke. en:User:Cacycle/wikEd_development#wikEd_API Sagt dass man um "test a wikEd variable (e.g. wikEdUseWikEd) without throwing an error if wikEd is not loaded" nur "typeof(wikEd.useWikEd) != 'undefined'" testen muss. Ohne WikEd hatte ich es noch nicht getestet gehabt - hätte ich natürlich noch gemacht und habe es nun gemacht: Ja, es kommt in der Tat ohne WikEd "ReferenceError: wikEd is not defined". Ist Cacycles Beschreibung also falsch oder verstehe ich sie falsch?

7. ich habe noch ein paar Kommentare hinzu und parseAsSummary klarer belegt. Für "if ($editbox.length != 1) return;" stimmt doch der Kommentar "exits silently if not exactly one #wpUploadDescription is found", oder?

8. Ist nun deployt (funktioniet in Opera, Firefox und (gleich auch in) IE getestet. Danke! :) Viele Grüße --Saibo (Δ) 00:38, 12. Aug. 2011 (CEST)

5. Man muss die Beschreibung von Anfang an lesen: Das if (typeof(wikEd) == 'undefined') { wikEd = {}; } gehört auch noch dazu. Ich persönlich empfinde es aber als unschön einfach so eine globale Variable einzuführen.

7. Ja.

8. Danke. --Schnark 09:46, 26. Aug. 2011 (CEST)

Grösse des Eingabefelds

Siehe BD:Nightflyer#Neue Version hochladen: Wäre es möglich, das Eingabefeld Dateiänderungen bei Re-Uploads kleiner (weniger hoch) zu machen? --Leyo 21:31, 31. Aug. 2011 (CEST)

Ich wusste, dass diese Frage irgendwann kommen würde. Es sollte gehen, wenn du noch folgende Zeile ergänzt:

  } else {
     parseAsSummary = true; // bei Upload von neuer Dateiversion wird eingegebener Text nur im Log erscheinen
     $editbox.attr('rows', '1').css('height', '1em'); //nur einzeilig
     $('.hide-for-reupload').hide();
     $('.show-for-reupload').show();
  }

Mit enthalten ist auch schon der Code für deinen nächsten Punkt. --Schnark 09:33, 1. Sep. 2011 (CEST)

Danke! Ich hab's umgesetzt. Nun werden bei mir (FF) aber alle „g“ usw. unten abschnitten. Erhöht man dafür am besten '1em'? --Leyo 10:38, 1. Sep. 2011 (CEST)

Du hast recht. Mach mal 1.5em oder so daraus. Ein .css('height', '') müsste es zwar eigentlich auch tun, führt bei mir aber zu einem zweizeiligen Eingabefeld, auch wenn ich nicht verstehe warum. --Schnark 11:02, 1. Sep. 2011 (CEST)

Mit 1.5em passt's. --Leyo 11:09, 1. Sep. 2011 (CEST)

Hmm.... passt mir nicht. Ein Mehrzeiliges Eingabefeld, bei dem nur eine Zeile angezeigt wird: bäh!. Außerdem unübersichtlich bei längeren Kommentaren. Bitte zurück. Wirklich nicht nötig. Man muss doch nicht überall dran herumbasteln... Viele Grüße --Saibo (Δ) 01:40, 2. Sep. 2011 (CEST)

Gut, neuer Versuch:

  } else {
     parseAsSummary = true; // bei Upload von neuer Dateiversion wird eingegebener Text nur im Log erscheinen
     $editbox.replaceWith(mw.html.element('input', {'class': 'mw-summary', id: 'wpUploadDescription',
                                maxlength: '250', size: '60', value: '', name: 'wpUploadDescription',
                                type: 'text'})); //durch einzeiliges Eingabefeld ersetzen
     $editbox = $('#wpUploadDescription'); //neues Eingabefeld speichern
     $('.hide-for-reupload').hide();
     $('.show-for-reupload').show();
  }

Das muss aber gründlich getestet werden. --Schnark 09:45, 2. Sep. 2011 (CEST)

Ich hab's mal testweise übernommen. Bei mir wird das Feld nur etwas weniger breit gemacht, die Höhe bleibt gleich. So sollte es IMHO nicht (zu lange) bleiben. --Leyo 16:59, 2. Sep. 2011 (CEST)

Unter anderem solche Dinge meinte ich mit gründlichem Testen. --Schnark 09:23, 3. Sep. 2011 (CEST)

  } else {
     parseAsSummary = true; // bei Upload von neuer Dateiversion wird eingegebener Text nur im Log erscheinen
     $editbox.replaceWith(mw.html.element('input', {'class': 'mw-summary', id: 'wpUploadDescription',
                                maxlength: '250', size: '60', value: '', name: 'wpUploadDescription',
                                type: 'text'})); //durch einzeiliges Eingabefeld ersetzen
     $editbox = $('#wpUploadDescription'); //neues Eingabefeld speichern
     $editbox.css('height', 'auto'); //Höhe korrigieren
     $('.hide-for-reupload').hide();
     $('.show-for-reupload').show();
  }

Ich kann JS (im Gegensatz zu CSS) leider nur live testen. Wenn das Ergebnis schlimm gewesen wäre, hätte ich den Edit natürlich sofort rückgängig gemacht.

Jetzt passt es, ausser dass die Zeile für meinen Geschmack etwas kurz geraten ist. Ich würde die Länge etwa verdoppelt auch unter Berücksichtigung des vorgegebenen Textes lud eine neue Version von „Datei:…“ hoch: hat man noch etwas Luft bis zum Erreichen der 250 Zeichen.

Wenn man auf Datei hochladen klickt, aber etwas vergessen hat und somit die Warnung Die hochgeladene Datei ist leer. […] erscheint, hat das Feld Dateiänderungen wieder die ursprüngliche Grösse. --Leyo 11:51, 3. Sep. 2011 (CEST)

Non-live Testen kannst du so (zumindest machte ich es so): per Adblock Originalscript blockieren und per Firebug das neue Script per Konsole laden. Eigentlich meinte ich, dass einzeilig generell Mist ist... Wieso so klein wenn doch Platz ist? Viele Grüße --Saibo (Δ) 03:08, 4. Sep. 2011 (CEST)

Ich hatte Firebug schon mal erfolglos ausprobiert. :-(

Einzeilig ist sinnvoll, da es aussehen soll wie die normale Zusammenfassungszeile und nicht wie das Feld für die Informationsvorlage usw. (beim Erstupload von Dateien). Nur breiter sollte es sein. --Leyo 15:35, 4. Sep. 2011 (CEST)

Komm einfach mal in den Chat - vielleicht kann ich dir ja mit Firebug helfen.

Einzeilig: wie viele Zeichen nimmt denn ein Logeintrag auf? Sinnvollweise sollte man das dann auch gleich checken. However, ich finde nicht, dass man hier rumändern muss. Eine kurze Zeile ist blöd - da passt kaum was rein. Und ich habe mein Fenster nicht auf ner Breite von einem Meter - da ist die Zeile automatisch kleiner... Dann mach halt, wenn du so überzeugt davon bist. ;) Sonst beteiligt sich hier ja eh keiner. Viele Grüße --Saibo (Δ) 01:59, 5. Sep. 2011 (CEST)

ad Zeile zu kurz: Einfach size: '60' erhöhen, 60 ist die Länge des Feldes in Zeichen

ad Warnung nach Hochladen: Da vergisst der Server den Reupload-Parameter, da lässt sich wohl nichts machen

ad maximale Läge des Logbucheintrags: Die Grenze liegt immer bei 250 Byte, daher das maxlength: '250' (das sind 250 Zeichen, also etwas zu viel). Mit MW 1.18 ließe sich ein JS-Modul einbinden, dass aus der Begrenzung in Zeichen eine in Byte macht.

Hat einer von euch schon getestet, ob WikEd mit der Änderung klar kommt? D. h., findet er die geänderte Zusammenfassungszeile, um dort den Text wieder hineinzutun? Ich selbst kann das nicht testen, da ich meinen Firefox (durchaus mit Absicht) so konfiguriert habe, dass WikEd nicht läuft. --Schnark 09:31, 5. Sep. 2011 (CEST)

Achso, wenn die Grenze schon beschränkt ist, dann ist gut. Zweibytezeichen kommen ja hier wohl eher selten vor.

Die feste Zeilenlänge ist ungünstig (entweder sie ist den Widescreenmitvollbildfensterusern zu klein oder den Schmalfensterusern zu breit). Die normale (beim Bearbeiten von Artikeln/Seiten) Zusammenfassungszeile passt sich dynamisch an die Fensterbreite an. Weißt du wie das gemacht ist?

ad WikEd: Nein, läd nicht (sichtbar). Komischerweise aber auch nicht, wenn ich das Script per Adblock blockiere... muss wohl an was anderem liegen. Vielleicht gehts ja morgen wieder.. Viele Grüße --Saibo (Δ) 01:39, 6. Sep. 2011 (CEST)

Ich tendiere dazu, die Versuche das Feld einzeilig zu machen, aufzugeben. Die dynamische Breite ist über CSS an die ID wpSummary gekoppelt. Natürlich könnte man jetzt noch dafür dynamisch CSS erzeugen, aber auch wenn ich WikEd überhaupt nicht mag, ist eine Inkompatibilität von WikEd mit diesen Änderungen in meinen Augen ein Grund, die Änderungen nicht durchzuführen. --Schnark 10:25, 6. Sep. 2011 (CEST)

Nun klappt das Laden von WikEd (wie gesagt - es war auch mit blockiertem Uploadscript so, dass WIkEd nicht lud). Bei reUpload: WikEd erkennt das verkleinerte Feld und wandelt es in ein mehrzeiliges WikEd-Feld mit unbegrenzter Länge um, von dem aber nur eine Zeile angezeigt wird. Das ist sehr verwirrend - weil dann bei Erreichen des Zeilenendes der Text plötzlich wegscrollt ohne dass man einen Scrollbalken sähe. Wenn man das Feld so machen könnte, wie die Zusammenfassungszeile ist, wäre super, aber so wie es jetzt ist, ist es nicht gut. Viele Grüße --Saibo (Δ) 22:07, 6. Sep. 2011 (CEST)

Hier tut sich nichts, ich habe daher die Änderungen erstmal revertiert. Was auch noch fehlt, ist dass alles, was im Standardfeld steht in das neue, kleine umkopiert wird (ist mir eben passiert, dass ich tippte und nach Laden des Scripts alles weg war). Viele Grüße --Saibo (Δ) 00:49, 11. Sep. 2011 (CEST)

Solange sich keiner findet, der sich gut mit WikEd-kompatibler Programmierung auskennt (nein, das bin nicht ich), ist der Revert eindeutig das Beste. Die beiden letzten Zeilen können wieder rein, sobald es extra Texte gibt, die beim Reupload gezeigt bzw. versteckt werden sollen. --Schnark 09:12, 12. Sep. 2011 (CEST)

Wenn man verhindern könnte, dass WikEd bei dem verkleinerten Feld aktiv wird, dann wäre es ja auch gut, möglichst eben noch, dass sich das Feld dynamisch verbreitert, so wie das ZQ-Feld (das bekommt übers CSS den Parameter). Ich hab's nur blöderweise in meinen Texts nichts manuell zuweisen können. Keine Ahnung ob da noch an JS für die ZQ-Zeile aktiv ist.

Damit nach dem ersetzen des Feldes der alte Content da ist müsste man direkt nach dem Ersetzen übrigens einfach einmal umkopieren:

$('#wpUploadDescription').val($editbox.val()); //copy over the old content

Viele Grüße --Saibo (Δ) 22:38, 12. Sep. 2011 (CEST)

Für den Fullrevert sehe ich keine Berechtigung. Das riesige Feld empfinde ich als echt verwirrend für Neulinge (von denen wohl die wenigsten WikEd verwenden). Zumindest die Höhe sollte gegenüber dem Erstupload verringert werden. --Leyo 13:36, 15. Sep. 2011 (CEST)

Wie wär's übrigens mit nem Bugreport, statt hier herumzufrickeln? ;) Die Höhe kann von mir aus aus wenige Zeilen (vier?) reduziert werden (wenn du weiß wie es geht, dann mache es - ich versuchte es schon und bekam es nicht heraus). Daher der böseböse "Fullrevert". Einzeilig funktioniert es aber wie gesagt nur unschön. Viele Grüße --Saibo (Δ) 04:25, 16. Sep. 2011 (CEST)

Mit Bugzilla kenne ich mich leider nicht aus. Eine Verringerung der Zeilen auf ca. vier wäre schon ein Fortschritt, auch wenn ich nach wie vor ausgehend von meiner letzten Version eine Verbreiterung der Zeile bevorzugen würde. --Leyo 14:24, 16. Sep. 2011 (CEST)

Die Ersetzung durch ein einzeiliges Feld ist halt eine so massive Änderung, dass andere Tools, die die normale Mediawikioberfläche annehmen (wie WikEd) dann durcheinanderkommen. Die Reduktion der Höhe des immernoch mehrzeiligen Feldes dürfte nicht (oder keine) Probleme machen. Wenn Jemand weiß, wie das geht, gern. Mit

$j("textarea").eq(0).attr("rows", "4");

(oder ähnlich) gehts leider nicht (er ändert zwar die row-Anzahl im html, aber nicht in der Ansicht). Viele Grüße --Saibo (Δ) 23:36, 16. Sep. 2011 (CEST)

(ausrück) Wie in meinem ersten Vorschlag geht es im Prinzip:

     $editbox.attr('rows', '4').css('height', 'auto');

Nur musste ich feststellen, dass die Anweisung an den Browser, die Höhe automatisch einzustellen, zwar eine Änderung der Höhe bewirkt, diese aber auch nicht unbedingt etwas mit der Zeilenanzahl zu tun hat. Da der Zeilenabstand anscheinend 1.5em beträgt, kann man für 4 Zeilen css('height', '6em') wählen und hoffen, dass alles passt. --Schnark 09:24, 17. Sep. 2011 (CEST)

MediaWiki:Uploadtext

MediaWiki:Uploadtext passt bei Re-Uploads nicht mehr wirklich. Ist in dieser Hinsicht etwas möglich? --Leyo 21:46, 31. Aug. 2011 (CEST)

Alles, was für Re-Uploads versteckt werden soll, mit einem <div class="hide-for-reupload">...</div> (oder span etc., nur die Klasse ist wichtig) umgeben, alles, was für den Re-Upload eingeblendet werden soll, mit <div class="show-for-reupload" style="display:none">...</div> umgeben. Der obige Code macht diese Dinge dann sichtbar bzw. unsichtbar. --Schnark 09:33, 1. Sep. 2011 (CEST)

Ich habe unter MediaWiki Diskussion:Uploadtext auf diese Diskussion hingewiesen und möchte auf allfällige Reaktionen warten. Es scheint mir, dass quasi der gesamte Text ersetzt werden müsste. --Leyo 10:38, 1. Sep. 2011 (CEST)

Hört sich okay an. Das, was nur für Reuploads gilt, sollte aber dann vorangestellt einen Hinweis mit style="display:none" bekommen, dass folgendes nur für Reuploads gilt. Interpretiert ein Browser kein CSS steht es ja immer (auch bei Erstupload) da. Viele Grüße --Saibo (Δ) 01:47, 2. Sep. 2011 (CEST)

Ich kann mir zwar nicht vorstellen, dass heutzutage noch jemand mit einem Browser ohne CSS surft, und dann ausgerechnet eine Datei hochladen will, aber schaden kann es nichts. --Schnark 09:45, 2. Sep. 2011 (CEST)

Schaden kann es nicht, Korrekter ists. Viele Grüße --Saibo (Δ) 02:55, 4. Sep. 2011 (CEST)

Vorschaufunktion bei Reuploads funktioniert nicht

Hi, bei Reuploads macht die Vorschaufunktion exakt — nichts.

Lässt sich das einigermaßen einfach reparieren? Andernfalls könnte man den Vorschau-Knopf bei Reuploads auch gleich weglassen (sonderlich hilfreich ist er da ja sowieso nicht). --Patrick87 (Diskussion) 22:46, 8. Mai 2013 (CEST)

bugzilla:48319 --Schnark 09:35, 10. Mai 2013 (CEST)

Lokal behoben mit dieser Änderung. Der Umherirrende 09:30, 11. Mai 2013 (CEST)

Mit dem MediaWiki Update vom 20. Juni, sollte der Workaround nun nicht mehr nötig sein. --Patrick87 (Diskussion) 20:16, 20. Jun. 2013 (CEST)

Tastaturkürzel für Vorschau

Hallo Admins,

könnt ihr bitte folgende kleine Änderung einfügen, die es erlaubt die Vorschaufunktion mittels der Tastenkombination "Shift+Alt+P" zu aktivieren? Also genau so wie auch beim Bearbeiten von Artikeln.

Die Zeile
$('input[name="wpUpload"]').after($(mw.html.element('input', {value: previewText, type: 'button'})).click(function(){
bitte ersetzen durch
$('input[name="wpUpload"]').after($(mw.html.element('input', {value: previewText, type: 'button', accesskey: 'p'})).click(function(){
(die Änderung habe ich bereits in meiner Kopie des Scripts auf der englischen Wikipedia getestet)

Danke und Gruß, --Patrick87 (Diskussion) 21:44, 12. Mai 2013 (CEST)

Am besten sollte dann noch ein Aufruf von mw.util.updateTooltipAccessKeys dazu, also dem Button eine beliebige ID geben und nach dem Click-Handler noch ein mw.util.updateTooltipAccessKeys($('#beliebige ID')); einfügen. --Schnark 09:25, 13. Mai 2013 (CEST)

Da musst du mir kurz auf die Sprünge helfen... So funktioniert es nämlich nicht. --Patrick87 (Diskussion) 11:49, 13. Mai 2013 (CEST)

Ich hatte noch einen geeigneten title vergessen.

$('input[name="wpUpload"]').after($(mw.html.element('input', {value: previewText, title: previewText + ' [p]', type: 'button', id: 'wpPreview', accesskey: 'p'})).click(function(){

--Schnark 09:14, 14. Mai 2013 (CEST)

OK, super! Also bitte ändern wie in dieser Diff: User:Patrick87/UploadForm.js&diff=555105905&oldid=554601857. Danke, --Patrick87 (Diskussion) 22:13, 14. Mai 2013 (CEST)

Die nötigen Änderungen am Skript sind jetzt vorgenommen. Danke und Gruß, --Patrick87 (Diskussion) 00:30, 20. Mai 2013 (CEST)

Der Tastaturkürzel p wird von MediaWiki auf der Seite Spezial:Hochladen bereits für die Druckversion vergeben. Bei mehrfach vergebenen gleichen Tastaturkürzeln setzt der Browser bei Eingabe des Kürzels den Fokus zwischen den Stellen hin und her, aktiviert die Funktion aber erst bei einem Enter. Die Druckversion ist für diese Seite entbehrlich und kann komplett entfernt werden durch

$( '#t-print' ).remove();

Außerdem sollte

mw.util.updateTooltipAccessKeys($('#wpPreview'));

ersetzt werden durch

$('#wpPreview').updateTooltipAccessKeys();

und beim Erzeugen des Tooltips (title: previewText + ' [p]') kann der Zusatz + ' [p]' entfallen, da das durch die Funktion updateTooltipAccessKeys() erzeugt wird. --Fomafix (Diskussion) 08:55, 22. Jul. 2014 (CEST)

Kleine Anmerkung: Statt den kompletten Print-Link zu entfernen, wäre

// remove accesskey from "Printable version" sidebar link (conflicts with accesskey "p" for preview button on Special:Upload)
$('#t-print > a').removeAttr('accesskey');

wohl die elegantere Version. Ob es sinnvoll ist den doch ziemlich sinnlosen Link auf Special:Upload hingegen von vornherein zu unterdrücken wird in bug 56786 diskutiert. --Patrick87 (Diskussion) 21:04, 22. Jul. 2014 (CEST)

Wenn der Link für die Druckversion beibehalten wird und nur Tastenkombination entfernt, dann sollte der Tooltip auch entsprechen aktualisiert werden: $('#t-print > a').removeAttr('accesskey').updateTooltipAccessKeys();. --Fomafix (Diskussion) 16:22, 5. Aug. 2014 (CEST)

Wurde nun endlich umgesetzt. --Fomafix (Diskussion) 10:53, 7. Feb. 2015 (CET)