Wikisource:Technikwerkstatt

Auf dieser Seite werden Abschnitte automatisch archiviert, die seit 7 Tagen mit dem Baustein {{Erledigt|1=~~~~}} versehen sind. Die Archivübersicht befindet sich unter Wikisource:Technikwerkstatt/Archiv.

Kürzel: WS:TW

Beginne ein neues Thema.

Willkommen Hier ist der richtige Ort für technische Fragen rund um Wikisource zu diskutieren. Änderungen und Fragen werden zuerst im Skriptorium vorgestellt, damit sie allen bekannt sind. Die technischen Themen werden dann nach ca. 1 Woche mit einem Hinweis hierhin verlagert und hier ausdiskutiert. Allgemeine, organisatorische und weitere Fragen kannst du im Wikisource:Skriptorium stellen. Inhaltliche Fragen zu einem bestimmten Quellentext kannst du bei der Wikisource:Auskunft oder auf der entsprechenden Diskussionsseite stellen. Ganz dringende Fragen kann man – vorzugsweise abends – den Wikisource-Mitarbeitern auch im Chat stellen. Ältere Beiträge findest du im Archiv.

Grober Fehler in PDF-Version mit PR2

In der PDF-Version von Civilisation und Wildniß wird die zweite Seite nicht übernommen. Ich vermute, dass es daran liegen könnte, dass diese Seite in mehrere Abschnitte aufgeteilt ist. --Liondancer 01:21, 9. Jun. 2009 (CEST)

Das können wir hier nicht ändern, da musst du wohl einen neuen Bugtracker-Eintrag schreiben, dass Extension:Collection nicht mit Extension:Labeled Section Transclusion funktioniert. --enomil 01:28, 9. Jun. 2009 (CEST)

Gerade gesehen, finanzer hat dies schon gemeldet: PediaPress Ticket #421. Habe den Fehler wieder aus der Versenkung geholt. --enomil 14:50, 17. Jul. 2009 (CEST)

<pages /> funktioniert ebenfalls nicht, siehe PediaPress Ticket #646. -enomil 15:10, 17. Jul. 2009 (CEST)

Die beiden Fehler wurden auf pediapress als erledigt markiert, kann das nochmal jemand testen, ob es nun richtig angezeigt wird? --enomil 13:52, 9. Apr. 2010 (CEST)

Seiten mit sections gehen immer noch nicht. --Rudolph H 18:12, 9. Apr. 2010 (CEST)

Durch Bug 21136 kann eine Lösung wohl nicht implementiert werden. --enomil 15:43, 21. Apr. 2010 (CEST)

Bitte alle für 21653 voten, dort scheint sich das Problem zu manifestieren. Ein Armutszeugnis. --Ayacop 18:41, 11. Sep. 2011 (CEST)

Seitenzahlen

Ich habe bei <pages/> das Anzeigen von Seitenzahlen durch Javascript aktiviert. Es soll keine sichtbare Änderung geben ; Seitenzahlen werden immer im Text gezeigt. Diese Änderung wird aber eine bessere Indexierung durch Suchmaschinen erlauben. Seitenzahlen können auch Links vom Text gezeigt werden, mit "self.pr_pageNumbersInline=false;" ThomasV 21:39, 12. Aug. 2010 (CEST)

Weiss Du was hier http://de.wikisource.org/wiki/Briefe,_die_ihn_nicht_erreichten los ist? Keine Seitenzahlen --Starshollow 13:48, 16. Aug. 2010 (CEST)

Sind bei mir vorhanden. Hast du zufällig Seitenzahlen ausgeblendet (Monobook: linkes Menü -> Anzeigeoptionen -> Seitenzahlen einblenden/ausblenden)? --enomil 14:20, 16. Aug. 2010 (CEST)

hmmm....Ich hab Monobook, aber finde keine Anzeigeoptionen --Starshollow 14:38, 16. Aug. 2010 (CEST)

