Wikidata:Forum/Archiv/2019/08

From Wikidata
Jump to navigation Jump to search
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Nachtragung von topic's main category (P910)?

Als ich vor einiger Zeit durch Verknüpfung einer deutschen und einer niederländischen Gemeinde-Themenkategorie ein Datenobjekt erzeugt, darin category's main topic (P301) gesetzt hatte und nun zum Thema der Kategorie wechselte, war mir jemand mit dem Setzen von topic's main category (P910) und dem Verschieben der Commons-Kategorie aufs Kategorie-Objekt zuvorgekommen. In der Hoffnung, dass so etwas regelmäßig passiert, habe ich jetzt bei allen Französische-Gemeinde-Themenkategorien aus der letzten Flut von User:GZWDers Bot User:GZWDer (flood) category's main topic (P301) gesetzt, ohne auf der anderen Seite topic's main category (P910) zu setzen und die Commons-Kategorie zu verschieben (und auch bei allen international verwaisten Kategorien aus de:Kategorie:Pennsylvania nach Ort, de:Kategorie:Kalifornien nach Ort, de:Kategorie:Illinois nach Ort, und de:Kategorie:Michigan nach Ort). Frage: Wird das regelmäßig nachgetragen oder muss man das doch von Hand machen? -- Olaf Studt (talk) 11:50, 28 July 2019 (UTC)

@M2k~dewiki: Wenn ich mir Wikidata:Database reports/Constraint violations/P301 so ankuck’, sollte man das wohl von Hand machen, wenn man an einer zeitnahen Erledigung interessiert ist, oder? -- Olaf Studt (talk) 11:35, 31 July 2019 (UTC)
Hallo @Olaf Studt: zu Wikidata:Database reports/Constraint violations/P301: das Abarbeiten von Inkonsistenzen ist grundsätzlich immer begrüßenswert, vielen Dank dafür! Wobei "zeitnah" hier ein relativer Begriff ist, in der Liste finden sich etliche Objekte die vor über drei Jahren gelöscht wurden, die Referenz darauf ist bzw. war bis jetzt in anderen Objekten aber noch immer enthalten. Die kleineren Abschnitte aus der Liste (z.B. "Type Wikimedia-Kategorie (Q4167836)" violations mit 25 Einträge) wird man wohl manuell erledigen können, bei den längeren Listen Inverse violations (Violations count: 28764) wird es ein Tool oder Script brauchen. Siehe diesbezüglich auch Wikidata:Project_chat#Wikidata:Database_reports/Constraint_violations/P301_-_inverse_violations_and_references_to_deleted_objects. --M2k~dewiki (talk) 15:00, 31 July 2019 (UTC)
So ein Tool oder Script zu basteln, ist aber keine Aufgabe für einen Anfänger wie mich! Nachdem ich bei den restlichen US-Staaten P301 und P910 gesetzt und die Common-Kategorie verschoben habe (wobei ich erwartungsgemäß auf ein paar Fälle gestoßen bin, wo der Ort schon in anderen als der englischen WP eine Kategorie hatte), bin ich bei den Franzosen mit dem Nachtragen jetzt mit A bis F fertig (wobei A bis E stinklangweilig waren). -- Olaf Studt (talk) 14:41, 4 August 2019 (UTC)

Abfrage

Ich habe keine Ahnung von den Abfragen. Gibt es ein Objekt mit P5965 und dem Wert 81150450029 für ein Naturdenkmal "Eiche am Schafweideweg" in Sindelfingen. Es gibt zu einigen anderen bereits ein Objekt z. B. Q58020250, ein Baum, der nur ein paar Meter weiter steht. Inzwischen gibt es eine Commons-Category:Eiche am Schafweideweg. Muss ich ein neues Objekt anlegen, oder gibt es bereits eins? --Giftzwerg 88 (talk) 19:13, 3 August 2019 (UTC)

Um zu schauen, ob es Items mit einem bestimmten Wert bei einer Eigenschaft gibt, kann man auch die normale Suchfunktion nutzen: Special:Search/haswbstatement:P5965=81150450029. Ist oft einfacher und schneller als eine Abfrage zu basteln. In diesem Fall findet sich jedenfalls kein Item mit diesem Wert. --Kam Solusar (talk) 19:44, 3 August 2019 (UTC)

Fehlerhafte Bezeichnung und Verwendung von connecting line (P81) im Deutschen

P81 bezeichnet als Eigenschaft eine Linie des öffentlichen Verkehrs und wird z.B. dazu verwendet zu beschreiben, welche Linien an einem Bahnhof oder Bushof halten, oder was benachbarte Stationen in Bezug auf einzelne Linien sind (adjacent station (P197)).Diese Art der Verwendung geht eindeutig aus den jeweiligen Beschreibung hervor und lässt sich auch in der internationalen Verwendung erkennen. Im deutschen heißt die Eigenschaft fälschlicherweise "Strecke" und wird oft für Eisenbahnstrecken verwendet an denen ein Bahnhof liegt. Beides scheint mir jedoch eindeutig falsch zu sein. Die Verwendung müsste entweder vereinheitlicht oder die Eigenschaft aufgespalten werden--Trockennasenaffe (talk) 19:34, 6 August 2019 (UTC)

Nachtrag: Ganz so eindeutig scheint das doch nicht zu sein, auch die englischsprachigen Beschreibungen widersprechen sich da teilweise und es wird mal so oder mal so verwendet. Teilweise für die physikalische Strecke aber auch für eine Linie, teilweise sogar unterschiedlich in den verlinkten Beispielen. Auf jeden Fall sollte man da Eindeutigkeit schaffen.--Trockennasenaffe (talk) 19:39, 6 August 2019 (UTC)

Question about dewiki template editing

Just wondering, what's the process to edit templates on dewiki? I get the impression that users are not allowed to edit them in dewiki so they end up complaining in Wikidata (on dozens of talk pages with words probably leading to blocks in other wikis) or doing thousands of manual edits on dewiki. (I'm posting this here as it's mainly about dewiki, sorry about the question in English). --- Jura 21:58, 7 August 2019 (UTC)

