Benutzer Diskussion:Schnark

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche
Automatische Archivierung
Auf dieser Seite werden Abschnitte sonntags automatisch archiviert, deren jüngster Beitrag mehr als 30 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Die Archivübersicht befindet sich unter Archiv. Das momentan verwendete Archiv ist Archiv 3.

Herzlichen Dank …[Bearbeiten]

… für deine Skripte! Das macht die Arbeit um einiges einfacher. Auf Fliegelflagel bin ich nämlich erst durch diese „nette“ Warnung aufmerksam geworden. --Filzstift  09:23, 22. Jul. 2014 (CEST)

Laut Spezial:Linkliste/Benutzer:Schnark/js/jsmodules.js ist die Anzahl der Anwender innerhalb eines Tages um über 20 % gefallen, das hätte ich ehrlich gesagt nicht erwartet. --Schnark 10:49, 22. Jul. 2014 (CEST)
Ich denke diese Scriptverwaltung wird sich nun exponentiell verbreiten wie seinerzeit PDDs monobook. Ich würde ggf. die von dir nicht mehr unterstützten Module (z.B autoanträge) adaptieren und ein wenig die Werbetrommel rühren (vlt. könntest du auch noch meine 2 Scripte aufnehmen? S. β-WP). Kleine Kritik, der Speicherbutton ist inkonsistent oberhalb der Seite (Fliegelflagel) evtl. wäre ein 2.er unten kein Problem (z.B. wie in Bugzilla, oder die Navigation in der Versionsgeschichte etc…) Danke auch User: Perhelion10:42, 25. Jul. 2014 (CEST)
Siehe Benutzer:Schnark/js/fliegelflagel#Aufnahme fremder Skripte für die Bedingungen, unter denen ich Skripte anderer Autoren aufnehme. --Schnark 11:04, 25. Jul. 2014 (CEST)

Code-Review[Bearbeiten]

Hier fürs 1. meine besagten Vorschläge (mit Ausbaupotential):

1.

{
	id: 'threadSign',
	title: 'signing',
	description: 'Ermöglicht das automatische Signieren eigener Diskussionsbeiträge.',
	docpage: '//de.wikipedia.org/wiki/User:Perhelion/signing',
	category: 'edit',
	config: [
		{id: 'usersignature', desc: 'individuelle Signatur (einfach)'},
	]
	scripts: '[[User:Perhelion/signing.js]]'],
	only: action === 'edit'
},

2.

