Wikisource:Technikwerkstatt/Archiv/2009

Archiv Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der URL-Zeile deines Browsers (Beispiel: [[Wikisource:Technikwerkstatt/Archiv/2009#Abschnittsüberschrift]]).

Problem beim Erstellen einer Seite:

Beim Erstellen von Seite:Oberamt_Wangen_001.jpg werden in Kopfzeile und Fußzeile, nicht wie gewohnt, die Daten des Projekts eingefügt. (Index:Beschreibung_des_Oberamts_Wangen) Ist das so gewollt oder mache ich etwas falsch? --9xl 12:40, 27. Mär. 2009 (CET)[Beantworten]

Vorlage ist jetzt wieder angepasst. ThomasV 13:06, 27. Mär. 2009 (CET)[Beantworten]
Archivierung dieses Abschnittes wurde gewünscht von: 9xl 14:00, 27. Mär. 2009 (CET)[Beantworten]

Proof Read 2

Hilfe zu der neuen Version von Proofread ist hier Wikisource:Proofread zu finden.

Archivierung dieses Abschnittes wurde gewünscht von: 9xl 17:40, 12. Mai 2009 (CEST)[Beantworten]

ProofreadPage update

Ich habe gerade ProofreadPage geändert (und natürlich verbessert); die Modifikation ist noch nicht aktiv. Nachdem sie aktiv wird, werden die Zitierempfehlungen momentan kapputt gehen. Um sie zu reparieren muss ich dann ein Paar Vorlagen auf de.ws aktualisieren. Aber das kann ich tun erst wenn die neue Version aktiv ist. ThomasV 11:05, 17. Mär. 2009 (CET)[Beantworten]

Archivierung dieses Abschnittes wurde gewünscht von: enomil 15:54, 7. Jul. 2009 (CEST)[Beantworten]

ProofreadPage Layout

Ich habe gerade das neue Layout auf de.ws aktiviert. Dieses Layout wird auch auf anderen subdomains verwendet.

Mit dem neuen Layout ist est möglich, zwischen horizontalen und vertikalen Verteilung dynamisch zu wählen (mit dem fünften Button im Toolbar). Man kann auch die Vertikale (bzw. Horizontale) Verteilung als Option wählen, einfach so :

var proofreadpage_default_layout='vertical';

Es gibt auch neue Bearbeitungsstand buttons; ich habe sie zur deutschen 'Seitenstatus' Vorlage angepasst.

Es ist noch möglich, für die, die das wollen, das alte Layout zu benützen, mit dieser Option in ihren monobook.js :

var proofreadpage_setup = proofreadpage_setup_de;

Ich empfehle es aber nicht. Das alte Layout gibt es nur hier auf de.ws, und zukunftig werde ich mich nicht mehr damit beschäftigen (das heisst, keine neue Entwicklungen, und nur sehr einfache Bugs fixen).

Paulis has mich gefragt, die Lupe wiedereinzubauen. Erst muss ich erklären, dass ich sie weggebaut habe, weil sie bei Sprachdomains wie Hebraisch oder Arabisch nicht richtig funktionierte. Ich arbeite jetzt an einem neuen Zoom, aber das wird noch Zeit brauchen.

ThomasV 10:31, 2. Mai 2009 (CEST)[Beantworten]

Dann würde ich bevor ich solche Änderungen mache mit der Community reden und dafür sorgen das die sinnvollen Features wie Lupe und so weiter auch weiterhin funktionieren. Es gibt bei guten Softwareingenieuren die Fähigkeit neue Versionen abwärtskompatibel zu programmieren und vorher zu testen. Wieso funktionieren die Settings

var disableTriple = true; // Proofread 2 nur ein Edit Fenster
var hideExpanded = true; // Proofread 2 mehr Platz auf dem Schirm

nicht mehr. Desweiteren lies meine Bemerkungen im Skriptorium Wikisource:Skriptorium#Ausgeblendeter_Seitenstatus. Da gehören solche Änderungsorgien vorher angekündigt. Wieso sind die Bilder bei der Seitenanzeige so groß. Noch ein Bug. -- Jörgens.Mi Talk 22:55, 6. Mai 2009 (CEST)[Beantworten]


Leider bin ich kein guter Ingenieur.
ich werde das alte Layout hier wieder aktivieren, bis die Bugs korrigiert sind. Es sollte noch bis zum nächsten MediaWiki Update funktionnieren.
ThomasV 03:36, 7. Mai 2009 (CEST)[Beantworten]
Archivierung dieses Abschnittes wurde gewünscht von: enomil 15:54, 7. Jul. 2009 (CEST)[Beantworten]

Zusammenfassungszeile bei Änderungen auf Indexseiten

Wird bei mir seit einiger Zeit immer mit "-> new index" überschrieben. Hängt das evtl. mit den letzten Änderungen zusammen? --Rudolph H 13:05, 17. Mai 2009 (CEST)[Beantworten]

Seit dem letzten Update nicht mehr aktiv. --enomil 15:54, 7. Jul. 2009 (CEST)[Beantworten]
Archivierung dieses Abschnittes wurde gewünscht von: enomil 15:54, 7. Jul. 2009 (CEST)[Beantworten]

Zentrierte Linie

Ich hätte geschworen, dass damals, als ich das hier abgespeichert habe, die Linie nach dem Autornamen zentriert war, aber jetzt ist sie es eindeutig nicht mehr. Wie krieg ich das hin, dass die zentriert ist? -- Cecil 13:57, 28. Mai 2009 (CEST)[Beantworten]

Steht auf meiner ToDo-Liste, werde heute Abend mal drüber schauen, Problem besteht im FF und Chrome, IE und Opera funktionieren. --enomil 16:54, 28. Mai 2009 (CEST)[Beantworten]
Der ausgegebene HTML-Text lautet: <div style="text-align:center"><hr style="width:10em;" /></div>
Ob das hr-tag auf 'text-align' reagieren soll, kann diskutiert werden. Eigentlich ist es kein Text.
>Cecil: Nimm {{LineCenterSize|100|30|__________}} , das geht bestimmt in allen Browsern. --9xl 17:39, 28. Mai 2009 (CEST)[Beantworten]
Vorlage sollte nun einwandfrei funktionieren. Bitte nicht in <center></center> oder {{Center}} packen, die Formatierung sollte von alleine erfolgen. Testreihe ist in meiner Vorlagenwerkstatt zu finden.
9xl:text-align soll Blockelemente und seine Kinderelemente horizontal ausrichten, so ist es vorgesehen, siehe dazu meine Analyse. --enomil 18:52, 28. Mai 2009 (CEST)[Beantworten]
Na ja, warum einfach - es geht ja auch herrlich von hinten mit der linken Hand in die rechte Hosentasche ;-) --9xl 20:15, 28. Mai 2009 (CEST)[Beantworten]
Archivierung dieses Abschnittes wurde gewünscht von: enomil 15:54, 7. Jul. 2009 (CEST)[Beantworten]

Bitte einmal an unser Format (SeitePR) anpassen. --enomil 19:30, 7. Jul. 2009 (CEST)[Beantworten]

Angepasst. --enomil 22:44, 7. Jul. 2009 (CEST)[Beantworten]
Archivierung dieses Abschnittes wurde gewünscht von: enomil 22:44, 7. Jul. 2009 (CEST)[Beantworten]

Probleme mit IE 8

Warum springt beim IE8 der Cursor an die Unterseite des Bearbeitungsfensters bei Eingaben? Das nervt gewaltig! Wenn das nicht geändert werden kann, werde ich den IE 8 löschen und nur noch mit dem Firefox arbeiten. --A. Wagner 22:16, 10. Jun. 2009 (CEST)[Beantworten]

Archivierung dieses Abschnittes wurde gewünscht von: --A. Wagner 19:41, 11. Jul. 2009 (CEST)[Beantworten]

Ich habe bisher Fußnoten à la Siehe Wikipedia: [[:w:Steinlaus|Steinlaus]] formatiert und jetzt mal der Einfachheit halber [[Wikipedia:Steinlaus]] probiert. Bei ersterer Form führte der Link zur de.WP, bei letzterer zur en.WP – sollte er nicht zur de.WP führen? --Liondancer 19:47, 25. Apr. 2009 (CEST)[Beantworten]

Die ausgeschriebenen Versionen sind auf bestimmte Domains festgesetzt, was zu 99% bei allen Wikimedia-Projekten identisch ist (Liste der default Interwikis). Die Kurzformen verlinken, wenn keine andere Sprachversion im 2. Parameter angegeben ist, auf die jeweilige gleichsprachige Interwiki-Version. --enomil 15:54, 7. Jul. 2009 (CEST)[Beantworten]
Archivierung dieses Abschnittes wurde gewünscht von: enomil 17:20, 13. Jul. 2009 (CEST)[Beantworten]

Neue Vorlagen im Seitenkopf

Ich will meinen Bot modernisieren. Was muss jetzt im Seitenkopf stehen? --Catrin 16:09, 12. Jul. 2009 (CEST)[Beantworten]

Die PR2-Header werden gerade durch ThomasV’s Bot (ThomasBot · Beiträge) ersetzt. Es kommen jetzt die beiden Vorlagen PageQuality und Seitenstatus2 zum Einsatz. Durch MediaWiki:ProofreadPage.js werden diese auch noch automatisch (wenn JS enabled) beim Editieren ersetzt. --enomil 17:28, 13. Jul. 2009 (CEST)[Beantworten]

Vielen Dank. --Catrin 18:18, 13. Jul. 2009 (CEST)[Beantworten]

Archivierung dieses Abschnittes wurde gewünscht von: enomil 21:26, 13. Jul. 2009 (CEST)[Beantworten]

Geschweifte Klammern über mehrere Zeilen in Tabellen

Weiß jemand eine Lösung, geschweifte Klammern darzustellen, die sich in einer Tabelle über mehrere Zeilen erstrecken? Im von mir bearbeiteten Projekt Weinsberg, vormals freie Reichs-, jetzt württemb. Oberamtsstadt. Chronik derselben kommen solche Klammern ab Seite:Dillenius Weinsberg 057.png mehrfach vor, auf Seite:Dillenius Weinsberg 063.png sieht man gleich mehrere Beispiele. Sie ordnen jeweils mehrere Elemente auf der linken Seite einer Aussage auf der rechten Seite zu, haben also eine inhaltliche Bedeutung und sollten deswegen m.E. nicht einfach weggelassen werden. Ich habe etwas rumprobiert, aber nur Teillösungen gefunden.

&#125;

kodiert die Klammer, mit Tabellenkonstruktionen bekomme ich sie auch zwischen die jeweiligen Spalten, und zentriert in die Mitte ihrer eigenen Spalte bekomme ich sie auch noch. Nicht so einfach ist, der Klammer die richtige Größe bzw. Höhe zu verleihen und sie an die richtige Stelle zu bugsieren, so dass sie alle gewünschten Zeilen links umfasst und rechts mit ihrer Spitze mittig auf den dort stehenden Text zeigt. Ich dachte, mit einer Größenangabe in em statt % oder pt wäre evtl. eine Größe der Klammer relativ zur angezeigten Schriftgröße zu erreichen, und bin so zu einem Konstrukt wie

<div align="center" style="font-size:6em">&#125;</div>

gekommen. Zur vertikalen Positionierung ist mir außer mehrfachem Einsatz von <br /> allerdings bislang nichts eingefallen, und das Resultat ist nicht sonderlich präzise. Ein weiteres Problem ist, dass das Klammer-Zeichen, je größer es wird, natürlich nicht nur an Höhe, sondern auch an Dicke zunimmt, was nicht unbedingt erwünscht, jedenfalls nicht nötig ist.

Hat jemand weitere Ideen, wie man hier vorgehen könnte? Viele Grüße -- Rosenzweig 14:35, 5. Jul. 2009 (CEST)[Beantworten]

Klar, wenn das Ding Größer wird, dann wird es auch fetter. Vertikal hat man nicht viele Möglichkeiten außer zentrieren mit style="vertical-align:middle;".
Ich würde die Dinger weglassen. Es ist nicht unser Ziel, das Druckbild exakt nachzubilden. Natürlich muss klar sein, was zusammen gehört. Dazu notfalls leere Tabellenzeilen einfügen. Andere Möglichkeit ist Texte wiederholen, bspw. Seite 63:
d) Rinderfeld, erkauft 1398
e) Oberndorf, erkauft 1398
f) Streichenthal, erkauft 1398
Ich habe in ähnlichen Fällen auch schon Tabellen mit Gitternetzlinien benutzt, obwohl die Vorlage ohne Linien war oder nur teilweise Rahmen hatte. Eben um Klarheit zu schaffen. --9xl 16:49, 5. Jul. 2009 (CEST)[Beantworten]
Alternativ noch über TeX oder Unicode. --enomil 15:16, 7. Jul. 2009 (CEST)[Beantworten]