Well, it’s dewiki. Technically, you can "just edit" templates in most cases. However, there are lots of rules and conventions, formal and informal ones, which can make this a rather unpleasant task as other users expect you to be aware of those rules; as usual in dewiki, the tone is quickly pretty aggressive once you fail to comply with project standards—similarly as when dewiki users come to Wikidata to complain about something they do not like :-/
More in general, there are lots of users in the dewiki core community who are rather conservative about template use, particularly when it comes to use of infoboxes and navi templates. "It complicates wikitext editing" and "content should be text, not tables/infoboxes/navis" are two important positions there. This is also the reason why there is barely any infobox usage in articles about persons except for sportspersons, but even the latter are far from systematically being equipped with infoboxes. The fact that most forms of automated editing are also seen rather critical makes people waste a lot of time with tedious manual editing. —MisterSynergy (talk) 09:19, 8 August 2019 (UTC)
I see. In the case at hand, the template already exists (Template:Disambiguation (Q6148868)) and is present on pages. It has only rarely been edited over the last ten years. What shall we suggest to dewiki users who don't want to go through all that? Doing 10,000s of edits on Wikidata merely because one can't do a single edit on a dewiki-template doesn't appear to be valid option. --- Jura 14:16, 8 August 2019 (UTC)
Well, de:Template:Begriffsklärung is kind of a special case. It is in use on ~274.000 mainspace pages and thus fully protected. Yet it woud be possible to make suggestions for improvements on the template talk page.
Do we talk about interwikilinks from family name items here? --MisterSynergy (talk) 15:05, 8 August 2019 (UTC)
That seems to be the thing people would like to see on dewiki.
Adding {{#invoke:Interwiki from P460|InterwikiP1889fn}} there should do (after copying Module:Interwiki from P460 to dewiki). (correction: it's 2 edits, not 1). --- Jura 15:26, 8 August 2019 (UTC)
I am pretty sure that there will not be a consensus for such an approach if it cannot be suppressed on a per-page basis. A viable approach would be if there was en:Template:Interwiki extra imported to dewiki, and this template was added by bot to dab pages where extra interwiki could be displayed. There was a bot request recently at de:Wikipedia:Bots/Anfragen#Fehlende Interwikis bei Namens-BKS, but one editor questioned whether those interwiki should really be there, and now there needs to be more discussion.
From my experience this means that the dewiki community will not be able to change anything on their side, no matter how much needed this change is. —MisterSynergy (talk) 17:06, 8 August 2019 (UTC)
Thanks. It should be possible to include a parameter to de-activate it. BTW, the script doesn't add any interwiki if one is already present. It's working on frwiki and Commons. At least now we have thread to send people to .. will do so on Talk:Q27924673. --- Jura 17:11, 8 August 2019 (UTC)

Cound somebody explain, what is the core of this problem? Some templates in dewiki can be edited by everyone and other are fully protected for a good reason. I really see the problem that some wikis have an article like "Michel Sisters" where other just have a disambigiation containing "Bety Michel" and "Lilly Michel", which have separate articles. The first wikis may or may not have a redirect page from the individual names to the group. Some wikis split disambiguation pages into names of persons and names of geografic features, others list both on the same page in separeted pararaphs. And at least in the german wikipedia we have cascading disambiguation pages which include "John Smith" into "Smith". It is not easy to establish for both a one to one connection with other wikis. Would like to talk about these problems in Stockholm. --Bahnmoeller (talk) 05:55, 9 August 2019 (UTC)

Q15853748 und Q56541313

Die Items beschreiben haargenau das gleiche, eine Liste mit Menschen, die den Nachnamen Wathelet tragen. Aus unerfindlichen Gründen wurde hier mit Property:P1889 festgelegt, dass diese beiden Items nicht zusammengeführt werden können, was die einzig sinnvolle Lösung wäre. Ich habe versucht, das destruktive P1889 aus einem der Namensartikeln zu entfernen, es ging nicht, es gab einen roten Kasten mit einer Fehlermeldung. Wie können diese Items zusammengeführt werden? Grüße vom Sänger ♫ (talk) 07:01, 26 July 2019 (UTC)

Nein, die gehören nicht zusammengeführt. Wenn Du Interwikis übernehmen möchtest, müsstest Du das entweder komplett händisch nach der alten Methode machen, oder en:Template:Interwiki extra nach dewiki importieren und dort im Artikel zur Anwendung bringen. --MisterSynergy (talk) 07:47, 26 July 2019 (UTC)
Mir wurde erklärt, dass Interwikilinks über WD laufen. Hier gehören diese Artikel im Wikiversum unbedingt verinterwikilinkt, da kann kein Zweifel dran bestehen. Wie kann das bewerkstelligt werden? Bzw. wann und warum hat sich WD von den Interwikilinks verabschiedet? Grüße vom Sänger ♫ (talk) 07:52, 26 July 2019 (UTC)
Mit solchen "unbedingten" Wahrheiten, an denen "kein Zweifel dran bestehen" kann, ist das bekanntlich so eine Sache. Meist ist dann doch das Gegenteil der Fall, wie hier auch. Die meisten Interwikilinks werden über Wikidata gemacht, aber eben nicht alle. In Ausnahmesituationen wie hier eine vorliegt, muss man das weiter händisch machen. Die Möglichkeiten habe ich genannt... --MisterSynergy (talk) 07:58, 26 July 2019 (UTC)
@MisterSynergy: auch der englische Artikel ist eine reine BKS. Es werden genau wie bei den anderen Artikeln lediglich Personen mit diesem Namen aufgelistet, ohne Hintergrund-Infos zum Namen. Und der französische hat sogar genauso einen spezialisierten BKS-Hinweis für Familiennamen. Daher gehören diese Wikipedia-Artikel, die alle den gleichen Inhalt haben, selbstverständlich auch mit dem gleichen Wikidata-Objekt verlinkt. --Wickie37 (talk) 11:53, 26 July 2019 (UTC)
Die Artikel sollten interwikiverlinkt sein, soweit ist das richtig. Aber das sollte eben nicht über Wikidata gemacht werden. Es ist projektweiter Konsens, dass Wikipedia-Artikel mit BKS-Flag und solche ohne BKS-Flag in separaten Objekten eingehängt werden. Der enwiki-Artikel hat kein solches Flag, die anderen drei im andern Objekt haben das Flag. Auch könnte jemand im enwiki-Artikel etwas über den Namen schreiben, was auf einer reinen BKS eher nicht erlaubt wäre, denn es ist ein reiner Linkhub.
Es gibt übrigens ein Userskript User:Matěj Suchánek/checkSitelinks.js, welches in Special:MyPage/common.js eingebunden werden kann, und dann BKS-Sitelinks beim Laden eines Objektes mit einem Icon kennzeichnet. --MisterSynergy (talk) 12:26, 26 July 2019 (UTC)
Das ist doch Sophisterei gegen die LeserInnen. Um der reinen Le(e/h)re willen, darf nicht zusammengehören, was zusammengehört. Merkbefreite Regelhuberei, damit ja nicht pragmatisch und richtig, sondern korintenkackerisch und absurd gehandelt wird. Macht nur weiter so und scheißt auf die Nutzer, dann wird Euch bald niemand mehr ernst nehmen. Die Artikel gehören absolut eindeutig zusammen, egal ob sich ein Schwesterprojekt für oder gegen diesen komischen Flag entschieden hat. Es gibt imho keine gutartige Begründung für diesen absurden Bürokratismus um des Bürokratismus willen. Aktuell ist es halt wegen der Idiotie hier zusammengestümpert, eigentlich sollte es eine korrekte Lösung direkt hier geben.Grüße vom Sänger ♫ (talk) 13:57, 26 July 2019 (UTC)
Alle Artikel sind BKS und beschäftigen sich mit einem Nachnamen. Daher müssten sie nach der "reinen Lehre" doch eher mit beiden Wikidata-Objekten verknüpft werden. Wenn das nicht möglich ist, muss man sich eben für eines entscheiden, aber hier völlig willkürlich aufzuteilen geht gar nicht.
Meine bevorzugte Variante wäre, alle BKS, in denen ausschließlich ein Nachnamen bzw. Personen mit diesem Namen behndelt werden, mit dem Namensobjekt zu verknüpfen, denn da wo es noch andere Bedeutungen eines Wortes gibt, gibt es in der Regel eh separate Artikel, sodass der Konflikt da gar nicht auftritt. --Wickie37 (talk) 15:38, 26 July 2019 (UTC)
"könnte jemand im enwiki-Artikel etwas über den Namen schreiben" ja könnte, hat aber keiner, und könnte auch jemand bei der deutschen Seite machen. --Wickie37 (talk) 15:41, 26 July 2019 (UTC)
Der enwiki-Artikel ist keine BKS, er sieht bloß aus wie solche aus.
Es gibt hinreichend viele Fälle, in denen eine solche Vereinfachung schiefgeht, und mit volatilen Einzelfall-Entscheidungen basierend auf einem Zustand zu einem beliebigen Zeitpunkt kriegen wir diese Interwikilinks nicht organisiert. Der Projektkonsens wie oben angedeutet (separate Objekte für unterschiedliche Konzepte) ist dahingehend deshalb auch eindeutig, und aus meiner Sicht ist das konsequent. Wikidata ist eben kein bloßer Interwiki-Dienst für Wikipedias, auch wenn einige das so gern hätten.
Ich habe jedenfalls Alternativlösungen angeboten, die das für Euch rein praktisch zum gewünschten Ergebnis bringen würden. Es liegt an Euch, diese nun umzusetzen. --MisterSynergy (talk) 16:31, 26 July 2019 (UTC)
Alle Seiten enthalten die gleiche Information, also müssen entweder alle Seiten BKS sein oder keine. So wie ich das verstehe, ist das Problem wohl, dass die unterschiedlichen Sprachprojekte unterschiedliche Definitionen dafür haben, was eine BKS ist. Wenn das so ist, ist die bisherige Situation aber nun wirklich die schlechteste Lösung. Eine gemeinsame Datensammlung wie Wikidata, kann nicht funktionieren, wenn jeder unterschiedliche Definitionen verwendet. Eine Zusammenführung von Daten, die auf Basis unterschiedlicher Definitionen kategorisiert werden, ist zu nichts zu gebrauchen. --Wickie37 (talk) 18:39, 26 July 2019 (UTC)
Das die beiden Wikidata-Objekte getrennt gehören, da bin ich voll deiner Meinung. Nur gehören die Wikipedia-Verknüpfungen nicht getrennt, weil die alle den gleichen Aufbau haben, nur in unterschiedlichen Sprachen. --Wickie37 (talk) 18:42, 26 July 2019 (UTC)
Übrigens ist der Zustand jetzt auch volatil: Sollte jemand auf die Idee kommen, dass es im englischen auch noch eine andere Bedeutung gibt, und die in den Artikel eintragen würde der ja damit zur {{Disambiguation|surname}} und die sind hier als BKS kategorisiert. --Wickie37 (talk) 18:48, 26 July 2019 (UTC)
  • It's a fairly trivial change to link all surname pages on enwiki to disambiguation pages in other wikis. Similarly, all disambiguation pages on dewiki could be made to link to surname pages in other wikis if no sitelink is present. This is something that can be change on enwiki/dewiki respectively. Either it hasn't been tried or there is no consensus on enwiki/dewiki to do so. In both cases, I don't think it would be appropriate for Wikidata to make this editorial choice on their behalf. We keep getting complaints about enwiki/dewiki here, but I don't quite see people trying to edit those wikis directly. --- Jura 12:09, 28 July 2019 (UTC)
The problem is that it is not only a conflict between enwiki and dewiki. The frwiki even categorises articles with "etymology" section as disambiguation, e.g. fr:Dupont --Wickie37 (talk) 15:59, 28 July 2019 (UTC)
frwiki uses the LUA modul to make some additional links. Interestingly before, we had a user that came here to complain about the absence of links repeatedly, but didn't bother to implement it himself. Please ping me if you make some progress at enwiki or dewiki. --- Jura 12:22, 29 July 2019 (UTC)
It seems that there is no nonambiguous definition of disambiguition in the Wikiverse, and thus this is no valid distinction method for the non-alignment of items, that are nonambiguous to be connected as interwikilinks. It looks like bureaucracy as the cause for bureaucracy.
Es sieht so aus, als ob die zweifelsfreie Definition von Begriffsklärung im Wikiversum nicht existiert, und dies daher keine valide Methode ist, um Items auseinanderzureißen, die unzweifelhaft per Interwikilink zusammengehören. Es sieht aus wie Bürokratie um der Bürokratie willen.
Grüße vom Sänger ♫ (talk) 11:54, 29 July 2019 (UTC)
BKS sind in der Datenbank als solche gekennzeichnet, das ist zweifelsfrei definiert -- wenn auch auf einer recht technischen Ebene. Eine zweifelsfreie andere, aber nicht-technische Definition haben wir nicht, und die ist auch nicht in Sicht. In welchem Zusammenhang die Wikipedia-Projekte dieses Flag verwenden, bestimmen sie als autonome Projekte selbstverständlich selbst.
Willkür hingegen wäre es, wenn einzelne Benutzer nach Gutdünken Interwikis *in Wikidata* vermischen so wie Du es machen möchtest. Morgen kommt dann ein weiterer Benutzer, bewertet die Situation anders, und zieht wieder alles auseinander. Und das ganze passiert potenziell in hunderttausenden Objekten -- das haben wir hier alles schon mehrfach erlebt, es hat sich als unpraktikabel erwiesen. Die *technische* Definition als BKS ist deshalb ausschlaggebend dafür, ob die Seiten *in Wikidata* interwikiverlinkt sein dürfen, oder nicht. Was die Wikipedias darüber hinaus interwikiverlinken, ist nicht Gegenstand dieses Projektes.
Deshalb nochmal: ich habe Euch Tipps gegeben, wie Ihr das wie gewünscht in dewiki umsetzen könnt -- das müsst Ihr aber selbst machen. Nach dem Import von en:Template:Interwiki extra (und zugehörigem Modul) wäre es exakt ein Edit in dewiki, und die Interwikisituation im betreffenden Artikel wartet sich danach sogar ohne weiteres zutun oder beobachten. --MisterSynergy (talk) 12:14, 29 July 2019 (UTC)
Es ist eben nicht ein Edit, sondern ca. 20000 Artikel, in die das eingetragen werden muss. Aber wenn es da wirklich keinen Willen gibt, das zentral zu lösen, werde ich nachher versuchen einen Bot-Betreiber auf DE zu finden, der die Liste abarbeitet --Wickie37 (talk) 16:55, 29 July 2019 (UTC)
Im Moment werden diese rein technokratischen Flags von den einzelnen Projekten offensichtlich sehr willkürlich und ohne gemeinsames System vergeben, was zu solch eindeutig schlechten Zuständen wie dem hier erwähnten führt. Natürlich kann mensch die Augen vor der Welt verschließen, und sich auf seine technokratische Scheinwelt beschränken und so tun, als sei's die richtige, aber das ist natürlich für normal denkende Menschen absurd. Hier in diesem Fall ist es absolut eindeutig, nur die völlig willkürliche und nicht interprojektär begründbare Nichtsetzung des Flags in der enWP für vollkommen identische Artikel behindert die sinnvolle und erwünschte Verlinkung solcher Artikel im Wikiversum. Und wir sind schließlich für menschliche BenutzerInnen da, nicht für autistische Technokraten ohne Realweltbezug. Grüße vom Sänger ♫ (talk) 18:58, 7 August 2019 (UTC)
Wenn es dir darum geht den Einzelfall zu lösen, kannst du das tun in dem du redirekts erstellts. WMDE ist leider ein bischen langsam damit den RfC umzusetzen, aber es ist möglich die redirekts zu erstellen. Ich hab das kurz für dieses item gemacht. Wenn es dir um den generellen Fall geht, dann gibt es in vielen Einzelfällen Probleme, wenn Items wie diese gemergt werden.
dewiki könnte ein template wie Interwiki extra auch per bot auf die 20,000 Seiten verteilen. Das bräuchte keine manuellen edits. ChristianKl ❪✉❫ 14:54, 9 August 2019 (UTC)
Bei dewiki ist leider der Status Quo in jeder Hinsicht in Beton gegossen, das Projekt ist praktisch bewegungsunfähig. Selbst wenn der Status Quo erkennbar Mist ist. Es wurde ja vorgeschlagen, das per Bot und Template:Interwiki_extra zu lösen, aber ... "daaas muss erstmal woanders diskutiert werden". Als nächstes kommt jemand um die Ecke und will ein Meinungsbild sehen, und damit ist die Sache dann gänzlich tot.
Das ist allerdings dewiki's Problem, und kein Grund in Wikidata gegen den allgemeinen Konsens Sachen zu verpfuschen. --MisterSynergy (talk) 15:13, 9 August 2019 (UTC)

Q21468222 und Q21126436

In der Hoffnung, hier nicht komplett falsch zu sein: Meines Erachtens ist einer der beiden Q im Betreff redundant bzw. es gibt keine Kategorie:Stolpersteine in Uslar (Q21126436) in der deutschen Wikipedia. Damit die Commons-Kategorie richtig mit Q21468222 verlinkt werden kann, müsste Q21126436 darin "gemerged" werden. Sehe ich das richtig und wenn ja, könnte das jemand erledigen? --Migebert (talk) 17:04, 7 August 2019 (UTC)

Aktuell sollen solche auf der Wikistruktur basierenden Items erhalten bleiben. Erst wenn sämtliche Verlinkungen aus den WD Statements generiert werden, können diese Items entfernt werden. In diesem Fall könnten dann beide Items weg. Die Liste ergibt sich ja aus den Items, die sie beinhaltet. --GPSLeo (talk) 17:16, 9 August 2019 (UTC)

How to see all existing instances of a subclass for a particular class?

I'm trying to classify this image yet I'm running into a problem: we already have anthropomorphic cat, but I don't see any anthropomorphic bears, etc. I want to make sure they indeed do not exist, and thus I want to see all instancess subclassed from anthropomorphic character before starting to create new ones -- and I I'm not sure how to do that! -- Wesha (talk) 18:08, 12 August 2019 (UTC)

--MisterSynergy (talk) 11:14, 13 August 2019 (UTC)

Doppelter Eintrag?

Hallo, sind Q5486518 und Q2237559 nicht das gleiche? --Berthold Werner (talk) 10:56, 13 August 2019 (UTC)

Sieht aus als hätte es da zwei Schlachten zu verschiedenen Zeiten gegeben. Die polnischsprachige Wikipedia hat auch Artikel zu beiden Schlachten. Nach meinem Dafürhalten ist das was verschiedenes. Viele Grüße! --MisterSynergy (talk) 11:07, 13 August 2019 (UTC)
Stimmt, da sind unterschiedliche Jahreszahlen. --Berthold Werner (talk) 13:17, 13 August 2019 (UTC)

Bevorzugter Rang bei Einwohnerzahl

Ich bin neu hier und befürchte, die Frage ist schon oft gestellt worden: Sollten nicht alle Listen von Einwohnerzahlen einen bevorzugten Rang haben? Fast alle Queries (einschließlich der Beipiele hier) würden sich doch darauf verlassen. Insgesamt geht das hier z.B. bei den dt. Städten recht unterschiedlich zu. --Faring (talk) 01:21, 13 August 2019 (UTC)

Ohne genaue Hintergründe zu kennen:
  • Tendenziell will man genau einen Eintrag mit bevorzugtem Rang haben, obwohl mehrere möglich sind und vermutlich häufig auch eingestellt sind.
  • Man sollte sich dann aber auf einen anerkannten Prozess zur Ermittlung des zu bevorzugenden Wertes einigen; keine Ahnung ob das der Fall ist. Kandidaten wären:
    • Neueste Zahlen bevorzugen
    • Zahlen einer bestimmten Zählmethode bevorzugen
    • Zahlen einer bestimmten Quelle bevorzugen
    • (usw.)
Wenn es da einen Konsens gibt -- ich bin da nicht im Thema -- dann könnte man das zumindest zu einem guten Teil automatisiert einstellen. --MisterSynergy (talk) 11:11, 13 August 2019 (UTC)
Danke, ich werde das mal beobachten und melde mich wieder, wenn ich einen Plan habe. --Faring (talk) 23:07, 13 August 2019 (UTC)

Zusammen geführte Items wieder trennen

Hallo, eine IP hat fälschlicherweise Q4690037 und Q2135867 zusammen geführt. African Red slip pottery ist aber nun mal nur eine Form der Red slip pottery. Somit ist jetzt eine Ober- mit einer Unterkategorie vermengt. Ich schaffe es nicht, das wieder rückgängig zu machen. Wie geht das? -- Marcus Cyron (talk) 19:16, 13 August 2019 (UTC)

Hallo Marcus, im Grunde musst Du nur in beiden Objekten alte Versionen wiederherstellen, und das geht am besten über die Versionsgeschichte. Da sind hinter jeder Version links "zurücksetzen" (englisch "restore"), mit denen eine alte Version wiederhergestellt werden kann. In Q4690037 hast Du schon alles richtig gemacht, wobei das einfacher gegangen wäre ;-). Hier kannst Du ebenfalls die Weiterleitung durch "zurücksetzen" wieder entfernen, indem Du die Version vom 31. Mai wiederherstellst. Wichtig ist dabei, dass Du zuerst das zusammengeführte Objekt rückgängig machst, und danach erst die Weiterleitung entfernst. Viele Grüße, MisterSynergy (talk) 19:22, 13 August 2019 (UTC)
Hallo, das habe ich schon versucht, siehe die Versionsgeschichte. Aber vielleicht nicht in der richtigen Reihenfolge? Wenn das Jemand übernehmen könnte, wäre ich sehr dankbar, da ich gerade in Stockholm nicht viel mehr machen kann, als zu versuchen keinen Unsinn durch rutschen zu lassen. -- Marcus Cyron (talk) 19:28, 13 August 2019 (UTC)
Ich habe das schnell erledigt. Es kann eigentlich nur die falsche Reihenfolge gewesen sein. Da Du mittlerweile Q4690037 selbst erledigt hattest, ging das nun glatt durch. Viel Spaß in Stockholm! —MisterSynergy (talk) 19:33, 13 August 2019 (UTC)

(BK) @MisterSynergy: - ich danke dir. Wenn ich zurück bin schaue ich mir das mal genauer an, damit ich in Zukunft weiß, wie es geht. -- Marcus Cyron (talk) 19:33, 13 August 2019 (UTC)

Tanja Bruske

Ich habe anhand der Homepage im Wikipediaartikel zu Tanja Bruske das komplette Geburtsdatum übernommen nämlich den h, 23. November 1978 in Hanau Deutschland  ( natürlich mit Quellenangabe ). Könnt ihr diese Daten für Wikidata übernehmen ? Gruss Avestaboy  – The preceding unsigned comment was added by Avestaboy (talk • contribs) at 18:53, 14 August 2019‎ (UTC).

Wenn Du in de:Tanja Bruske die Daten auch in der Personendaten-Vorlage einfügst, dann werden sie vermutlich irgendwann nach Wikidata importiert. Allerdings kannst Du auch das Objekt Tanja Bruske (Q62818992) über sie direkt bearbeiten. —MisterSynergy (talk) 19:56, 14 August 2019 (UTC)

Problem linking to Wiktionary and Wikipedia

When I try to create a link to the German wiktionary or Wikipedia I get an error saying that the page could not be found, although I copied and pasted the URL. Looks like the macro adds a quote when looking up the page. Roland Wingerter (talk) 19:44, 14 August 2019 (UTC)

You just need to past the page title, not the full URL. Besides that, Wiktionary Interwikilinks are a special case, see Wikidata:Wiktionary/Sitelinks how it works. —MisterSynergy (talk) 19:52, 14 August 2019 (UTC)

Die Wikidata-Broschüre ist da.

Wikimedia Deutschland hat eine neue Broschüre über die freie Wissensdatenbank Wikidata herausgegeben. Die Printversion kann unter community@wikimedia.de angefragt werden. Eine pdf-Version folgt in Kürze. --Nicolas Rück (WMDE) (talk) 14:59, 29 July 2019 (UTC)

pdf Q66448215

Jetzt auch als pdf verfügbar. --Nicolas Rück (WMDE) (talk) 15:29, 6 August 2019 (UTC)

Q66448215 --Jeb (talk) 08:30, 15 August 2019 (UTC)

Q64167086

Bin gerade per Zufall über Lisa Krischel-Brog (Q64167086) gestolpert. Ist so ein Eintrag sinnvoll? Oder gehört der gelöscht. Mich machte diese riesige unsinnige Kurzbeschreibung aufmerksam. -- sk (talk) 08:03, 15 August 2019 (UTC)

Sicher, dass du das richtige Item verlinkt hast? Das ist ein ganz normales Item für eine Person. --GPSLeo (talk) 15:11, 15 August 2019 (UTC)
Vermutlich war diese Version gemeint. Grüße vom Sänger ♫ (talk) 15:14, 15 August 2019 (UTC)
@Stefan Kühn: Das sind Boteinspielungen. Die müssen per Hand nachbearbeitet werden. Problematischer finde ich Einträge wie Markus Glaser (Q66429703) oder Richard Heigl (Q66429713), die offenbar auf VIAF beruhen und nur Links zu Normdatensätzen enthalten. Da kann man nur hoffen, dass VIAF nicht mehrere Personen vermischt. --Kolja21 (talk) 21:07, 16 August 2019 (UTC)

Sammlung

Wenn ein Kunstwerk eine Leihgabe ist, erscheinen Leihgeber und Leihnehmer als Sammlung, oder sollte sich dies auf die Sammlung beim Leihgeber beschränken? --Oursana (talk) 10:58, 14 August 2019 (UTC)

Könntest Du ein Beispiel nennen? --Faring (talk) 22:14, 19 August 2019 (UTC)

New tools and IP masking

Hey everyone,

The Wikimedia Foundation wants to work on two things that affect how we patrol changes and handle vandalism and harassment. We want to make the tools that are used to handle bad edits better. We also want to get better privacy for unregistered users so their IP addresses are no longer shown to everyone in the world. We would not hide IP addresses until we have better tools for patrolling.

We have an idea of what tools could be working better and how a more limited access to IP addresses would change things, but we need to hear from more wikis. You can read more about the project on Meta and post comments and feedback. Now is when we need to hear from you to be able to give you better tools to handle vandalism, spam and harassment.

You can post in your language if you can't write in English.

Johan (WMF)

14:18, 21 August 2019 (UTC)

Freileitungsmast und Leitungsmast

Sollten nicht die beiden Elemente Q1144084 und Q914711 nicht zusammenführen, denn wo liegt der Unterschied zwischen den beiden - zumindest in der detuschen Sprache sehe ich keinen - aber vielleicht sollten di ebeiden genauer beschrieben werden. danke K@rl (talk) 08:01, 24 August 2019 (UTC)

transmission tower (Q914711) bezieht sich nur auf Strommasten. utility pole (Q1144084) beschreibt alle Arten von Leitungsmasten z.B. für Telefonkabel. Einige Wikis haben auch separate Artikel für beides. --GPSLeo (talk) 12:56, 24 August 2019 (UTC)
Da kommen aber die Missverständnisse raus, denn AT wird ein Telefonmast ebenso als Freileitungsmast bezeichnet. deswegen sind ja in allen Wikis verschiedene Artikel. --K@rl (talk) 12:53, 25 August 2019 (UTC)

Dänemark vs. Königreich Dänemark

Denmark (Q35) und Kingdom of Denmark (Q756617) sollten klarer differenziert oder zusammengelegt werden. Zurzeit sind z.B. beide als sovereign state (Q3624078) eingeordnet und es ist bei beiden die gleiche population (P1082) zugeordnet. --Wickie37 (talk) 17:16, 25 August 2019 (UTC)

Das Kingdom of Denmark (Q756617) umfasst neben Denmark (Q35) auch Greenland (Q223) und Faroe Islands (Q4628). Die Beschreibung macht das auch direkt klar. In wieweit alle Aussagen richtig sind, kann ich nicht sagen, dazu habe ich zu wenig Ahnung vom Völkerrecht und der dänischen Verfassung. --GPSLeo (talk) 19:50, 25 August 2019 (UTC)

Gemeinde in Deutschland mit "bevorzugtem Rang"

Wir haben hier 570 von insgesamt 12.180 deutschen Gemeinden bei denen die Beziehung Unterklasse von Gemeinde in Deutschland mit bevorzugtem Rank markiert ist (z.B. Q3951, Aalen). Das führt dazu, dass diese Gemeinden bei der häufig genutzten Abfrage "wdt:P31/wdt:P279* wd:Q515" (ist eine direkte oder Unterklasse von "Stadt") nicht mehr gefunden werden. Ich frage mich ganz allgemein, ob es überhaupt einen Grund geben könnte, eine P279, Unterklasse von zu bevorzugen. Wenn ich nichts übersehen habe, würde ich mich darum kümmern, die Ränge dort zu entfernen. --Faring (talk) 14:47, 19 August 2019 (UTC)

einverstanden. Grüße Bigbossfarin (talk) 20:48, 20 August 2019 (UTC)
Für mich klingt das nach einem Fehler im Query Service, gibt es einen guten Grund, das der Query Service hier diese Antwort gibt? ChristianKl ❪✉❫ 16:59, 27 August 2019 (UTC)
Nee, der Query Service macht das richtig. Mit wdt: werden nur Aussagen mit bestrank berücksichtigt, sprich alle Aussagen mit bevorzugtem Rang, sofern vorhanden, ansonsten alle Aussagen mit normalem Rang. Nie aber Aussagen mit missbilligtem Rang.
Man könnte ?item wdt:P31/wdt:P279* wd:Q515 ändern zu ?item p:P31/ps:P31/wdt:P279* wd:Q515, um rankunabhängig alle Aussagen zu berücksichtigen, allerdings auch solche mit missbilligtem Rang. Das sollten allerdings nicht besonders viele sein. --MisterSynergy (talk) 17:47, 27 August 2019 (UTC)

Lemma ausbessern?!

Hi, leider habe ich beim Anlegen von English billiards player (Q66759445) nicht aufgepasst, sollte mit Bindestrichen durchgeschleift werden. „Verschieben“ und neues Lemma vergeben bietet das System ja leider nicht an. Daher dachte ich das geht dann wohl über „zusammenlegen“. Also habe ich English billiards player (Q66759460) angelegt, um beide auf das neue Objekt zusammenzuführen. Hat leider nicht geklappt. Kann mir jemand Tipps geben, wie damit umzugehen ist? Dank im Voraus. Rafael Zink (talk) 15:48, 27 August 2019 (UTC)

Erledigt. Jetzt ging's. Da hing wohl das System gestern. ;-) Rafael Zink (talk) 15:52, 27 August 2019 (UTC)
Neues Problem. Wir haben uns in der de:WP darauf geeinigt, nicht mehr die französische Schreibweise carom billiards player (Q26876987) zu nutzen, sondern die deutsche Schreibweise mit „K“ carom billiards player (Q66774238). Jetzt ist nur auf das alte Objekt per Weiterleitung zusammengelegt worden. Dabei bin ich mir sicher, den Haken rausgenommen zu haben. Das lässt sich so jetzt nicht mehr ändern in der Weiterleitung. Kann das jemand fixen, bitte. Dank im Voraus. Rafael Zink (talk) 16:09, 27 August 2019 (UTC)
✓ Done: carom billiards player (Q26876987). Du hättest kein neues Item erstellen müssen; einfach nur Label und Alias abändern. -- Reise Reise (talk) 16:29, 27 August 2019 (UTC)
Danke. Was meinst du damit? Beschreibe mal kurz. Gruß Rafael Zink (talk) 18:04, 27 August 2019 (UTC)
Da rechts oben ist das Stift-Symbol mit dem Link "Bearbeiten". Wenn man dort draufklickt, kann man Label, Beschreibung und Alias in verschiedenen Sprachen ändern. Die Screenshots von Help:Label/de, Help:Description/de und Help:Aliases/de sind leider deutlich veraltet, allerdings geht es dort auch mehr um den Inhalt. -- Reise Reise (talk) 18:57, 27 August 2019 (UTC)
Ah. OK. Danke. :-) Rafael Zink (talk) 20:18, 27 August 2019 (UTC)

