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)

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)

Doppelter Link

Ich habe, als ich eine Index-Datei speichern wollte, die Fehlermeldung "Doppelter Link" bekommen. Im Text hiess es: "In einer Index-Seite darf ein Link nur einmal vorkommen." Diese Fehlermeldung war leicht verständlich und eindeutig. So weit so gut.

Jetzt der schlechte Teil. Die Datei wurde nicht gespeichert. Anscheinend sollte ich vor dem Speichern den doppelten Link entfernen. Ist das wirklich nötig? Es könnte doch sein, dass ein Benutzer in bestimmten Fällen bewusst eine fehlerhafte Datei speichert, um den Fehler dann, in einem weiteren Bearbeitungsschritt, zu verbessern.

Weiter fielen mir folgende komische Verhaltensweisen auf, die vielleicht auch verbessert werden können.

1. Ich wollte in der Datei auf einen Schlag 800 Links einfügen. Wie sollte ich nun den Link, der doppelt ist, finden? Wenn das Programm weiss, DASS ein Link doppelt ist, weiss es doch bestimmt auch WELCHER Link doppelt ist. Ich hätte also erwartet, dass mir der Link in der Fehlermeldung angezeigt wird.
2. Ich habe vor dem Speichern-Befehl den Vorschau-zeigen-Befehl gegeben. Das Programm hat ohne weiteres die Vorschau angezeigt, und alles war in dieser Ansicht so, wie ich es habe wollte, sodass ich den Speichern-Befehl gegeben hab. Warum hat das Programm mich nicht schon beim Vorschau-zeigen-Befehl auf den Fehler aufmerksam gemacht?
3. Die Fehlermeldung erschien in einem eigenen Fenster und nicht, wie es doch anscheinend üblich ist, im Bearbeiten-und-Vorschau-Fenster. Als ich in meinem Browser den Zurückgehen-Befehl gegeben hab, wurde wieder das Bearbeiten-und-Vorschau-Fenster angezeigt, zum Glück noch mit meinen Bearbeitungen.
4. In dem Fehlermitteilungsfenster gab es einen Link "Zurück zur Hauptseite". Was hat dieser Link mit Bearbeiten, Vorschau und Fehlermitteilung zu tun? Ich habe ihn nicht benutzt. Wahrscheinlich wären doch meine Bearbeitungen verlorengegangen.
5. Dann habe ich im Bearbeiten-Fenster die untere Hälfte des Textes auskommentiert und wieder auf Speichern geklickt. Es erschien wieder dieselbe Fehlermitteilung. Der doppelte Link musste sich also in der oberen Hälfte des Textes befinden. Ich habe also die Hälfte der oberen Hälfte auskommentiert und wieder auf Speichern geklickt. Fehlermitteilung. Das ging mehrfach so weiter. Schliesslich habe ich den gesamten Text auskommentiert. Fehlermitteilung! Das bedeutet, das Programm findet auch doppelte Links, die auskommentiert sind. Was hat das für einen Sinn?

Es blieb mir nichts anderes übrig als die Links portionsweise einzufügen und zu speichern. Tatsächlich war es dann die letzte Portion, in der der doppelte Link enthalten war.

Ende gut alles gut, könnte man sagen. Aber das bessere ist der Feind des guten. Ich hoffe also, dass ein paar von meinen Verbesserungsvorschlägen aufgegriffen werden.

Gruss

Kolja Pastor (Diskussion) 17:44, 8. Mär. 2012 (CET)

Escapefehler bei PDF/Buch-Funktion

Hallo, beim erzeugen des Buches Apokalypse des Elias als PDF oder Buch bricht der Parser nach der ersten Überschrift ab und macht erst wieder ganz unten bei den Anmerkungen (ohne die Überschrift selbst) weiter. Das passiert auch bei anderen Büchern von Altjüdisches Schrifttum außerhalb der Bibel . Sämtliche per Vorlage eingebundene Kapitel fehlen somit. Statt der Überschrift erscheint im PDF:

<span id="19. Kapitel: Mahnworteunknown operator: u'&'" />

Es scheint so als würde das & nicht in &amp; umgewandelt werden. Weiß einer wie oder wo man das beheben kann? --79.235.97.162 00:12, 9. Apr. 2012 (CEST)

Die PDF Funktion ist für Wikipedia gemacht, bei WS gibt es eigentlich nur Probleme damit. Wesentlich besser ist der E-Book Export: http://toolserver.org/~tpt/wsexport/book.php , in das Feld "Title of the page:" den WS Titel einfügen, also Apokalypse des Esdras --Jowinix 00:52, 9. Apr. 2012 (CEST)

Ok danke. Könnte dann vielleicht der Link zum Tool auch (oder statt der PDF wenn es hier sowieso nicht geht) bei Drucken/exportieren eingefügt werden? So ist das fast nicht zu finden :) --79.235.97.162 01:09, 9. Apr. 2012 (CEST)

Suchen/ersetzen-Funktion und Mozart