Kurz mal ein Screenshot hochgeladen, wo sich die Option befindet, da siehst du auch, dass die Seitenzahlen (bei mir) angezeigt werden. --enomil 14:57, 16. Aug. 2010 (CEST)

Ok, im Mozilla funktioniert...Im IE 8 (den ich für berufl. Mails brauche) zumindest mit Standardeinstellungen nicht (bei pages index etc.) , trotzdem Danke--Starshollow 15:04, 16. Aug. 2010 (CEST)

Okay, da muss dann sich ThomasV wohl mal dahinter klemmen, da ich nicht mit IE arbeite. --enomil 15:08, 16. Aug. 2010 (CEST)

Hm, nach dem Aktualisieren mit F5 werden die angezeigt, beim nochmaligen Aufruf der Seite sind die wieder weg. Nur IE und unangemeldet. -- Paulis 17:56, 16. Aug. 2010 (CEST)

Kein Javascript - keine Seitenzahlen. Das ist ein Unding! Wer aus Sicherheitserwägungen Javascript deaktiviert hat, bleibt außen vor. Zur Anzeige der Seitenzahlen müssen "wikisource.org" und "bits.wikimedia.org" zur Ausführung von Scripten freigegeben sein. Das gilt für angemeldete und unangemeldete Benutzer. Beim angemeldeten sicheren Zugang über "secure.wikimedia.org" hilft noch nicht einmal die uneingeschränkte Zulassung von Javascript. Solange es keinen "Fallback" gibt, ist die javascript-gebundene Anzeige wieder zu deaktivieren. -- Oculus Spectatoris ^disputio_e-mail 19:01, 16. Aug. 2010 (CEST)

Wir haben wieder einen Fall, dass ohne hinreichende Tests uns etwas vor die Nase gesetzt wurde, was inakzeptabel ist --FrobenChristoph 20:01, 16. Aug. 2010 (CEST)

Nanana, Seitenzahlen ausblenden gabs schon zu Zeiten von PR1. Ist ja keine Neuerung in dem Sinne, also nicht immer gleich auf die Barikaden gehen. Ja und Oculus, Ws geht mit son Fehler nicht gleich unter, heb dir doch die Dramatik für wirklich dramatischen Sachen auf. Soweit ich sehe, sollte IE jetzt auch funktionieren - jedenfalls bei mir gehts. -- Paulis 20:24, 16. Aug. 2010 (CEST)

Natürlich ist das noch kein Weltuntergangsszenario - nur der Anfang davon. Selbstverständlich kann es trotz sorgfältiger Vorbereitung zu Pannen kommen. "Es soll keine sichtbaren Änderungen geben" ist aber nicht gerade eine Formulierung, die ein ausreichendes Testen erwarten lässt. Und prompt geht es in die Hose. Die Dramatik kommt von solchen unausgegorene Aktionen, die ohne Netz und doppelten Boden auf den Rücken anderer ausgetragen werden, insbesondere wenn es sich um sicherheitrelevante Maßnahmen handelt. Ich verkneife mir wohlweislich eingehende Anmerkungen über die unsinnige Verwendung von Javascript, denn dies ist ein unermeßlich großes Feld des Ärgernis. Dennoch frage ich, wie das Ausführen eines Script auf dem Rechner des Benutzers die Indizierbarkeit der Daten auf den Servern erhöhen soll? Immerhin wird üblicherweise im gegenteiligen Sinn die Script-Unfähigkeit der Crawler zur Verbrämung von E-Mail-Adressen herangezogen. Warum muss die Formatierung per Javascript Rechenzeit fressen, obwohl der gleiche Effekt durch eine CSS-Eintrageung erreichbar ist? Man sollte den Anfängen wehren, bevor es wirklich dramatisch wird. -- Oculus Spectatoris ^disputio_e-mail 00:08, 17. Aug. 2010 (CEST)

Es geht nicht um unseren Servers, sondern um allgemeine Suchmaschinen, wie Google, die unsere Texte indexieren. Seitenzahlen gehören zum Text nicht, desshalb sollen sie auch nicht mit dem Text indexiert werden. Doch werden sie jetzt indexiert, weil sie im Text hardcoded sind. Beispiel mit einer Suche :