Kann man hier auch Vandalen in die Schranken weisen?

Somal eben schnell einen Eintrag schaffen, nur um der Erste zu sein kann es doch nicht sein.--Bahnmoeller (talk) 20:01, 27 August 2019 (UTC)

Um welches Item oder welchen Edit geht es dir? ChristianKl ❪✉❫ 20:32, 27 August 2019 (UTC)
Das einzig Tool um Vandalismus schnell zu finden, das mir einfällt, ist User:Lucas Werkmeister/SpeedPatrolling. Leider aber ohne Möglichkeit die Sprachen zu wählen. Ansonsten wie in jedem Wiki über Special:NewPages. --GPSLeo (talk) 07:54, 28 August 2019 (UTC)
Es geht wohl eher um Topic:V67q62zj3umub7gy. Es ist kein Vandalismus, neue Objekte anzulegen und nur mit wenigen grundlegenden Aussagen auszustatten. Die Zahl der angelegten Objekte je Benutzer interessiert hier eh niemanden. @M2k~dewiki: FYI. --MisterSynergy (talk) 08:05, 28 August 2019 (UTC)

Hallo, wichtiger als die "Vollständigkeit" (wodurch definiert?) eines Objektes von Beginn an ist aus meiner Sicht, dass es überhaupt ein Objekt (idealerweise ohne Dubletten) gibt, damit anschließend diverse Bots und Tools (Petscan, Template-Harvester, Quickstatements, ...) die fehlenden Properties automatisch für eine große Anzahl von Objekten aus den verschiedenen Sprachversionen der Wikipedia ergänzen können. Die Entscheidung ob es sich um eine neues Objekt handelt oder nicht kann teilweise nur semi-automatisch (beispielsweise mit Hilfe von Petscan, damit es zu einer möglichst geringen Anzahl von Dubletten kommt wobei über die verschiedenen IDs und Constraint-Violations ggf. später auch noch Dubletten gefunden werden) vorgenommen werden, daher ist das Anlegen der Objekte aus meiner Sicht ein erster wichtiger Schritt für das Funktionieren der Bots und Harvester zum Importieren einzelner Properties.