Danke für die Anregungen. Unicode scheidet m.E. aus, das mag in der DOS-Kommandozeile gut aussehen, aber nicht in einem Text wie hier. TeX ist interessant, damit setzen Verlage schließlich ganze Bücher, und wenn wir hier volle TeX-Unterstützung hätten, wäre es auch im vorliegenden Fall das Mittel der Wahl. Mit einem Konstrukt wie <math>\left. \begin{align} \text{aüöbenßÄÖÜ}\\ \text{aüöbenßÄÖÜ}\\ \text{aüöbenßÄÖÜ} \end{align} \right\rbrace </math> erhält man:

 

Und da zeigt sich auch schon das Problem: Umlaute und ß werden nicht angezeigt. Für Umlaute gäbe es Umweg-Konstruktionen, aber für das ß könnte ich höchstens ein griechisches Beta (β) nehmen, und nachdem die Schrift in diesen math-Abschnitten sowieso schon von der sonst verwendeten abweicht, wäre das m. E. zuviel. Also scheidet TeX zumindest in dieser Form auch aus. Evtl. könnte man TeX noch nehmen, um in einer eigenen Tabellenzelle eine geschweifte Klammer zu erzeugen, die zwar höher als normal, aber nicht dicker ist. Das ist aber schon ein ziemlicher Aufwand, bei dem fraglich ist, ob das Ergebnis ihn rechtfertigt. Wahrscheinlich werde ich daher wie von 9xl angeregt auf die Klammern verzichten und das Problem mit zusätzlichen Tabellenzeilen etc. lösen. Viele Grüße -- Rosenzweig 12:55, 11. Jul. 2009 (CEST)[Beantworten]