• "kaum gucke ich mit dem Kopf ein bißchen" : 50 Ergebnisse, aber von Wikisource ist nichts zu finden.
• "kaum gucke ich mit dem Kopf ein 134 bißchen" : 1 Ergebnis : Gruß nach vorn (Tucholsky), auf Wikisource.

Mehr info zu diesem Thema hier ThomasV 00:52, 17. Aug. 2010 (CEST)

Nun, das ist zumindest ein bedenkenswerter Grund für die Änderung. Es wäre schön gewesen, wenn er gleich so deutlich erwähnt worden wäre. Dennoch ist die Lösung mittels Javascript nicht optimal. Wie oben bereits erwähnt, funktioniert das Einschalten der Seitenzahlen auch bei erlaubtem Javascript nicht, wenn man über den gesicherten Zugang angemeldet ist. Google beschreibt die Vorgehensweise seines Googlebots als vergleichbar mit der eines Textbrowsers. Diese kümmern sich um CSS meist genausowenig wie um Scripte. Ist der Gogglebot in dieser Hinsicht "fortschrittlicher" oder warum muss die Style-Information per Script nachgeladen werden? -- Oculus Spectatoris ^disputio_e-mail 13:48, 18. Aug. 2010 (CEST)

Dieser Script befindet sich auf wikisource.org ; desshalb ist es momentan bei paranoischen Settings nicht "erlaubt". Ich werde es später in die Proofreadpage Erweiterung einbauen, aber es muss zuerst weiter getestet werden und stabil sein. Code Updates von MediaWiki kommen sehr selten ; wenn ich etwas direkt in die Extension einbaue, dann kommen Korrekturen sehr langsam. So langsam dass Froben meint, ich hätte [m]eine Dev-Kumpels wohl entsprechend instruiert, [m]eine Programmänderung auf die lange Bank zu schieben.

Deine Frage über Googlebots verstehe ich nicht. Suchmaschinen indexieren Style-Information nicht, ob sie von Google betrieben sind oder nicht.

ThomasV 15:26, 18. Aug. 2010 (CEST)

Dass Suchmaschinen wie Textbrowser Style-Informationen nicht beachten ist eigentlich auch mein Kenntnisstand. Deshalb müsste es meines Erachtens möglich sein, die Seitenzahlen samt Link mit einer Formatierung aus einer CSS-Datei sichtbar zu machen. Derzeit wird aber per Javascript vom Browser am Ende des Seitenaufbaus eine Formatierung nachgeladen. Daher meine Frage, ob das nötig ist, weil der Googlebot doch etwas mit Styles anfangen kann, oder welchen anderen Grund es gibt. -- Oculus Spectatoris ^disputio_e-mail 22:32, 18. Aug. 2010 (CEST)

Klar, jedes element kann mit Formatierung und CSS sichtbar oder unsichtbar gemacht werden. Das hat aber mit dem Script nichts zu tun. Die Rolle von diesem Script ist nicht, die Seitenzahlen sichtbar zu machen, sondern sie zu erzeugen. ThomasV 23:20, 18. Aug. 2010 (CEST)

Der Quelltext ist mit und ohne Javascript gleich. Das Script greift sich die "class"- und "id"-Angaben aus dem leeren "span"-Tag (warum sind da eigentlich zwei verschachtelt?) und stellt sie dar. Die selbe Aufgabe sollte aber auch durch entsprechend formulierte CSS-Anweisungen geleistet werden können. Neben dem Entfallen des mehr oder weniger unsicheren Javascripts könnte jeder Benutzer Einfluss auf die Darstellung am eigenen Rechner nehmen. -- Oculus Spectatoris ^disputio_e-mail 23:45, 18. Aug. 2010 (CEST)

Wenn du eine Lösung hast, die nur CSS und keinen Javascript braucht, dann zeige sie bitte. ThomasV 00:50, 19. Aug. 2010 (CEST)