Täglich werden in der deutschsprachigen Wikipedia rund 300 neue Artikel angelegt, im Monat sind das rund 9.000 Artikel. Dazu kommen noch Kategorien, Navigationsleisten, usw. Aktuell finden sich mehrere tausend unverbundende Artikel, Kategorien, Navigationsleisten, etc. unter

In unregelmäßigen Abständen legt ein Bot für alle Artikel ohne Objekt Objekte an, allerdings ohne Rücksicht auf allfällige Dubletten zu nehmen, meist auch ohne zumindest "ist ein"-Property anzugeben:

Was ist die generelle Strategie, wie, wann, wodurch, ... sollen die Objekte für diese 9.000 neuen Artikel pro Monat angelegt bzw. mit bestehenden Objekten verknüpft werden?

Es gibt verschiedene Strategien für den Umgang mit unverbundenen Seiten, und keine davon ist zwingend die beste. Ich finde den Ansatz, regelmäßig unverbundene Seiten mit einem Objekt auszustatten und dort ein paar grundlegende Aussagen zu ergänzen, als Mittelweg eigentlich ganz hilfreich. Wenn das nicht gemacht wird, bleiben sie entweder *sehr lang* unverbunden, oder werden irgendwann ohne irgendwelche Aussagen ergänzt, was die Sache auch nicht einfacher macht. Wir können IMO jedenfalls nicht erwarten, dass jemand laufend pro Tag 300 neue Objekte verschiedenster Art mit einer Aussagen-Vollaussattung anlegt. Objekte wachsen typischerweise inkrementell, und Automatisierung durch verschiedene Benutzer spielt dabei eine große Rolle. --MisterSynergy (talk) 09:04, 28 August 2019 (UTC)