Umlaute lassen sich durch einen Umweg darstellen: <math>\ddot{a}\ddot{o}\ddot{u}\ddot{A}\ddot{O}\ddot{U}</math>
 
ß lässt sich nicht darstellen (auch nicht durch \ss bzw. \ss{}). --enomil 17:17, 13. Jul. 2009 (CEST)[Beantworten]

Ja, wie ich oben geschrieben hatte. Die Pseudo-Umlaute sehen allerdings eher bescheiden aus. -- Rosenzweig 16:29, 14. Jul. 2009 (CEST)[Beantworten]

Archivierung dieses Abschnittes wurde gewünscht von: enomil 19:01, 15. Jul. 2009 (CEST)[Beantworten]

Hier wird bei Seite 70 kein Link angezeigt. Es ligt offensichtlich an der Zeilennummernvorlage im derselben Quellenzeile. Wenn ich einen Umbruch einfüge gehts wieder. Wer kann helfen? --Catrin 15:05, 11. Jul. 2009 (CEST)[Beantworten]

Nachtrag: Das Problem konnte ich bei Firefox 3.0.7 und 3.0.11 feststellen, der Internet Explorer 7 machts richtig. --Catrin 15:14, 11. Jul. 2009 (CEST)[Beantworten]

Zeile muss immer vor Seite stehn. -- Paulis 15:30, 11. Jul. 2009 (CEST)[Beantworten]
Danke, alles bereinigt. --Catrin 16:06, 11. Jul. 2009 (CEST)[Beantworten]
Archivierung dieses Abschnittes wurde gewünscht von: Catrin 16:08, 11. Jul. 2009 (CEST)[Beantworten]

Ausgeblendeter Seitenstatus

Offensichtlich war ich nicht mehr auf dem neuesten Stand, nach dem häufig oder standardmäßig der Seitenstatus auf der Bearbeitungsseite ausgeblendet ist und damit eine Änderung des Bearbeitungsstandes nur noch Eingeweihten möglich ist, die von so einer Statuszeile wissen und auch, wo man sie wieder einblendet. Dass kann es wohl nicht sein. Für das normale Korrekturlesen braucht kein Mensch die Werkzeugleiste, aber zur Änderung des BS muss man erst mal wissen, dass sich dort hinter einem nichtssagenden Button eine Statuszeile verbirgt, die eingeblendet werden muss. Warum eigentlich? Wenn ich Korrekturlesen will, dann kann ich auch gleich die Statuszeile sehen, wenn ich sie nachher eh zu ändern habe.

Ich beschäftige hier mich hauptsächlich mit Literaturlisten, Themenseiten, Biographien usw. aber wenn ich einmal eine Kleinigkeit korrigieren will und an das falsche Werk gerate, dann komme ich mir vor wie ein Vollidiot, wenn ich nach Jahren, die ich WS nun kenne, erst einmal fragen muss, wo diese verdammte Statuszeile geblieben ist und wenn ich schon fragen muss, dann möchte ich nicht wissen, wie viele Neulinge anonym schon unbemerkt herumprobiert und ohne nachzufragen aufgegeben haben.

Dass ist nicht meine Vorstellung von einem niederschwelligen Einstieg zu den Korrekturen Dann brauchen wir auch keine Einstiegswerbung wie „Hilf mit!“ auf der Hauptseite zu machen. Wir sollten dort besser hinschreiben „RTFM: Lies das Handbuch, dann kannst auch du mitmachen“ --88.67.112.47 10:51, 5. Mai 2009 (CEST) Nachtrag: Könnte auch ein technisches Problem sein, siehe: http://de.wikisource.org/wiki/Seite_Diskussion:De_Kafka_Prozeß_346.jpg daher Beitrag wieder gestrichen--88.67.112.47 10:57, 5. Mai 2009 (CEST)[Beantworten]

Nur eine Anmerkung: Ich habe ThomasV bereits auf seiner Diskussionsseite über das Problem, das bei IPs die Metadaten ausgeblendet sind und keine Quality-Buttons angezeigt werden, unterrichtet. --enomil 10:59, 5. Mai 2009 (CEST)[Beantworten]
Was werden hier wieder für unangekündigte Änderungen vorgenommen. Ich komme an die Vorlagen nicht mehr ran. Ich kann den Seitenstatus nicht mehr setzen. Unten tauchen bescheurte bunte Felder auf. Ich erwarte das Änderungen an der proofread2 Exytension von ThomasV vorher hier deutlich angekündigt werden. und nachgefragt wird ob wir den neuen Mist haben wollen. Oder er soll ein schalter einbauen, das wir diese besch... gängelnden JS-Funktionen abschalten können. Außerdem soll er seine extension besser testen!!!!. Es kann nicht angehen das plötzlich da Bild Platz einneimmt ohne Ende. Das ist absolut schlechter Stil. Es mag ja sein das das seinen persönlichen Vorlieben entspricht. aber hier gibt es Community, mit der soll er zusammenarbeiten. Am besten sollten man den ganzen neuen Mi... revertieren MFG Ich bin mehr als sauer -- Jörgens.Mi Talk 22:29, 6. Mai 2009 (CEST)[Beantworten]
Im Vertikalen Layout macht die Zoomfunktion Blödsinn, beim zoomen sollte er nicht mehr Platz auf dem Bildschirm einnehmen, sondern in dem bestehnden Fenster den Scan vergrößern und horizontale Scrollbalken anbieten. Es macht ja keinen Sinn das Scan-fenster so zu vergrößeren das man links daneben genau einen Buchstaben schreiben kann. -- Jörgens.Mi Talk 23:16, 6. Mai 2009 (CEST)[Beantworten]
opera 9.64 scheint zu funktionieren aber ab und zu wird das Bild in voller Größe angezeigt
Google chrome scheint zu funktionieren
Firefox 3.0.10machts falsch
IE scheint dasselbe Problem wie der FF zu haben -- Jörgens.Mi Talk 23:30, 6. Mai 2009 (CEST)[Beantworten]

Die Änderung war angekündigt, sowie der Grund, warum ich sie ausgeführt habe, siehe Wikisource:Technikwerkstatt. ThomasV 03:31, 7. Mai 2009 (CEST)[Beantworten]

Archivierung dieses Abschnittes wurde gewünscht von: 14:55, 17. Jul. 2009 (CEST)

Noincludes gehen verloren beim Editieren mit Firefox

Gerade sind bei mir die noincludes verschwunden, als ich einen Tippfehler beheben wollte: http://de.wikisource.org/w/index.php?title=Seite%3ADe_Kafka_Schlo%C3%9F_446.jpg&diff=774852&oldid=774842

Liegt das an meinen Einstellungen in Wikisource oder gibt es da Probleme mit den neueren Firefox-Versionen. Ich habe diese Version verwendet: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 --bhaak 09:24, 16. Jul. 2009 (CEST)[Beantworten]

Fehler nicht reproduzierbar für mich. --enomil 17:03, 16. Jul. 2009 (CEST)[Beantworten]
Hab den Fehlerverursacher gefunden. Wenn bei den Einstellungen bei Gadgets "wikEd" aktiviert ist, kommt es zu dem beschrieben Verhalten. Deaktiviert tut es, wie es sollte. --bhaak 09:14, 21. Jul. 2009 (CEST)[Beantworten]
Archivierung dieses Abschnittes wurde gewünscht von: bhaak 09:14, 21. Jul. 2009 (CEST)[Beantworten]

