https://www.wikidata.org/w/index.php?title=Q1632952&type=revision&diff=1399945609&oldid=1397858777 Das war kein Vandalismus und deshalb unnötig.de:Portal:Film/Fehlende_Oscar-Artikel#Oscarverleihung_1968.
User talk:MisterSynergy
Jump to navigation
Jump to search
"18:40, 1 April 2021 MsynABot talk contribs m 35,635 bytes 0 Protected "Parsons School of Design (Q1339626)": Highly used item: to be indefinitely semi-protected per Wikidata:Page protection policy#Highly used items; please use Template:Edit request on the item talk page if you cannot edit this item ([Edit=Allow only" Please explain how I may regain editor access, how to unlock this 'semi-protected' page, I do not see a 'Template:edit request' option on item talk page, as stated in MsynABot History notation.
Once you have made 50 edits, you gain "autoconfirmed" rights here at Wikidata. You will then be able to edit this item.
Until then, you can place an edit request on the item talk page, using the Template:Edit request. You can simply add your request there, and add {{Edit request}} anywhere within the section. Experienced users will then be able to find your request, and help in case they understand it.
Thanks for responding, I may only edit this page, so cannot make 50 edits to gain 'autoconfirmed' right, if the page is locked. 'talk' appears empty..."There is currently no text in this page. You can search for this page title in other pages, search the related logs, or create this page." don't see Template:Edit request option. Instead use "Creating Talk:Q1339626" discussion link option?
Regarding editing rights, an alternative to 50 edits is to make a request for the "confirmed" right at Wikidata:Requests for permissions/Other rights#Confirmed. This is a right which would be added to your account temporarily until you reach 50 edits, and it should enable you to edit semi-protected items directly.
Re "Edit request": item talk pages are not structured content, they use "wikitext" source code just as Wikipedias. If the item talk page in question does not exist yet as in this case, do not hesitate to create it. You can simply add your request on this page; in order to make it visible to the community, place the text {{Edit request}} (including the double curly brackets) anywhere on that page.
Danke, dass du die Unilisten wieder flott gemacht hast. Du schreibst: "unlimited results are too many results; limit to 1000." Ich habe mehrere Listen erstellt: User:Einsteiger/Universities. Gibt es eine Regel, wie man lange Listen am besten aufteilt? (Schön wäre chronologisch, aber da nicht bei allen Personen die Lebensdaten bekannt sind, vermutlich eher alphabetisch.) Kannst du es mir an einem Beispiel zeigen? Dann übernehme ich die Einstellung für die anderen Listen. - Wikidata:ENA Strasbourg/Listeria/École nationale d'administration people ist schon bei knapp 4.000 Personen angelangt. Ideal wäre, wenn ListeriaBot, so wie die Archiv-Bots, selbst die Aufteilung übernehmen könnte.
Listen mit tausenden Einträgen sind eigentlich eher nicht so richtig praktikabel, aus verschiedenen Gründen. Zum Einen kann man das irgendwann eh nicht mehr richtig erfassen, zum anderen kommen diverse technische Limitierungen zum Vorschein. Besser ist es, solche Listen feiner zu gliedern.
Bei der Tübingen-Liste von heute morgen steht zum Beispiel in der Abfrage drin: { ?item ?p1 wd:Q153978 } UNION { ?item ?p1 [ wdt:P361 wd:Q153978 ] }. Das bedeutet im Wesentlichen: "hat irgendwas mit der Uni Tübingen zu tun". Man kann das zum Beispiel genauer anschauen und stellt fest, dass etwa hälftig die Eigenschaften educated at (P69) und employer (P108) genutzt werden, und abgesehen davon nur ganz paar andere. Es wäre also sinnvoll, die Liste in drei Listen aufzuteilen: eine für <Person><besuchte Bildungseinrichtung><Uni Tübingen>, eine für <Person><Arbeitgeber><Uni Tübingen>, und eine für alles andere. Ich kann gerade nicht sagen, ob das schon genug ist damit der Bot damit klar kommt – jedenfalls wäre das schonmal deutlich fokussierter.
Soll ich das mal aufsetzen und wir schauen das an? Falls es nicht klappt oder gefällt, können wir das jederzeit auch wieder löschen. Viele Grüße!
Danke, das klingt nach einem guten Ansatz. Trotzdem werden die Uniliste dann aber die 1000er-Marke knacken. Es gäbe zahlreise Doppeleinträge, denn die Masse an Doktoranden, die via ORCID eingespielt wurden, sind sowohl P69 wie P108. Was hälst du von einer Liste für Personen, die in Wikipedia einen Artikel haben und zwei Listen (Nachname A-M, N-Z oder P69, P108) für alle anderen?
Vorschlag: die Mitarbeiter nach Geburtsjahr aufsplitten, siehe zum Beispiel:
- Wikidata:University of Tübingen/Listeria/UTübingen employees (born before 1900)
- Wikidata:University of Tübingen/Listeria/UTübingen employees (born 1901–1950)
- Wikidata:University of Tübingen/Listeria/UTübingen employees (born after 1951 or unknown)
Da kann man natürlich alles mögliche noch dran verbessern (etwa Seitentitel durch Verschieben :-D), aber so haben wir immerhin schonmal eine Aufteilung gefunden, die ohne "LIMIT" auskommt. Für Studierende könnte man ebenso vorgehen. Würde Dir das gefallen?
Die Listen sehen sehr professionell aus. Danke! Ich habe Wikidata:University of Tübingen/Listeria/UTübingen people in eine Einstiegsseite umgewandelt. Ist Englisch als Sprache obligatorisch? Für Paris und Straßburg würde ich die Unilisten gerne auf Französisch erstellen.
Nee, ist nicht obligatorisch und lokale Sprache macht sicherlich Sinn. Man könnte das ganze wohl auch gleich mehrsprachig anbieten, das wäre aber recht aufwändig.
Du kannst da erstmal viel mit Rumspielen und Sachen ausprobieren. Ich gebe gerne Ratschläge, wenn Du meinst welche zu brauchen. Wenn irgendwas nicht klappt und gelöscht werden muss, kann ich das auch gern auf dem kurzen Dienstweg erledigen.
Super, dann probiere ich das heute Abend aus.
Die fehlenden Listen auf Englisch zu erstellen, klappt problemlos. Nur bei der Sprache komme ich nicht weiter. Laut Template:Wikidata list/doc reicht es, in den Spalten den Sprachcode einzufügen. Beispiel:label/fr. Anscheinend ist es aber doch komplizierter, s. Testseite: Wikidata:Université de Tübingen/Listeria/UTübingen employés (nés avant 1900).
Hallo, ich habe jetzt alle Unilisten, die zu lang waren, aufgesplittet.
Es war eine Fusselarbeit mit vielen Tippfehlern. Kannst du bitte folgende Testseiten löschen:
- Wikidata:Université de Tübingen/Listeria/UTübingen employés (nés avant 1900)
- Wikidata:ENS Paris/Listeria/ENS Paris people
- Wikidata:ENA Strasbourg/Listeria/École nationale d'administration (nés avant 1950)
- Wikidata:Wikidata:ENS Paris/Listeria/École normale supérieure employés (nés avant 1900)
- Wikidata:Wikidata:ENS Paris/Listeria/École normale supérieure employés (nés avant 1950)
- Wikidata:Wikidata:ENS Paris/Listeria/École normale supérieure employés (nés après 1951 ou inconnu)
- Wikidata:Wikidata:ENS Paris/Listeria/École normale supérieure élèves (nés avant 1900)
- Wikidata:Wikidata:ENS Paris/Listeria/École normale supérieure élèves (nés 1901–1950)
- Wikidata:Wikidata:ENS Paris/Listeria/École normale supérieure élèves (nés après 1951 ou inconnu)
Danke schon mal!
Okay, erledigt. Ich hoffe, dass ich nicht versehentlich was falsches gelöscht habe ;-)
Tausend Dank!
Hello. Could you restore it? I would like to check it.
Q105771354 is restored. Please have a look, it seems to be abandoned.
Thanks for running the bot, it looks like a good step forward! However, the protection changes are appearing on the watchlist on the English Wikipedia for related items, which probably isn't necessary. Is there a way you can avoid that, or does that need a phabricator ticket to fix?
Hey Mike, I don't think I can change that. The bot account has a botflag, and the protection changes appear to be tagged as bot edits as well (on my watchlist). I do not explicitly set "botflag=True" while changing the protection, but I am actually not aware whether the corresponding pywikibot function actually supports such a parameter, and usually it is not necessary anyways when the account already has a botflag.
OK. Could you pause the bot, and we can take it up on phab? I can start a ticket if you want.
The edit summary does not seem to be producing a proper link. Can this be fixed?
Which link?
Huh? It's https://www.wikidata.org/wiki/Wikidata:Page_protection_policy#Highly_used_items for me. See the protection log and it also appears correctly on my watchlist. Where do you see that link?
I see that link from enwp...
Okay, seen it. The software apparently confuses the namespace prefix with an interwiki prefix when not being used locally.
Not sure what to do. I do not want to clutter the wikidata-local protection log any further, but this is also not ideal. Suggestions?
No need to change the ones that have already been done, but if there was a reliable way of producing a working link on other wikis that would be great!
:d:
?
But this would appear in the Wikidata protection log as well, wouldn't it?
Also, I think we should consider this to be a bug in the software. It does not have any problems to make a proper link out of Template:Edit request. It is only a problem when the Wikidata namespace is used.
For the record: I have fixed this problem, and it now renders in client wikis as desired.
Since I am running it with a smaller starter batch (~1500 protections out of the total ~25k), and 1300+ of them are already done, I would prefer to continue running it until today's queue is depleted. This will also hopefully produce a report in the end. I was originally planning to ramp it up over a couple of days, but I could wait for the phab—as long as there is a perspective for a solution in the near future.
OK, finishing the run makes sense. I'll start a phab ticket.
Phab ticket at https://phabricator.wikimedia.org/T276613
Interestingly, I apparently do not see these logs on my German Wikipedia watchlist. There is at least one case which should appear on my enwiki and dewiki watchlist, but it only shows up on enwiki.
Let's discuss on phab?
Want to make sure that this is actually the case and this needs some more investigation. There are so many filter options that it is difficult to be really sure… :-P
Seems like the phabricator task is a non-starter. I'm inclined to continue without it being closed first…
I'd prefer if you gave it more time (e.g., a week).
It's still dead.
Since my availability might reduce in the next time again, I would really prefer to continue the initial runs which I prefer to oversee closely.
Mike, are you still interested in this discussion?
Sort of, I'd like to see it fixed, but that's over at Phab...
Yeah, but there is literally no perspective that anyone ever picks this ticket up and does something. It is not even targeted properly to anyone. The situation effectively blocks the implementation of this task forever.
Nagging there might help? Or at Wikidata:Contact the development team? Or else, I guess just go for it, and point any other people that complain to the phab ticket...
Yeah, I would then just continue within the next days. If nobody else complains, it's not a serious issue anyways. Otherwise we'll see how the phab ticket develops…
The second starter batch has finished. I have not received any further feedback yet.
Hello, and thank you for your work and the useful contributions of MsynBot.
MsynBot seems to be changing the property "Country" to "Country of registry" for all the ships it encounters. This is incorrect: "Country of registry" is a notion that makes sense only for modern commercial vessels. Research vessels, pleasure craft, warships, old merchantmen etc do not have a "Country of registry". For example, I just saw an instance concerning Q5502230, a sailing frigate from 1795.
The bot needs a more complex set of rules, or failing this it should leave such questions to humans who understand them.
Cheers!
Hey Rama, the batch was a one-time job, so my bot will not do any of such property moves again. It was basically done as an initial setup of "country of registry" based on a request by another user right after that property was created. I am aware that some of the moves are at least questionable, particularly for shipwreck items and indeed some very old ships. Yet, to my knowledge these are only very few cases, so there have not been any attempts so "fix" anything yet.
It is worth to mention that for old ships, the "country" property is often equally inapplicable as "country of registry".
Strip Poker Night at the Inventory (Q64372387), now that the ATT ID property exists I believe point two of WD:N covers it (serious and publically-available reference). I had thought structural need (from characters/source works) covered it before, but I must have been incorrect.
Also requesting that ZONE-tan (Q64437961) be undeleted so it can be merged into ZONE-tan (Q68704983). Thank you for reading this request.
All done. Please do the merge and add the identifier as you have indicated here.
Thank you, I have now done so. Linked from the SPNATI item is GitGud (Q65555701) (I can add terms of service URL (P7014) / privacy policy URL (P7101) / ToS;DR service numerical identifier (P8525)), and also Welcome to the Inventory (Q65560564) (a podcast), Embla Academy (Q65891232) (a work), Trueno (Q64410329) and Angie (Q65923245) (characters). I don't recall what the latter three are but I am willing to improve them; I trust your judgment call either way.
I have restored all of them, so please have a look.
(I also added wikilinks to your comment, in order to keep track of this discussion)
Hello there, MisterSynergy! I am writing to you because a new WMF project, Structured Data Across Wikimedia (SDAW), is about to start.
SDAW is a grant-funded programme that will explore ways to structure content on wikitext pages in a way that will be machine-recognizable and -relatable, in order to make reading, editing, and searching easier and more accessible across projects and on the Internet.
The reason why I am contacting you is because of your work on Wikidata and the other Wikimedia projects, and your opinion would be of great interest for us to kickstart the discussion. We defined a series of questions we would like to have feedback on. If you want to ask a question on your own, or just want to share with us your ideas or opinions, please feel free to do so!
Also, if you know some other user(s) that can be interested, please let me know or invite them to join the discussion. The more, the better!
Hope to hear from you soon!
Again, someone is having an >200/min edit rate, probably causing the >5s maxlag periods, and others edit despite that maxlag. Are you / is someone aware of this?
I am not monitoring this all the time; I just start my script when someone complains.
Do you refer to User:Gnoeee? They are using QuickStatements with their admin account and have no control over the throttling, unfortunately:
- The QuickStatements tool just goes as quickly as possible and until now nobody was able to convince User:Magnus Manske to change this.
- Admin accounts are not rate limited, because this is necessary for very few admin actions. I did lobby to change this when the general rate limit was introduced a couple of months ago, but it was found to be too complicated and thus not changed.
So, an unfortunate situation. Since we cannot prohibit admins to use the QuickStatements tool, there is little we can do here. Admins should, however, preferably not run larger jobs with their regular account through this tool.
I have stopped my batch.
Thanks to you both for handling the problem.
Now the same with @Wiki13. How does he even manage to edit while maxlag is 7s with QS, and at this rate? Please stop it, do you not monitor maxlag? An admin should know.
It's others too. Someone must have removed QS restrictions, all hell is loose.
@SCIdude Please see Help:QuickStatements#Best_practices. It has to do with the fact we are both administrators, which has the noratelimit attached to it. This means in some cases QS will go as fast as it possibly can and sometimes at a normal pace. Unfortunately there is not a good solution for now, other than hoping for the tool maintenainer to implementing a rate limit for all QS users.
Hi there, I've relinked all 3 pages and I've given my rationale in the edit summary. Feel free to revert my change if you really disagree with the rationale. But in that case I would be really interested in understanding why you think that's the case. You can reply here if you want. Thank you. ~~~~
Yes, I disagree.
In general, disambiguation/dab page sitelinks should not be linked with non-dab page sitelinks here at Wikidata. Wikidata items are about distinguishable *concepts*, not simple interwikilink collectors where you can throw some stuff together. The concept of a family name is very different from a Wikimedia dab page, and under no circumstances they should be merged.
An issue here is that Wikipedias do not really have a concise definition how a disambiguation page should look like, and thus pages with similar content have different definitions on different Wikipedias. What matters in the end is whether there is the disambiguation flag set in the Mediawiki database for a given page—you can usually set or remove it with templates such as en:Template:Disambiguation. Since the projects have autonomy over their content, we do not try to adjust something for them in order to have simpler procedures here at Wikidata.
Please be also aware that on dab pages, non-family name content can be added at any time; however, in contrast there are usually no details about the family name itself provided. There are also quite a lot of situations where a dab page *and* a family name for the same term exist on a single Wikipedia, which does require two items as well.
If you still want to have these additional interwikilinks for similar pages (but different concepts), you need to define them locally. Either via oldschool interwikilinks in the source of the pages (quite difficult to maintain in good shape), or with templates such as :en:Template:Interwiki extra. There may be more in enwiki, but I am not very familiar with the situation over there. The idea is that the template adds oldschool interwikilinks in the background based on what it finds in a given Wikidata item; for dab page and name items, this can also probably be automated to some degree, as we have the relationship between them available as structured data here at Wikidata.
I am happy to answer follow-up questions. However, I ask you to restore the items in separated condition, as everything else violates common Wikidata procedures, and it will be torn apart again at some point anyways.
I understand your point, and I agree with most of what you say. It is also true that all 3 pages are about the same surname, and only about the surname, and if we simply unlink them from one another we're doing the reader a disservice. I feel that second-guessing the future, and doing things wrong now on the off-chance that in some hypothetical future the content of one of the articles changes is not a good enough reason to do things wrong now. Do you agree that if somebody is going to take it upon himself to make changes on wikidata that will have the effect of unlinking articles that are about the exact same subject, that person should also do his best to leave behind whatever structure needs to be in place so that the reader is not harmed by it being hidden from him that articles in other languages about the exact same subject exist? ~~~~
First of all, let me clarify that I do not simply express personal opinion here. What I have described above is project consensus, and we as the Wikidata community are in fact quite annoyed by editors coming in and merging items for the sake of "more interwikilinks" or so, although we deliberately want to keep them separated. This is usually done with good faith, but still against the wide consensus here. It happens a lot, unfortunately, and leads to significant maintenance efforts to undo the mess afterwards.
Please be aware that you are building your position on the assumption that all Wikipedia projects would prefer "more interwikilinks" in these situations over exact interwikilinks. Long before Wikidata was started, Wikipedias have already had policies which governed that interwikilinks should be added based on an exact 1:1 match. Due to the inferior technological solution, it was a real mess in practice, but Wikidata has actually not changed much about this approach—it just continues what the Wikipedias wanted and tried to achieve anyways, and makes the entire interwikilink management a lot easier and cleaner.
If you now force all interwikilinks into one Wikidata item, in order to increase interwikilinking, projects can barely decide by themselves not to take part in this scheme. It is thus much more friendly to let each project for itself decide how to deal with close, but not exact matches. As I indicated above, you can actually automate most of the local interwiki management through the use of templates if you/your projects want(s) to, potentially even implicitly with very little need for human interaction. You need to seek consensus in the local project, however.
This independence of Wikipedia communities is also the reason why I do not reach out to them in order to optimize things ("for Wikidata" as they usually perceive it).