Ich hatte befürchtet, dass Du das fragst. ;-)

Zwar mache ich mich gerade mit den Spezialitäten des Wikimedia-Umfeldes vertraut, habe zu meinem größten Bedauern aber noch nichts Fertiges vorzuweisen. Allerdings freue ich mich, dass Du die Bereitschaft für eine Alternativlösung erkennen lässt. Bis mir eine Konfiguration gelungen ist, arrangiere ich mich mit dem gelegentlichen Einschalten von Javascript für Wikisource. Gruß, Oculus Spectatoris ^disputio_e-mail 10:55, 19. Aug. 2010 (CEST)

Ob Seitenzahlen hardcoded sind oder nicht, hat wieder einmal die Community nach reiflicher Überlegung zu entscheiden und nicht unser Programm-Diktator --FrobenChristoph 14:19, 18. Aug. 2010 (CEST)

Ich halte die Verbesserung der Suchfähigkeit für sinnvoll, da keine Fähigkeiten der Community davon betroffen sind, ist aus meiner Sicht gegen einen Betatest und einer späteren Einführung, wenn es dann mit allen browsern funktionert nichts entscheidendes einzuwenden. Und irgendwann muss man aus der geschützten Sandbox in's real für abschließende Tests gehen. Auf [Wikisource-l] wird darüber schon seit einiger zeit in Summe positiv diskutiert -- Jörgens.Mi ^Talk 00:00, 19. Aug. 2010 (CEST)

Beim IE 8 erst kaputte, mittlerweile gar keine Seitenzahlen. Bitte um Behebung, da ich leider meistens nicht mit Mozilla arbeiten kann. --Starshollow 15:13, 27. Aug. 2010 (CEST)

OCR-Buttons außer Betrieb?

Wenn ich auf die OCR-Buttons klicke, ergibt das seit einiger Zeit nur noch "undefined" im Textfeld... Ist da was bekannt? --Jmb1982 15:10, 4. Jan. 2011 (CET)

Mir nicht, denn ich habe schon seit längerer Zeit keine OCR-Buttons mehr. --9xl 18:55, 4. Jan. 2011 (CET)

Ich seit heute auch nicht mehr. -- Dorades 13:11, 8. Jan. 2011 (CET)

Mir geht es wie Jmb1982: Buttons da, aber bei Betätigung undefined als Ergebnis. -- Rosenzweig 18:12, 8. Jan. 2011 (CET)

Ich reihe mich ein , bei mir geht keiner von beiden. Beide melden undefined, auch bei klaren Texten -- Jörgens.Mi ^Talk 22:57, 2. Feb. 2011 (CET)

Wer keine OCR-Buttons mehr hat: bei Spezial:Einstellungen, Reiter „Bearbeiten“ den Haken bei „Erweiterte Bearbeiten-Werkzeugleiste aktivieren” entfernen. Allerdings funktionieren die OCR-Buttons bei mir auch nicht mehr, und spasseshalber habe ich mal auf en.ws getestet, da gehen sie auch nicht. --Beate 16:26, 7. Feb. 2011 (CET)

Aber was ich gerade in en.ws gesehen habe, wenn ich hier http://en.wikisource.org/wiki/Index:Historical_account_of_Lisbon_college.djvu auf einen roten Link klicke (unten), wird automatisch ein OCR eingefügt. Das ist aber schick! Oder geht das bei mir, weil wir „Normal“-OCR und Fraktur-OCR haben? --Beate 12:50, 14. Feb. 2011 (CET)

OCR wird automatisch eingefügt, weil der Textlayer bereits im DjVu enthalten ist. Das funktioniert bei uns genauso, aber eben nur bei DjVus mit enthaltener OCR. PDD 13:09, 14. Feb. 2011 (CET)

OCR-Button noch immer mit Ergebnis "undefined"

Gibt es dazu noch immer keine Neuigkeiten? Das ist doch ein sehr wichtiges Werkzeug, das ich auch dringend benötigte. Wer kann da (wissensgestützt) vorbreschen? Mein Dank ist ihm gewiss, --Konrad Stein 20:06, 9. Feb. 2011 (CET)

