Benutzer Diskussion:Umherirrender/Archiv/2018-2
Löschung meines Accounts
Hallo Umherirrender,
könntest du mein Account komplett und irreversible löschen? Admins wie JD wollen über meine Benutzerseite herrschen. Ich lehne das kategorisch ab. Es sind meine Seiten. Da hier kein Konsens erzielt wird, will ich die Seiten unwiederuflich killen lassen. Also rote statt blaue Schrift. Keine Versions- kontrollen mehr, kein rein garnichts mehr. Ich verlasse die Wikipedia endgültig auf Nimmerwiedersehen. Nochmal: Nein, ich will keine freiwillige Selbstsperre, sondern eine komplette Löschung. Danke für deine letzte Hilfe und Tschüss...
Quern (nicht signierter Beitrag von Quern (Diskussion | Beiträge) 13:47, 7. Jul. 2018 (CEST))
- @Quern: Umherirrender ist seit Mai inaktiv. JD will nicht herrschen, er setzt nur geltende Regeln um. Admins können auch gelöschte Seiten sehen, und Accounts löschen geht nicht, das lässt die Software nicht zu. Viele Grüße, Luke081515 14:01, 7. Jul. 2018 (CEST)
- Mir egal, ob man gelöschte Seiten sehen kann, macht meine Seiten endlich platt. --Quern (Diskussion) 14:46, 7. Jul. 2018 (CEST)
- Hallo Quern, Diskussionsseiten angemeldeter Benutzer werden grundsätzlich nicht gelöscht, siehe Wikipedia:Diskussionsseiten#Benutzer ansprechen (letzter Absatz). Deine Benutzerseite, also Benutzer:Quern, kann aber problemlos gelöscht werden, wenn Du das möchtest. Soll ich das tun? (Dein Streit mit JD scheint sich ja nur deine Disku zu betreffen, deswegen die Nachfrage.) Gruß --Schniggendiller Diskussion 15:01, 7. Jul. 2018 (CEST)
- Mir egal, ob man gelöschte Seiten sehen kann, macht meine Seiten endlich platt. --Quern (Diskussion) 14:46, 7. Jul. 2018 (CEST)
Würdest du bitte
Diese Edits prüfen und so anpassen, dass die Seiten nicht verunstaltet bleiben. Ich habe es hier (vorher deine Umstellung → nach Anpassung Sign. Skafa) schon geändert. Da du jedoch der Verursacher bist wäre es nett, wenn du die restlichen paar mal anpassen könntest. Vielen Dank im Voraus. --Liebe Grüße, Lómelinde Diskussion 08:49, 30. Aug. 2018 (CEST)
- @Lómelinde: Der Umherirrende ist hier nur noch selten und dann in wichtigen Angelegenheiten tätig.
- Wenn ich das richtig sehe, geht es darum, dass irgendjemand anders seine Fancy-Signatur mit nicht sehr intelligentem HTML geschmückt hat, so dass die angestrebte optische Wirkung jetzt nicht mehr erzielt wird.
- Der Umherirrende hatte wohl Syntaxfehler behoben; die dekorative Optik liegt in der Verantwortung des Signierers.
- LG --PerfektesChaos 16:20, 1. Sep. 2018 (CEST)
- Er hat eine Benutzervorlage ersetzt und dadurch die defekte Syntax erzeugt, ob sie vorher schon defekt war weiß ich nicht, vermutlich stand das mal so in der Vorlage wenn es dieser Benutzer:Skafa~dewiki/Unterzeichnung ähnlich war, denn es wunderte mich schon, dass so etwas durch einem Profi erfolgte. Soll ich demnach einen Benutzer bitten, der entweder seit 2009 oder seit 2015 nicht mehr aktiv ist, diese Seiten anzupassen? Klar kann ich das auch selbst, aber ist der Umherirrende nicht in der Lage diese Fehler anzupassen, darf er sich nur um „wirklich wichtiges“ kümmern? Dass er selten hier ist weiß ich, ich sah nur die Ersetzung und habe hier gefragt, weil er diese durchgeführt hat. Außerdem, ist es immer mein Ziel andere für diese Fehler zu sensibilisieren, nur dann wenn alle darauf achten haben wir überhaupt eine Chance dieser Fehlerflut Herr zu werden. Es läuft nicht weg. --Liebe Grüße, Lómelinde Diskussion 06:33, 2. Sep. 2018 (CEST)
- @Lómelinde:
- Der Umherirrende wird die einfach nur gesubstet haben.
- Das heißt, er fügt in die Seite ein
{{subst:Benutzer:Skafa/Unterzeichnung}}
und speichert ab. - Das heißt, er hat den Quellcode der Benutzervorlage niemals gesehen.
- Er hatte nur ein gutes Werk getan und die Namensräume von einer überflüssigen Vorlagenfummelei befreit, und dafür bin ich erstmal dankbar.
- Die Verantwortung für die dekorierende Syntax liegt bei dem Benutzer, der die „Vorlage“ programmiert hatte.
- Selbst wenn der Umherirrende, was ich nicht glaube, den Inhalt eingefügt hätte statt wie üblich zu substen, so ist es allgemeiner Usus, die vom Benutzer gewünschte Programmierung 1:1 zu übernehmen.
- In keinem Fall wäre er dazu verpflichtet gewesen, 2015 eine damals noch nicht beanstandete HTML-Syntax umzuschreiben.
- Er hat nicht seine persönliche Signatur entworfen, er hat keine Vorlage für die Allgemeinheit programmiert, er hat die Syntax nicht gebaut, sondern er hat der Projektstabilität einen Dienst erwiesen und erstmal eine sehr unerwünschte Syntax eliminiert.
- Das heißt, er fügt in die Seite ein
- Du darfst keine derartigen Arbeitsaufträge verteilen.
- Und wenn ich dann schon dranschreibe, dass das keine gute Idee war, dann räsonniere bitte nicht.
- Wenn du vorher schon weißt, dass Leute hier nur noch sehr wenig aktiv sind, dann ist es völlig verfehlt, ihnen sowas auf die BD zu schreiben.
- Stell dir vor, du loggst dich nach vier Monaten erstmalig hier wieder ein, und findest zur Begrüßung eine solche Beschwerde.
- Vielleicht bist du arbeitslos geworden, hattest einen Herzinfarkt, deine Frau war gestorben, du musstest in eine kleinere Wohnung umziehen.
- Dann loggst du dich still und leise wieder aus und kommst nie wieder.
- Das Ziel deines Arbeitsauftrags wirst du jedenfalls nicht erreichen.
- Dass der Umherirrende sich nach drei Monaten einmalig hier überhaupt wieder gemeldet hatte, ging auf meine persönliche Initiative zurück.
- Mir wäre sehr viel daran gelegen, wenn er in den nächsten Jahren wieder mehr Zeit und Lust zu seinem alten Heimatwiki hätte.
- Der Umherirrende wird von der Angelegenheit ohenhin nichts mehr mitbekommen, weil durch meine Antwort die Archivierungskriterien erfüllt waren und das Ganze nächstes Wochenende im Archiv verschwindet.
- Der Umherirrende wird die einfach nur gesubstet haben.
- LG --PerfektesChaos 13:50, 2. Sep. 2018 (CEST)
- Hallo, ich hatte die Nachricht schon gelesen und gesehen, dass die Änderungen lange her sind. Außerdem waren es reine Wartungsmaßnahmen und nur durch subst: erfolgt, da fülle ich mich heute nicht mehr so für verantwortlich.
- Der Hinweis auf Fehler ist immer richtig, in diesem Fall werde ich es auch nicht wiederholen, da die Vorlage nicht weiter eingebunden wurde.
- Ich hatte damals nicht auf optisches geachtet, da Signatur-Anpassungen an sich auch wieder schwierig sind. Ich weiß auch nicht, wie heute mit font-Tags in Signaturen umgegangen wird, daher lasse ich es erstmal unverändert und hoffe auf eure Kompetenz bei den Linter-Fehlern. Der Umherirrende 19:07, 2. Sep. 2018 (CEST)
- @Lómelinde:
Sorry ich wollte keinen Stress machen. Ich denke immer, wenn eine Signatur dazu führt, dass dadurch eine Seite komplett verunstaltet wird, ist es sinnvoll diese anzupassen. Aber ich bin schon sehr müde von all diesen Fehlerbehebungen und sie nehmen kein Ende, weil sich kaum jemand dafür interessiert. Dankeschön für die Antwort. --Liebe Grüße, Lómelinde Diskussion 06:16, 3. Sep. 2018 (CEST)
Bytes in der Versionsgeschichte werden bei Importen falsch gezählt
Bei phab:T114806 hattest Du ja schon mal sehr gut helfen können. Kannst Du dieses Problem auch aus der Welt schaffen? Siehe z. B. die Versionsgeschichte von Woodcrest (Kalifornien). Hier habe ich mittels importUpload Versionen unter den Artikel geschoben. Normalerweise müsste doch auch hier in der Versionsanzeige die Differenz der Bytes zwischen der letzten importierten Version und der ersten Version des Artikels angezeigt werden, also (-7.026). Ich denke, dass das bei der Programmierung der Mediawiki-Software mal vergessen wurde. Vielleicht weiß @PerfektesChaos auch etwas dazu. Kannst Du hier wieder etwas unternehmen? Vielen Dank und liebe Grüße, – Doc Taxon • Disk. • Wikiliebe?! • 13:58, 19. Okt. 2018 (CEST)
- Ich hab da nix zu, und bin mir auch nicht sicher, ob die physische Reihenfolge in der Datenbank-Tabelle auch nach Datum erfolgt, sondern nach Hinzufügung. Dann gibt die Differenz zweier physisch aufeinanderfolgender Datensätze natürlich Ulk. Wobei die Datenbank-Tabelle natürlich aufsteigend nach Versionsnummern sortiert ist, also die jüngst in das Projekt importierten Versionen größere Versionsnummern tragen, obwohl sie kalendarisch älter sind als vielleicht bei uns die Seite angelegt wurde. Zur Darstellung der Versionsgeschichte wird nach Zeitstempel sortiert, die Differenzen jedoch zwischen benachbarten Versionsnummern. Ich meine, mich dunkel erinnern zu können, dass das schon immer das Grundproblem gewesen war.
rev_len
wird wohl zum nächstenrev_id
und nicht zum nächstenrev_timestamp
berechnet. - VG --PerfektesChaos 14:14, 19. Okt. 2018 (CEST)
- ja, dann müssten die bestehenden Versionen beim Import automatisch neue Versionsnummern bekommen, dann passt's wieder. Aber logisch ist's schon, dass die nachgetragenen Versionen aktuelle revision IDs kriegen. – Doc Taxon • Disk. • Wikiliebe?! • 14:26, 19. Okt. 2018 (CEST)
- Es wird der Unterschied zum rev_parent_id von den beiden rev_len gebildet. rev_parent_id wird aber nicht angepasst und so gibt zwei Versionen mit rev_parent_id = 0 (die dann bei lokalen Benutzern auf Spezial:Beiträge als Seitenerstellungen gefiltert werden können). Beim damaligen Task waren die parent_ids bei den importierten Versionen falsch, hier muss eine bestehende Version angepasst werden. Schlimmer wird es, wenn der Import zeitlich überlappend ist. Dann müsste man auch die parent_ids anpassen, da sonst die zeitliche Reihenfolge nicht zur parent_id-Reihenfolge passt. Dadurch das aber die importieren Versionen (in deinem Beispiel, da die Bearbeitunge nicht dem lokalen Benutzer zugeordnet wurden) einfach zu erkennen sind, ist es schwierig zu sagen, ob dort Minus stehen muss oder man es als Neuanlage sehen soll. Ich finde die richtige Bewertung der parent_id beim Import schwierig (History-Merge ist ähnlich). Ich meine es gab auch dazu eine Diskussion auf einer Mailingliste, aber werde nicht fündig.
- Ich würde gerne helfen, kann aber nicht sagen was in der globalen Community hier als richtig gesehen wird. Der Umherirrende 17:57, 19. Okt. 2018 (CEST)
- ja, dann müssten die bestehenden Versionen beim Import automatisch neue Versionsnummern bekommen, dann passt's wieder. Aber logisch ist's schon, dass die nachgetragenen Versionen aktuelle revision IDs kriegen. – Doc Taxon • Disk. • Wikiliebe?! • 14:26, 19. Okt. 2018 (CEST)
- Also, beim overlap geht absolut rein gar nix.
- Eindeutig auflösbar ist hingegen die für uns typische Situation:
- Die jüngste importierte Version ist älter als der Zeitpunkt, an dem die Seite angelegt wurde.
- Das ist grad der Fall des Nachimports.
- Am 16. Mai wurde hierzuwiki eine neue Seite angelegt und mit dem aktuellen Inhalt des anderen Wikis befüllt, darauf aufbauend eine Übersetzung begonnen.
- Später wird die Vorgeschichte bis einschließlich 11. Mai nachimportiert. Das ist genau der Stand, der hierzuwiki benutzt wurde.
- Wenn es bei der Anlage erstmal nur C&P gab, müsste die Differenz genau Null sein.
- Dieser Zustand könnte beim Import analysiert werden und dann die entsprechenden Zeiger umgebogen werden. Momentan zeigen die in Reihenfolge der Versionsnummern.
- Diskutiert wurde das hier und weltweit schon seit einem Jahrzehnt immer mal wieder.
- Schönes Wochenende --PerfektesChaos 18:49, 19. Okt. 2018 (CEST)
Hallo Umherirrender, ich weiß nicht, an welche Seite der Wikipedia ich mich mit einem Anliegen am besten wenden kannst und du warst der letzte Bearbeiter der Vorlage {lang}}
. {{lang|kk|Text wohl für kasachisch}} führt, scheinbar erst seit gestern, zu einer Fehlermeldung. Siehe bspw. Artikel Astana. Die Fehlermeldung verweißt auf Vorlage:Arab/styles.css. Da du die Skriptsprache Lua in der Zusammenfassung nanntest und ich vielleicht annehmen kann, dass du über Programmierkenntnisse verfügst, weißt du, woran es liegen könnte? Oder gibt es ein Board, wo ich das Problem mal erläutern könnte? Es scheint nicht die einzige, betroffene Vorlage zu sein: siehe Karatschi. --Christian140 (Diskussion) 08:20, 1. Nov. 2018 (CET)
- Habe gerade auf der Diskussionsseite den Hinweis von Benutzer:PerfektesChaos entdeckt. Allerdings ist das ganze Rot in den Artikel nicht schön. --Christian140 (Diskussion) 08:23, 1. Nov. 2018 (CET)
- Ui, die fehlende Seite hatte ich in der Pipeline, wusste aber nicht, dass die irgendwer benötigen würde. Außerdem hatte sich bei meinen Tests nicht ergeben, dass ihr Fehlen zu einer sichtbaren Fehlermeldung führen würde; so habe ich sie jetzt grad angelegt.
- Die einfachste Stelle, um sich mit solchen Anliegen irgendwohin zu wenden, ist WP:FZW. Das langt schon, dort lesen genug sachkundige Leute mit. Wenn du es genauer einschätzen kannst, kämen vielleicht auch WP:VWS oder WP:TWS in Frage (siehe Kasten oben in dieser Seite bei Quelltextbearbeitung), oder in diesem Fall die Vorlagendiskussionsseite. Aber wenn FZW nicht mehr weiter weiß, dann wissen die immerhin genauer, welche Werkstatt das Problem dann lösen kann.
- Einzelne Benutzer solltest du eher nicht kontaktieren, wenn du nicht weißt, dass sie mit dem konkreten Problem direkt etwas zu tun hätten.
- Sorry for inconvenience --PerfektesChaos 10:38, 1. Nov. 2018 (CET)
Bytes in der Versionsgeschichte werden bei Importen falsch gezählt
Bei phab:T114806 hattest Du ja schon mal sehr gut helfen können. Kannst Du dieses Problem auch aus der Welt schaffen? Siehe z. B. die Versionsgeschichte von Woodcrest (Kalifornien). Hier habe ich mittels importUpload Versionen unter den Artikel geschoben. Normalerweise müsste doch auch hier in der Versionsanzeige die Differenz der Bytes zwischen der letzten importierten Version und der ersten Version des Artikels angezeigt werden, also (-7.026). Ich denke, dass das bei der Programmierung der Mediawiki-Software mal vergessen wurde. Vielleicht weiß @PerfektesChaos auch etwas dazu. Kannst Du hier wieder etwas unternehmen? Vielen Dank und liebe Grüße, – Doc Taxon • Disk. • Wikiliebe?! • 13:58, 19. Okt. 2018 (CEST)
- Ich hab da nix zu, und bin mir auch nicht sicher, ob die physische Reihenfolge in der Datenbank-Tabelle auch nach Datum erfolgt, sondern nach Hinzufügung. Dann gibt die Differenz zweier physisch aufeinanderfolgender Datensätze natürlich Ulk. Wobei die Datenbank-Tabelle natürlich aufsteigend nach Versionsnummern sortiert ist, also die jüngst in das Projekt importierten Versionen größere Versionsnummern tragen, obwohl sie kalendarisch älter sind als vielleicht bei uns die Seite angelegt wurde. Zur Darstellung der Versionsgeschichte wird nach Zeitstempel sortiert, die Differenzen jedoch zwischen benachbarten Versionsnummern. Ich meine, mich dunkel erinnern zu können, dass das schon immer das Grundproblem gewesen war.
rev_len
wird wohl zum nächstenrev_id
und nicht zum nächstenrev_timestamp
berechnet. - VG --PerfektesChaos 14:14, 19. Okt. 2018 (CEST)
- ja, dann müssten die bestehenden Versionen beim Import automatisch neue Versionsnummern bekommen, dann passt's wieder. Aber logisch ist's schon, dass die nachgetragenen Versionen aktuelle revision IDs kriegen. – Doc Taxon • Disk. • Wikiliebe?! • 14:26, 19. Okt. 2018 (CEST)
- Es wird der Unterschied zum rev_parent_id von den beiden rev_len gebildet. rev_parent_id wird aber nicht angepasst und so gibt zwei Versionen mit rev_parent_id = 0 (die dann bei lokalen Benutzern auf Spezial:Beiträge als Seitenerstellungen gefiltert werden können). Beim damaligen Task waren die parent_ids bei den importierten Versionen falsch, hier muss eine bestehende Version angepasst werden. Schlimmer wird es, wenn der Import zeitlich überlappend ist. Dann müsste man auch die parent_ids anpassen, da sonst die zeitliche Reihenfolge nicht zur parent_id-Reihenfolge passt. Dadurch das aber die importieren Versionen (in deinem Beispiel, da die Bearbeitunge nicht dem lokalen Benutzer zugeordnet wurden) einfach zu erkennen sind, ist es schwierig zu sagen, ob dort Minus stehen muss oder man es als Neuanlage sehen soll. Ich finde die richtige Bewertung der parent_id beim Import schwierig (History-Merge ist ähnlich). Ich meine es gab auch dazu eine Diskussion auf einer Mailingliste, aber werde nicht fündig.
- Ich würde gerne helfen, kann aber nicht sagen was in der globalen Community hier als richtig gesehen wird. Der Umherirrende 17:57, 19. Okt. 2018 (CEST)
- ja, dann müssten die bestehenden Versionen beim Import automatisch neue Versionsnummern bekommen, dann passt's wieder. Aber logisch ist's schon, dass die nachgetragenen Versionen aktuelle revision IDs kriegen. – Doc Taxon • Disk. • Wikiliebe?! • 14:26, 19. Okt. 2018 (CEST)
- Also, beim overlap geht absolut rein gar nix.
- Eindeutig auflösbar ist hingegen die für uns typische Situation:
- Die jüngste importierte Version ist älter als der Zeitpunkt, an dem die Seite angelegt wurde.
- Das ist grad der Fall des Nachimports.
- Am 16. Mai wurde hierzuwiki eine neue Seite angelegt und mit dem aktuellen Inhalt des anderen Wikis befüllt, darauf aufbauend eine Übersetzung begonnen.
- Später wird die Vorgeschichte bis einschließlich 11. Mai nachimportiert. Das ist genau der Stand, der hierzuwiki benutzt wurde.
- Wenn es bei der Anlage erstmal nur C&P gab, müsste die Differenz genau Null sein.
- Dieser Zustand könnte beim Import analysiert werden und dann die entsprechenden Zeiger umgebogen werden. Momentan zeigen die in Reihenfolge der Versionsnummern.
- Diskutiert wurde das hier und weltweit schon seit einem Jahrzehnt immer mal wieder.
- Schönes Wochenende --PerfektesChaos 18:49, 19. Okt. 2018 (CEST)
- nicht archivieren, das Problem muss noch behoben werden – Doc Taxon • Disk. • Wikiliebe?! • 20:54, 29. Okt. 2018 (CET)
- auch bei Spezial:Versionsgeschichten vereinen gibt es genau das gleiche Problem, siehe Spezial:Diff/168095072/169625799 Diff. – Doc Taxon • Disk. • Wikiliebe?! • 11:07, 31. Okt. 2018 (CET)
- nicht archivieren, das Problem muss noch behoben werden – Doc Taxon • Disk. • Wikiliebe?! • 20:54, 29. Okt. 2018 (CET)
- Auch nach 1,5 Jahren sehe ich hier keine Möglichkeit das zu verbessern. Daher erlaube ich mir, das es archiviert wird. Der Umherirrende 19:54, 2. Jul. 2020 (CEST)