Verbesserungswunsch zu Druck- und PDF-Versionen

Generell vermisse ich in den PDF-Versionen

  • einen Hinweis auf Wikisource in der Nähe des Seitentitels
  • wesentliche Angaben aus den Textdaten (wie Herkunft, Jahr) (auch in der „normalen“ Druckversion)

--Liondancer 01:21, 9. Jun. 2009 (CEST)[Beantworten]

Manches lässt sich darüber lösen, dass man Druckversionen für Vorlagen (wie Textdaten) erzeugt. Die anderen Dinge, wie Seitentitel müssen über den Bugtracker angefordert werden. --enomil 01:50, 9. Jun. 2009 (CEST)[Beantworten]
Besser direkt über PediaPress: PediaPress Open Source Repository, Wiki and Bug Tracking System. --enomil 01:29, 22. Jul. 2009 (CEST)[Beantworten]
Archivierung dieses Abschnittes wurde gewünscht von: enomil 01:29, 22. Jul. 2009 (CEST)[Beantworten]

Absätze und Seitenwechsel bei Proofread

Wie erzeuge ich am geschicktesten Absätze, wenn diese mit einem Seitenwechsel einhergehen? Beim Zusammenfügen mit der SeitePR-Vorlage werden zusätzliche Umbrüche in den Quellseiten ignoriert, bzw. diese in den Quellseiten gar nicht erst mit abgespeichert. Eine Leerzeile zwischen den SeitePR-Aufrufen finde ich unschön, der Absatz gehört IHMO in die Quellseiten. --Rudolph H 16:39, 1. Mär. 2009 (CET)[Beantworten]

Dafür gibts noch nicht allzulange die Vorlage {{PRZU}} d.h. nach dem Text eine Leerzeile und auf die nächste Zeile dann die Vorlage. -- Paulis 17:34, 1. Mär. 2009 (CET)[Beantworten]

Das hatte ich gesucht! Danke sehr! --Rudolph H 18:49, 1. Mär. 2009 (CET)[Beantworten]
Auch von mir Danke, ich kannte das noch gar nicht und habs doch manchmal vermisst. Gruß, Jonathan Groß 16:32, 3. Mär. 2009 (CET)[Beantworten]

Erledigt-Baustein entfernt (gesetzt 15:54, 7. Jul. 2009 (CEST)) von enomil.

Durch eine Änderung (r52982) ist es nun nicht mehr notwendig, {{PRZU}} zu setzen. Absätze bei Seitenwechsel können nun durch doppelte Leerzeile am Seitenende realisiert werden.

Beispiel: Die doppelte Leerzeile am Ende von Seite:Urkunden und Akten aus dem Archiv der Klarissen zu Neuss.djvu/3 (Version 750734) erzeugt einen Umbruch in der Einbindung auf Urkunden und Akten aus dem Archiv der Klarissen zu Neuss (bitte weiter runterscrollen, bei den oberen Seiten wurden bereits die doppelten Leerzeilen entfernt). --enomil 17:08, 13. Jul. 2009 (CEST)[Beantworten]

Nachtrag: Scheint nur mit <pages /> zu funktionieren. Beim normalen Einbinden über {{SeitePR}} und ähnliche Vorlagen werden die Leerzeilen von der MediaWiki-Software entfernt. --enomil 14:54, 17. Jul. 2009 (CEST)[Beantworten]
Archivierung dieses Abschnittes wurde gewünscht von: enomil 16:20, 5. Aug. 2009 (CEST)[Beantworten]

NamespaceAlias WS

Ich würde gerne im Bugtracker den NamespaceAlias "WS" für den Namespace "Wikisource" beantragen und stelle dies hier zur Diskussion. Durch den Alias ist es möglich, auf Seiten aus dem Wikisource-Namensraum mit Hilfe von WS zu verlinken bzw. diese direkt aufzurufen. Ebenfalls können dann Shortcuts auch im richtigen Namensraum angelegt werden (zur Zeit befinden diese sich im NS:0). --enomil 21:10, 13. Jul. 2009 (CEST)[Beantworten]

Antrag zu finden unter Bug 19884. --enomil 23:02, 23. Jul. 2009 (CEST)[Beantworten]
Sehr sinnvoll. Sehe keinen Grund es nicht zu machen. Gruß -- Finanzer 22:39, 14. Jul. 2009 (CEST)[Beantworten]
Bin ebenfalls dafür, vielleicht sollte man bei der Gelegenheit gleich noch ein paar weitere Aliae beantragen. (Die WP hat unter anderem PD und WD für Portal_Diskussion und Wikipedia_Diskussion). --René Mettke 17:05, 15. Jul. 2009 (CEST)[Beantworten]
Portale führen wir nicht. Fallen also P und PD weg. WD für Wikisource_Diskussion braucht es mE (noch) nicht (Nutzung der Wikisource_Diskussionsseiten der letzten 30 Tage), wenn aber Konsens darüber besteht, können wir sie prophylaktisch mit beantragen. Seite, Index, Kategorie, Spezial, ... (+ Diskussion) brauchen zur Zeit auch keine Alias. --enomil 18:51, 15. Jul. 2009 (CEST)[Beantworten]

Ich denke, es geht nicht an, dass hier Technikfreaks unter sich irgendwelche Änderungen beschließen, die soe allgemeinverständlich zu kommunizieren nicht imstande sind. Wenn erwünscht ist, dass ein Konsens signalisiert ist, dann heißt das, man muss das übliche unverständliche Geek-Speak beiseitelassen und für jeden Mitarbeiter verständlich schlüssig zusammnfassen, was die Vorteile, vor allem aber die Nachteile der vorgeschlagenen Regelung sind. Nur weil jemand Informatik studiert, hat er hier keine Lizenz, die Community zu überfahren. Ich verstehe überhaupt nicht, worum es geht. Und es ist auch nicht meine Aufgabe, mich stundenlang einzuarbeiten. Wenn es nicht möglich ist, ein anschauliches, für jeden nachvollziehbares Beispiel anzuführen, dann muss eine Änderung eben unterbleiben --Historiograf 16:42, 22. Jul. 2009 (CEST)[Beantworten]

reinquetsch Mit überfahren der Community hats ja nun wirklich nix zu tun, ganz im Gegenteil. Ein einfaches "ich verstehs nicht" hätte völlig ausgereicht. -- Paulis 18:00, 22. Jul. 2009 (CEST)[Beantworten]
Läuft schon seit dem 14. auf Wikisource:Skriptorium#Technikwerkstatt, aber wenn alles pennt, braucht man sich nicht zu wundern und eine Regelung, was Kann- und Muss-Aufgaben wenigstens von Admins sind werden ja auch stets verhindert. Kein Wunder wenn normale Benutzer, die sich engagieren wollen, irgendwann die Schnauze voll haben von auf Zuruf regierten Projekten. --94.217.96.171 17:10, 22. Jul. 2009 (CEST) Na bloß gut, dass du seit dem 14. nicht gepennt hast. -- Paulis 17:25, 22. Jul. 2009 (CEST)[Beantworten]