Über das OCR-"undefined" bin ich nun auch drüber gestolpert. Dachte schon meine djvu-Datei taugt nix. -- Matthead 11:16, 14. Feb. 2011 (CET)

Nix neues, siehe oben: Wikisource:Technikwerkstatt#OCR-Buttons außer Betrieb? kam aber keine Antwort. --Beate 12:46, 14. Feb. 2011 (CET)

Und wie gehts nun weiter? Wen muss man wo fragen? -- Matthead 19:45, 14. Feb. 2011 (CET)

ThomasV. Das Zeug läuft soweit ich mich erinnere auf dem Toolserver, genauso wie sein Bot, der auch den Dienst großteils verweigert. --enomil 20:20, 14. Feb. 2011 (CET)

Das sieht schlecht aus. Benutzer:ThomasV ist seit längerer Zeit nicht mehr gesehen worden. Auch in seinem Heimatwiki ist er seit zwei Monaten inaktiv und antwortet nicht auf seiner Disku. --9xl 11:17, 15. Feb. 2011 (CET)

Hatte er denn da ein Monopol drauf? Ist das ein Programm, das beständig gewartet werden muss? Können wir uns an einen anderen Techniker wenden? (Ich weiß leider nicht einmal wie der Toolserver organisiert ist). --Konrad Stein 19:35, 15. Feb. 2011 (CET)

Monopool denke ich mal, hat er nicht, es wurde aber zusätzlich von ThomasV angeboten, hatte sich sonst bisher niemand gefunden. Ob Wartungsintensiv, keine Ahnung, aber wenn Fehler auftreten und der Nutzer inaktiv ist, bleibt es halt bei den Fehlern, keine Ahnung in wie weit andere Toolserver-Mitarbeiter da eingreifen können, dürfen und wollen; ich denke aber, dass ehr selten in die Prozesse der anderen eingegriffen wird, wenn diese nicht gerade dazu beitragen, den Toolserver lahm zu legen. Es gibt aber einen eigenen Bugtracker (JIRA), ansonsten sind die Damen und Herren auch über IRC zu erreichen. Alles weitere siehe man über http://toolserver.org --enomil 10:13, 18. Feb. 2011 (CET)

Hier habe mal auf dem Toolserver-Wiki angefragt. Das wird aber dort wohl wenig nützen. Wurde ThomasV eigentlich überhaupt von jemanden per email kontaktiert? Nur warten bis er in einem wiki wieder aktiv wird ist ja auch keine Lösung. Aber wie ich gerade sehe ist er seit vorgestern auf wikisource-Projekten aktiv, und hat eine Übersichtsliste der Probleme erstellt: MediaWiki update 16/02/2011 ... lots of issues with this update. here is a list of what does work and what does not. -- Matthead 11:35, 18. Feb. 2011 (CET)

ThomasV meint, dass ein Admin Tesseract auf dem Toolserver installieren müsse, dann wolle er den ocr-Button reaktivieren. Hat jemand Kontakt zu einem Toolsaver Admin? Mir fehlen jedenfalls die Kenntnisse um eine vernünftige Anfrage zu stellen. --Konrad Stein 18:17, 26. Feb. 2011 (CET)

Auf dem Toolserver issue tracker wurde Reinstall Tesseract OCR eingetragen. -- Matthead 23:48, 26. Feb. 2011 (CET)