{
	id: 'autoSectiontId',
	title: 'auto-sectionSummary',
	description: 'Dieses Skript ergänzt automatisch den korrekten Seiten-Abschnitt in der Zusammenfassungszeile bei neuen / veränderten Abschnitten oder ganzseitigen Bearbeitungen.',
	docpage: '//de.wikipedia.org/wiki/User:Perhelion/sectionSummary',
	category: 'edit',
	scripts: '[[User:Perhelion/sectionSummary.js]]',
	only: action === 'edit'
},
Ich habe mich dabei etwas an Wikipedia:Technik/Skin/JS/mw/libs gerichtet (sollten dabei nicht veraltete Scripte gestrichen werden)⁈ PS: auskommentierter Code liegt aus Beta. L.G. User: Perhelion11:56, 15. Aug. 2014 (CEST)
Schon der erste Punkt meiner oben verlinkten Anforderungen ist nicht erfüllt, JSHint findet in beiden Skripten haufenweise Probleme. --Schnark 12:02, 15. Aug. 2014 (CEST)
Hm* ja das sind aber Lappalien, da ich sonst ein nowiki reinsetzen muss, werde ich korrigieren (ich habe ja auch ein „use strict“ drinnen). PS: beide sollten auch (ohne weitere config) global sein. Wie und was „deine“ Debug-Scripte tun habe ich auch noch nicht ganz verstanden (ich nehme mal an vglb. mit dem von jQuery). User: Perhelion12:11, 15. Aug. 2014 (CEST)
The Function constructor is a form of eval. ist alles andere als eine Lappalie, die Fehler in Benutzer:Perhelion/sectionSummary.js erst recht nicht (sobald du da auch den stritct mode verwendest, wirst du das deutlich bemerken). --Schnark 12:22, 15. Aug. 2014 (CEST)
Habe nun beide nochmal etwas überarbeitet (hatte bereits eine „stritct“-Version auf Beta), ich hoffe jetzt ist’s besser. Code-Tips nehme ich natürlich gerne entgegen. Mit der Ladeprozedur bin ich mir auch noch nicht ganz sicher, meinst du es wäre (fürs signing) besser das .hook Object zu verwenden? PS: ich habe auf externen Projekten neuerdings einen Fliegelflager-Fehler: Uncaught TypeError: Cannot set property 'userFallback' of undefined (global.js 53) VG User: Perhelion12:29, 16. Aug. 2014 (CEST)
Den Fehler in extratabs.js habe ich behoben.
Zu deinem Code so ein paar Dinge, die mir auf die Schnelle unangenehm auffallen:
  • editform = document.editform ist uraltes Level 0 DOM und sollte nicht mehr verwendet werden.
  • $(headlines).not(headlinesOld).get();: Ich meine zu verstehen, was das soll, wundere mich, dass es tatsächlich funktioniert, und bin mir sicher, dass das nirgends dokumentiert ist, und folglich niemals verwendet werden sollte.
  • $([":input#wpSave",":input#wpPreview",":input#wpDiff"]).each(function(){$(editform).on("click", this, forceSummary);}); Hat diese komplizierte Methode Events zu binden irgendeinen tieferen Sinn, den ich nicht verstehe?
  • cfg.wgSiteName === 'Wikipedia' macht mehr Probleme als es löst, da in fr dort beispielsweise Wikipédia steht.
  • cfg.wgUserLanguage === "de" Denk’ an die Schweizer und Österreicher, die wollen lieber Deutsch als Englisch lesen. Zudem kommen unten noch mal Lokalisierungen, die sollten alle an einem Platz sein.
--Schnark 11:33, 19. Aug. 2014 (CEST)
Vielen Dank für den Review! Ich werde mich mal heute Abend oder morgen darum kümmern (bzw. genauer dazu antworten). Dabei hätte ich auch Kritik zu einem deiner ersten Scripte, dem WikiEditor. Der Code scheint etwas umständlich bzw. unperformant (wie ich schon mal andeutete, ich Gegensatz zu Krinkles Script welches alle Buttons in einem Rutsch ins DOM schickt… mehr vlt. dazu dort, vlt. ist dass auch der Grund warum du ihn nicht im Default vom Fliegelflagel hast) Wobei ich gleich bei meinem 3. Vorschlag bin (der mir aber nicht so wichtig ist)c:sMirC Ich hatte überlegt diese wieder als Erweiterung für dein WikiEditor-Script zu gestallten, ich habe mich jedoch (aus mehreren Gründen dann doch) für ein Standalone entschieden (zudem du unserer erste „Zusammenarbeit“ ja als deprecated eingeordnet hast). Es ist schon etwas beschämend (für die WMF) dass es keine offizielle und einfache API, so wie für die klassische Toolbar gibt. Ich habe viel Code kommentiert, da ich festgestellt habe, dass ich selber nach paar Monaten alles vergesse.:P LG
  • @jQuery: wie du ja schon selber bemängelt hast, gibt es da von Zeit zu Zeit Änderungen. Aber es ist eigentlich schon für JavaScript an sich bezeichnend, dass es eine solche umfangreiche Ersatz-Lib geben muss. Ich habe mal mit Python angefangen, JS ist dagegen grottenschlecht zu händeln. User: Perhelion17:28, 19. Aug. 2014 (CEST)