Löschen eines doppelt angelegten Elements

Kann mir bitte jemand Q66828246 löschen. Es wurde von mir irrtümlich für Q61043817 nochmals angelegt. Danke für die Hilfe K@rl (talk) 13:54, 30 August 2019 (UTC)

Hallo @Karl Gruber:, die beiden Objekte wurden zusammengeführt, siehe auch Help:Merge/de#Das_„Merge“-Helferlein. --M2k~dewiki (talk) 14:14, 30 August 2019 (UTC)

Wie umgehen mit nicht existenten Objekten?

Siehe diese Löschdisk [1] (en): @Peter James:

Behalten wir nicht existente Objekte (konkret, einen Berg den es unter diesem Namen nicht gibt) in WD, weil es Referenzen auf Geonames oder GNS oder sonstwo gibt? (Weil die Amis das sagen?) Versuchen wir unsere Fantasie walten zu lassen und das nicht existente Objekt (auf Basis von was?) mit einem ähnlich geschriebenen Objekt zu identifizieren und in der Folge zu mergen? Mit all dem Rattenschwanz an notwenigen Mergevorgängen in bot-generierten Wikipedias (wie sv oder ceb)? Markieren wir nicht existente Objekte nicht weiter als Berg, See oder Land, sondern als fictional object (Q15706911) (wird nur in externen Datenquellen = nur in der Literatur erwähnt)? Oder löschen wir den Müll einfach? lg --Herzi Pinki (talk) 09:12, 31 August 2019 (UTC)