Bin ebenfalls dafür. -- Paulis 17:25, 22. Jul. 2009 (CEST)[Beantworten]

Ja. --Stepro 18:01, 22. Jul. 2009 (CEST)[Beantworten]

Ich auch, (nach der Erklärung).-- Jowinix 19:30, 22. Jul. 2009 (CEST)[Beantworten]


Hier jetzt eine detailreichere und allgemeinere Erklärung. Histo: Da ich nicht imstande bin allgemeinverständlich zu kommunizieren, brauchst du hier nicht weiter lesen.

Ein Namespace alias ist eine Abkürzung oder verkürzte Schreibweise für einen Namensraum (Namensräume sind die Bezeichnungen vor dem Doppelpunkt, wie Benutzer, Benutzer Diskussion, Wikisource, usw.). Für das Projekt Wikisource schlage ich vor, die Bezeichnung WS einzuführen.

Für den normalen Benutzer verändert sich damit folgendes: Will man über die Suche zum Beispiel auf die Seite Wikisource:ADB-Werkstatt, so muss man in das Suchfeld "Wikisource:ADB-Werkstatt" eingeben. Durch die Einführung des Namespace alias müsste man nur noch "WS:ADB-Werkstatt" eingeben und man käme zur gleichen Seite. Dies gilt auch für das Setzen von Verlinkungen, es würde dann ausreichen [[WS:ADB-Werkstatt]] aufzuschreiben.

Die Suche-Vorschläge, dass heißt, wenn man etwas ins Suchfeld eingibt, schlägt einem die Software Seiten vor, die mit dieser Zeichenfolge beginnen, untersützt dies dann ebenfalls: Wer nach ADB-Seiten im Wikisource-Namensraum sucht, indem er Wikisource:ADB eingibt und eine Liste von Seiten erhält, die mit Wikisource:ADB beginnen, kann dann einfach WS:ADB eingeben und erhält die gleichen Vorschläge.

Im Grunde braucht man dann nicht mehr Wikisource: einzugeben, sondern kann einfach WS: benutzen, die Software erkennt beide zum Namensraum Wikisource zugehörig. Dies wird zum Beispiel auch bei Wikipedia benutzt (dort entspricht WP: gleich Wikipedia:). Anzumerken ist noch, dass beide simultan genutzt werden können, also nicht Wikisource: durch WS: ersetzt, sondern durch dieses ergänzt wird.

Daneben gibt es noch ein paar technische Aspekte: Die derzeitigen "Shortcuts" (wie WS:TW für Wikisource:Technikwerkstatt), befinden sich im allgemeinem Namensraum (Namensraum 0, ist durch keinen gesonderten Bezeichner aufrufbar), dort wo auch die Quelltexte sich befinden. Dort gehören sie aber eigentlich nicht hin. Wenn die Änderung durchgeführt wird, kann WS:TW nach Wikisource:TW verschoben werden (befindet sich also dann auch im richtigen Namensraum). Dadurch, dass man anstatt Wikisource: einfach WS: eingeben kann, verändert sich nichts in der Benutzung der "Shortcuts". Es erhöht sich außerdem die Wartbarkeit, da man schneller Änderungen an Seiten im Wikisource-Namensraum finden kann, als Änderungen an Seiten im allgemeinen Namensraum und auch die Liste der Seiten im Namensraum Wikisource kürzer ist, als die im allgemeinem Namensraum.

Fehler sind schon länger nicht mehr aufgetreten und alle Funktionen sind noch in dem Umfang verfügbar, wie sie vorher vorhanden waren (kurz: keine Nachteile bekannt).

Anbei noch ein paar Links zur technischen Dokumentation auf MediaWiki:

--enomil 18:52, 22. Jul. 2009 (CEST)[Beantworten]

Ich dachte das wäre schon immer. Also +1. --Rudolph H 19:58, 22. Jul. 2009 (CEST)[Beantworten]

  • Nein, das brauchen wir nicht. Das führt zu Abkürzungen, die nur noch Eingeweihte verstehen. Das Beispiel sagt eigentlich schon alles: WS:ADB-Werkstatt spart gegenüber Wikisource:ADB-Werkstatt 8 Zeichen von 24. Ich bitte euch, spendiert diese 8 Tastaturanschläge im Interesse der allgemeinen Lesbarkeit. Und wenn das irgendwo so oft vorkommt, dass es lästig wird, kopiert "Wikisource:", oder was auch immer, in die Zwischenablage. Mit Strg-V ist das noch schneller einzufügen. --9xl 08:18, 23. Jul. 2009 (CEST)[Beantworten]
    Gegenbeispiel: Kürzlich wurde WS:Etat angelegt, weil der Link bis dahin ins Lehre führt. Mit dem Alias wäre das unnötig, da die Eingabe von [[WS:Etat]] direkt auf Wikisource:Etat führen würde. Bonus wäre, dass die (der Konvention folgende) Großbuchstabenweiterleitung WS:ETAT im richtigen Namensraum läge. --René Mettke 22:31, 23. Jul. 2009 (CEST)[Beantworten]


Der Namensraum-Alias WS wurde heute durch einen Serveradmin eingerichtet. Raymond 19:26, 3. Aug. 2009 (CEST)
Alle Kürzel wieder hergestellt. --enomil 16:19, 5. Aug. 2009 (CEST)[Beantworten]
Archivierung dieses Abschnittes wurde gewünscht von: enomil 16:19, 5. Aug. 2009 (CEST)[Beantworten]

Scan-Frage

Ich kann bei Herder Index:Zerstreute Blaetter V.pdf ab Seite 223 keinen Scan aufrufen. Könnte das mal jemand anschauen. Vielen Dank --Lydia 15:52, 1. Nov. 2009 (CET)[Beantworten]

Sowohl gepurged als auch getouched auf commons, keine Veränderung. Auch kein aktiven Bugreport dazu gefunden. Erstmal abwarten, ob es nur temporäre Probleme bei der Einzelseiten-Erstellung sind (beschädigte PDF schließ ich mal aus, wird beim Download korrekt angezeigt). --enomil 16:10, 1. Nov. 2009 (CET)[Beantworten]
Paulis hat eine neue Version hochgeladen, sollte somit erledigt sein. --enomil 21:16, 11. Nov. 2009 (CET)[Beantworten]
Archivierung dieses Abschnittes wurde gewünscht von: enomil 21:16, 11. Nov. 2009 (CET)[Beantworten]

Extension:StringFunctions

Was muss ich tun, damit die Extension:StringFunctions auf de.wikisource aktiviert wird? --9xl 14:13, 13. Nov. 2009 (CET)[Beantworten]

Kurze Antwort: Warten bis es global aktiviert wird.
Länger: Die Funktionen wurden in die ParserFunctions Extension aufgenommen (r50997), jedoch Standard auf aus gestellt ($wgPFEnableStringFunctions). Es gibt zur Zeit noch Fehler und evtl. Sicherheitslücken, so dass dieser Teil noch nicht aktiviert wird. Auf Einzelprojekten dies aktivieren zu wollen, führt immer wieder dazu, dass auf den globalen Bugrequest verwiesen wird (siehe dazu Bug 6455, der auf WONTFIX steht). Wird wohl in absehbarer Zeit nicht aktiviert werden, auch wenn einige Funktionen daraus sehr praktisch wären. --enomil 14:46, 13. Nov. 2009 (CET)[Beantworten]
Schade, wäre auch zu schön gewesen. --9xl 14:56, 13. Nov. 2009 (CET)[Beantworten]
Archivierung dieses Abschnittes wurde gewünscht von: 9xl 15:01, 11. Dez. 2009 (CET)[Beantworten]