Da im Mozart-Artikel mehr als 1000mal „Mozart“ kursiv gekennzeichnte werden sollte, hab ich im Bearbeitungsfenster diese Version benutzt. Mit enttäuschendem Ergebnis. Das sah dann (ca.) so aus: „''Mo''Mozart''f“, wobei das „f“ für den 3. Buchstaben nach „Mozart“ steht. Beim Suchwort „Jahn“ war es ähnlich, k. A. wie oft das vorkommt. „Haydn“, kam ca. 65mal vor, wurde korrekt kursiv gesetzt, einmal allerdings jedenfalls übersehen. Ich hab dann versucht, nur in den 1. dreißig Seiten das „Mozart“ zu kursivieren. Mit dem Ergebnis, dass ich gezählte 144mal nachzukorrigieren hatte. Frage: Mach ich da was falsch? Und wenn ja, was? (MS-Word kann da nicht genutzt werden, der unterscheidet diese versch. Apostrophen nicht). Zabia (Diskussion) 19:46, 17. Apr. 2012 (CEST)

Suchen/ersetzen mit welchem Programm? --enomil 20:54, 17. Apr. 2012 (CEST)

Wikisource, Bearbeitungsfenster, enomil. Zabia (Diskussion) 21:20, 17. Apr. 2012 (CEST)

Jetzt hab ichs geschnallt: Mit IE, 8. Zabia (Diskussion) 21:23, 17. Apr. 2012 (CEST)

Benutz du irgend einen speziellen Editor hier? (Also wo kommt diese Suchen/Ersetzen Funktion her, so eine ist mir nicht bekannt. Btw. IE 8 kann ich aufjedenfall nicht testen). --enomil 22:05, 17. Apr. 2012 (CEST)

Ich hab in meinen Einstellungen bei Bearbeiten/Beta-Funktionen, beide Häkchen gesetzt ( Erweiterte Bearbeiten-Werkzeugleiste aktivieren) und (Dialoge für das Einfügen von Links, Tabellen usw. aktivieren). k. A. ob das der Grund ist. Das Suchen/Ersetzen-Tool erscheint auf der oberen Leiste, oberhalb des Fensters ganz rechts (Lupe mit Bleistift). Zabia (Diskussion) 08:07, 18. Apr. 2012 (CEST)

Danke, die Beta-Funktionien habe ich sonst nicht aktiv. Den beschriebenen Fehler kann ich mit Opera ebenfalls reproduzieren (äußert sich evtl. etwas anders, aber das Ergebnis bleibt: falsche Ersetzung). Auch mit RegEx in der Suchzeichenkette konnte ich es nicht ordentlich auflösen. Falls hier jemand weis, wo das replace-tool im WikiEditor definiert ist, dann mal bitte melden. Alternative Lösung habe ich derzeitig nicht parat (und ohne RegEx-Suche wird es schwer das 100% zu lösen). --enomil 13:28, 18. Apr. 2012 (CEST)

Danke, für Deinen Einsatz. Ich werd dann halt ohne auskommen. Wie gesagt, wäre es praktisch beim Fetten (Dialoge), Kursivieren. Gruß ;-)) Zabia (Diskussion) 16:58, 18. Apr. 2012 (CEST)

Vorlage:MDZ

Läßt sich bei dieser Linkvorlage einrichten, bestimmte Seiten anzusteuern? Viele Grüße --Konrad Stein (Diskussion) 12:55, 5. Mai 2012 (CEST)

Sicherlich ist es machbar (sag ich mal jetzt), aber der Resolver des MDZ kann auf verschiedenste MDZ-Angebote mit unterschiedlichen URLs leiten und für jedes Angebot müsste ein eigener Parameter eingebaut werden und der Verlinker muss nachsehen oder sich merken, welcher Parameter gefragt ist. Man könnte höchstens noch dass Angebot, unter dem die meisten Digitalisate vorgehalten werden, als Standard für die Einzelseitenverlinkung voreinstellen, wenn nichts anderes angegeben wird. Ich möchte auch schon lange Vorlagen für die Einzelseiten der unterschiedlichen MDZ-Angebote haben, da für bestimmte Themen, insbesondere dort wo es ohnehin an Monografien mangelt, direkte Links auf die Fundstellen immer wichtiger werden. Beispiel: Einträge in Ortslexika und Topographien für kleinere Orte, dergleichen Biographica wie Personenlexika und tausend andere Sachen eben. --188.99.191.122 22:49, 5. Mai 2012 (CEST)

Wenn URN soetwas wie das Handle-System mit seinem urlappend-Parameter nicht hat (Bsp.: http://hdl.handle.net/2027/njp.32101074861855?urlappend=%3Bseq=332), dann wird es schwer soetwas umzusetzen, da man dann wohl wieder auf nicht-persistente Links umsteigen müsste. Leider ist mir bisher soetwas nicht bekannt. --enomil 10:59, 7. Mai 2012 (CEST)