Da es wohl noch dauern wird, bis die OCR-Software Tesseract wieder auf dem Toolserver und auf Wikisource funktioniert, habe ich mir Tesseract 3.00 auf dem Windows-Rechner "installiert" und ausprobiert, anhand der Württembergische Oberamtsbeschreibungen für Backnang. Das Ergebnis nach 1 Stunde Texterkennung (oder Textverkennung?) habe ich als 870kB Text auch auf commons abgelegt. Der OCR-Text enthielt viele Fehler wie "ii" anstatt "ü", oder "nnd" anstatt "und". Außer "u" und "n" sind auch oft "c" und "e" sowie "f" und "s" vertauscht. Einige systematische Fehler habe ich mit Suchen-Ersetzen automatisch korrigieren lassen, wobei teils über Tausend Änderungen vorgenommen wurden. Dieses Rad haben zuvor auch schon andere erfunden, siehe etwa Benutzer:Joergens.mi/mwjed/macro. Da auch manche schon auf Wikisource:OCR verlinkt haben, habe ich dort nun etwas erstellt. Bitte dort ergänzen. -- Matthead 18:57, 27. Feb. 2011 (CET)

Vorlagen REIAL und REWLL

Nun sehe ich, dass meine gutgedünkte Vorlagen REIAL und REWLL den Server in die Knien bringen. Zur Funktion siehe auch hier und hier. Kann die Vorlage technisch optimisiert werden, oder gibt es nur den Weg die Listen auf mehrere Seiten aufzuspalten? Falls letzteres, wie viel (wie wenig) Einträge (Aufrufe) dürfen/sollen pro Seite stehen? Danke, --S8w4 05:02, 11. Aug. 2011 (CEST)

Inzwischen habe ich die #ifexist Schleife herausgenommen, die Frage bezieht sich also auf die frühere Version. Der Server ist heutzutage auch ohne #ifexist nicht sehr froh mit diesen langen Tabellen. --S8w4 09:15, 12. Aug. 2011 (CEST)

Hab mal noch bei RE/Bild das LZNum durch ein einfacheres Konstrukt ersetzt. --enomil 17:29, 12. Aug. 2011 (CEST)

Index-Reiter nun mit ID

Sobald r95346 live ist, besitzt der Index-Reiter auf Werkseiten eine ID (ca-proofread-source) und kann somit auch ausgeblendet werden (Originalzustand vor dem größeren letzten Update der Proofread-Extension). (Bug 27455 – proofreadpage source without id) --enomil 13:18, 24. Aug. 2011 (CEST)

MediaWiki 1.18

Fehler und zu Erlädigendes im Zusammenhang mit dem MW Update vom 6. Oktober 2011

hiddenStructure

→ Von WS:SKR#Warum sehen die Infoboxen plötzlich so anders aus? hierher zu verschieben.

Auf die CSS-Class sollte jedoch vollständig verzichtet werden. Betrifft soweit fast alle Infoboxen. --enomil 22:43, 6. Okt. 2011 (CEST)

Erweiterte Bearbeitungsleiste

→ Von WS:SKR#Erweiterte Bearbeitungsleiste hierher zu verschieben.

zusätzliche Leerzeilen im Footer

→ Von WS:SKR#zusätzliche Leerzeilen im Footer hierher verschoben.

Die Änderungen führen bei mir bei jeder Seitenänderung (Namensraum Seite:) zu ein bis zwei überflüssigen Leerzeilen am Seitenende. Kann man das einfach beheben, ohne ein Fass aufzumachen? --Dorades 22:27, 6. Okt. 2011 (CEST)

Fehler für mich nicht reporduzierbar noch verständlich. Ohne Bsp. und Angabe von Browser (+Version) komm ich da auch nicht weiter. --enomil 22:37, 6. Okt. 2011 (CEST)

Firefox 7.0.1. Monobook. Es entstehen sowohl bei BS-Änderungen ([1]), als auch bei Bearbeitungen ohne BS-Änderung ([2]) oft zwei Leerzeilen am Ende der Seite; offenbar aber nicht bei allen Benutzern, bei Michail manchmal nur eine, manchmal gar keine. --Dorades 22:44, 6. Okt. 2011 (CEST)

hab Chrome 14 und das Problem mit den zusätzlichen Leerzeilen noch gar nicht mitbekommen. Gruß --Finanzer 22:49, 6. Okt. 2011 (CEST)

FF 3.6.23 fügt Leerzeilen in der Fußzeile ein. --Jowinix 22:54, 6. Okt. 2011 (CEST)

