Mal abgesehen davon, dass der Artikel lediglich mit zwei toten Links "belegt" ist, die laut archivierter Fassung früher mal Webshops waren, setzt der eine dieser Links [[Dupionseide]] auch noch mit [[Wildseide]] gleich. Wäre schön, wenn kompetente Leute das mal auf eventuelle Redundanz überprüfen würden. Hinzu kommt, dass der Artikel stellenweise Ratgebercharakter hat. --[[Spezial:Beiträge/87.150.3.19|87.150.3.19]] 10:45, 16. Mai 2020 (CEST)
Mal abgesehen davon, dass der Artikel lediglich mit zwei toten Links "belegt" ist, die laut archivierter Fassung früher mal Webshops waren, setzt der eine dieser Links [[Dupionseide]] auch noch mit [[Wildseide]] gleich. Wäre schön, wenn kompetente Leute das mal auf eventuelle Redundanz überprüfen würden. Hinzu kommt, dass der Artikel stellenweise Ratgebercharakter hat. --[[Spezial:Beiträge/87.150.3.19|87.150.3.19]] 10:45, 16. Mai 2020 (CEST)
:Es gibt [[Wikipedia Diskussion:WikiProjekt Textilverarbeitung und Kleidung]].--[[Benutzer:Mabschaaf|Mabschaaf]] 11:28, 16. Mai 2020 (CEST)
:Es gibt [[Wikipedia Diskussion:WikiProjekt Textilverarbeitung und Kleidung]].--[[Benutzer:Mabschaaf|Mabschaaf]] 11:28, 16. Mai 2020 (CEST)
::Danke, sowas suchte ich. --[[Spezial:Beiträge/87.150.3.19|87.150.3.19]] 13:16, 16. Mai 2020 (CEST)
== Transfer Wikipedia > Wikivoyage ==
== Transfer Wikipedia > Wikivoyage ==
Version vom 16. Mai 2020, 13:17 Uhr
Automatische Archivierung
Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 2 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind oder deren jüngster Beitrag 4 Tage alt ist.
Du hast Fragen zur Bearbeitung der Wikipedia und keine Antwort auf Hilfe:FAQ gefunden? Dann bist du hier richtig! Fragen werden nicht per E-Mail beantwortet, sondern nur auf dieser Seite. Bei aktuellen Themen findet sich hier oft schon eine passende Diskussion, die deine Frage beantworten kann. Bitte diskutiere dann dort und lege keinen neuen Abschnitt zum selben Thema an.
Abschnitte, deren jüngster Beitrag mehr als vier Tage zurückliegt oder die seit zwei Tagen mit dem Baustein {{Erledigt|1=~~~~}} gekennzeichnet sind, werden automatisch archiviert. Möglicherweise findest du auch im Archiv die Antwort auf deine Frage. (Gesamtarchiv • diese Woche)
Letzter Kommentar: vor 4 Jahren26 Kommentare16 Personen sind an der Diskussion beteiligt
Wenn ich in der Versionsgeschichte die Funktion "Versionen vergleichen" erscheint es mir, als wäre da eine andere Schrift, die ich nicht so gut lesbar finde. (Wirkt wie eine uralte Schreibmaschinenschrift.) Wurde da etwas geändert oder habe ich etwas verstellt oder guck ich heute schief? Gruß --Mirkur (Diskussion) 18:18, 30. Apr. 2020 (CEST)Beantworten
Seit dem heutigen Softwareupdate (siehe Wikipedia:Projektneuheiten) wird in den Diffansichten die Schriftart verwendet, die man hier als „Schriftart für den Text im Bearbeitungsfenster“ eingestellt hat. Also entweder dort umstellen (dann hat man auch im Bearbeitungsfenster serifenlose Schrift), oder Folgendes in die eigene common.css eintragen:
/* kein Monospace in der Diffansicht */.diff-addedlinediv,.diff-deletedlinediv,.diff-contextdiv{font-family:sans-serif;font-size:95%;}
Das stellt die Proportionalschrift nur in der Vergleichansicht wieder her und lässt das Bearbeitungsfenster unangetastet. Gruß, -- hgzh18:27, 30. Apr. 2020 (CEST) PS 5. Mai: Zurücksetzung der Schriftgröße ergänzt.Beantworten
Entgegen meiner Ankündigung unten habe jetzt doch etwas gebastelt und dabei festgestellt, dass – zumindest bei mir – offenbar auch die Schriftgröße (mit font-size:Wert;) noch angepasst werden müsste, um komplett die alte Formatierung wiederzubekommen. --Jumbo1435 (Diskussion) 21:53, 4. Mai 2020 (CEST)Beantworten
Die feste Zeichenbreite finde ich an dieser Stelle durchaus sinnvoll. Es wirkt nur deshalb so klobig, weil der Rest der Seite eine kleinere Schriftart hat. Mir reicht deshalb ein font-size-Eintrag mit dem Wert 12px. --Rodomonte (Diskussion) 23:26, 4. Mai 2020 (CEST)Beantworten
gudn tach!
mir geht es wie Rodomonte. gerade bei whitespace-aenderungen sind monospace-fonts angenehmer. nur sind 13px halt zu viel. -- seth23:31, 4. Mai 2020 (CEST)Beantworten
Ja, ohne Serifen wäre die alte Ansicht. Aber eigentlich müsste diese Version funktionieren. Neuladen einer Vergleichsseite, Browserneustart etc. hat nichts gebracht? Oben habe ich noch die Zurücksetzung der Schriftgröße ergänzt. Gruß, -- hgzh08:39, 5. Mai 2020 (CEST)Beantworten
gudn tach!
@user:Brodkey65: wenn du jetzt (mit dem neuen css-file) ein diff laedst und anschliessend dieses diff ohne beruecksichtigung des caches neulaedst (z.b. im firefox mit ctrl + shift + r), sieht es dann wieder so wei frueher aus? -- seth10:12, 5. Mai 2020 (CEST)Beantworten
@seth: Guten Morgen! Das ursprüngliche hgzh-Script hat bei mir net geholfen, vgl. mein genervtes Rumspielen gestern. Ich habe dann das Skript von Benutzer:Jumbo1435 genommen und es mit dem Tipp des Kollegen mirer kombiniert. Ich habe bei font size statt Wert einfach mal zunächst 12px und dann 11px eingetragen. Jetzt sieht es mit 11px wieder so wie früher aus bei mir, denke ich. Auf jeden Fall ist jetzt ein Arbeiten wieder möglich. MfG, --Brodkey65|...„Am Ende muß Glück sein.“10:33, 5. Mai 2020 (CEST)Beantworten
Ich begrüsse die Fontänderung tatsächlich. Die dicktengleiche Schrift erlaubt eine präzisere Darstellung; und tatsächlich müssten die meisten, die sich jetzt darüber beschweren, genau diese Schrift bestens aus dem Bearbeitungsfenster kennen. Aber der Mensch ist halt ein Gewohnheitstier und wenn man sich jahrelang an eine bestimmte Darstellung gewöhnt hat, können schon kleine Änderungen als störend empfunden werden, ich kenne das schon auch... Gestumblindi22:53, 5. Mai 2020 (CEST)Beantworten
(BK) Das Problem in meinen Augen ist, dass die dicktengleiche Schrift schreibfreundlicher, aber leseunfreundlicher ist. Ich sehe bei ihr zum Beispiel besser, wieviele Doppelpunkte ich zur Einrückung setzen muss, kann leichter einzelne Buchstaben einfügen. Aber das Lesen finde ich mühsamer (so wie auch z. B. bei älteren maschinengeschriebenen Dissertationen), weshalb ich, wenn ich nicht die Vorschau nutze, die meisten Tippfehler übersehe. Beim Versionenvergleich geht es aber doch um eine reine Lesefunktion, die bei umfangreichen Bearbeitungen größere Textmengen betreffen kann. Deshalb leuchtet mir nicht ein, wieso jetzt standardmäßig die gleiche Schrift für das Lesen und Schreiben festgelegt wird. Der einzge Vorteil ist in meinen Augen, dass man Mini-Änderungen leichter findet. --Amberg (Diskussion) 02:47, 7. Mai 2020 (CEST)Beantworten
gudn tach!
ich stimme dir zu. alles hat seine vor- und nachteile. monospace-fonts eignen sich hervorragend zum programmieren und editieren. zum fliessenden lesen dagegen sind sie weniger geeignet. und wenn man typographen glaubt (was ich tue), ist das nicht nur eine gewohnheitssache.
in welcher schriftart man leichter rechtschreibfehler findet, halte ich fuer eine interessante frage. in der schule wird kindern ja beigebracht, dass sie beim fehlersuchen den lesefluss brechen sollten. z.b. bekommt man da teilweise den tipp, dass man wortweise rueckwaerts lesen soll, um sich nicht vom inhalt ablenken zu lassen. (klar, grammatikfehler findet man dann nicht mehr so leicht.)
meine vermutung ist, dass die css-aenderer vor allem die korrektur ueber die lesefreundlichkeit gestellt haben. und wahrscheinlich sind es ohnehin programmierer (die monospace gewohnt sind).
Info: Mit Gerrit:594826 wurde diese Softwareänderung rückgängig gemacht. Begründung: People do not like the change, so it is being reverted. Codereview muss noch erfolgen. Geht vermutlich dann erst nächste Woche Donnerstag hier live. — RaymondDisk.08:48, 7. Mai 2020 (CEST)Beantworten
Komischerweise ist das geschützte Leerzeichen jetzt (nach dem Update) im Text, also in den Artikeln, extrem breit dargestellt. Ob das vom Erfinder so gewollt war? --Grullab (Diskussion) 01:03, 9. Mai 2020 (CEST)Beantworten
Hmm … Eingefügte/verschobene Punkte und Kommata sind zwar besser zu erkenne, dafür ist der Unterschied zwischen Minus und Halbgeviertstrich weg.
Das grundsätzliche Anliegen ist durchaus berechtigt.
Wer den Artikel nicht sehen kann, sondern vorgelesen bekommt, erhält nicht am Anfang den Einleitungsabschnitt, wie es eigentlich auch sein soll, und kann sich daran orientieren, worum es dann in dem Artikel gehen wird, und ob es der gewünschte Artikel wäre, sondern bekommt vorgelesen, was es mit diesem Bild auf sich hätte – kann aber das Bild nicht sehen.
Wikipedia:Barrierefreiheit ist so unterirdisch mickrig und unvollständig, dass ich das kürzlich komplett neu und konkret geschrieben habe per Hilfe:Textgestaltung/Barrierefreiheit. Der Einleitungsabschnitt wird dort zwar thematisiert, aber die Geschichte, dass der Zugang zum Einleitungsabschnitt durch vorangestellte Bilder verbaut wird, taucht dort auch noch nicht auf. Infoboxen haben ein ähnliches Problem, aber können wohl leichter übersprungen werden.
„Da ist nämlich das erste Bild bündig mit dem zweiten Absatz“ – wo wäre das Problem? Warum nicht?
(vom Fragesteller) Es gibt kein "Problem", ich finde es nur gestalterisch nicht ansprechend. Vor allem aber mache ich mir Gedanken um die ca. 100 anderen Bilder, die ich in den letzten Jahren ganz oben in bis dahin "bildleere", d.h. Nur-Text-Artikel gesetzt habe. .. Andere Frage: Bevor sich die WP in dieser Hinsicht bei geschätzt 500.000 Artikeln mit Bild fundamental ändert... Wäre es da nicht irgendwie sinnvoller, wenn die Programmierer von Lesegeräten ein bisschen Überstunden machen würden? Ich bin kein Programmier-Experte, aber das klingt irgendwie nicht schwer, zumal die WP ja nun eine der meistbesuchten (und besten ;-) Internetseiten ist. Ein anderer Ansatz wäre - könnte man nicht in der Mediawiki-SW eine "Lesegeräte-Erkennungs-Funktion" einbauen o.ä.? Schließlich beginnt ein Bild immer mit doppel-eckiger Klammer, was glaub ich auf nichts anderes hindeuten kann als auf ein Bild (doch: aber Tondateien wird man wohl irgendwie ausschließen können) 217.7.150.12223:56, 8. Mai 2020 (CEST)Beantworten
Es wäre wirklich ein ausgesprochen suboptimaler Zustand, wenn wegen der Rücksichtnahme auf Sehbehinderte Bilder nicht mehr so eingebunden werden „dürften“, dass sie oben bündig mit dem oberen Rand des ersten Absatzes abschließen. Da müsste dann auf jeden Fall eine Lösung gefunden werden. Das Problem scheint aber nicht allzu akut zu sein, wenn man (heißt: ich) nach mehr als 8 Jahren mehr oder weniger permanenter Anwesenheit im ANR wie im Metabereich noch nie was davon gehört hat… --Gretarsson (Diskussion) 00:39, 9. Mai 2020 (CEST)Beantworten
Die Bildunterschriften zum Startbild sollten möglichst klug gewählt werden und eine sinnvolle Aussage zum Lemma machen.
Wenn das Startbild keine allg. Repräsentation des Themas ist, verschiebe ich es gerne ans Ende des Einleitungsabschnitts, dann kommt es neben dem Inhaltsverzeichnis zu stehen, grundsätzlich kein Nachteil, vor allem bei größeren Bildern. Gruß --Chiananda (Diskussion) 01:46, 9. Mai 2020 (CEST)Beantworten
Das ist aber keine Lösung für Artikel, in denen das Startbild sehr wohl eine „allg. Repräsentation des Themas ist“, und ich wage mal zu behaupten, dass das auf nicht wenige Artikel zutrifft. Ein Patentrezept für die Beschriftung gibt es auch nicht (davon abgesehen: definiere „sinnvolle Aussage zum Lemma“ -- wichtig ist i.e.L., dass die Bildbeschreibung den Zusammenhang zwischen dem, was auf dem Bild zu sehen ist, und dem Lemma her(aus)stellt). --Gretarsson (Diskussion) 03:51, 9. Mai 2020 (CEST)Beantworten
Bilder die das Lemma illustrieren gehören an den Artikelanfang. Wenn nun Software für Blinde damit nicht gescheit umgehen kann, dann muss diese geändert werden. Nicht aber die Bilder nach unten geschoben werden.
Das ist so in vielen Newsportalen und auch hier der Fall (und auch sinnvoll), dass Bilder die für einen Artikel stehen (und oft sind es ja nur "Stockfotos") eben oben als erstes gelistet sind. Mit dieser Realität muss eine entsprechende Software dann umgehen können. --mirer (Diskussion) 03:56, 9. Mai 2020 (CEST)Beantworten
Was ist das denn für ein absurder Kommentar? Die Blinden und ihre Software sollen gefälligst selber für Barrierefreiheit sorgen? Wir fordern Barrierefreiheit von den Blinden anstatt von den Sehenden? Genausogut könntest Du sagen "Wenn blinde Menschen nicht das Titelbild einer Zeitschrift sehen können, dann muss eben was an ihrer Blindheit geändert werden".
Software für Blinde wird ständig überarbeitet und verbessert, aber sie kann nun mal auf dem jeweiligen Stand nur das, was sie eben kann. Ob das bei diesem Beispiel ein Problem ist und wenn ja für wen (es gibt ja völlig unterschiedliche Sehbehinderungen und völlig unterschiedliche Hilfsmittel), weiß ich nicht. Wer immer das da vor 12 Jahren reingeschrieben hat, hat ja offenbar gar keine Software für Blinde genutzt, sondern ein "Lesegerät" - was auch immer er damit meint.
Gibt es hier nicht vielleicht ein Portal oder eine Gruppe von blinden/ sehbehinderten Nutzern, die man mal fragen könnte, ob das heute noch ein Problem ist? --87.150.1.314:44, 11. Mai 2020 (CEST)Beantworten
Nun mal langsam. Es wurden nicht die Blinden aufgefordert, sehen zu lernen, sondern eine Anpassung der Software für Blinde gefordert. Ich sehe das genauso. Wie oben bereits geschrieben wurde sind Artikel, die mit einem Bild beginnen auch außerhalb der Wikipedia absolut üblich und eine Lesesoftware muss damit umgehen können. Man kann nicht von der Wikipedia verlangen, dass sie ihre Inhalte an schlechte Darstellungssoftware anpasst. Wenn ich morgen einen Browser auf den Markt bringe, der Artikel nur anzeigt, wenn sie mit dem Wort Donaudampfschifffahrtsgesellschaftskapitänsmütze beginnen, kann ich ja auch nicht verlangen, dass das Wort jetzt in jeden Artikel eingefügt wird. --Redrobsche (Diskussion) 14:54, 11. Mai 2020 (CEST)Beantworten
Die fragliche Screenreader-Software muss sämtliche Webseiten auf dem Planeten vorlesen können.
Sie kann keine Kenntnis davon haben, wie die deutschsprachige Wikipedia enzyklopädische Artikel zu formatieren geruht.
Wenn, dann wäre es Aufgabe der Wikipedia-Autoren, ihren Einleitungsabschnitt als solchen zu kennzeichnen.
Vorlage:Dieser Artikel und Vorlage:Begriffsklärung beispielsweise enthalten zwei an Screenreader adressierte semantische Hinweise, dass es sich einerseits um eine wichtige Information handelt, ob man überhaupt den gesuchten Artikel erreicht hätte, dass zum anderen das blau-rote BK-Icon völlig irrelevant sei.
Ansonsten sind in unserem Artikelinhalt alle Elemente gleichberechtigt, und die globale Screenreader-Software hat keinerlei Chance zu erlernen, was in unseren Artikeln wichtig oder unwichtig wäre.
Infoboxen sind Tabellen, und Blinde lernen nach kurzer Zeit, dass sie eine am Anfang stehende Tabelle jetzt eher nicht öffnen und sich dann Zeile für Zeile vorlesen lassen wollen. Bei bestimmtem Informationsbedürfnis in bestimmten Artikeln vielleicht doch mal. Das muss aber ein Mensch wissen; die Software entscheidet da überhaupt nichts.
Die vorgeschalteten Bilder sind Elemente wie jedes andere, und ihre Bildlegenden und Bildnamen werden erstmal vorgelesen. Bis irgendwann danach mal der Einleitungsabschnitt beginnt.
Die fragliche Software kann sowas durchaus unterscheiden, aber erst, nachdem die Wikipedia-Autoren eine inhaltliche Einstufung und Kennzeichnung jedes Elements nach Wichtigkeit vorgenommen haben. Nachdem die Wikipedia-Autoren diese Deklarationen vorgenommen haben, kann die Software das auch entspechend umsetzen.
Die Kenntnisse der Wikipedia-Autoren in Fragen der Barrierefreiheit sind erfahrungsgemäß mickrig, und weder bei exzellenten Artikeln noch sonstwo wird darauf viel geachtet. Wir haben auch schon genug Hürden für Neu-Autoren in Sachen WWNI, RK, Belegpflicht, Typografie, Zitierregeln, und vieles andere mehr. Dann auch noch ein Verständnis für Barrierefreiheit und entsprechende Gestaltung zu entwickeln übersteigt die Fähigkeiten meist.
Eine barrierefreie Gestaltung ist übrigens auch immer nett für Mobilgeräte. Dort sollte eigentlich auch mit dem Einleitungsabschnitt zuerst dargestellt sein, damit schon mal zu sehen ist, worum es auf der Seite gehen wird, und nicht erst sechs Seiten über Infobox und Bildergalerie gescrollt werden muss, bis dann mal gesagt wird was diese Seite eigentlich will.
@PerfektesChaos: Habe mich nie mit diesem Barrierefreiheitskram beschäftigt – obwohl der ja zweifellos extrem wichtig ist –, aber kann die Mediawiki-Software nicht auch automatisch Bilder und deren Bildunterschriften in Artikeln als für Blinde unwichtig kategorisieren? Mir fällt kein Anwendungsszenario ein, bei dem ein Blinder sich für die Bilder oder deren Bildunterschriften interessieren würde, ganz gleich, wo im Artikel sie sich befinden. (In manchen Artikeln wird auf die Bilder Bezug genommen, bis vor kurzem zum Beispiel in Analverkehr – dankenswerterweise im Zuge eines Rundumschlags gegen unbrauchbare Quellen entfernt –, aber das ist auch sonst eigentlich nicht gut.) --77.6.80.11500:36, 12. Mai 2020 (CEST)Beantworten
Nein, die MediaWiki-Software kann nicht für alle 1000 Wikis festlegen, dass alle Bilder und Bildunterschriften immer unwichtig sind.
Es wäre auch diskriminerend, denn auch Blinde wollen erfahren, dass es dort eine Abbildung gibt und was darauf zu sehen wäre.
Selten aber technisch möglich sind inhaltliche ausführliche Bildbeschreibungen bei uns hinterlegt, die erklären, was auf einem Foto oder in einer Grafik dargestellt ist.
Blinde können Personen aus ihrer häuslichen Umgebung bitten, ihnen zu beschreiben, was auf einem interessant scheinenden Bild zu sehen wäre. Dazu müssten sie aber erstmal wissen, dass es dort überhaupt ein Bild gäbe, und das können sie nicht, wenn irgendeine Software weltweit für alle Wiki-Seiten oder ein Screenreader radikal alle Bilder weglässt.
Es ist unsere Aufgabe, unsere Artikelinhalte zugänglich zu gestalten; sei es für Menschen, die nur begrenzt deutsch können und auf eine einfache Sprache angewiesen sind; sei es für Blinde. Oder für jemanden mit einem Smartphone, worüber global um die Hälfte aller Abrufe von Artikeln laufen.
Praktisch alle zusätzlichen Icons in unseren Artikeln, also dekorative eye-catcher wie das oben von mir erwähnte blau-rote Wegweiser-Icon bei Begriffsklärungshinweisen usw., die keinen weiteren Inhalt bieten, sondern nur die textliche Information daneben nochmal grafisch zusammenfassen sollen, sind von mir als unwichtig klassifiziert worden, und von deren Existenz bekämen Blinde überhaupt nichts mit. Das ist aber eine inhaltliche Entscheidung, die menschliche Bearbeiter in jedem Einzelfall treffen müssen.
Anders zusammengefasst: Immer, wenn es für die WP-Autoren mühsam wird, fordert irgendwer eine allwissende globale Super-Software, die ihnen die inhaltliche Kleinarbeit abnehmen und für sie die inhaltlichen Entscheidungen treffen soll, wie was wo geschehen soll. Kommt es tatsächlich mal dazu, dass irgendwo MediaWiki-Software ein Fitzelchen in dieser Richtung macht, dann gibt es sofort ein Riesengeschrei. Schon allein weil sich daurch irgendwas ändert, woran man sich gewöhnt hatte, und da müsste man ja was Neues lernen.
Bei allem nötigen Respekt für deinen Softwarelösungsdefätismus: Wenn man demnach die Wahl hat zwischen „für Sehende ok, für Blinde doof“ und „für Sehende doof, kommt dafür Blinden entgegen“, dann darf man sich auch nicht beschweren, wenn die Wikipedia-Autoren sich für die Variante entscheiden, die ihnen, also Sehenden, konveniert.
Meine Idee ging eher in die Richtung – da ich mich aber mit diesem Barrierefreiheits-Kram wie gesagt nicht auskenne, weiß ich nicht, ob das technisch überhaupt geht –, die Software automatisch markieren zu lassen: Das ist ein Bild zum Absatz, der darauf folgt. Lieber Screenreader, lies bitte den Absatz zuerst. So, wie ein sehender Mensch in der Regel ja auch erst den Absatz und dann die Unterschriften der zugehörigen Bilder liest – es sei denn, die Bilder sind echte eye-catcher, nur ist das irgendwie subjektiv und für den Blinden auch irgendwie egal. (Und ich bezweifle, dass es für jemanden – sei es Wikipedia-Autor oder blinder Leser – einen großen Unterschied macht, ob eine Bildunterschrift vor oder nach einem Absatz gelesen wird.)
Das müsste die Software übrigens auch nicht global und weltweit machen, sondern das könnte je nach Sprachversion konfigurierbar sein (wie schon so viele andere Dinge auch). Und ich bin ebenfalls nicht überzeugt, dass bei Hinzufügen eines Features, das ohnehin nur von Blinden bemerkt werden würde, wikipediaweit ein großes Geschrei anhübe. --77.8.168.17214:02, 12. Mai 2020 (CEST)Beantworten
Alle diese inhaltlichen Regeln, zu denen es ohnehin kein technisches Pendant gibt, müsste der menschliche inhaltliche Bearbeiter auf genau dieser Seite für genau dieses Bild und genau diesen Absatz explizit einzeln kennzeichnen.
Es gibt keinerlei Regel, die sich auf alle zweieinhalb Millionen Artikel und Millionen weiterer Seiten allein in dieser Wikipedia, dann noch von der MediaWiki-Software für global um 1000 Wikis anwenden ließe.
Es ist noch nicht einmal möglich, die Grenzen eines Einleitungsabschnitts durch die Software erkennen zu lassen. Eigentlich würde gelten, dass von Beginn des Inhaltsbereichs bis zur ersten Abschnittsüberschrift die kurze Zusammenfassung stehen würde. Wir haben aber auch mehrere langjährige „Hauptautoren“, die sich konsequent weigern, überhaupt eine Abschnittsüberschrift als Abgrenzung des Einleitungsabschnitts in „ihren“ Artikeln zu erlauben, und eine eingefügte in Hunderttausenden anderer Artikel übliche Abschnittsüberschrift systematisch wieder herauslöschen. Wodurch der gesamte Artikel zu einem einzigen gleichmäßigen Brei wird.
Für die Milliarde an Seiten, die von der Wiki-Software aufbereitet werden, gilt dann halt, dass alle Elemente, egal ob Text oder Bild, gleichberechtigt in der Reihenfolge vorgelesen werden wie sie im Inhaltsbereich stehen; von einer Tabelle wissen Benutzer dann halt irgendwann, dass dies Infoboxen oder Linkboxen sein werden, und können sie erstmal überspringen.
Das gleiche Darstellungsproblem haben übrigens die Mobilgeräte, namentlich die kleineren Smartphones; die Autoren bauen ihre Artikel regelmäßig so auf, dass sie nur auf einem Desktop-Schirm oder Tablet mittlerer Größe sinnvoll dargestellt werden können.
Der Sinn des Einleitungsabschnitts ist für Benutzer von Mobilgeräten genauso wie für Blinde, dass sie zunächst einmal kurz umrissen bekommen, worum es im nachfolgenden Artikel gehen wird. Zu sehen ist auf dem Mobilgerät aber erstmal die Infobox in voller Bildschirmbreite, danach kommen ggf. die Bilder, und erst danach wird erzählt, was das für ein Artikel ist und was das Lemma in etwa bedeutet.
Letzter Kommentar: vor 4 Jahren11 Kommentare4 Personen sind an der Diskussion beteiligt
Tab. einfach ohne Kopfzeile
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Tab. einfach mit Kopfzeile
Überschrift
Überschrift
Überschrift
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Tab. mit Kopfzeile, 1. Zelle doppelzeilig
Überschrift
Überschrift
Überschrift
Untertitel
Untertitel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Tab. sortierbar mit Kopfzeile
Überschrift
Überschrift
Überschrift
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Tab. sortierbar mit Kopfzeile, 1. Zelle doppelzeilig
Überschrift
Überschrift
Überschrift
Untertitel
Untertitel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
So etwas 100 % Sicheres wie den Wunschparkplatz (gebührenfrei) habe ich mir schon immer für meinen Fuhrpark (3 Räder, Bollerwagen, Schlauchwagen, Roller, Dreirad) gewünscht. Da findet kein Mensch hin. Dumm ist nur, dass man sinnvolle Verbesserungsideen eher in en-wiki unterbringt und realisiert. Dann landen sie vielleicht auf Umwegen auch bei unseren WP-Gurus und werden als eigene Idee ins Volk geworfen.
Im aktuellen Fall geht es schlicht um ein Feature, dass bei sehr langen Tabellen den Kopf fixiert und beim scrollen stets anzeigt. Dazu sind in der passenden, globalen css-Datei (elements.css ?) genau zwei durchgetestete und 100% funktionierende Zeilen (ca. 150 Anschläge) einzufügen.
In manchen Fällen kann Phabricator der richtige Ort dafür sein, dort wurde dieser Wunsch schon 2012 geäußert: phab:T42763. Die Sache ist ja doch etwas komplexer, wenn man sie global für alle Tabellen ermöglichen will, und ohne entsprechendes JS nicht machbar. In MediaWiki:Common.css lokal neue Klassen vorzuschlagen ist wenig zielführend; deine CSS-Lösung würde, wenn ich das richtig verstanden habe, nicht mit sortierbaren Tabellen zurechtkommen und auch nicht mit mehrzeiligen Headern (zumindest sind das die mir bekannten Probleme, gibt vielleicht noch mehr). In einzelnen Vorlagen per TemplateStyles kann man die Funktion aber natürlich jederzeit einbauen, wenn funktional. Gruß–XanonymusX (Diskussion) 22:53, 10. Mai 2020 (CEST) Wobei ich das mit den sortierbaren Tabellen selbst nicht nachvollziehen kann, ist vermutlich nur für eine JS-Lösung relevant.Beantworten
So wie ich es verstanden habe, beschäftigt sich phab:T42763 mit der overflow-Variante, die zwar deutlich eleganter ist, aber da stellt sich WP selbst ein Bein mit der Sortierfunktion bzw. JS, sowie einiger kleinerer "Vereinfachungen" bei der Anlage/Umsetzung von Tabellen (thead fehlt mitunter). Das wäre ein enormer Aufriss, so etwas softwareseitig zu realisieren. Mein Vorschlag ist etliche Nummern kleiner und greift, ehe JS dazwischen funkt.--Klaus-Peter (auf und davon)13:34, 12. Mai 2020 (CEST)Beantworten
Anscheinend geht es darum, das, was Benutzer:Gadacz (Klaus-Peter) in seine common.css eingetragen hat, für alle nutzbar zu machen:
Gadacz, ich hab das lokal im Firefox getestet ohne die Klasse kopf (und ohne das Webkit-Prefix). Dazu fällt mir auf:
Das funktioniert eben nicht in 100 % der Fälle: Nur bei sortierbaren Tabellen wird vom Parser ein thead erzeugt.
Die obige zweite Zeile ist syntaktisch fehlerhaft, wird aber auch gar nicht benötigt, wegen Anmerkung 1, denn der Parser erzeugt dann außerdem nur th-Elemente. Vermutlich wolltest Du das hier ausdrücken, oder?
Nun, die bei mir eingetragene Variante funktioniert (fast) 100%-ig. Lediglich bei rowspan in den Kopfzeilen gibt es Displayfehler, mit denen man aber leben kann. Da werden bei mehrzeiligen Köpfen nur Zweitzeilen dargestellt, also die Zellen (ohne rowspan) , die einen Eintrag haben. Den Trick, die komplett zu bedienen, habe ich noch nicht gefunden, lohnt aber kaum.
Ja, die 2, Zeile kann man den Hasen geben. es reicht: table.kopf th {position:-webkit-sticky; position:sticky; top:0;}. Dabei entstehen aber bei Zwischenzeilen/feldern mit !=<th> unschöne Ergebnisse, da die dann auch ‚angeklebt‘ werden und die Werte der Kopfzeile überdecken.
Irgendwie setzte ich aufs falsche Pferd mit der 2. Zeile. Letztendlich wollte ich ‚unsortierte‘ Kopfzeilen einschließen, aber sonstige <th> übergehen. Dummerweise verwendet WP für alle Zeilen und Zellen, die mit ! starten das <th>, auch mitten im <body>. Das könnte man eleganter und eindeutiger lösen.
Klar, Klassekopfsucht erst mal nach<thead>. Gibt es leider nicht immer (nur bei sortable. Ohne Sortierung findet man nur . So muss man auf alle <th> abstellen.
Würde WP konsequent bei ALLEN Tabellen mit Kopfzeilen thead vor tbody einsetzen, wäre es nie ein Problem. So muss man versuchen diese Mängel zu umschiffen.
Ohne die Zwischenlinien im Kopf kann man überleben, die stören weniger als total verschwindende Kopfzeilen. Wer da wen nicht mag, ist mir schleierhaft, zumal auch explizit ergänzte css-Anweisungen zur Randgestaltung ignoriert werden.
@Gadacz: Ich habe oben an die Seite 5 Testtabellen eingefügt. Dazu ein Vorschlag, das Darstellungsproblem bei rowspan und mit den inneren Rahmen bleibt aber bestehen:
Danke für die interessanten Varianten. Werde sie mal durchtesten. Klar, common.css ist sicher eine sinnvolle Lösung, setzt aber voraus, dass jeder 'normale' Leser bei WP angemeldet ist und mit der Technik umgehen kann. Oft bemerke ich, dass viele Autoren und Entwickler total den Anschluss zur Umwelt verloren haben und meinen, WP sei nur ein Spielfeld für Insider. Ich denke mal, die überwiegende Masse sind nur unbescholtene Leser, die gezielt oder ergoogelt auf WP-Artikel stoßen und die möglichst flott erfassen und begreifen wollen. Gerade für die wäre es hilfreich, wenn sie bei den zahlreichen Monstertabellen mit ohnehin kryptischen Werten etwas den Überblick behalten können. WP ist KEIN Selbstzweck für Freaks!
Standardmäßig für alle würe denkbar, aber unsinnig, da erst für Tabellen interessant, die deutlich über den Bildschirm rennen. Daher meine Klasse-kopf-Idee, die ich gesteuert vorbestimmen kann, wie toptext, sort, zebra usw. Das muss der Leser auch fressen.
@Speravir habe es jetzt mal bei global.css eingetragen und mnacht eigentlich fast genau das, was ich will. An den selector hatte ich garnicht gedacht. DANKE! Nun, für mich selbst ist das ausreichend. An den Rest der Welt zu denken ist das Privileg anderer Experten.--Klaus-Peter (auf und davon)06:06, 15. Mai 2020 (CEST)Beantworten
Hinten angefangen (ich hätte da selbst gleich nachsehen können): position - CSS: Cascading Style Sheets | MDN; dort steht --webkit-sticky im Beispiel noch drin, offensichtlich wegen des Safari. Den IE erreichst Du damit aber sowieso nicht.
„Mein“ obiger Code wird leider auch in einigen Infoboxen aktiviert (obwohl gar nicht immer eine Tabelle notwendig wäre, ja rein syntaktisch sogar fehl am Platz ist – wenn nur wenigstens immer ein Klasse infobox vorhanden wäre)(*), insofern ist Dein Anliegen mit einer zusätzlichen Klasse verständlich. Irgendsoetwas hatte ich auch befürchtet, deswegen meine Bemerkung, dass ich das als Voreinstellung für zu gewagt halte. PerfektesChaos könnte mit Sicherheit zu dem gesamten Thema viel mehr erklären oder wenigstens auf eine passendere Stelle hinweisen.
(*) Beispiele von der heutigen Startseite: Santa Pola, Wolmido (bei beiden scheint die Tabellenform aber gerechtfertigt), alle (?) Taxoboxen wie in SARS-CoV-2, die wohl keine Tabelle sein müssten; ohne Darstellungsproblem dagegen Nördlicher Drömling (Tabelle ohne th-Element), Schlacht bei Cartagena (460) (gar keine Tabelle).
hzgh hatte die gleiche Angelegenheit bereits einmal ablehnend kommentiert.
Das gehört, wenn überhaupt, in die Hände kompetenter MediaWiki-Entwickler.
Das lokale Gefrickel hier ist gaga.
Man hatte 1998 aus exakt diesen Gründen die Elemente <thead> und <tfoot> in HTML.4 eingeführt, um sich genau die Möglichkeit zu eröffnen, dazwischen den <tbody> scrollen zu können.
Bis heute wird das jedoch nicht deckend und mehr als experimentell von den Browser-Entwicklern unterstützt.
Hinter dem letzten Komma steht das Wort "umfasst" allein. Dieses kann hier problemlos direkt im Hauptsatz angefügt und der Umstand somit eliminiert werden:
Nicht immer klingt eine solche Elimination stimmig:
Die Person, die hart arbeitet, schwitzt. -> Die Person schwitzt, die hart arbeitet.
Mir ist klar, dass "Die hart arbeitende Person schwitzt." eine Lösungsmöglichkeit zur Elimination darstellen würde. Ich möchte mich aber hier auf den Fall der Umsetzung des einzeln stehenden Wortes beschränken.
Drei Fragen:
1) Gibt es für das durch Komma abgetrennte einzeln stehende Wort einen Begriff und wird dieser in einem Wikipedia Artikel behandelt?
2) Ich habe oben argumentiert, dass die zweite Elimination nicht stimmig klingt. Bei der Methode bin ich auf Sprachgefühle angewiesen. Gibt es auch eine logische (grammatikalische) Analyse, die aussagt, ob eine Elimination möglich ist? Wird diese Analyse in einem Wikipedia Artikel behandelt?
3) Mir erscheint - insbesondere in Wikipedia Artikeln - die eliminierte als die erstrebenswertere Form, sofern sie wie im ersten Beispiel problemlos ist. Würdet ihr Euch dem anschließen?
Wenn's zu lang wird oder die Satzklammer zu weit gespreizt ist, empfiehlt sich meist eine Aufteilung in mehrere Sätze.
Etwa so: "Das Sonnensystem ist die Gesamtheit aus der Sonne als Zentralgestirn und dem sie umkreisenden Planetensystem. Zu letzterem gehören ..." --Zinnmannd08:41, 12. Mai 2020 (CEST)Beantworten
Siehe auch: Wikipedia:Wie schreibe ich gute Artikel#Schreibe in ganzen Sätzen: "Satzkonstruktionen mit verschachteltem Satzgefüge oder weit gespannter Satzklammer mindern häufig die Verständlichkeit – beispielsweise: Müller-Demasch nahm an der Pariser Seerechtskonferenz von 1909, bei der er die viel beachtete Festrede über Eigentumsrechte an Eisbergen hielt, teil." Hier liegt allerdings der Fokus auch auf "weit gespannter Satzklammer", nicht auf Satzklammer als solcher. Ich wäre also zurückhaltend mit grundsätzlichen Entfernungen. Wie immer bei Stilfragen ist das auch ein Stück weit Geschmacksfrage bzw. Einzelfallentscheidung (wir raten ja auch vom Passiv ab und natürlich gibt es in Einzelfällen gute Gründe, einen Satz im Passiv zu schreiben). Gruß --Magiers (Diskussion) 09:08, 12. Mai 2020 (CEST)Beantworten
Ich löse solche Satzklammern immer auf, wo ich auf sie stoße und es nicht (wie oben bei „Die Person, die hart arbeitet, schwitzt“) fragwürdig wäre. In der Regel ist das stilistisch zumindest nicht weniger günstig (wenn nicht sogar besser) und üblicherweise leichter lesbar.
Ich bezweifle, dass das ein linguistischer Fachbegriff ist, aber den Grund hat jemand mal so beschrieben, dass die Satzstruktur des Deutschen „konkav“ sei wie ein Suppenteller, und wenn nicht genug Rand da sei, fließe die Suppe raus. Deswegen würden im Deutschen gemeinhin solche Sätze als stilistisch schöner empfunden, bei denen Nebensätze eben nicht auf einer Seite nur durch ein Einzelwort eingerahmt sind. --77.8.168.17210:51, 12. Mai 2020 (CEST)Beantworten
Ich habe offensichtlich einen Beispielsatz gewählt, der dazu verleitet, dessen Verschachtelung und nicht die eigentliche Frage zu diskutieren. Ich hätte wohl nicht solch einen Bandwurm sondern ein kürzeres Beispiel wählen sollen. Ein solches wäre dieses - ungeachtet von einer Eignung für einen Artikel:
1) Ein Baum ist eine Pflanze, die alles, was daran wächst, umfasst. -> Ein Baum ist eine Pflanze, die alles umfasst, was daran wächst. versus
2) Die Person, die hart arbeitet, schwitzt. -> Die Person schwitzt, die hart arbeitet.
Mir geht es dabei ausschließlich um eine Umgestaltung durch das Umsetzen des einen durch Komma abgeteilten Wortes. Warum klingt das im ersten Beispiel gut und im zweiten nicht? Gibt es einen (grammatikalischen) Algorithmus oder eine weiche, weniger deterministische Methode, die hier die Frage "Wohlklang ja oder nein" beantworten kann oder geht das nur mit Sprachgefühl? Und ist dieses spezielle Problem in einem Wikipedia Artikel thematisiert? -- Tirkon (Diskussion) 01:39, 14. Mai 2020 (CEST)Beantworten
@Tirkon: Ich verschiebe dich mal nach hier unten, statt oben „dazwischengequetscht“ ;)
Ich finde lost words am Satzende auch dumm. Liest man leider besonders oft bei (alt-)philologischen Ausschweifungen wie:
„Das Wort ‚Xyz‘ leitet sich vom althochdeutschen xyß, mittelhochdeutsch xyss, von ursprünglich vorsanskritisch -xys… ab.“
Sowas geht einfacher:
„Das Wort ‚Xyz‘ leitet sich ab vom… blablabla mit komplizierten Klammerverschachtelungen und so.“
Letzter Kommentar: vor 4 Jahren8 Kommentare7 Personen sind an der Diskussion beteiligt
Mark Zuckerburg: "... entstammt einem jüdischen Elternhaus."
George Soros: "... der jüdischen Herkunft seiner Familie ...".
Bill Gates: keine Angaben zur Religionszugehörigkeit, weder bei ihm noch bei seiner Familie
Jeff Bezos: keine Angaben zur Religionszugehörigkeit, weder bei ihm noch bei seiner Familie
Warum wird bei den einen die Glaubenszugehörigkeit genannt und bei den anderen nicht?
--2003:F0:3F45:213D:C999:A0D3:39CA:EDE120:37, 12. Mai 2020 (CEST)Beantworten
Das musst du diejenigen fragen, die die Artikel geschrieben haben.
Grundsätzlich aber finde ich, dass die Glaubenszugehörigkeit nicht in unsere Biografien gehört, außer sie ist für die Person wichtig (also z. B. natürlich bei Geistlichen, aber auch bei Personen die wegen ihres Glaubens verfolgt wurden, bei Personen, die wie wegen ihres Glaubens Bedeutung erlangt haben oder z. B. auch bei Personen, für die ihre Religionszugehörigkeit einen wichtigen Teil ihres Lebens oder ihrer Persönlichkeit ausmacht). Es muss also im Einzelfall entschieden werden. -- Chaddy · D21:34, 12. Mai 2020 (CEST)Beantworten
Bei Zuckerberg hat der Anfragende Recht, warum da de Religionszugehörigkeit drin steht ist unklar, bei George Soros sieht das deutlich anders aus - zu seiner Biographie gehört, dass er, mit seiner Familie, als Jude während der Besetzung Ungarns durch die deutschen Streitkräfte unter Verfolgung zu leiden hatte. Im übrigen: Religion ist ja keine Schande, man muss sie nicht in jedem Fall reinschreiben, aber ist auch nichts ehrenrühriges. Gruß --Lutheraner (Diskussion) 23:18, 12. Mai 2020 (CEST)Beantworten
Das kann aber auch daran liegen, was in den Quellen vorzugsweise drinsteht oder eben nicht. Auf diese fußt aber die Wikipedia laut ihren Grundregeln. Dasselbe Problem besteht beispielsweise bei politischen Ansichten, wo manche in Quellen und der Wikipedia bevorzugt genannt werden. Zudem ist bei der Vielzahl der Autoren in Wikipedia eine Einheitlichkeit kaum erreichbar. Das kann nur ein streng schlussredaktionell geführtes System leisten. Aber solche Enzyklopädien sind durch die Wikipedia stark in den Hintergrund gedrängt worden. Jedes System hat seine Stärken und Schwächen. Ihr System hat Wikipedia erfolgreich gemacht, obwohl es gleichzeitig die hier kritisierte und andere Schwächen impliziert. -- Tirkon (Diskussion) 02:26, 14. Mai 2020 (CEST)Beantworten
Wenn das dazu führt, dass die (vermeintliche oder tatsächliche) Religionszugehörigkeit vor allem bei „Juden“ eingetragen wird, ist das ein Grund, die verwendete Literatur und deren Wiedergabe kritisch zu hinterfragen. --77.0.160.20500:35, 16. Mai 2020 (CEST)Beantworten
Wenn man die Nutzung der Quellen mit bevorzugter Nennung des Jüdischen hinterfragt, dann bricht der Großteil der Literatur weg - auch die als verlässlich angesehene. Es bleibt dann viel zu wenig übrig, aus dem Wikipedia sich speisen könnte. Nur eine gesellschaftliche Diskussion außerhalb Wikipedias kann die Quellen ändern, so wie es ehemals auch bei den Schaumküssen geschehen ist. Seinerzeit hätte eine Wikipedia auch nur den heute negativ konnotierten Begriff nennen können, weil es in den Quellen nichts anderes gab. Nur wenn sich durch eine solche gesellschaftliche Diskussion mehrheitlich veränderte Ansichten ergeben, besteht die Chance, dass sich das auch für die notwendige Vielzahl der Wikipedia Autoren auch durchsetzt. -- Tirkon (Diskussion) 11:38, 16. Mai 2020 (CEST)Beantworten
Peoplepill als Quelle
Letzter Kommentar: vor 4 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo, ich habe eine Frage zur Validität einer Quelle. Benutzer:Salaheghbali1985 hatte dankenswerterweise bei den Geburts- und Todesdaten von Hermann Argelander um Tag/Monat ergänzt. Ich hatte diese Angaben damals bei der Anlage des Lemmas nirgendwo finden können. Als Quelle ist dies hier angegeben https://peoplepill.com/people/hermann-argelander/ Weiß jemand, ob das eine zuverlässige Quelle ist.?Ich habe mal versucht, den dort angegebenen Referenzen nachzugehen, was mir bei etwa der Hälfte gelungen ist. Allerdings gab keine dieser Referenzen Auskunft zu Tag und Monat. --Mirkur (Diskussion) 22:55, 12. Mai 2020 (CEST)Beantworten
Danke schön, habe es korrigiert und die bessere Quelle angegeben (und dabei "zufällig" festgestellt, dass ich da sogar einen Zugang zu habe. Welch eine Entdeckung, auch das verdanke ich dir ja jetzt indirekt ;-) Das Datum, bis wann er die Institutsleitung inne hatte, lasse ich, weil das mit der Uni selbst gut bequellt ist. Gibt es eigentlich irgendeine Vorlage für solchen Angaben aus Kürschners oder reicht das so, wie ich es eingegeben habe. (Nur wenn du Lust hast.) Gruß --Mirkur (Diskussion) 16:10, 13. Mai 2020 (CEST)Beantworten
Gern geschehen :-) Bei der Uniseite steht ja nur, wann der nächste Prof angefangen hat, vielleicht dazwischen Vertretungen oder so? Aber keine Ahnung. Ja, Vorlage gibt es inzwischen ala {{KürschnerGelehrt |1=0 |Name= |ID=P????? |Abruf=2020-05-13}}--Berita (Diskussion) 16:20, 13. Mai 2020 (CEST)Beantworten
Idee: neues Schwesterprojekt, das nur die wichtigsten Aussagen zu jedem Stichwort sammelt
Letzter Kommentar: vor 4 Jahren10 Kommentare9 Personen sind an der Diskussion beteiligt
Twick.it in etwas länger? Sich mit Wikipedianer darüber zu streiten, was die zehn zentralen Aussagen zu einem Thema sind, stelle ich mir anstrengend vor, aber immerhin sind die Keyworder die ersten, die zu Hitler nichts zu sagen haben. NNW12:33, 13. Mai 2020 (CEST)Beantworten
Interessant, dass Wikipedianer bei der Erstellung einer neuen Informations- und Wissenssammlung gleich an möglichen Streit denken. Nach meiner Erfahrung halte ich es allerdings auch für besser, dass so eine Keywordsammlung von einem redaktionellen Team erstellt wird. Ich habe früher zusammen mit anderen solche 10-Satz-Biographien über Musiker und Schauspieler erstellt, weil es einerseits Platzprobleme (in Printmedien) und Speichermangel (schon lange her) gab. Dazu kam natürlich das Interesse der Leser, Fakten kurz und interessant präsentiert zu bekommen. Dieses Interesse gibt es noch immer, aber es zu erhalten setzt eine (praktisch journalistische) Recherchearbeit und Auswahl voraus. Das Abschreiben von Büchern und Einfügen schwurbeliger Beschreibungen würde in diesem Medium nicht gehen.
In der digitalen Welt hat es sich eingebürgert, nur die Einleitungen von WP-Artikeln zu übernehmen und evtl. zu analysieren und neu zusammenzustellen, ähnlich wie bei Google, wo ein Kasten mit den wichtigsten Facts angeboten wird.
10-Punkte zu einem bestimmten Thema findet man im Netz zu Hauf, aber leider nicht gesammelt zu allen Lemmata des Allgemeinwissens (Relevanzkriterien wird man dafür auch aufstellen müssen). Vgl. auch: Wikipedia in einem Band. MfG --Regio (Fragen und Antworten) 14:06, 13. Mai 2020 (CEST)Beantworten
Für amerikanischen Slang nennt man so was Urban Dictionary. Im Wikipedia-Kontext zwei Gedanken dazu:
Akademisch interessant und womöglich sogar praktisch gewinnbringend könnte der Versuch sein, „die zehn wichtigsten Aussagen zu einem Stichwort“ automatisch aus Wikidata zu generieren.
Dann merkt man auch leichter, wo in Wikidata noch Daten fehlen oder falsch eingetragen sind.
Wikidata ist ohnehin als Faktensammlung gedacht, warum also nicht gleich noch eine Verbalisierung dieser Fakten dranhängen. Das wird ein bisschen Arbeit für die NLP-Fraktion (NLP = natural language processing, leider eine Weiterleitung auf „Computerlinguistik“, was ich für widersinnig halte), hätte aber sicher seinen Mehrwert.
Man muss dieselben Informationen nicht zigmal duplizieren (Wikipedia, Wikidata, Keywordswiki und wer weiß, was noch; multipliziert mit der Anzahl Sprachversionen).
Die Zielsetzung ist eine andere als bei Wikipedia. Hier will man möglichst umfassend über ein Thema (Lemma) informieren. Keywordswiki befriedigt hingegen den Wunsch der TLDR-Fraktion nach prägnanter Zusammenfassung, völlig ungeachtet der tatsächlichen Komplexität. (Manche Leute behaupten, dieser Wunsch in Kombination mit der Komplexität der realen Welt nähre Rechtspopulismus.)
Ob der Ansatz für die meisten Themen überhaupt sinnvoll ist, wird man erst mal feststellen müssen. Wenn wir es nicht mal in Lang hinkriegen, so was wie Seinsmächtigkeit zu erklären, wird das mit nur zehn Aussagen auch nicht besser gelingen.
Konflikte und Gezerre wird es immer geben, das ist kein Gegenargument. Die Frage ist halt, ob der Mehrwert die Konflikte rechtfertigt.
Für genau solche Zusammenfassungen sind Artikeleinleitungen da. Und wer's gerne noch prägnanter hätte, kann ja bei Wikidata nachschauen. -- Clemens14:58, 13. Mai 2020 (CEST)Beantworten
Genau dafür ist die Einleitung (ggf. samt Infobox) eines Artikels ja gedacht. Aber solange manche Autoren meinen, dass solch eine Einleitung reicht, bringt das nicht viel:
Max Moritz Mustermann (* 29. Februar 1904 hinter dem Mond, † 6. Januar 1955 ebenda) war ein Bildhauer der Moderne aus Taka-Tuka-Land.
Bisher hat es diverse Ansätze für Enzyklopädien gegeben, die andere Formen wie Wikipedia haben sollten - auch kompaktere. Nichts davon hat bisher an Wikipedias Erfolg annähernd kratzen können. Fast alles wurde aufgegeben. Lediglich Spezial-Wikis z.B. zu Science Fiction Serien mit zumeist wenigen Autoren konnten einige Erfolge verbuchen. Die beste Möglichkeit für das hier angefragte Vorhaben ist vermutlich eine Top down Gestaltung von Wikipedia Artikeln. Man beginnt zunächst in der Einleitung mit dem Vermitteln eines Anfangsverständnisses für den Artikelgegenstand in möglichst einfacher Sprache und geht dann von den wichtigsten zu den weniger wichtigen Merkmale über. Jeder kann dann so weit lesen, wie er möchte. Das ist vermutlich besser, als eine exakt vorgegebene Anzahl von Merkmalen und adaptiert besser an die unterschiedliche Komplexität der Artikelgegenstände und das unterschiedliche Leserinteresse. -- Tirkon (Diskussion) 03:07, 14. Mai 2020 (CEST)Beantworten
13. Mai
Unsichtbare Änderungen
Letzter Kommentar: vor 4 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Irgendwo haben wir eine Empfehlung, dass kleine Änderungen, z.B. am Quelltext, die keine sichtbaren Änderungen hervorrufen, besser unterbleiben sollten. Garde finde ich sie nicht – wer hilft mir auf die Sprünge? Muchas gracias, --Φ (Diskussion) 12:09, 13. Mai 2020 (CEST)Beantworten
Damit ist diese genau richtig für die deutschsprachige Wikipedia, und wir fokussieren uns darauf, hier eine saubere Zuordnung der GND zu pflegen. Damit ist die Gang voll ausgelastet.
Früher mal hatten wir noch die Schweden mit SELIBR, die sich als vollredundant herausgestellt hat, und die inzwischen bei uns rausgeflogen ist.
Dann halten wir international noch die VIAF, die aber aus seltsamen Algorithmen automatisch aggregiert wird und zuweilen Purzelbäume schlägt.
Die Japaner stehen eher nicht mehr im Fokus, war vielleicht mal 2007 interessant gewesen, ist mit Wikidata nicht mehr unser Kerngeschäft, in deren Katalogen rumzusuchen.
Ähnlich für LoC/LCCN; ist eigentlich von VIAF/Wikidata abgedeckt.
Alle zusätzlichen ID sind redundant; wir haben keine Kapazitäten, diese zusätzlich einzupflegen und sauber und konsistent zu halten. Schau halt nach Wikidata.
@Wurgl: Da bin ich überfragt. Ich weiß nur, dass sich die schweizerischen Bibliotheken an der GND beteiligen. Daher gibt es für uns keinen Handlungsbedarf. @Bahnmoeller: Die Normdaten der japanischen Parlamentsbiblithek stehen nur aus historischen Gründen in der Normdatenvorlage. Die Web NDL Authorities waren technisch gesehen Vorreiter. Heute würde wir naheliegender Weise eher SUDOC (Frankreich) und NUKAT (Polen) berücksichtigen. --Kolja21 (Diskussion) 21:18, 13. Mai 2020 (CEST)Beantworten
Mir ist jedenfalls aufgefallen, dass die Datensätze der Schweizer bei der VIAF immer (zumindest bei allen, die ich angeguckt habe) einen Link zur DNB enthalten. Und einmal hab ich der DNB einen Fehler per Mail gemeldet und als Antwort erhielt ich "vielen Dank für den Hinweis. Der Datensatz wurde von unseren Schweizer KollegInnen erstellt. …"
Und dann gibt es noch die Zusammenarbeit, wie hier beschrieben: https://www.dnb.de/DE/Professionell/Metadatendienste/Metadaten/Voclink/voclink_node.html Die entsprechenden Datensätze in https://data.dnb.de/opendata/macs.nt.gz enthalten keine speziellen Links auf irgendwas in der Schweiz, nur solche auf die DNB. Wäre jedenfalls ausgesprochen seltsam, wenn die Schweizer mit den anderen drei zusammenarbeiten, das unter einer freien Lizenz veröffentlichen aber dennoch keine Hinweise (Links oder Ids) auf ihre Datensätze liefern, die anderen aber sehr wohl.
Hallo,
wir verwenden Media Wiki und wollte fragen wie man in der linken Sidebar den Link für die "zuletzt besuchte Seiten" einfügen kann? Dort wo sonst Hauptseite, Thmenprotale steht. Soll nun eine neue Überschrift hin, wo sich immer die letzten 5 Seiten die man besucht hat wieder finden.
Letzter Kommentar: vor 4 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo Wiki-Team, einige Regelseiten kenne ich bereits, so zum Beispiel WP:NS, weil man da über "Wie schreibe ich gute Artikel" deutlich drauf hingeweisen wird als wichtige Vorgabe. Heute stolpere ich über den obigen Artikel zu der Modefirma und bin entsetzt: Der Artikel liest sich wie eine Verlängerung der Firmenwebsite! Er ist voll von Lobpreisungen, Übertreibungen, individuellen Wertungen und Superlativen. Das alles hat in einer Enzyklopädie nichts zu suchen. Nicht alle angegebenen Quellen sind seriös (Blogs?) und prüft man genauer, steht teilweise nicht in den Quellen das, was mit der Angabe belegt werden soll. Zudem sieht man, dass zum Beispiel die Vogue und andere an dem Artikel mitschreiben, hier gibt es also zusätlich möglicherweise auch Interessenskonflikte. Wo meldet man so einen Artikel oder wer neutralisiert den? Gibt es da eine Stelle? Wenn ja, würde ich mich freuen, wenn man die auf diesen Artikel aufmerksam machen könnte. Ich bin keine Modefachfrau und habe keine vertiefte Kenntnisse, die ich einbringen könnte. Darum dies nur als Hinweis. Vielen Dank. --2003:E3:D70E:8200:A4D4:EAAD:A0E3:CFB819:53, 13. Mai 2020 (CEST)Beantworten
Hallo IP,
erste Anlaufstelle ist die Diskussionsseite des Artikels, die Du zehn Minuten vor Deiner Meldung hier ja gefunden hast. Wenn sich dort über Wochen nichts tut, kann es angebracht sein, zum Beispiel hier vorstellig zu werden.
Der Hauptautor des Artikels hat sich in seiner aktiven Zeit zu einem guten Teil mit Modethemen befasst. Ob er zum Thema die nötige Distanz hatte, lässt sich nicht ermitteln, einen Interessenskonflikt kann man da aber nicht herauslesen. Die Einleitung des Artikels geizt nicht mit positiven Attributionen, aber die Einleitung soll nur den folgenden Artikeltext zusammenfassen (und deshalb übrigens keine Belege enthalten), so dass die Darstellung möglicherweise gerechtfertigt ist. Der folgende Text stellt die Geschichte der Firma bei sehr oberflächlicher Betrachtung sehr positiv dar und belegt das teilweise, während die Gegenwart eher neutral und knapp beschrieben wird. Ich habe mich mangels Zeit da jetzt nicht eingelesen, aber kann es eventuell sein, dass die Firma früher mal wichtig war und jetzt halt von ihrem ehemaligen Ruhm zehrt?
Letzter Kommentar: vor 4 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
WP:Übersetzen ist scheinbar wieder von Hochakademikern geschrieben, jedenfalls blicke ich nicht durch. Wenn ich mit Chrome browse, wird mir bei anderssprachigen Artikeln das Übersetzungstool angeboten. Das Ding angeklickt, so unmanierlich liest sich das gar nicht. Natürlich hab ich den Anspruch, das Ding sprachlich auf korrekt zu trimmen, und da ich auch nur Artikel aus meinem Fachbereich schreiben würde, auch die Zusammenhänge korrekt wiedergeben. Dazu mir zugängliche Belege. Reicht das? Ist es dann durch die sprachliche Anpassung mein eigenes Werk?--scif (Diskussion) 02:30, 14. Mai 2020 (CEST)Beantworten
Durch Übersetzen allein wird es nicht dein Werk. Dafür müsstest du es schon komplett umformulieren und am besten auch inhaltlich etwas umstrukturieren/ergänzen, so dass es nicht vollständig der Vorlage folgt. So wie man es sonst auch macht, wenn man mit geschützten Quellen arbeitet. Ansonsten einfach die Versionsgeschichte importieren lassen oder eine der Alternativen, die im Link genannt sind.--Berita (Diskussion) 13:44, 14. Mai 2020 (CEST)Beantworten
Also wenn du dir mal so eine übersetzte Version durchgelesen hast, wirst du mir zustimmen, dass es ohne Umformulierung nicht geht.Wo wäre konkret das Problem, so eine Übersetzungsversion im BNR auf ordentlich zu trimmen und dann in den ANR zu stellen?scif (Diskussion) 20:14, 14. Mai 2020 (CEST)Beantworten
Aber warum sollte es dein eigenes Werk sein? Du hast dann etwas eleganter formuliert, die Hauptarbeit (und auch die Entscheidung welche Quellen, welche Inhalte, welche nicht) hatte jemand anderes. Die 50 Vorgängerversionen können doch in der Versionsgeschichte genannt werden, du bist der 51. --195.200.70.4317:30, 15. Mai 2020 (CEST)Beantworten
Warum entsteht kein automatisches Inhaltsverzeichnis?
Letzter Kommentar: vor 4 Jahren9 Kommentare5 Personen sind an der Diskussion beteiligt
Auf der Seite Benutzer Diskussion:Sciurus/WWKW sind mehrere Abschnitte mit unterstrichener Überschrift. Trotzdem entsteht dort kein! automatisches Inhaltsverzeichnis.
Ah ja danke, das Kürzel hatte ich, viertel vor eins, nicht mehr entschlüsselt, wohl überlesen und auch mein Mauszeiger hat sich nicht dahin verirrt oder ist dort gelandet. Vielleicht geht das einigen Mitlesenden ja ebenso, dann wäre mein Hinweis nicht ganz sinnlos gewesen? --Diwas (Diskussion) 22:04, 15. Mai 2020 (CEST)Beantworten
15. Mai
Südkorea Informationen Korrekturanfrage
Letzter Kommentar: vor 4 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo.
Ich schaue auf die Seite und bitte um Korrektur, weil etwas nicht stimmt.
Das ist für Südkorea.
Auf der Seite gibt es eine Karte von Korea. Aber die stimmt nicht.
Wir haben kein Japanisches Meer, sondern Ostmeer.
Wenn man "Japanisches Meer" benutzt, dann es als Resultat des Expansionismus und der Kolonialherrschaft Japans zeigen kann.
Das ist falsches Information, deshalb verlange ich stark, Korrektur zu werden.
Ich hoffe, dass die falsche Informationen von Korea nicht mehr beweiter werden.
Mindestens benutzen Sie bitte andere Karte auf der Seite, die sudkorea vorstellt. (nicht signierter Beitrag von221.139.99.166 (Diskussion) 04:51, 15. Mai 2020 (CEST))Beantworten
Das stimmt schon! Das Japanische Meer wird in Südkorea als Ostmeer und in Nordkorea als Koreanisches Ostmeer bezeichnet. Wir leben in D-A-CH und haben den verbreitetsten Namen 日本海 übernommen, da JapanJapan die längste Küste zu diesem Meer im Westen hat. Auch für die Russen mit der längsten Ostküste ist es Япо́нское мо́ре (Japonskoje More ), für die Chinesen 日本海 (Rìběn hǎi = Japanisches Meer)
So viel Argumentiererei wäre gar nicht nötig gewesen, Meere können halt in verschiedenen Sprachen unterschiedliche Bezeichnungen haben, und im Deutschen heißt das fragliche Meer halt Japanisches Meer. In Korea hat man die Bezeichnung meines Wissens übrigens auch erst vor einigen Jahren geändert, aus ideologischen Gründen (siehe oben). --77.0.160.20509:54, 15. Mai 2020 (CEST)Beantworten
Neue Ansicht
Letzter Kommentar: vor 4 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
Wurde mal wieder an der Ansicht gepusselt? Wenn ich nun schreibe werden mir Verlinkungen, usw. bunt, oder mit Hinterlegungen dargestellt. Das ist sehr gewöhnungsbedürftig. Könnte solches nicht mal vorher angekündigt werden? --Itti07:32, 15. Mai 2020 (CEST)Beantworten
Das wusste ich auch nicht. Ich fragte auch nicht, ich dachte mir nur, dass sie uns jetzt auch noch den Quelltexteditor Schritt-für-Schritt wegnehmen. Danke für die Info. Eingeschaltet hatte ich diesen Stift definitiv nicht. --Hexakopter (Diskussion) 12:05, 15. Mai 2020 (CEST)Beantworten
Dieser Abschnitt kann archiviert werden. Itti 08:29, 15. Mai 2020 (CEST)
Download-Links entfernen?
Letzter Kommentar: vor 4 Jahren8 Kommentare3 Personen sind an der Diskussion beteiligt
Hallo zusammen,
ich habe soeben mit diesem Edit einen Link entfernt, welcher beim Anklicken direkt eine Software downloadet. Ich nehme an, solche Links sind nicht gewünscht. Gibt es die Möglichkeit diese systematisch zu finden und zu entfernen? Gleichzeit sah ich, dass mittels "insource:/"ftp:"/" einige Links auftauchen, die auf einen ftp verweisen. Ist dies gewünscht? LG -Phzh (Diskussion) 12:23, 15. Mai 2020 (CEST)Beantworten
Da wird keine Software direkt gedownloadet, der Link zeigt auf ein Verzeichnis und keine Datei. Leider wird FTP mittlerweile aber von den meisten Browsern nicht mehr unterstützt. In dem konkreten Beispiel ist der Server aber auch über http erreichbar, sodass man den Link einfach ändern kann. --Wickie3712:57, 15. Mai 2020 (CEST)Beantworten
Ich muss mich korrigieren, das war doch ein Datei-Link, aber nicht auf ein Programm sondern auf eine html-Datei. Und Firefox hat wohl doch noch einen rudimentären FTP-Support drin, aber nicht mehr lange: [1]. --Wickie3713:19, 15. Mai 2020 (CEST)Beantworten
Von den FTP-Links die ich jetzt stichprobenartig aus der "insource:/"ftp:"/"-Suche ausprobiert habe, hat übrigens kein einziger funktioniert. Kann es sein, dass die Bots, die nach nicht mehr erreichbaren Links suchen, FTP-Links ignorieren? --Wickie3713:23, 15. Mai 2020 (CEST)Beantworten
WP:BOTA. Es dürfte nicht allzu schwer sein, einen Bot zu schreiben, der systematisch Links anfragt und immer dann eine Meldung auf die Diskussionsseite eines Artikels pappt, wenn er einen findet, dessen HTTP-Antwort einen Content-Disposition-Header enthält – oder noch rigoroser: dessen HTTP-Antwort im Content-Type-Header nicht text/html, application/pdf oder application/x-pdf deklariert. Daten anderen Typs sind aller Wahrscheinlichkeit ohnehin nicht wertvoll für Wikipedia. Vermutlich könnte man so eine Funktionalität relativ einfach in den Bot einbauen, der ohnehin Weblinks auf Erreichbarkeit prüft. --77.0.160.20513:48, 15. Mai 2020 (CEST)Beantworten
Äh, richtig, aber die FTP-Links erkennt man auch am ftp://. Ich war schon einen Schritt weiter und dachte an http/https-URLs, die unmittelbar einen Download einleiten. So was gibt’s ja auch. --77.0.160.20516:52, 15. Mai 2020 (CEST)Beantworten
Denkmale und Denkmäler
Letzter Kommentar: vor 4 Jahren9 Kommentare7 Personen sind an der Diskussion beteiligt
Komisch finde ich es, dass in der Wikipedia unheitlich mal von Denkmälern, dann von Denkmalen die Rede ist. Also etwa Baudenkmale/Baudenkmäler, Bodendenkmale/Bodendenkmäler, Naturdenkmale/Naturdenkmäler. Kann man sich da nicht auf 1 Linie einigen, etwa Denkmale? -- Willi13:39, 15. Mai 2020 (CEST)Beantworten
Die Österreicher machen es besser: "Liste der denkmalgeschützten Objekte in...". Dann kriegt man auch den nächsten Konflikpunkt: Kulturdenkm.. oder Baudenkm.. gleich mit gelöst. --Global Fish (Diskussion) 13:48, 15. Mai 2020 (CEST)Beantworten
Denkmale und Denkmäler sind auch zwei unterschiedliche Sachen. Zumindest habe ich es auch mal so gelernt, wie verbreitetet das allerdings ist, weiß ich nicht. Aber bspw. hier wird es auch erwähnt: „Der Unterschied liegt darin, dass die Denkmalwelt einen sehr feinen Unterschied macht zwischen dem Plural Denkmale und Denkmäler. Den Plural Denkmäler verwenden wir für gesetzte Denkmäler, und den Plural Denkmale für all die Orte, die wir heute als authentisches Zeugnis und Quelle gern für die Zukunft erhalten möchten und die wir als Denkmale ausweisen.“ Wurde dieser Unterschied im Meinungsbild eigentlich gewürdigt? --Yeerge (Diskussion) 23:55, 15. Mai 2020 (CEST)Beantworten
Ich glaube nicht. Ich meine wir orientieren uns in der Verwendung zumindest für die Listen etc. am Sprachgebrauch des jeweiligen Denkmalschutzgesetzes.--Olaf2 (Diskussion) 08:48, 16. Mai 2020 (CEST)Beantworten
Erstens das, und zweitens denke ich nicht, dass dieser Unterschied (der in der von Yeerge genannten Quelle behauptet wird) wirklich bestehen würde. Das Wort hat einfach zwei Pluräler ;-), und der Streit, welche Form die richtige ist, lief auch schon vor über 200 Jahren. [2]--Global Fish (Diskussion) 08:50, 16. Mai 2020 (CEST)Beantworten
Denkmale?
Denkmäler?
Beides?
Ich habe das mal nach Bundesland und der im dortigen Denkmalschutzgesetz verwendeten Pluralform aufgelistet und ein paar illustrierende Bilder angeheftet:
Übersicht nach deutschen BundesländernAls diese Diskussion schonmal hochkam, hatte ich eine Übersichtskarte erstellt, welches Bundesland welchen Plural verwendet (Denkmale = dunkel, Denkmäler = hell). --Jumbo1435 (Diskussion) 11:24, 16. Mai 2020 (CEST)Beantworten
Link auf ausländische Wikipedia
Letzter Kommentar: vor 4 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Ich möchte den Begriff "False Memory" auf die Wikipedia-Seite https://en.wikipedia.org/wiki/False_memory verlinken, bin aber bisher trotz aller Erläuterungen damit gescheitert. Wie geht das?
"Bearbeitungskonflikt" auf neuerstellter Diskussionseite
Letzter Kommentar: vor 4 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Diskussion:StEG I 600–711 habe ich vorhin erstellt. Beim Speichern des Beitrags erschien plötzlich ein Bearbeitungskonflikt mit mir selbst, meine Änderung war bereits gespeichert und es erschien eine Version, die angeblich im BK zu dieser zwischenzeitigen Änderung stand, mit einer Doppelung des Diskussionabschnitts, der obere mit bereits ausgefüllter Signatur, der unter mit den vier Tilden (--~~~~) Weiß jemand etwas darüber, gibt es ähnliche Erfahrungen? Ich habe Screenshots erstellt, bei Bedarf könnte ich die hochladen oder versenden. Gruß,
--Universal-InteressierterDisk.Arbeit00:56, 16. Mai 2020 (CEST)Beantworten
Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Hi, gibt es einen Mechanismus (Vorlage ...?) der aus den beiden Informationen a) deutscher Artikelname und b) gewünschter Sprachcode den Artikelname oder den Verweis auf den entsprechenden Artikel einer anderen Sprachversion liefert?
z.B. Input: "Deutschland" und "en" ergibt "Germany" bzw. en:Germany
die Interwikiverlinkung links im Menü ist mir bekannt - diese Links als gezielte Abfrage als zwischen-Arbeitsschritt auf einer Benutzerseite z.b. ist gefragt
Gruß und Danke --Mrmw (Diskussion) 08:40, 16. Mai 2020 (CEST)Beantworten
Neuer Artikel "Nicht gesichtet"
Letzter Kommentar: vor 4 Jahren12 Kommentare6 Personen sind an der Diskussion beteiligt
Aber seit wann ist das so? Meine direkt angelegten neuen Artikel sind automatisch gesichtet. Es muss also an der Verschiebung aus dem BNR liegen, aber diese "Hürde" ist mir neu. --KnightMove (Diskussion) 10:59, 16. Mai 2020 (CEST)Beantworten
Ist schon seit einer Weile so, dass ab und zu verschobene Artikel von anderen gesichtet werden müssen, seit wann, hmmm irgendwann Mitte 2019 nach einem Softwareupdate, meine ich. --Liebe Grüße, LómelindeDiskussion11:11, 16. Mai 2020 (CEST)Beantworten
(BK) Jepp, es liegt an der Verschiebung aus dem BNR. Bzw. daran, dass es gesichtetete Versionen dort nicht gibt. Daher sind auch alle in den ANR verschobenen Versionen erst einmal ungesichtet. Allerdings sichte ich „meine“ Artikel nach dem Verschieben regelmäßig selbst, es ist mir neu, dass man das nicht kann. --Björn11:15, 16. Mai 2020 (CEST)Beantworten
Ach ja, richtig... *g* Meine mich aber zu erinnern, dass das vorher auch schon so war. Meine Vermutung geht eher in Richtung eines fehlenden Buttons. --Björn11:21, 16. Mai 2020 (CEST)Beantworten
Könnte (!) etwas mit dem folgenden Uralt-Schnipsel in meiner common.css zu tun haben:
Früher, also vor dem ominösen Update, konnte ein Benutzer, der bereits Sichterrechte besaß jederzeit einen Artikelentwurf im BNR anlegen und in den ANR verschieben, ohne dass eine nachträgliche Sichtung erforderlich war. Anders bei Benutzern ohne dieses Recht. Siehe auch Archiv 2019. Ich weiß nur, dass auch ich seither Artikel nachsichte, dieein langjähriger Mitstreiter aus seinem BNR verschiebt. Das war definitiv früher nicht notwendig. Ich selbst lege daher auch keine Entwürfe mehr im BNR an. Es muss sogar schon Ende 2018 gewesen sein. siehe hier Januar 2019. Und ohne Nachsichtung 15. Dezember 2018 und hier Sichten bei Verschiebung BNR -> ANR. Wie die Zeit vergeht. --Liebe Grüße, LómelindeDiskussion11:57, 16. Mai 2020 (CEST)Beantworten
Man kann seine eigenen verschobenen Artikel im gleichen Arbeitsschritt sichten, in dem man auch die Kategorien wieder "scharf" schaltet. Und deshalb eine ungare Stichwortsammlung direkt nicht im BNR anzufangen ist nicht sinnvoll. --Bahnmoeller (Diskussion) 12:46, 16. Mai 2020 (CEST)Beantworten
Unbestritten. Dem Fragesteller fehlt indes offenbar die Möglichkeit zur Erstsichtung verschobener Artikel, wenn ich das richtig verstanden habe. Warum ist das so und wie kann man dem abhelfen? --Björn12:49, 16. Mai 2020 (CEST)Beantworten
Letzter Kommentar: vor 4 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Ich wollte diesen Artikel mal einem zuständigen Portal vorstellen, kann aber keins finden, das für Textilien o.ä. zuständig ist. Gibt es sowas?
Mal abgesehen davon, dass der Artikel lediglich mit zwei toten Links "belegt" ist, die laut archivierter Fassung früher mal Webshops waren, setzt der eine dieser Links Dupionseide auch noch mit Wildseide gleich. Wäre schön, wenn kompetente Leute das mal auf eventuelle Redundanz überprüfen würden. Hinzu kommt, dass der Artikel stellenweise Ratgebercharakter hat. --87.150.3.1910:45, 16. Mai 2020 (CEST)Beantworten
Letzter Kommentar: vor 4 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo. Es gibt einen Artikel, der faktisch als Werbeplattform erstellt wurde, der jedoch sehr gut in Wikivoyage passt und den die für diesen kleinen Missbrauch verantwortliche Benutzerin (Sie hat sich auf meinen Vorschlag in WV auch angemeldet) dann dort weiter betreuen würde. Kann den Transfer jemand vornehmen? Die Vorbereitung würde ich machen, es ginge nur um den technischen Prozess. Gerne nähere Informationen dazu.--Schuhmacher (Diskussion) 11:57, 16. Mai 2020 (CEST)Beantworten
21:34, 12. Mai 2020 (CEST)
Japan die längste Küste zu diesem Meer im Westen hat. Auch für die Russen mit der längsten Ostküste ist es Япо́нское мо́ре (Japonskoje More ), für die Chinesen 日本海 (Rìběn hǎi = Japanisches Meer)