Das wird in der Regel situativ entschieden, und es gibt entsprechend nicht unbedingt die eine richtige Lösung. Ein paar Gedanken:
  • Wenn der externe Datenbankeintrag ein sich auf ein real existierendes Objekt bezieht, aber irgendwie fehlerhaft ist, kann man durchaus zusammenführen, und alle bekannterweise falsche Information missbilligen oder entfernen.
  • Bei einem kompletten Fantasiegebilde kann man das Objekt löschen, oder alternativ irgendwie eine Auszeichnung als fictional object (Q15706911) (oder Unterklasse davon) einstellen.
    • Für letztere Vorgehensweise spricht, dass gelegentlich eine vollständige Abdeckung externer Kataloge angestrebt wird, und man wegen solcher Fehler keine Lücken erzeugen möchte, über die sich später jemand anderes dann wundert.
    • Möglicherweise wird der Betreiber des externen Kataloges so auch auf den Fehler aufmerksam.
    • Zu beachten ist auch, dass wir hier eigentlich die Quellenlage abbilden möchten, und nicht irgendeine ultimative Wahrheit die keine Abweichung von der Realität kennen darf.
    • Einen wirklich zwingenden Grund gibt es fürs Behalten allerdings eigentlich nicht; weil solche Objekte über fiktives praktisch nichts kosten und, sofern die Aussagen richtig mit Rängen ausgestattet sind, auch keine Datennutzer beeinflussen, würde ich persönlich so etwas einer Löschung vorziehen.