Bei mir auch Leerzeilen in Kopf- und Fußzeilen-Fenster (Opera 11.50 auf WinXP). Außerdem lassen sich auch die WikiSyntax-Tags nicht in die Fußzeile einfügen, sie landen stattdessen im Bearbeiten-Fenster. -- Mapmarks 22:57, 6. Okt. 2011 (CEST)

Danke, betrifft also alle Browser (schließt schonmal nen reinen Browser-JS-Fehler aus).

Falls Rev. aktiv, die noch mit NEW gekennzeichnet sind, dann liegts wohl an r98583. Es werden zusätzliche \n (Absätze) eingefügt. Das JS was für die Zusammenfügung zuständig ist (irgendwo auf oldwikisource, soweit ich mich erinnere), filtert die für Header und Text raus (da das JS genau 3 Leerzeilen in den Footer setzt, nicht mehr und nicht weniger), der Footer wird einfach an das restliche angebunden: der zusätzliche Umbruch kommt hinzu. Jede Vorschau und jedes Speichern fügt jeweils einen mehr hinzu. --enomil 23:04, 6. Okt. 2011 (CEST)

Als Comment hinzugefügt 98583#c23895. --enomil 23:12, 6. Okt. 2011 (CEST)

Solange dies noch aktiv ist: [3] --enomil 16:25, 14. Okt. 2011 (CEST)

Den vorigen Beitrag verstehe ich nicht ganz. Aber was Neues: in der Fußzeile wird keine Leerzeile mehr eingefügt, dafür aber eine am Ende des Textfensters. (Browser etc. siehe oben.) -- Mapmarks 04:42, 18. Okt. 2011 (CEST)

So "neu" ist das gar nicht, wie dem auch sei, dass hat alles mit Bug 26028 – Script should not remove line-breaks after initial noinclude tags zu tun. Die letzte Änderung dahingehend ist r99979 (noch nicht live). Ich hab den Überblick in den Revisions ansonsten verloren (dahin gehören solche für ProofreadPage/ProofreadPage_body.php, ProofreadPage/proofread.js und evtl. Teile von WikiEditor und EditPage). --enomil 12:53, 18. Okt. 2011 (CEST)

Bei den englischsprachigen Kollegen. --enomil 19:46, 19. Okt. 2011 (CEST)

Fällt in diesen Problemkreis auch die Zwangsbeglückung von Zeilenwechseln beim Neuanlegen von Seiten? Ist mir bei Ueber die allmähliche Verfertigung der Gedanken beim Reden aufgefallen, erzeugt einen Zeilenwechsel vor Seitenwechseln und lässt sich nicht abstellen (ich wüßte jedenfalls nicht wie). Absicht oder Bug? --Konrad Stein 02:39, 23. Okt. 2011 (CEST)

Sehe gerade: ist wohl identisch mit dem Beitrag von Mapmarks. --Konrad Stein 02:39, 23. Okt. 2011 (CEST)

Unser Fix ist wohl zu radikal: entfernt alle Leerzeilen aus dem Footer, was die Darstellung von Überschriften stört. Z. B hier: Seite:Schenck Wiesbaden 049.jpg --Robot Monk 19:10, 28. Okt. 2011 (CEST)

• Dieses Problem ist auf en.ws und old.ws altbekannt, ist ein Bug in der Mediawiki (Bugzilla #26028). Das Problem is fixiert in Zukunft aber ein Robot muss alle Fehler korrigieren. Bitte sehen oldwikisource:Wikisource:Scriptorium#Line_breaks_in_pages und dort alles fragen. Mehr Wissen kann man auf en:Wikisource:Scriptorium#Extra_linebreaks_being_inserted_in_Page_space bekommen.-- Doug.^{(Diskussion • Beiträge)} 16:05, 29. Okt. 2011 (CEST)

Die überflüssigen Leerzeilen sind raus, danke für den Hinweis und die Unterstützung im IRC. -- Paulis 19:07, 29. Okt. 2011 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Paulis 19:07, 29. Okt. 2011 (CEST)

Kategorienanzeige

→ Von w:Wikipedia:FZW#MW118: Kategorienanzeige.

Das Layout für die Kategorieanzeige hat sich verändert, hat nun vielmehr Leerraum. Wer jedoch das alte Layout wiederhaben will, der tut in seine monobook.css (für Monobook), vector.css (für Vector) oder common.css (für alle Skins) folgende Zeilen:

#catlinks li {
        display: inline;
        border-left: none;
        padding: 0;
}
#catlinks li:first-child { padding-left: 0; }
#catlinks li:before { content: " | "; }
#catlinks li:first-child:before { content: ""; }