Der Code von wikieditor.js ist alt und überarbeitungsbedürftig, aber nicht unperformant. Auch Krinkels und dein Skript fügen die Schaltflächen eine nach der anderen ins DOM ein. Auch bezüglich der API irrst du, während Wikieditor eine API für mehr oder weniger alle benötigten Aufgaben besitzt, ist es die alte Toolbar, deren API sehr bescheiden ist und nur einen Bruchteil der Dinge abdeckt, die man sinnvollerweise tun möchte. --Schnark 09:38, 22. Aug. 2014 (CEST)
Hallo Schnark, mit einer Antwort habe ich mich etwas schwer getan. Zum einen habe ich mich bemüht natürlich nichts falsches zu unterstellen. So bin ich leider mit der Code-Änderung immer noch nicht fertig.
  • @0 DOM: Dem kann ich leider nicht ganz folgen. Welche moderne Anleitung oder welchem konkreten deprecated Hinweis entspricht dies?
  • @Events binden: Ich bin eigentlich immer bestrebt gewesen keine eigene Syntax zu erfinden und dabei die Variante mit dem geringsten bzw. kompatibelsten, sprich jQuery-Code zu verwenden, so dass ich annehmen muss, dass der jQuery-Code inzwischen aktualisiert wurde, wenn du auf die ".click()"-Funktion hinaus willst. (Das ":input" ist natürlich überflüssig, bzw. dachte ich, dass wenn ich über das Parent-Element das Event binden würde, der Zugriff performanter ist.) Demnach wäre die bessere Lösung wohl diese: $(["#wpSave","#wpPreview","#wpDiff"]).each(function(){$(this).click(forceSummary);});
  • @Array: Das verwundert mich ebenfalls, eigentlich müsste das get() komplett überflüssig sein und tatsächlich ist diese nur für DOM-Elemente vorgesehen. Demnach würde wohl richtig .toArray() sein. Allerdings scheint hier auch $.makeArray() völlig redundant⁈
  • @Wikieditor: Tatsächlich bin ich [d/m]einer Behauptung nun gründlicher nachgegangen und habe dabei dieses Script verwendet. Demnach hält Krinkles Script irgendwie zwei Möglichkeiten bereit (ein Container falls das Textfeld noch nicht bereit ist⁈), der Normalfall ist allerdings wie du gesagt hast, jeden Button separat ins DOM zu schicken. Bei meinem Script allerdings werden tatsächlich 2 Gruppen in einem Rutsch (wohl wegen ihrer Gleichartigkeit) ins DOM geschickt. Einzig die Tab-Schaltfläche ist ein weiterer Zugriff (+ dem Icon-Hack), was darauf schließen lässt, dass die WikiEditor-API hier keine performantere Möglichkeit zulässt.
Ein paar kleine Fehler habe ich dann auch noch gefunden, ich melde mich dann wenn ich soweit bin. Schönes Wochenende. User: Perhelion13:33, 30. Aug. 2014 (CEST)
  • Ich halte es für einen Anachronismus, dass Formularelemente mit einem name-Attribut immer noch unter diesem Namen unter document erreichbar sind. Wenn man ohnehin jQuery verwendet, dann sollte man (von sehr seltenen Ausnahmen abgesehen), so tun, als gäbe es document gar nicht. Wenn du die Editform haben willst, nimmst du $('#editform').
  • $(["#wpSave","#wpPreview","#wpDiff"]).each(function(){$(this).click(forceSummary);}); ist keine bessere Lösung, sondern ebenfalls fehlerhafter Code. Wenn man $() ein Array als Parameter übergibt, muss es ein Array aus DOM-Knoten sein. Dein augenblicklicher Code bindet (unter Ausnutzung der Merkwürdigkeit, dass er trotz des Arrays funktioniert) drei Eventhandler an die Editform, die alle per Eventdelegation ein Kindelement überwachen, was so ziemlich das komplizierteste Verfahren ist, das ich mir vorstellen kann. Was spricht denn gegen die offensichtliche Lösung $('#wpSave, #wpPreview, #wpDiff').click(forceSummary);?
  • Wie bereits geschrieben muss ein Array, das $() als Parameter übergeben wird, ein Array aus DOM-Knoten sein. jQuery ist für DOM-Manipulationen da, nicht für Array-Manipulationen. Unabhängig davon, ob der Code funktioniert, ist Code, der ein gewöhnliches Array an $() übergibt, falsch.
  • Wenn du ernsthaft mit jQuery arbeiten willst, solltest du dir die Dokumentation vollständig durchlesen.
  • Beim Wikieditor hast du recht, aber nur in diesem einen speziellen Fall: Wenn man gleichzeitig eine neue Gruppe anlegt und ihr mehrere Schaltflächen hinzufügt, kommt es nur zu einer DOM-Manipulation. In allen anderen Fällen, also insbesondere wenn man (mehrere) Schaltflächen zu einer schon bestehenden Gruppe hinzufügt, werden die Schaltflächen unabhängig von der Art des Aufrufs einzeln in den DOM-Baum eingefügt. --Schnark 10:51, 2. Sep. 2014 (CEST)