Hallo, wir die Letzte Änderungen aufmöbeln können, mit Ihrer Stimme für diese Installation. JackPotte 19:48, 15. Nov. 2009 (CET)[Beantworten]

Archivierung dieses Abschnittes wurde gewünscht von: 9xl 10:13, 13. Dez. 2009 (CET)[Beantworten]

Wiktionary Hover: ein JavaScript am Doppelklick

Wikinews vorschlägt ein Skript, um die wiktionary Definition in einer kleinen Kader anzeigen, wenn Doppelklickend auf ein Wort. Es ist bereits in den folgenden Wiktionary Helferlein installiert: in Französisch und Italienisch. Das Interface der Karte abhängt von der Sprache des Benutzers Präferenzen.

Für installieren dies hier, wir sollen stimmen für eine Administrator Operation, in:

  1. MediaWiki:Gadget-dictionaryLookupHover.js, Kopien ohne Anführungsstriche: "importScriptURI('http://en.wikinews.org/w/index.php?title=MediaWiki:Gadget-dictionaryLookupHover.js&action=raw&ctype=text/javascript');"
  2. MediaWiki:Gadgets-definition, zufügen hinzu: "* dictionaryLookupHover|dictionaryLookupHover.js"
  3. MediaWiki:Gadget-dictionaryLookupHover, beschreiben den Helferlein. JackPotte 19:48, 15. Nov. 2009 (CET)[Beantworten]
Archivierung dieses Abschnittes wurde gewünscht von: 9xl 10:13, 13. Dez. 2009 (CET)[Beantworten]

Browser-Kompatibilität

Neben den Problemen mit den PR2-JS sind mir noch weitere aufgefallen. Beide im Opera Browser:

  1. Die Hauptseite wird übergroß dargestellt (man kann nach rechts und unten scrollen, als wäre sie 2x so breit und lang). Konnte bis jetzt "nur" CSS-Fehler finden, die daran Schuld sein könnten (kein guter Code für die Boxenerstellung der Hauptseite, werde ich demnächst mal bereinigen und schauen, ob es daran lag).
  2. Schlimmer finde ich, dass Opera nicht mit {{BlockSatzStart}} zurecht kommt. Passiert jedoch nur meist, wenn viele Seiten eingebunden werden, manchmal aber auch nur bei 3 Seiten. Konnte keine unsichtbaren Zeichen, die vielleicht durch das OCR reingekommen sind, finden, auch sonst bin ich ratlos. Wenn man die includierten Seiten nur in ein div-Container oder nur in eine Tabelle mit jeweils text-align:justify; einfügt, klappt es einwandfrei. Die Vorlage setzt aber erst eine Tabelle und darin ein div, das scheint Opera nicht ganz so zu verkraften. Ein Beispiel wo solch ein Fehler auftritt wäre Leben und Thaten des ehrwürdigen Paters Simpertus, es kommt aber häufiger vor, als man denkt. Leider wird die Vorlage zu oft eingebunden, als dass ich sie einfach so umstellen und testen will. --enomil 01:26, 8. Mai 2009 (CEST)[Beantworten]
    Problem scheint in der Version Opera 9.64 nicht mehr aufzutreten. Das letzte Mal habe ich es bemerkt, als 2 Leerzeichen hintereinander verwendet wurden, kann aber auch nur Zufall sein, dass durch Entfernung des 2. Leerzeichen wieder ein normales enstanden ist. --enomil 15:54, 7. Jul. 2009 (CEST)[Beantworten]
    Durch Anpassungen der Vorlagen BlockSatzStart und BlockSatzEnd funktioniert es nun mit Opera und sollte auch in den anderen Browsern zu keinen Problemen führen. Wenn in anderen Browsern Probleme auftreten, bitte hier melden. --enomil 00:56, 21. Jul. 2009 (CEST)[Beantworten]
Archivierung dieses Abschnittes wurde gewünscht von: 9xl 08:32, 26. Mär. 2010 (CET)[Beantworten]

Skin 'Modern'

Ich wollte hier auch auf den Skin 'Modern' wechseln. Dabei ist mir aber aufgefallen, dass bei PR2 im Seiten-Namensraum die Scans nur im Editiermodus sichtbar sind. Kann das hier wer richten oder wo kann ich das melden? -- Cecil 20:07, 14. Aug. 2009 (CEST)[Beantworten]

Primär kann das nur ThomasV machen (sekundär auch jeder mit einem SVN-Zugang), entweder warten, ob er hier darauf reagiert oder einen Bugreport schreiben (und an ihn eintragen unter assigned to). --enomil 00:06, 15. Aug. 2009 (CEST)[Beantworten]
Archivierung dieses Abschnittes wurde gewünscht von: 9xl 08:56, 28. Mär. 2010 (CEST)[Beantworten]

Usability release

Seit heute ist das erste Usability relase (Acai) aktiv, dieses beinhaltet neben dem neuen Skin Vector (Vorschau) auch eine neue Edit toolbar, welche aber noch nicht mit der ProofreadPage Extension kompatibel ist. Auch die dazugehörigen Texte wurden noch nicht übersetzt, das sollte aber demnächst im translatewiki geschehen und dann eingespielt werden. --enomil 15:36, 2. Jul. 2009 (CEST)[Beantworten]

Einige IDs wurden wieder zurückgesetzt: Bug 19527. Im Translatewiki wurde soweit alles übersetzt, Update lässt auf sich warten. --enomil 19:00, 15. Jul. 2009 (CEST)[Beantworten]
Übersetzungen sind eingespielt. „Werbung“ ist auch geschaltet, oben neben dem Benutzernamen kann man bei „Beta ausprobieren“ den Vector Skin und die neue Edittoolbar aktivieren (geht natürlich auch über die Einstellungen: Skin unter Aussehen, Edittoolbar unter Bearbeiten und dort der letzte Eintrag). Noch einmal anzumerken, es dürfte nicht mit der PR2-Erweiterung kompatibel sein. --enomil 00:58, 7. Aug. 2009 (CEST)[Beantworten]

Statistiken zur Nutzung gibt es unter Spezial:PrefStats. --enomil 02:19, 14. Aug. 2009 (CEST)[Beantworten]

Archivierung dieses Abschnittes wurde gewünscht von: enomil 13:53, 9. Apr. 2010 (CEST)[Beantworten]

GIF thumbnails

Wer einen Bugtracker-Account hat, kann gerne einmal für den Bug voten:

Bug 16451: GIF scaling limit should be applied to animated GIFs only

Dieser hängt zusammen mit dem Bug 17791: ProofreadPage broken for GIF images due to assuming it can always create thumbnails. --enomil 20:47, 16. Jul. 2009 (CEST)[Beantworten]

Der Patch wurde heute mit rev:54284 eingespielt. Die Frage ist nur noch, wann die aktuelle Software live geht. Nachzulesen unter w:WP:NEU. Raymond 17:41, 3. Aug. 2009 (CEST)[Beantworten]