--MisterSynergy (talk) 17:05, 31 August 2019 (UTC)
Wenn dem so ist, dass WD keine Wahrheit darstellt, sondern jede Abweichung von der Realität erlaubt, dann sind die Daten (alle Daten hier in WD) wertlos. Garbage in, garbage out. Dann gibt es auch keinen Vandalismus. Und es macht keinen Sinn, Daten richtig zu stellen. WD macht dann keinen Sinn.
Falsche Namen stehen btw. nicht in Properties, sondern in Bezeichnung und Auch bekannt als und dort wüsste ich nicht, wie das mit Rängen zu versehen ist.
Ob sich ein externer Datenbankeintrag auf ein real existierendes Objekt bezieht und die beiden Objekte zusammenzuführen, ist immer ein bisschen Theoriefindung. lg --Herzi Pinki (talk) 17:38, 31 August 2019 (UTC)
War vielleicht ein bisschen unglücklich ausgedrückt. Natürlich möchten wir am Ende, dass bei Abfragen nur "richtiges" herauskommt, sofern wir das jedenfalls feststellen können. Wenn ein fehlerhafter externer Datenbankeintrag mit passenden Rängen ausgestattet ist, dann ist er zwar vorhanden, stört aber halt eben nicht.
In Bezeichnungen (und Aliasen) kannst Du falsche Information einfach entfernen, da gibt es tatsächlich keine Ränge.
Bei der Feststellung, ob in der externen Datenbank ein Fehler vorhanden ist, wird tatsächlich oft eine Mischung aus Heuristiken, persönlichen Bewertungen (beides irgendwie TF), und natürlich dem Hinzuziehen weiterer Quellen vorgenommen. In der Summe ist dann zum Beispiel ein Berg in einer externen Quelle kein Berg mehr in Wikidata, sondern halt ein "fiktiver Berg". Klar, dass man da vorsichtig sein sollte, und eben nicht leichtfertig Dinge als fiktiv abstempeln möchte. Oft sind die Fehler in den externen Datenbanken aber derart offensichtlich, dass man da mit hoher Sicherheit eine Entscheidung treffen kann. Eine Löschung ist dann jedenfalls nicht zwingend, es gibt im Gegenteil und wie beschrieben sogar gute Gründe für ein anderes Vorgehen. --MisterSynergy (talk) 17:47, 31 August 2019 (UTC)
Das zusammengemischte Objekt Großer Speikkofel (Q21878939) hat jetzt 3 GeoNames ID (P1566). Das ist eine Constraint-Violation. Ist das besser als Löschen? Wie wird das aufgelöst? Indem die 3 zusammengeführten Objekte wieder vereinzelt werden? Auch bei GNS Unique Feature ID (P2326) gibt es eine Constraint-Violation. Auf GeoNames habe ich die Namen jetzt gleichgezogen. --Herzi Pinki (talk) 18:05, 31 August 2019 (UTC)
Ja, eine Constraint violation ist in diesem Zusammenhang besser als eine Löschung. Bei Identifikatoren kannst Du mit Rängen die Sichtbarkeit nach außen steuern. Wenn es einen Haupteintrag für den Berg gibt, dann bekommt er bevorzugten Rang. Datennutzer sehen dann nur diesen einen Wert, sofern sie nicht explizit nach allen Werten fragen. --MisterSynergy (talk) 18:18, 31 August 2019 (UTC)
Es übersteigt meine Kompetenz und meinen Willen, bei 3 Geonames Ids den Haupteintrag zu identifizieren. Insoferne ist das sehr theoretisch. lg --Herzi Pinki (talk) 18:58, 31 August 2019 (UTC)
Kleine Anmerkung von jemandem, der im Bereich narrativer (fiktionaler) Werke tätig ist; "fiktiver Berg" ist eher ungünstig, da es sich um eine Klasse von Objekten in fiktionalen Werken handelt (e.g. Lonely Mountain (Q26098)). fictional entity (Q14897293) ist definiert als "Entität, welche ausschließlich in fiktionalen Werken existiert"; es ist eine Unterklasse von creative work (Q17537576). Weder ist eine Datenbank ein fiktionales Werk noch lässt sich ein Fehler in ihr wohl als kreatives Werk bezeichnen. non-existent entity (Q64728693) würde sich wohl besser eignen, um entsprechende Entitäten zu kennzeichnen. Der Zweig fiktiver Entitäten sollte genausowenig mit Fehlern in Datenbanken etc. "zugemüllt" werden wie der Zweig realer Entitäten. - Valentina.Anitnelav (talk) 18:37, 31 August 2019 (UTC)
danke, trotzdem würde ich mich nicht wehren, sollte jemand Geonames als Fantasiewerk bezeichnen. --Herzi Pinki (talk) 18:58, 31 August 2019 (UTC)

Schon erstaunlich, wie das Nichtlöschen eines Tippfehlers ausufern kann! lg --Herzi Pinki (talk) 18:58, 31 August 2019 (UTC)

Galslacher Kogel (Q21875836) so etwa? lg --Herzi Pinki (talk) 21:23, 31 August 2019 (UTC) Habe das Objekt auf Geonames gelöscht. Würde das so passen? --Herzi Pinki (talk) 21:29, 31 August 2019 (UTC)

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Forum/Archiv/2019/08&oldid=1012381062"