--enomil 23:43, 6. Okt. 2011 (CEST)

Lutherbibel Randnotizen

Ich habe auf dieser Seite probehalber die Randnitizen mit der Vorlage NotizLinks eingetragen. Leider laufen sie bei mir (Firefox 3.xx) in den Text und sind damit nicht zulesen. Gibt es eine Möglochkeit das besser zu machen? ZU bedenken ist dabei, das die Text auch länger sein können, wie z.B. hier ausserdem gib es im Text Notizen am Innen- und Aussenrand, mit unterschiedlicher Bedeutung einmal Erklärungen einmal Verweis auf andere Bibelstellen. Catrin 21:38, 13. Dez. 2011 (CET)

Vielleicht sollte man dem NotizText auch etwas Platz zugestehen (verweis auf die Änderung im BlockSatzStart): [4]. Ansonsten muss das im Projekt intern geregelt werden, wie verfahren wird (NotizLinks/Rechts, als Ref, Register, ...). --enomil 21:49, 13. Dez. 2011 (CET)

Weitere Diskussion bitte hier. --Batchheizer 14:57, 16. Dez. 2011 (CET)

Verlinkung in der ADB-Kopiervorlage

Folge ich dem in der Kopiervorlage folgendermaßen angegebenen Link

• Heinrich Theodor Flathe: Friedrich August III., Kurfürst von Sachsen. In: Allgemeine Deutsche Biographie (ADB). Band 7. Duncker & Humblot, Leipzig 1877, S. 786–789.

lande ich bei ADB:Friedrich August I. König von Sachsen statt ADB:Friedrich August I. (König von Sachsen)

per mouseover wird aber das (richtige) Klammerlemma angezeigt. Was ist da los? --WikiAnika 22:34, 20. Dez. 2011 (CET)

Nachtag: aus WS funktioniert es jetzt (funktionierte bis eben aber auch nicht). bei w:Friedrich_August_I._(Sachsen) besteht das Problem aber noch immer. --WikiAnika 22:37, 20. Dez. 2011 (CET)

Fehler für mich nicht reproduzierbar. --enomil 22:49, 20. Dez. 2011 (CET)

Bin zur Zeit mit Mopsgeschwindigkeit unterwegs. Vielleicht liegt es daran. Werd aber immer noch an die leere Seite verwiesen. --WikiAnika 23:18, 20. Dez. 2011 (CET)

Zentrierung in Poem

Bitte mal mit verschiedenen Browsern testen, ob der gewünschte Effekt auftritt.

• Beispiel 1: Zwischen dem zentrierten Text und dem nachfolgenden Text wird eine Leerzeile eingefügt (derzeit standard)
• Beispiel 2: Hier sollte keine solche Leerzeile vorhanden sein

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore, sed diam voluptua. 23. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.

Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore, sed diam voluptua. 23. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.

Opera 11.60 okay. --enomil 16:13, 18. Jan. 2012 (CET)

Firefox 9.0.1. okay. -- Dorades 16:20, 18. Jan. 2012 (CET)

Firefox 3.6.2. okay... (Die IT installiert mir aus Sicherheitsgründen keine neuere Version...) --194.8.210.62 16:33, 18. Jan. 2012 (CET)

Auch mit Chrome 16, IE 9 und Safari 5.1 ist es ok. --9xl 07:57, 19. Jan. 2012 (CET)