Nachdem der Patch wieder deaktiviert war, ist er jetzt wieder drin, siehe unter anderem w:WP:NEU#8. April. --enomil 13:55, 9. Apr. 2010 (CEST)[Beantworten]

Archivierung dieses Abschnittes wurde gewünscht von: enomil 13:55, 9. Apr. 2010 (CEST)[Beantworten]

Status-Problem

Mir hat es auf der Index-Seite eines eigentlich korrigierten Projektes (zweiter Text) zwei Seiten noch als unkorrigiert angezeigt (auf zwei unterschiedlichen Rechnern), obwohl die Seiten selbst den richtigen Header anzeigten und im Farbenkästchen auch den richtigen gelben Radiobutton ausgewählt hatten. Nachdem refreshen, usw. nicht gewirkt hat, wollte ich gerade einen Nulledit machen. Folge: der Status wird jetzt in der Indexdatei richtig angezeigt, Nulledit ist aber das keiner gewesen. Lösche ich meinen Edit (hier), ist zwar das Kästchen unten noch richtig ausgewählt, der Header stimmt aber nicht mehr und auf der Index-Seite stimmt die Anzeige auch wieder nicht. Kann das noch jemand anderes reproduzieren? -- Cecil 12:25, 20. Okt. 2009 (CEST)[Beantworten]

Problem schon länger bekannt und gestern hab ich dafür noch den Bug erstellt, da es bis jetzt noch nicht gefixed werden konnte: bugzilla:21181. --enomil 12:52, 20. Okt. 2009 (CEST)[Beantworten]
Danke. Dann reparier ich mal die eine Seite wieder. -- Cecil 13:28, 20. Okt. 2009 (CEST)[Beantworten]
Ist es das Wikisource:Skriptorium#Bug_auf_der_Indexseite? --9xl 16:14, 20. Okt. 2009 (CEST)[Beantworten]
Ja. --enomil 16:30, 20. Okt. 2009 (CEST)[Beantworten]

Nachdem ich soeben Seite:Der_Stechlin_(Fontane)_129.jpg auf "Fertig" gesetzt habe, sind 5 Seiten, die erst neulich (früheste: 13. Oktober) ihren Korrekturstatus geändert haben, betroffen. Interessanterweise sind keine Edits von mir dabei, obwohl manche noch neuer als die falsch angezeigten sind. Vielleicht hilft das in irgendeiner Form? --Dorades 18:55, 4. Nov. 2009 (CET)[Beantworten]

Auch bei [[1]] ist es so, es waren auch noch die Seiten 326, 328, 329 und 333 des gleichen Projekts betroffen, alle Seiten haben gemeinsam, dass sie ref-Tags beinhalten... --Jmb1982 00:46, 6. Nov. 2009 (CET)[Beantworten]
Archivierung dieses Abschnittes wurde gewünscht von: enomil 13:56, 9. Apr. 2010 (CEST)[Beantworten]

Ich hab ein Problem mit längeren Passagen (mehr als ein Paar Wörter) auf Hebräisch innerhalb deutscher Texten. Da in Vorlage:Hebräisch Zeilenumbrüche verboten sind, kann ich diese Vorlage im Blocksatz nicht benutzen. Momentan muss ich mit <span dir="rtl" class="hebrew"> auskommen. Vorlage:Hebräisch wird nur von einigen wenigen Seiten genutzt. Ich würde vorschlagen, dass Vorlage:Hebräisch standardmäßig Zeilenumbrüche nicht verbietet. Für Verwendung in den ADB- und RE-Artikeln, wo hebräische Wörter nur vereinzelnt vorkommen, ist es sowieso egal. Ich hab kurzerhand eine Testvorlage gemacht. Ist als erster Parameter nowrap gegeben, wird hebräischer Text aus dem 2. Parameter gelesen und ohne Zeilenumbrüche wiedergegeben. Sonst wird hebräischer Text aus dem 1. Parameter gelesen, so wie jetzt. Und hier kann man sehen, wie das alles funktioniert. Können wir diese Funktionalität in die Vorlage:Hebräisch übernehmen? -- Shruggy 01:25, 11. Nov. 2009 (CET)[Beantworten]

Archivierung dieses Abschnittes wurde gewünscht von: enomil 13:56, 9. Apr. 2010 (CEST)[Beantworten]

pages index + SeitePR

Wenn SeitePR auf page index folgt, dann gibtes einen Zeilenumbruch. Mich däuchte, der Fehler ist neu, jedenfalls wäre mirs ganz sicher aufgefallen, bei den Zwerg-Sagen zb, Übergang 356-357. Jetzt eben auch bei Cäcilia. -- Paulis 14:02, 14. Nov. 2009 (CET)[Beantworten]

Das lässt sich glücklicherweise einfach umgehen, hab gerade gemacht. -- Shruggy 16:38, 14. Nov. 2009 (CET)[Beantworten]
Archivierung dieses Abschnittes wurde gewünscht von: enomil 13:56, 9. Apr. 2010 (CEST)[Beantworten]

Gerade bei Der Aberglauben ist abzustellen aufgefallen, da passt was nicht. Während dieser Version bei mir im Firefox ok aussieht, überlappt sie beim IE den Text. A. Wagner hat das in dieser Version geändert. Jetzt ists im IE ok, dafür fliegts beim Firefox draußen in der Menüspalte rum. Angesichts größerer Nutzung zB hier sollte das wohl gerichtet werden. -- Cecil 17:00, 8. Jun. 2009 (CEST)[Beantworten]

Bei mir überlappt A. Wagners Version sowohl im FF3, als auch im Opera und im IE 8. -- DivineDanteRay 17:06, 8. Jun. 2009 (CEST)[Beantworten]
Erstere Version ist bei mir auch im IE8 ok. --Rudolph H 18:02, 8. Jun. 2009 (CEST)[Beantworten]
Hatte in der Firma vorhin IE 7. Dort ist die aktuelle Wagner-Version ok, die vorige ist teilweise übern Text. Nun zuhause mit IE 8 ist die alte Version ok, dafür ragt die aktuelle wie beim Firefox in den Text hinaus. -- Cecil 18:10, 8. Jun. 2009 (CEST)[Beantworten]

Firefox 3.6 stellt NotizLinks im Text dar, während NotizRechts [bei PR2] rechts neben und im Scan dargestellt wird (s. Seite:PhilonJosGermanCohn.djvu/007). -- Dorades 18:32, 19. Mai 2010 (CEST)[Beantworten]

Beim Blocksatz muss ein Rand freigelassen werden, z.B. durch {{BlockSatzStart|0|8em|8em}}. --Rudolph H 18:51, 19. Mai 2010 (CEST)[Beantworten]
Archivierung dieses Abschnittes wurde gewünscht von: enomil 14:53, 26. Aug. 2010 (CEST)[Beantworten]

Fehler