Hallo Schnark, danke der ausführlicheren Erklärung. Ich habe nun alle Scripte überarbeitet (und noch mal kleinere Fehler behoben). Auf Beta sind diese als Gadget eingerichtet (seit heute auch autoSectiontId) Des Weiteren schlage ich noch dieses (am Rande erwähnte, welches ich noch erweitern möchte) vor!?:

3. (international, nun am Projekt angepasstem Datei-Namensraum)

{
	id: 'emoticons',
	title: 'Emoticons',
	description: 'sMirC-Emoticons-Set für den WikiEditor (~70 Smilies)',
	docpage: '//commons.wikimedia.org/wiki/SMirC', // not really?
	category: 'edit',
	scripts: '//meta.wikimedia.org/w/index.php?title=User:Perhelion/WikiEditorEmoticons.js&action=raw&ctype=text/javascript&maxage=86400&smaxage=86400&bcache=1',
	only: action === 'edit'
},
Dabei ist mir aufgefallen dass beim Fliegelflagel (hast du hier schon ein Kürzel? :P) einbinden only: function (action) {return action === 'edit';}, nicht funktioniert!?[1] Was ich noch machen wollte (und leider nicht hinbekommen habe), ist die {{int: Variablen zu nutzen (mein Versuch mittels mw.message( 'prefs-signature')). Das wäre auch für das autoSectiontId-Script ganz nützlich. (PS: das editform = document.editform entferne bzw. ersetze ich gleich noch gänzlich) LG User: Perhelion19:37, 8. Sep. 2014 (CEST)
Dass ein Skript nicht geladen wird, wenn du prüfst, ob der aktuelle Namensraum 'edit' lautet, ist doch eigentlich offensichtlich, oder?
Bei deinen Skripts fallen mir immer noch beim groben Überfliegen einige Punkte auf, die noch korrigiert werden sollten:
http://de.wikipedia.beta.wmflabs.org/wiki/Benutzer:Perhelion/signing.js: ["edit", "submit"].indexOf Nicht, dass ich den IE8 als das Maß aller Dinge ansehe, aber trotzdem solltest du keinen Code verwenden, der dort nicht funktioniert (http://kangax.github.io/compat-table/es5/#Array.isArray).
if (cfg.wgContentLanguage === 'de') { regpages2 = ['Meinung']; } Auf N:Wikinews:Meinungen wird nicht signiert, aber dein Skript nimmt das fälschlicherweise an.
$textarea.textSelection Um das zu verwenden, musst du explizit jquery.textSelection laden (auch wenn es tatsächlich ohnehin geladen wird).
e = (e && window.Event)? e.target : e.srcElement; Das erste Argument in einem per jQuery gebundenem Event-Handler ist grundsätzlich ein jQuery-Event und sollte als solches behandelt werden.
http://de.wikipedia.beta.wmflabs.org/wiki/Benutzer:Perhelion/sectionSummary.js: ["edit", "submit"].indexOf siehe oben
sumM.new funktioniert zwar, trotzdem ist ein Identifier, der eigentlich ein Schlüsselwort ist, sehr unschön.
$(headlines).not(headlinesOld) Es gilt immer noch, was ich das letzte Mal geschrieben habe: Wenn man ein Array an $ übergibt, dann muss es ein Array aus DOM-Knoten sein, alles andere ist falsch, auch wenn es funktioniert.
mw.hook( 'wikipage.content' ).add(libs.autoSectiontId.exec); Mit LivePreview (in den Einstellungen aktivieren) wird das zu mehrfacher Ausführung führen.
--Schnark 10:15, 9. Sep. 2014 (CEST)
I'll do fix that all, but I don't see an easy alternative to not()!?
Ok I used the hook() to load the script before ready() (but yes I don't understand it really, but it get not loaded twice because I have another load check in it: if (typeof libs.autoSectiontId === 'object')!?)
@indexOf() I really don't believe the script work with IE8, but anyway the IE8 is not in the your given table!?
Yes I need more to do read some more documentation. Have a nice day. User: Perhelion 03:21, 11. Sep. 2014 (CEST)
Auch wenn ich hier gerade mehr auf Englisch als auf Deutsch schreibe, kannst du weiterhin Deutsch verwenden.
Jedes Mal, wenn der Hook aufgerufen wird (und beim LivePreview passiert das mehr als ein Mal pro Seite) wird libs.autoSectiontId.exec ausgeführt, daran ändert das if (typeof libs.autoSectiontId === 'object') nichts.
Der IE8 steht in der Tabelle, du musst nur die alten Browser explizit einblenden.
--Schnark 11:24, 11. Sep. 2014 (CEST)

Benutzer:Schnark/js/CSS#Interwikilinks auf wichtige Sprachen hervorheben[Bearbeiten]

Hallo Schnark, ich habe das die Tage ausprobiert; es funktioniert aber nicht. Ich nahme an, weil es noch aus der Prä-Wikidata-Zeit stammt? Gruß --Schniggendiller Diskussion 23:34, 2. Aug. 2014 (CEST)

Dir fehlt die schließende Klammer zu li.mw-history-line-updated {, sodass alles danach nicht funktionieren kann. CSS ist zwar sehr großzügig bei der Behandlung von Syntaxfehlern, aber geschweifte Klammern sind die Ausnahme, die müssen exakt stimmen. irgendwas; !important;, was bei dir zwei Mal vorkommt, ist auch falsch, entweder muss das !important; weg (wenn es bisher funktionierte), oder das Semikolon davor (falls das important tatsächlich notwendig ist). Das führt aber wenigstens nicht zu Folgefehlern. --Schnark 10:57, 8. Aug. 2014 (CEST)
Da du die Syntaxfehler immer noch in deinem CSS-Code hast, nehme ich mal an, dass du heutzutage nur noch auf ein Ping reagierst: @Schniggendiller:. --Schnark 11:04, 5. Sep. 2014 (CEST)
Schande, das hier habe ich tatsächlich aus den Augen verloren, danke für die Erinnerung. Die Syntaxfehler habe ich jetzt behoben, die engl. Interwikis werden jetzt auch hervorgehoben.
Du hast nicht zufällig eine Idee, warum es mir nicht gelingt, die Links auf Wikidata auf der BEO einzufärben?
Gruß --Schniggendiller Diskussion 00:23, 6. Sep. 2014 (CEST)
Ich färbe sie mittels li.wikibase-edit .plainlinks { color:#36B; } wie externe Links. --Leyo 00:44, 6. Sep. 2014 (CEST)
Zu Wikidata auf der Beobachtungsliste kann ich nichts sagen, da ich dank bugzilla:44874 dort einerseits keine Wikidata-Bearbeitungen sehe (was ich von Programmierern halte, die einen Bug, der mit "high", "critical", "16 votes" markiert ist, über ein Jahr völlig ignorieren, behalte ich besser für mich), andererseits dank Benutzer:Schnark/js/watchlist++ meine Beobachtungsliste ohnehin nicht mehr verwende. Aber [href*="https://www.wikidata.org"] kommt mir verdächtig vor, da ich protokollrelative Links erwarte, womit [href*="//www.wikidata.org"] korrekt wäre (und mit *= würde das auch mit Protokoll funktionieren). --Schnark 09:09, 6. Sep. 2014 (CEST)
Danke euch beiden, hat jedes für sich geholfen :-)) VG --Schniggendiller Diskussion 01:42, 13. Sep. 2014 (CEST)

New wikEdDiff / wDiff[Bearbeiten]

Hi Schnark,

After a long time, I have finally found the time to improve/rewrite wikEdDiff (.js) and its underlying wDiff (.js) library. It now has the following features and improvements:

  • Improved design and integration (colors, popup titles)
  • Stepwise split (paragraphs, sentences, words, chars)
  • Recursive diff
  • Bubbling up of ambiguous unresolved regions to line break
  • Optimizing the length of moved blocks
  • Moved blocks can contain insertions and deletions

I have tested it extensively and would like to hear your suggestions and your opinion, especially how it compares to Benutzer:Schnark/js/diff. Cacycle (Diskussion) 17:56, 27. Aug. 2014 (CEST)

The new diff looks really nice, though some block moves are still strange: On [2] look at the moved block marked in light green ("window.scroll(0, wikEd.GetOffsetTop(wikEd.inputWrapper));"). It is followed by a deletion inside the block, but that deletion goes until the end of the block. It's a bit strange to say that part was moved up there and then got deleted, instead of simply showing the deletion at the place where the block was originally.
One of my favorite diffs for testing is [3], which looks a bit strange, too. --Schnark 11:05, 28. Aug. 2014 (CEST)
Thanks for your suggestions! The deletion inside the light green block in wikEd diff is a special rare case as it is located right between two moved blocks. One of these blocks was invisible because it was converted to a deletion/insertion pair due to its small size. I have now improved the program, conversion of too short blocks into deletion/insertion pairs now actually un-links the respective words and repeats the block detection. This also helps avoiding sections consisting of mixed insertions and deletions - these are now one large deletion block followed by a large insertion block. Also, the Burg Gliechenstein diff looks better now for the same reason. Cacycle (Diskussion) 23:09, 1. Sep. 2014 (CEST)
Now you seem to have some endless loop in the script. On https://en.wikipedia.org/w/index.php?title=User%3ACacycle%2FwikEd.js&diff=623747179&oldid=623033506 Firefox warns me about an unresponsive script, but even if I let the script continue running many times, it doesn't finish. The line numbers at which Firefox pauses change, but https://en.wikipedia.org/w/index.php?title=User:Cacycle/diff.js&action=raw&ctype=text/javascript:2223 occured several times, so the loop seems to be around there. --Schnark 10:55, 2. Sep. 2014 (CEST)
It is not an endless loop, it just takes a while. After page load, it has to fetch both versions before it starts diffing. I have timed it, the first word-based diff calculation takes 7 s, the first char-based diff calculation takes 3 s, and the diff shortening (line 2223) takes 10 s for me. I will try to optimize these two routines - but this is probably the most extreme diff you can find on Wikipedia with its 2500 (!) diff tags and an article size of 755 kB. BTW, I have just changed the block colors to gray, added mouseover highlighting, and added jumping between block and mark upon clicking. Cacycle (Diskussion) 00:26, 3. Sep. 2014 (CEST)
I tried again, and now was patient enough to wait for the end. I had to click away the warning about an unresponsive script 6 times, which means it took 45 s for me, while my own script takes 5 seconds. --Schnark 10:48, 3. Sep. 2014 (CEST)
Version 0.1.10 is now heavily optimized for speed! Loading still takes a while though. Cacycle (Diskussion) 15:19, 8. Sep. 2014 (CEST)
Now it works without warnings about an unresponsive script, and only takes 15 seconds. Just to explain why I'm interested in large diffs, too: My script Benutzer:Schnark/js/artikel-statistik.js tries to find out the author of each piece of the text. To correctly handle texts that were deleted at some time and restored a few revisions later, it has to keep all the old versions in memory. It basically creates a diff of the first two revisions, then a diff between this diff and the third, a diff between that diff and the fourth, and so on. For large articles this means the script has to create many diffs that are really big. --Schnark 09:36, 9. Sep. 2014 (CEST)

Schnark: For typical Wikipedia edits, especially block deletions and re-insertions, you probably do not need recursive diffing. Turning it off (wDiff.recursiveDiff = false;) will accelerate the example by a factor of 10 in version 0.9.13! Cacycle (Diskussion) 15:31, 11. Sep. 2014 (CEST)

Custom css formatting of your diff not working[Bearbeiten]

Hi Schark,

I have a few formatting changes to you diff in my common.css. These stopped working a month or so ago. Do you know why?

I thought you might have renamed your classes but these seem to be the same names so I can't work it out.

Yaris678 (Diskussion) 15:38, 9. Sep. 2014 (CEST)

Oops, sorry. I didn't rename the classes .enhanced-diff-ins etc., but I did rename the #enhanced_diff (I wanted to get rid of most underscores in my scripts). Actually, there is no longer an element with an id, but using a class should be enough to override my styles. Replace any occurence of #enhanced_diff by .schnark-diff-container, and it should work again. --Schnark 09:14, 10. Sep. 2014 (CEST)
Cool. I have tweaked my common.css as you suggest and it works well now. Thanks. Yaris678 (Diskussion) 09:49, 11. Sep. 2014 (CEST)

Stubgenerator für Filme[Bearbeiten]

Hallo Schnark, ich mache mich langsam mit den Funktionen von Fliegelflagel vertraut und bin auf den Stubgenerator gestoßen. Cooles Tool! Habe gesehen, dass es das schon für Personen gibt. Ich hätte ja gern einen Filmartikelgenerator auf Grundlage der Formatvorlage Film. Denkst du, dass so etwas umzusetzen wäre? Hier gibt's eine Liste der filmbezogenen Properties bei Wikidata. –ðuerýzo ?! SOS 14:42, 11. Sep. 2014 (CEST)

Prinzipiell ist das möglich, die Konfiguration muss an drei Stellen ergänzt werden: Zum einen braucht es Benutzer:Schnark/js/stub.js/film (mit Inhalt analog zu Benutzer:Schnark/js/stub.js/person). Der Teil ist hoffentlich so leicht verständlich, dass du ihn selber anlegen kannst (auch unter Benutzer:Schnark/js/stub#Konfiguration dokumentiert). Die zweite Teil ist Benutzer:Schnark/js/stub.js/main.json (auch einfach, da muss nur ein "Film": "film" in die letzte Zeile dazukommen, um für Dinge, die ein Film sind die neue Film-Vorlage zu verwenden). Kompliziert ist der dritte Teil Benutzer:Schnark/js/stub.js/film.json. Ich bin immer noch nicht wirklich glücklich mit dieser Art von Konfiguration, mir fällt aber auch nichts besseres ein. Ich schlage vor, dass du einfach mal Benutzer:Schnark/js/stub.js/film anlegst, und ich die dazu passende Benutzer:Schnark/js/stub.js/film.json erstelle (wobei du dich natürlich gerne auch selbst daran versuchen kannst, wenn du meinst die Dokumentation oder Benutzer:Schnark/js/stub.js/person.json zu verstehen, kaputt machen kannst du nichts). --Schnark 09:48, 12. Sep. 2014 (CEST)
Ok, ich werde mal sehen, wann ich dazu komme. Mit dem Stubgenerator für Personen habe ich eben die Artikel Charles Grenzbach, Jan Domela und Edmond L. DePatie angelegt, wirklich ein tolles Tool!!! –ðuerýzo ?! SOS 10:00, 12. Sep. 2014 (CEST) ‎

Use of improved diffs in resolving edit conflicts[Bearbeiten]

Hi Schnark,

I think edit conflicts are a big deal. They don't seem like it to experienced editors, but they can be very off putting to new users. And a new user may get them more frequently, especially if they have just created an article and then other users pile in with their improvements.

I think the improved diff technology developed by you and Cacycle could help in this regard. I think that your article statistics add-on is especially helpful because it looks at more than one edit simultaneously.

What I think we want is something that, when there is an edit conflict, looks at the two changes and calculates a combined article. There will be some cases where this is just impossible, but with good diff calculation, it should be possible in a lot of cases. What do you think?

Yaris678 (Diskussion) 21:38, 11. Sep. 2014 (CEST)

What you propose is actually done already: When there is an edit conflict MediaWiki uses en:diff3 to try to do a three-way-merge. Only when this fails the user is informed about the edit conflict. Of course there may be edge cases where Cacycle's or my diff could resolve the conflict even if diff3 failed to do so, but I don't think they are that common. --Schnark 09:56, 12. Sep. 2014 (CEST)
Yes. It is these edge cases that I am concerned about. They are not common for most users, which is why most editors don't think about it most of the time. However, one of the most likely occasions is on a new article. New articles attract a lot of edits. New users often create new articles and so are more likely to be presented with an edit conflict that hasn't been resolved automatically. They also have the lowest amount of experience to draw on when they try to resolve the conflict manually and may just conclude that editing wikis is too hard. This is why I think it is a bigger issue than experienced editors may realise. I also think that solving this issue could help with new-editor retention, which is one of the things that a lot of the community is concerned about. Yaris678 (Diskussion) 15:16, 15. Sep. 2014 (CEST)

Benutzer:Schnark/js/syntaxhighlight[Bearbeiten]

Hallo Schnark, zuerst bedanke ich mich für deine Skripte und vor allem dieses spezielle Skript, um das es hier gehen soll.

Seit einigen Tagen habe ich festgestellt, dass es sowohl mit Google Chrome als auch mit Opera nicht ordnungsgemäß funktioniert. Ich benutze die aktuellste Chrome-Version 37.0.2062.120 und Opera-Version 24.0.1558.53. In beiden Browsern tritt der gleiche Fehler auf. Der Fehler liegt darin, dass der Text nicht dort positioniert ist, wo das Skript es annimmt.

Ich habe festgestellt, dass beim Laden das Bearbeitungsfeld zuerst ohne Skript korrekt geladen wird ([4]) und dass beim Laden des Skriptes der Zeilenabstand des Textes verringert wird und gleichzeitig die Syntaxhervorhebung erscheint. Folglich sieht das Bearbeitungsfeld am Ende so aus: [5]. Hier sieht man, dass Text und Syntaxhervorhebung nicht exakt übereinander positioniert werden. Hier wird der geringere Zeilenabstand beim Text (weiße Schrift) im Vergleich zum vom Skript angenommenen Text (schwarze Schrift) deutlich.

Mit Firefox tritt dieser Fehler nicht auf.

Vielen Dank für deine Hilfe! Grüße --Daniel749 Disk. (STWPST) 22:10, 12. Sep. 2014 (CEST)

Ich verwende Google Chrome eigentlich nie, sondern nur Firefox, habe aber gerade mal wieder auf die Schnelle eine portable Version installiert um das Problem zu testen. Es war die exakt die gleiche Chrome-Version wie bei dir, aber bei mir hat die Syntaxhervorhebung perfekt gepasst. Beim letzten Mal, als ich es versucht hatte, war die Verschiebung deutlich schlimmer als auf deinen Screenshots, aber seitdem habe ich diese Änderung vorgenommen, die eigentlich gegen die Reste von Bug 395425 ausreichen sollte. Ich weiß also nicht genau, warum bei dir die Zeilenhöhen nicht zusammenpassen. Falls diese Änderung nicht hilft: Funktioniert bei dir Remember the dot's Original? Funktioniert es, wenn du etwas am Browser-Zoom änderst? Funktioniert es, wenn du directWrite deaktivierst? --Schnark 09:48, 13. Sep. 2014 (CEST)
Deine Änderung hat schon ausgereicht, dass es wieder funktioniert. Auch beim Browser-Zoom funktioniert alles. DirectWrite habe ich standardmäßig aufgrund dieses Problems deaktiviert. Nochmals danke! Gruß --Daniel749 Disk. (STWPST) 10:21, 13. Sep. 2014 (CEST)
Google Chrome rechnet wohl an einigen Stellen auch in Bruchteilen von Pixeln, aber offenbar nicht wirklich konsistent, sodass die Zeilenhöhen zwar nominal den gleichen Wert hatten, intern aber verschiedene Werte verwendet wurden, sodass sich die Zeilen des Textes und der Hervorhebung immer weiter verschoben haben. --Schnark 11:15, 13. Sep. 2014 (CEST)