User talk:Pasleim

Hi Pasleim, are you aware of tools that can list duplicate sitelink names, where one (maybe even both) of them are not linked to wikidata? I am most interested in zh <> zh-yue, as persons' names will likely be the same, but zh articles might not be linked to wikidata. If no, would that be technically possible?

Hi Pasleim, how can I mark false positives. For example:

Q55609407 (de:Desolate) and Q112440100 (fr:Desolate)

via Wikidata:Do not merge

Yes, of course. But it should not appear on the list forever. I want to mark it as checked.

Thank you.

I understood now.

Problem solved.

Hi Pasleim, i've noticed that the object Q65971429 is an "inverse label for property P138". Why this object isn't a property?

Thanks

communicable disease are diseases that can have self contacts to others

Hi Pasleim, I was adding death dates today with pltools:recentdeaths and noticed that it added the same date twice in Q9302070. I'm not sure why.

Hey ԱշոտՏՆՂ, Pasleim is currently inactive. All tools under pltools are legacy code that is not really being maintained currently. As long is it works, we do not touch it, but if it breaks it's going to be gone quickly (unless someone volunteers to maintain these tools).

So, if this is a singular instance of a problem, I'd say we continue to run this tool, but once users complain about this more we would need to look whether we need to deactivate it.

Hallo Pasleim, ich bin mit User:Kolja21 uneins über die Benutzung und Unterscheidung von Band-Ausgabe.

Guckst Du Dir bitte Q41640108 an, denn ich kann auch den Eintrag Deines Bots nicht nachvollziehen. Oder liegt das daran, dass Q110183503 noch in meinen Augen falsch "Ausgaben" hat. Danke und Gruß

Das ist der "fixClaims" job, dessen Jobdefinitionen unter User:DeltaBot/fixClaims/jobs einsehbar sind. P629 und P747 sind als inverse Eigenschaften definiert, deshalb sollten sie auch entsprechend in beide Richtungen genutzt werden. Der Bot ergänzt lediglich die fehlende Hälfte dieses Aussagenpaars, solange Q110183503#Q110183503$bce3784c-4462-c683-ad84-0759eb42174f existiert.

ok, das habe ich mir gedacht und synchronisiere es. Wenn ich das gleich invers richtig gemacht habe, guckst Du dann bitte nochmal drüber, ob es grundsätzlich richtig ist, denn ich sehe das 37 bändige Werk derselben 1. Auflage als Bände, Serie, besteht aus, ist Teil von, während User:Kolja21 das als Ausgaben behandeln will und das ist schon sinnvoll das richtig einheitlich zu machen. Danke

Was da fachlich korrekt ist, kann ich auf die Schnelle nicht feststellen, und deshalb möchte ich mich da auch nicht einmischen ;-) Viele Grüße!

Danke aber soweit

Are there any plans to reboot it? I really loved the functionality.

Which reports exactly are missing updates?

Sorry, I was sure I replied on the PLbot discussion page. For the "growth WDQS pages" for: melting point (P2101): growth, boiling point (P2102): growth, electric dipole moment (P2201): growth, and ionization energy (P2260): growth.

Okay I see.

The underlying templates are being updated weekly by User:DeltaBot since September, as User:PLbot has been retired and its jobs have been migrated to DeltaBot. The SPARQL queries only displayed revisions by PLbot, so DeltaBot needed to be included as well. I have done so on Module:Property documentation (diff), so there should now be data for the recent months as well.

The only difference is that the update job is not running daily anymore. It is a relatively expensive job that takes a couple of hours per execution and creates permanent load for WDQS during execution, and I figured that weekly data is likely sufficient for most users.

Hello Pasleim! I am writing about the Hungarian elements of this list. Most of the elements marked "Implausible" are very old constituencies from the 19th century, the boundaries of which are difficult to reconstruct today. these constituencies did not have a seat at the time, they were named after the largest settlements, so it also happened that the names of several premises were given, and also that the seat changed. What is listed as a seat in these elements is often just the name of the most frequently mentioned settlement, which was not an official seat. Because of the above, in many cases I have given a geographical coordinate that deliberately does not point to a settlement, but to a "neutral" area between the several settlements in question. (Eg: felső választókerület (Udvarhelyszék I.) (Q120174613), nagysomkúti választókerület (Q121071523) etc.) What are your suggestions for removing these items from the list?

First question would be if Q28 is the correct value for P:P17 in those listed items. It does not really seem to describe just the state Hungary of today, but rather the nation of Hungary over several centuries—a time period where the actual state has existed in very different versions.

Yes, this is a pretty old misunderstanding on this question, I hope I can describe it well enough.

Q28 is the element of the country that i. u. It was created in 1000 and still exists today. Within this, of course, many forms of government were in force, and it can be divided into several historical eras, and its territory was also variable, but this does not change the fact that the element Q28 fully and perfectly describes the country that we are talking about today and before. Similar, for example, to element Q142, which refers to France created in 843 and still exists today.

The electoral district whose seat was, for example, the city of Szolnok, is located in the same country as it is today (by definition, the electoral district itself has undergone several changes due to electoral laws, so it cannot be marked with the same element in 1848 and 2023)

I hope this short answer helped.

Sure, I understand the situation here.

If you want to stick with Q28 values, we have several options:

• Accept the false-positive results on the report page as is. It might bug you and some other users, but it does not harm anyone.
• Define the farthest north, west, south, east coordinates for the entire history of Hungary as boundaries. This could produce way more false-negative results, i.e. cases that the bot neither sees and reports. In some sense this could be considered harmful compared to the status quo.
• Remove Hungary altogether from this report.

What is your preference?

Maybe I just now understood why these items were included in this list (there is no description of the list, so you can only infer). My thought was that the elements were included in this list because in some cases the coordinates do not point to a specific settlement or an inhabited part of it, but to a point that is difficult to identify. Now, however, I take it from your words that the elements were included in the list because the geographical coordinate is outside the territory of today's Hungary. Do I see it well?

Kinda correct, but it is not that precise in fact.

There is basically a box around (modern) Hungary with coordinate boundaries 44° … 49° North and 15° … 23° East (as defined in this file). Every item that says Hungary (Q28) in country (P17) that has coordinates outside of that box is being reported.

Solutions are as outlined above. We can change the box limits, remove Hungary from the report, or leave it as is.

I understand and thank you. I'll think about it.

It looks like PLBot is having some sort of problem, see here: https://www.wikidata.org/w/index.php?title=Template:Property_uses&diff=prev&oldid=1970046203

This is effecting the usage history tracking of properties and the display of property coverage on Property discussion pages.

Thanks for these tools btw, they're very useful to me! :D

Thank you for your report. I will have a look at this situation within the next days. This is indeed broken for some reason.

Looks like it's fixed, thank you!

The issue was resolved here: https://phabricator.wikimedia.org/T347284.

Overall, the job is still in a wonky state and it could fail again, but for other reasons than the issue in the phab ticket. I am currently reorganizing jobs of PLbot and DeltaBot to a hopefully more stable and maintainable configuration, but until this is completed, things can fail sometimes...

Hello Pasleim. I have a question. Is your "projectmerge"-bot still active? For example the last update of User:Pasleim/projectmerge/enwiki-specieswiki was the 12th of May. PieterJanR 07:22, 10 August 2023 (UTC)

Hey PieterJanR, that task has indeed been broken. I've fixed it, and it now catches up by updating all those projectmerge reports.