Vor der letzten großen PR2-Änderung gab es die Möglichkeit, sich Kopf- und Fußzeilen und Text im großen Textfeld anzeigen zu lassen. Und das hätte ich gern wieder. Es ist ja nichtmal möglich, mittels klick auf ein Zeichen in der Bearbeitungsleiste dieses in Kopf- bzw. Fußzeile einzufügen. Dieses rumkopiern ist reine Zeitverschwendung. Noch schlimmer finde ich aber, selbst wenn ich JavaScript ausschalte, dass die noinclude-tags nicht zu sehen sind. Hintergrund meiner Aufregung ist folgender Fehler, der schwierig zu beschreiben ist: Auf einigen Seiten erscheint ein Zeichen [2] welches auch nicht weg ist, wenn Text, oder zb poem-tags eingefügt werden. Es bleibt hinter dem Text, was aber bewirkt, dass PR auf der Projektseite dann nicht funktioniert. Ich kann also die noinclude-tags nicht sehen um den Fehler zu entfernen. Beispiel: Die_Schwestern_von_Lesbos#Seite 135 funktioniert nicht. Ich hoffe irgendjemand versteht mein Anliegen und kann Abhilfe schaffen. -- Paulis 08:46, 13. Aug. 2009 (CEST)[Beantworten]

Ich weiß zwar nicht genau ob wir das gleiche Problem meinen, aber wenn PoemPR für eine Seite verwendet wird die mit "Zeile" beginnt funktionierts nicht (die Seitenzahl auf der Projektseite läßt sich nicht anklicken – das gleiche Problem wie bei PR1 wenn die Reihenfolge nicht stimmt}, diese Erfahrung mußte ich schon bei Die Wolken machen. -- Jowinix 11:43, 13. Aug. 2009 (CEST)[Beantworten]
(quetsch) Zu dem Zeilenproblem, scheinbar legt sich der span über den Link von der Seitenzahl. Man müsste daher eventuell die class zeilennummer anpassen (hinsichtlich absolute Verschiebung und width). --enomil 20:14, 13. Aug. 2009 (CEST)[Beantworten]
Hallo Paulis, nicht ganz einfach. Ich sehe hier mit Opera eine Art Punkt, gefolgt von zwei Leerzeilen, meinst Du dies mit "Zeichen"? Mit dem IE sehe ich nur die Leerzeilen. Was Du mit "Die_Schwestern_von_Lesbos#Seite 135 funktioniert nicht" meinst, ist mir nicht klar. Der Anker funktioniert, und ich kann die Seite über den Seitenzahlenlink aufrufen und dort dann auch proofreaden. Magst Du das nochmal etwas detailierter beschreiben? --Rudolph H 19:37, 13. Aug. 2009 (CEST)[Beantworten]
reinquetsch IE, Opera machens; FF und Chrome hingegen weigern sich. -- Paulis 20:18, 13. Aug. 2009 (CEST)[Beantworten]
Ach so, dann bin ich leider raus. --Rudolph H 20:37, 13. Aug. 2009 (CEST)[Beantworten]
(BK) Das Zeichen müsste U+FEFF (ZERO WIDTH NO-BREAK SPACE) sein. Ich kann mir nur vorstellen, dass es durch die Botgesteuerte OCR kommt, denn das Unicode-Zeichen hat noch eine weitere Aufgabe: Es gibt die Codierung einer Datei ohne Wrapper an (siehe w:Byte Order Mark). Dass es hier als Punkt (oder kleiner Strich) angezeigt wird oder garnicht, liegt an den Browsern. Mehr zu dem Zeichen gibt im MSDN Blog Sorting it all Out von Michael Kaplan Every character has a story #4: U+feff (alternate title: UTF-8 is the BOM, dude!)
Scheinbar müssen wir damit leben: wer es sieht, kann es löschen, wenn es nicht zu löschen geht, Seite löschen und neuanlegen. Ansonsten eventuell einmal die Codierungen von OCR und Bot abstimmen. --enomil 20:05, 13. Aug. 2009 (CEST)[Beantworten]

Hintergrund deiner Aufregung gegen PR2 ist etwas, dass mit PR2 gar nichts zu tun hat... Dieser schwarze Punkt wurde von Finanzerbot ersellt. Es ist aber kein Melanom, du darfst es ruhig entfernen. ThomasV 19:58, 13. Aug. 2009 (CEST)[Beantworten]

Fehler mit der nichtklickbaren Seitenzahl bei PR2 sollte mit folgenden Änderungen erledigt sein (eventuell Seitencache löschen). PR1 nicht getestet (und hab es auch nicht vor). --enomil 20:41, 13. Aug. 2009 (CEST)[Beantworten]

PR1 zu ändern ist auch nicht nötig, weil ja die Reihenfolge der Vorlagen beeinflusst werden kann. Es ging nicht darum, dass das Zeichen nicht gelöscht werden kann, es hat nur einen Fehler produziert, der nicht auf den ersten Blick zu erkennen war. Na jedenfalls danke für die Erklärung und die Änderung. Und vielleicht findet sich irgendwann noch ein schlaues Köpfchen, welches mir meinen Wunsch von oben im ersten Teil meiner Frage umsetzen kann. -- Paulis 10:15, 14. Aug. 2009 (CEST)[Beantworten]
Archivierung dieses Abschnittes wurde gewünscht von: enomil 14:54, 26. Aug. 2010 (CEST)[Beantworten]

Problem mit Vorlage:SeitePR Rand

Diese Vorlage baut die Seiten nicht so zusammen, wie das sein soll. Ich habe 2 Beispielseiten erstellt:

Bei S2 werden die Seiten perfekt zusammengesetzt.

Ich habe mir die Vorlagen angeschaut und verglichen, kann aber nicht erkennen, woran das liegen könnte. Bitte um Hilfe. --9xl 16:34, 10. Sep. 2009 (CEST)[Beantworten]

Ich habe den Fehler gefunden. Seitenzahlen bei SeitePR Rand sollen nicht in ein <div>, sondern in ein <span> eingebunden werden. Sie ein Beispiel hier. -- Shruggy 18:21, 16. Nov. 2009 (CET)[Beantworten]
Dein Beispiel sieht gut aus, meines leider nicht. Seite 134 müsste aufrücken, wie bei Verwendung von SeitePR auf Benutzer:9xl/S2 zu sehen. --9xl 10:45, 17. Nov. 2009 (CET)[Beantworten]
Mit deinem Beispiel funktioniert es auch. -- Shruggy 12:56, 17. Nov. 2009 (CET)[Beantworten]
Archivierung dieses Abschnittes wurde gewünscht von: enomil 13:21, 24. Aug. 2011 (CEST)[Beantworten]

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)[Beantworten]

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)[Beantworten]
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)[Beantworten]
<pages /> funktioniert ebenfalls nicht, siehe PediaPress Ticket #646. -enomil 15:10, 17. Jul. 2009 (CEST)[Beantworten]
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)[Beantworten]
Seiten mit sections gehen immer noch nicht. --Rudolph H 18:12, 9. Apr. 2010 (CEST)[Beantworten]
Durch Bug 21136 kann eine Lösung wohl nicht implementiert werden. --enomil 15:43, 21. Apr. 2010 (CEST)[Beantworten]
Bitte alle für 21653 voten, dort scheint sich das Problem zu manifestieren. Ein Armutszeugnis. --Ayacop 18:41, 11. Sep. 2011 (CEST)[Beantworten]

Problem besteht nach wie vor. --Dorades (Diskussion) 13:45, 25. Feb. 2013 (CET)[Beantworten]

Archivierung dieses Abschnittes wurde gewünscht von: Mapmarks (Diskussion) 00:18, 15. Mär. 2019 (CET)[Beantworten]