[Wikidata-bugs] [Maniphest] T334352: Usage in SDC should be shown when deleting items on Wikidata
MisterSynergy added a comment. To add background to this request: we have recently had ~2400 deleted Wikidata items that were still used by SDC; many of these deletions have taken place years ago. It is super inconvenient to check whether an item is being used with SDC, thus practically no Wikidata admin includes this check in their deletion routine. This check needs to be made much much simpler. TASK DETAIL https://phabricator.wikimedia.org/T334352 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Mahir256, MisterSynergy, Ameisenigel, Aklapper, Astuthiodit_1, karapayneWMDE, Invadibot, GFontenelle_WMF, maantietaja, FRomeo_WMF, CBogen, ItamarWMDE, Nintendofan885, Akuckartz, Nandana, JKSTNK, Lahi, Gq86, E1presidente, Ramsey-WMF, Cparle, SandraF_WMF, GoranSMilovanovic, QZanden, Tramullas, Acer, LawExplorer, Salgo60, Silverfish, _jensen, rosalieper, Scott_WUaS, Susannaanas, Fuzheado, Jane023, Wikidata-bugs, Base, matthiasmullie, aude, Daniel_Mietchen, Ricordisamoa, Wesalius, Lydia_Pintscher, Raymond, Steinsplitter, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T331356: Wikidata seems to still be utilizing insecure HTTP URIs
MisterSynergy added a comment. Some remarks: - We should consider these canonical HTTP URIs to be //names// in the first place, which are unique worldwide and issued by the Wikidata project as the "owner" [1] of the wikidata.org domain. The purpose of these //names// is to identify things. - Following linked data principles, it is no coincidence that these names happen to be valid URIs. These are meant to be used to look up information about the named entity. It is okay to redirect a canonical URI to another location, including of course to a secure HTTPS location. - Pretty much every external project (i.e. outside Wikimedia) that has aligned its content with Wikidata in the past 10+ years uses these canonical HTTP URIs. While the canonical HTTP URIs are not very present within Wikidata (but still relevant e.g. in WDQS and hardcoded in plenty of tools/bots), external usage is huge—not necessarily to look information up, but primarily to express identity with names issued by others for the same entity [2]. - To my understanding, HSTS can be used to secure all but the first request of a client (that supports HSTS). - Canonical HTTP URIs are still widespread in many other linked data resources, since many projects have started issueing these before everything transitioned to HTTPS. Some projects have transitioned to canonical HTTPS URIs, however, with GND doing this in 2019 being a prominent example [3]. [1] Yeah, this is legally not super precise but it does not matter here [2] Examples: linked data for the Wikimedia Foundation at VIAF <https://viaf.org/viaf/137022054/rdf.xml> and GND <http://d-nb.info/gnd/10102830-1/about/lds>. The principle is the same everywhere else. [3] Background here: https://wiki.dnb.de/display/DINIAGKIM/HTTP+vs.+HTTPS+in+resource+identification TASK DETAIL https://phabricator.wikimedia.org/T331356 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: MisterSynergy, BCornwall, Bugreporter, Ennomeijers, Nikki, Volans, Aklapper, BBlack, Astuthiodit_1, KOfori, karapayneWMDE, joanna_borun, Invadibot, Devnull, maantietaja, Muchiri124, ItamarWMDE, Akuckartz, Legado_Shulgin, ReaperDawn, Nandana, Davinaclare77, Techguru.pc, Lahi, Gq86, GoranSMilovanovic, Hfbn0, QZanden, LawExplorer, Zppix, _jensen, rosalieper, Scott_WUaS, Wong128hk, Wikidata-bugs, aude, faidon, Mbch331, Jay8g, fgiunchedi ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T323460: WDCM update missing
MisterSynergy added a comment. In T323460#8427196 <https://phabricator.wikimedia.org/T323460#8427196>, @GoranSMilovanovic wrote: > I think we can close this ticket. Thank you. I think so as well, but leave it up to you to do so. Thank you for your efforts. TASK DETAIL https://phabricator.wikimedia.org/T323460 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: GoranSMilovanovic, MisterSynergy Cc: WMDE-leszek, Manuel, ItamarWMDE, GoranSMilovanovic, Aklapper, MisterSynergy, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T321571: Design request for new main page header image:
MisterSynergy added a comment.
In T321571#8419697 <https://phabricator.wikimedia.org/T321571#8419697>,
@Sarai-WMDE wrote:
>> - The background image ("hero") seems to scale okay-ish on desktop now,
but there is some CSS definition in the mobile skin (as much as I am aware)
which makes it scale down in a poor way on mobile. Not sure how to fix this, to
be honest.
>
> If not sure what the proper fix would be either, but strangely enough, just
disabling the `auto` height applied to the image (which I guess is enforcing
the original size and keeping the aspect ratio) seems to do the trick? I'm not
sure if the level of specificity here might be problematic, but I don't see any
other images affected by this change.
>
> F35817281: Nov-24-2022 12-00-53.gif
<https://phabricator.wikimedia.org/F35817281>
Yeah, I got this far as well, but I do not know how I can overwrite this
behavior. I can add a height attribute to the image in question, but I cannot
figure out which value it has to have. The problematic definition `.content a >
img { height: auto !important; }` seems to come from the Minerva skin which I
cannot modify.
>> - The light gray background is now `#f8f9fae6` as suggested, but is looks
pretty pale on my display. I personally would make it a bit darker.
>
> It's of course quite light in comparison to the previous version. Do you
think the legibility of the content is compromised? (e.g. poor contrast,
overlapping with image elements on the background). I like how we're now using
the same color applied to the main navigation menu (just with some opacity to
avoid disrupting the image): makes the page look quite balanced. But this is,
of course, quite subjective.
Legibility is fine, it's just … a very pale and partially transparent (as
intended) tone. The contrast to the background is barely there, but it
shouldn't really contrast the background anyways. Not sure how it looks on
cheap or poorly calibrated displays.
Anyways, perhaps it's simply the unfamiliar look which bothers me. This was
really not meant to be a real issue for debate here :-)
>> - The `16px margin` on desktop are defined in `.mw-body-content` as much
as I am aware. Since this looks like a skin definition, I have left it as is on
both desktop and mobile.
>
> If we fix the height of the image on mobile, this might stop being an
issue. The main problem at the moment is that the headerbox "touches" the page
header. There should be some spacing between the elements.
>
> Applying a rough margin bottom to the banner-container div in Minerva
creates the right spacing:
>
> F35817332: Screenshot 2022-11-24 at 12.38.42.png
<https://phabricator.wikimedia.org/F35817332>
Okay I begin to really understand the problem. I always used the mobile main
page while being logged in, with the very unpopular "Welcome, username!"
message between the search bar and the hero image. Then there is indeed no
problem.
However, when browsing the main page while not logged in, it does look wrong
indeed. I have thus added a 16px top margin to the main page hero image
container for logged-out users of the Minerva skin only.
>> Btw. I am not aware of any design guidelines. Is such a document available
somewhere?
>
> VERY long story short: The Wikimedia design system (Codex) – to some degree
based on the Wikimedia Design Style Guide
<https://design.wikimedia.org/style-guide/visual-style.html> – is in the making
by MWF (I'm a contributor to their team). All new styles (encoded as design
tokens) are available on the Codex Demo site
<https://doc.wikimedia.org/codex/latest/design-tokens/overview.html>. The
missing font styles will be published soon and are for now documented in Figma
<https://www.figma.com/file/mRvSsFD2Kwh8AZNjlx7rIl/%E2%9C%A8-Design-Tokens-%5BWIP%5D?node-id=1%3A3484=1Uw0pgJxHkCUqn74-1>.
Thanks, interesting. Will keep an eye on it!
TASK DETAIL
https://phabricator.wikimedia.org/T321571
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Sarai-WMDE, MisterSynergy
Cc: Mohammed_Sadat_WMDE, MisterSynergy, Sarai-WMDE, Lydia_Pintscher,
Arian_Bozorg, Aklapper, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja,
ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden,
LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T321571: Design request for new main page header image:
MisterSynergy added a comment.
Thank you for the advice. I have tried to implement as much as my
capabilities allow; I am not a frontend dev, thus please verify :-)
What's missing:
- The background image ("hero") seems to scale okay-ish on desktop now, but
there is some CSS definition in the mobile skin (as much as I am aware) which
makes it scale down in a poor way on mobile. Not sure how to fix this, to be
honest.
- The "want to help translate?" stuff is now inside the overlay; changing the
text is not that simple, since it is defined in a translatable template
<https://www.wikidata.org/wiki/Template:Help_translate_messages> and all
translations would need to be updated as well. Let's leave it as is for now.
- The light gray background is now `#f8f9fae6` as suggested, but is looks
pretty pale on my display. I personally would make it a bit darker.
- The `16px margin` on desktop are defined in `.mw-body-content` as much as I
am aware. Since this looks like a skin definition, I have left it as is on both
desktop and mobile.
Btw. I am not aware of any design guidelines. Is such a document available
somewhere?
TASK DETAIL
https://phabricator.wikimedia.org/T321571
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Sarai-WMDE, MisterSynergy
Cc: Mohammed_Sadat_WMDE, MisterSynergy, Sarai-WMDE, Lydia_Pintscher,
Arian_Bozorg, Aklapper, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja,
ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden,
LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T323460: WDCM update missing
MisterSynergy created this task. MisterSynergy added a project: Wikidata. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION WDCM data <https://analytics.wikimedia.org/published/datasets/wmde-analytics-engineering/wdcm/etl/> has been last updated on 2022-11-08, i.e. 12 days from now. As much as I am aware, it should run weekly and I ask for an update. TASK DETAIL https://phabricator.wikimedia.org/T323460 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: GoranSMilovanovic, Aklapper, MisterSynergy, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T278962: Allow redirects and the target article as independent sitelinks if redirect badge is used
MisterSynergy added a comment. I have already proposed a bot task that would deal with exactly such cases here: Wikidata:Requests for permissions/Bot/MsynBot 10 <https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/MsynBot_10>. TASK DETAIL https://phabricator.wikimedia.org/T278962 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Manuel, MisterSynergy Cc: Fralambert, Michael, William_Cheselden, Manuel, karapayneWMDE, CennoxX, Tagishsimon, Pokechu22, ExE-Boss, Ameisenigel, amy_rc, Mohammed_Sadat_WMDE, Bugreporter, Lea_Lacroix_WMDE, Taylor, Lucas_Werkmeister_WMDE, Addshore, MSGJ, Simon_Villeneuve, ChristianKl, Eugene, seav, kaldari, Naseweis520, Fuzheado, ItamarWMDE, Ladsgroup, DemonDays64, DannyS712, JAnD, Hsarrazin, deryckchan, agray, MisterSynergy, Liuxinyu970226, Delasse, Jheald, Aklapper, Lydia_Pintscher, Astuthiodit_1, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T321571: Design request for new main page header image:
MisterSynergy added a comment. Thanks for looking into this. Some more context: We have had several requests such as this one <https://www.wikidata.org/w/index.php?title=Wikidata_talk:Main_Page=1716381538#Layout_of_the_%E2%80%9CWelcome_message%E2%80%9D_on_the_gray_background> in August. As you can see on the screenshot, the gray box was cut off at the lower end (I was able to verify this on several of my own devices as well). Problem was that the gray overlay was using "position:absolute" within the top box that used "position:relative"; in that case, child elements do not define the height of parent elements any more and the observed behavior was to be expected. It just seems that nobody has considered small/mobile devices when designing the main page years ago. I have meanwhile changed the top box to using the much more modern css grid technique in order to fix the broken display. The background image, however, does not really scale well as it is not high enough. An additional problem is that the current background image has a CC-by-sa license, so we need to link to the file page at Commons in order to properly re-use it. The new image should have be in public domain or CC0 or so that does not require any attribution (and thus no link). TASK DETAIL https://phabricator.wikimedia.org/T321571 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Sarai-WMDE, MisterSynergy Cc: MisterSynergy, Sarai-WMDE, Lydia_Pintscher, Arian_Bozorg, Aklapper, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T143486: In some cases, moving or deleting pages on a client wiki does not result in sitelink updates / removal on Wikidata.
MisterSynergy added a comment. Another status update: I have now migrated this job from PAWS to Toolforge (`msynbot` tool account) . Due to memory restrictions on Toolforge, I had to rewrite much of the code unfortunately. The memory-intensive operation is no longer done with Python/pandas; instead I use a temporary tool database so that the operations runs on database servers that are not subject to k8s memory limits. After several test runs, I am confident that there is no memory issue to be expected in the foreseeable future even with the largest wikis. There is now a weekly k8s-cronjob that should keep the backlog short. I am also continueing to log edits done by the bot so that I can provide some insight into the situations that lead to inexistent sitelinks on item pages if necessary. TASK DETAIL https://phabricator.wikimedia.org/T143486 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Manuel, MisterSynergy, Mike_Peel, Bencemac, ARR8, abian, Nikki, matej_suchanek, Lydia_Pintscher, NicoScribe, Ladsgroup, PokestarFan, ArthurPSmith, Liuxinyu970226, Izno, hoo, Aklapper, Esc3300, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T315693: Inflated counts in site statistics
MisterSynergy added a comment. Can we please also quickly reset the counters to actual values? The item count on the Wikidata main page is fed from this table, and since it is a matter of 1-3 days that we hit 100.000.000 items (which we actually don't), there are quite some eyes on this counter these days. We do not want to claim this milestone prematurely. TASK DETAIL https://phabricator.wikimedia.org/T315693 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Ladsgroup, MisterSynergy Cc: MisterSynergy, Ladsgroup, Aklapper, agray, Hellket777, LisafBia6531, Astuthiodit_1, 786, Biggs657, karapayneWMDE, Invadibot, Devnull, LSobanski, maantietaja, Juan90264, Alter-paule, Beast1978, ItamarWMDE, Un1tY, Akuckartz, Hook696, Iflorez, Kent7301, joker88john, CucyNoiD, Nandana, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, QZanden, Marostegui, LawExplorer, Lewizho99, Minhnv-2809, Maathavan, _jensen, rosalieper, Neuronton, Scott_WUaS, Wikidata-bugs, aude, Mbch331, Jay8g, Krenair ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T278962: Allow redirects and the target article as independent sitelinks if redirect badge is used
MisterSynergy added a comment. In order to keep things simple, I'd like to mention that the community will anyways operate a (daily?) bot that manages these badges: - Add "sitelink to redirect" badge where it is missing - Remove "sitelink to redirect" badge and "intentional sitelink to redirect" badge from sitelinks to non-redirects Pages on client wikis can be turned into redirects (and vice versa) without any changes to Wikidata, so we need to keep updating these anyways. There is no way to keep this synced just with sitelink editing constraints on Wikidata. With this in mind, I think we could be kinda lenient with user edits and allow them to make changes that might require a subsequent edit by the bot. TASK DETAIL https://phabricator.wikimedia.org/T278962 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Fralambert, Michael, William_Cheselden, Manuel, karapayneWMDE, Dexxor, CennoxX, Tagishsimon, Pokechu22, ExE-Boss, Ameisenigel, amy_rc, Mohammed_Sadat_WMDE, Bugreporter, Lea_Lacroix_WMDE, Taylor, Lucas_Werkmeister_WMDE, Addshore, MSGJ, Simon_Villeneuve, ChristianKl, Eugene, seav, kaldari, Naseweis520, Fuzheado, ItamarWMDE, Ladsgroup, DemonDays64, DannyS712, JAnD, Hsarrazin, deryckchan, agray, MisterSynergy, Liuxinyu970226, Delasse, Jheald, Aklapper, Lydia_Pintscher, Astuthiodit_1, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T143486: In some cases, moving or deleting pages on a client wiki does not result in sitelink updates / removal on Wikidata.
MisterSynergy added a comment. Status update: the backlog of sitelinks to inexistent pages is cleared, except for: - Sitelinks to wikis that have been closed (their status is undetermined anyways; number of cases is unknown) - Sitelinks to Special pages, which appear as inexistent in some contexts but actually exist (these should not happen per guidelines, but there are ~1000 of such sitelinks currently in Wikidata) - Sitelinks to User pages where the user has a genered namespace prefix on the client wiki; these pages appear as inexistent in some scenarios as well; ~10 cases) I do not plan to touch these at the moment. Besides that, I was able to clear the backlog with a custom script, except for ~75 really obscure cases which needed manual intervention. This means that my bot script is able to deal with almost everything that has shown up in the past. The statistics provided by me on July 12 above in this task is still valid. The main culprit to my experience are rate-limit issues when pages are deleted on the client wiki at a high rate (admin bot, Special:Nuke, i.e. not ratelimited) so that the sitelink removal on Wikidata cannot keep up. Since almost everything can be fixed automatically, I do not see an urgent need to change anything in the software. TASK DETAIL https://phabricator.wikimedia.org/T143486 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Manuel, MisterSynergy, Mike_Peel, Bencemac, ARR8, abian, Nikki, matej_suchanek, Lydia_Pintscher, NicoScribe, Ladsgroup, PokestarFan, ArthurPSmith, Liuxinyu970226, Izno, hoo, Aklapper, Esc3300, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T143486: In some cases, moving or deleting pages on a client wiki does not result in sitelink updates / removal on Wikidata.
MisterSynergy added a comment. Status update: In the past days, I have removed deleted sitelinks for the "easy" cases where the reason is relatively obivous. This has reduced the number of open cases from ~60k to ~6k (i.e. 90% reduction). Findings: - Around 6k cases resulted from "move without redirect" scenarios on client wikis. This is much less than what I anticipated earlier, yet still a substantial amount. - Around 40k cases resulted from scenarios where the user batch-deleted plenty of pages on the client wiki at a high rate, either by using Special:Nuke or a custom deletion bot script. Since admins on client wikis usually enjoy noratelimit priviledges on the client wiki but not on Wikidata, this causes ratelimit issues when removing the sitelinks from Wikidata items. Since this is by far the most important reason why a deleted page might remain as a sitelink on the Wikidata item, it might be valuable to consider optimizations for this scenario. - Another 8k "deleted sitelinks" where not actually deleted, but their namespaces where renamed (on srwikinews and lmowiki only). I have simply updated the sitelinks so that this is not an issue any longer. There are more such cases waiting for a fix within the remaining 6k cases. Within the next days, I will have a look at the remaining "deleted sitelinks" in order to fix them as well. I will also set up a bot task that executes regularly, in order to keep the backlog short. TASK DETAIL https://phabricator.wikimedia.org/T143486 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Manuel, MisterSynergy, Mike_Peel, Bencemac, ARR8, abian, Nikki, matej_suchanek, Lydia_Pintscher, NicoScribe, Ladsgroup, PokestarFan, ArthurPSmith, Liuxinyu970226, Izno, hoo, Aklapper, Esc3300, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T143486: In some cases, moving or deleting pages on a client wiki does not result in sitelink updates / removal on Wikidata.
MisterSynergy added a comment. I don't think "User:Hoo bot" has much influence here as this bot has not edited Wikidata since 2016-10. While many cases are a couple of years old, they are not *that* old in fact. As much as I am aware, nobody has taken care of this for a long time now (but I am determined to do so…) TASK DETAIL https://phabricator.wikimedia.org/T143486 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Manuel, MisterSynergy, Mike_Peel, Bencemac, ARR8, abian, Nikki, matej_suchanek, Lydia_Pintscher, NicoScribe, Ladsgroup, PokestarFan, ArthurPSmith, Liuxinyu970226, Izno, hoo, Aklapper, Esc3300, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T143486: In some cases, moving or deleting pages on a client wiki does not result in sitelink updates / removal on Wikidata.
MisterSynergy added a comment. @Manuel: I have looked into this again. As of now, I have this list of potential reasons for sitelink update failures: 1. Sitelink configuration-related reasons 1. A page on the client is "moved without a redirect" to another namespace that is forbidden (?) at Wikidata (such as a page move from main namespace to "User" or "Draft" namespace, e.g. when the page is not fit for the main namespace). 2. A redirect page on the client is "moved without a redirect". Redirect sitelinks are not permitted, thus the sitelink cannot be updated. 2. User-based reasons 1. The user performing a sitelink change on a client does not have a local account at Wikidata 2. The user performing a sitelink change on a client is not permitted to edit Wikidata due to a block 3. The user performing a sitelink change on a client exceeds their rate-limit at Wikidata (seems rather unlikely) 3. Page-based reasons 1. The item page is protected to a level that the user performing a sitelink change on a client is not allowed to edit it 4. Wikidata edit capacities limited 1. Wikidata editing was generally rate-limited when the client sitelink had been changed (e.g. due to high maxlag), and the user made several sitelink changes in a short time (this might be the case with some bots) 2. Wikidata was read-only when the client sitelink had been changed 5. Project configuration-related reasons 1. There are a couple of cases where a namespace has been renamed on client Wikis, but the sitelinks to that namespace have not been updated on Wikidata. There seem to be auto-redirects in place, but technically the old titles do not exist any more Currently I see roughly 60.000 sitelinks that do not exist as a page on the client. My impression is that 1A is the major and dominant contributor here, and maybe 4A to some extent as well. I will soon start to repair 1A cases including some logging for future investigations. If the backlog is shorter, I think it should become easier to learn something about the other scenarios as well. TASK DETAIL https://phabricator.wikimedia.org/T143486 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Manuel, MisterSynergy, Mike_Peel, Bencemac, ARR8, abian, Nikki, matej_suchanek, Lydia_Pintscher, NicoScribe, Ladsgroup, PokestarFan, ArthurPSmith, Liuxinyu970226, Izno, hoo, Aklapper, Esc3300, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T143486: In some cases, moving or deleting pages on a client wiki does not result in sitelink updates / removal on Wikidata.
MisterSynergy added a comment. @Manuel: - I got a bot task approved that allows me to tidy these sitelinks up regularly (i.e. remove from the item if the page is inexistent on the client wiki). This itself can be considered a "dirty" solution to the problem, but clearly not the best one. - However, it has not been executed yet due to a lack of time for Wikidata on my side in recent months. - AFAIR, the main issue currently is that the evaluation workflow is kinda demanding regarding memory usage. During drafting the code on PAWS with its 3 GB memory limit, I offloaded parts of the evaluation for larger wikis to my local machine which has sufficient memory available. For a fully automated deployment on Toolforge, this is of course not possible. Instead, there may even be stricter memory limits applying on Toolforge than on PAWS. - Why does it need so much memory? My approach queries "all pages per client wiki" (from the client's `page` table) and "all sitelinks in Wikidata" (from Wikidata's `wb_items_per_site` table) into separate Pandas DataFrames and subsequently looks for differences using Python. In other words: I avoid checking millions of cases individually by sitelink, and use a pretty quick per-client-wiki approach instead that requires me to hold all information for a given client wiki in memory. So, the code itself is pretty much ready-to-roll, but I need to find a place to run this fully automated. If you are interested, I can try to generate an updated list of cases for further inspection but it would be helpful to really understand your needs. Do you want to further evaluate this? TASK DETAIL https://phabricator.wikimedia.org/T143486 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Manuel, MisterSynergy, Mike_Peel, Bencemac, ARR8, abian, Nikki, matej_suchanek, Lydia_Pintscher, NicoScribe, Ladsgroup, PokestarFan, ArthurPSmith, Liuxinyu970226, Izno, hoo, Aklapper, Esc3300, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T278962: Allow redirects and the target article as independent sitelinks if redirect badge is used
MisterSynergy added a comment. In T278962#7929755 <https://phabricator.wikimedia.org/T278962#7929755>, @Taylor wrote: > But storing it at WikiData requires to re-run the single bot and reinspect all pages on all wikis regularly. It's not that complicated. Using the existing SQL databases and the WDQS query endpoint, one can manage this efficiently—in particular with only one or two queries per project. A couple of minutes runtime per day would be sufficient to keep this synced with little delay for all client wikis. TASK DETAIL https://phabricator.wikimedia.org/T278962 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Manuel, karapayneWMDE, Dexxor, CennoxX, Tagishsimon, William_Cheselden, Pokechu22, ExE-Boss, Ameisenigel, amy_rc, Mohammed_Sadat_WMDE, Bugreporter, Lea_Lacroix_WMDE, Taylor, Lucas_Werkmeister_WMDE, Addshore, Jakob_WMDE, MSGJ, Simon_Villeneuve, ChristianKl, Eugene, seav, kaldari, Naseweis520, Fuzheado, ItamarWMDE, Ladsgroup, DemonDays64, DannyS712, JAnD, Hsarrazin, deryckchan, agray, MisterSynergy, Liuxinyu970226, Delasse, Jheald, Aklapper, Lydia_Pintscher, Astuthiodit_1, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T143486: [feature request] remove sitelinks / update sitelinks on Wikidata when pages are deleted/moved on client wikis (all users)
MisterSynergy added a comment. I came across some of these cases and thought the situation could require some tidying, so I wrote a script which lists sitelinks to inexistent client wiki pages in order to process them. Some patterns that I notice after closely looking at dewiki, ptwiki, and cawiki: - There are several hundred such cases for each of these three wikis; cawiki is even clearly above 2000 cases. These sitelinks to inexistent pages are still there in Wikidata, but I plan to remove them soon. - Both "User does not exist at Wikidata" and "User is blocked at Wikidata" are super rare scenarios that might not even be worth to worry about. In almost all cases, neither of these is the case. - The clear majority of cases are the result of "move without leaving a redirect behind" actions on client wikis; deletions make up for a much smaller number. - Two patterns that happens surprisingly often: - A user performs "move without leaving a redirect behind" on a redirect page on a client wiki. I suppose the corresponding action on Wikidata fails because redirects are not allowed as sitelinks. - A user performs "move without leaving a redirect behind" on a client wiki and the page is moved to another namespace. Is it intentional that the corresponding action on Wikidata fails, or does it happen by accident? In some cases, it would indeed be better to remove the sitelink rather than updating it, e.g. when a page is moved from main to user namespace in the client wiki. There are still plenty of cases which cannot be explained in any of these ways. Maybe "Wikidata is read-only" at the moment of the edit can also lead to missed sitelink updates. TASK DETAIL https://phabricator.wikimedia.org/T143486 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: MisterSynergy, Mike_Peel, Bencemac, ARR8, abian, Nikki, matej_suchanek, Lydia_Pintscher, NicoScribe, Ladsgroup, PokestarFan, ArthurPSmith, Liuxinyu970226, Izno, hoo, Aklapper, Esc3300, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T297513: Wikidata does not allow search for deleted items
MisterSynergy added a comment. In T297513#7564527 <https://phabricator.wikimedia.org/T297513#7564527>, @Lydia_Pintscher wrote: > This sounds useful indeed. Is this something that can be done as an external tool? Not sure whether this is a good idea. Access to deleted content is restricted to admins, but a tool would make a lot of it available to everyone. Does WMF allow this? TASK DETAIL https://phabricator.wikimedia.org/T297513 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: MisterSynergy, Lydia_Pintscher, SilentSpike, Mahir256, Lymantria, Aklapper, Bovlb, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T295275: Dedicated section on Wikidata Item and Property pages for classifying Properties
MisterSynergy added a comment. Good to see this problem being addressed. Some remarks: - As much as I am aware, we do not fail the classification job completely. It's the P279 <https://phabricator.wikimedia.org/P279>/subclass-of hierarchy which some refer to as the "Wikidata ontology" that is problematic, because it is generic in topic, global in reach, and does not closely resemble any other ontology from elsewhere so that we cannot stricly build this on sources. I suggest to limit modifications to P279 <https://phabricator.wikimedia.org/P279> claims. - Main reasons for the poor P279 <https://phabricator.wikimedia.org/P279> ontology, from daily Wikidata editing experience over several years: - Requires high level of knowledge and experience. We leave editors pretty much alone to learn the necessary skills. - Poor tooling; simple edits in the P279 <https://phabricator.wikimedia.org/P279> hierarchy can have severe adverse effects that are difficult to project even for experienced users. - Lack of awareness; editors often modify P279 <https://phabricator.wikimedia.org/P279> claims to fix something else, such as e.g. a constraint violation in another item (it would be better to fix the item, leave the constraint violation there for others to fix it, or sometimes to fix the constraint definition). - Also: often there is not a clear "correct" or "incorrect" approach when classifying data items, and some situations are arguably not easy to resolve. This needs more community discussion and probably also an explicit definition of the term "Wikidata ontology", its purposes, and its design principles. - In general, I think we should rather restrict the ability to add, modify, or remove P279 <https://phabricator.wikimedia.org/P279> main values by introducing a new user group "ontologist" (or so). This would be similar to "property creator", which is another user group based on technical skills and experience in a certain field. The community could then elect or assign the right to interested, qualified users. My only concern is that this might not scale well. TASK DETAIL https://phabricator.wikimedia.org/T295275 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Tagishsimon, PKM, Naseweis520, ArthurPSmith, Streetmathematician, Csisc, Ayack, Tpt, MisterSynergy, TomT0m, Salgo60, Mohammed_Sadat_WMDE, Lucas_Werkmeister_WMDE, Manuel, Aklapper, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T226885: Set up an open-source bot in Toolforge to regularly semi-protect the most used Wikidata Items
MisterSynergy added a comment. In T226885#7196677 <https://phabricator.wikimedia.org/T226885#7196677>, @Lydia_Pintscher wrote: > I think this is now being done regularly by @MisterSynergy, correct? Yes, with User:MsynABot. - The task is scheduled to be run autonomously once a week on Toolforge. Works fine so far since roughly March this year. - Details about the job and the source code can be found on the bot's user page in Wikidata. The source code might appear in some (external?) repository eventually. - There are still some minor things to be improved, but I am monitoring it and there is effectively not much effort required any longer for me as the bot operator. TASK DETAIL https://phabricator.wikimedia.org/T226885 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Lydia_Pintscher, MisterSynergy, Nintendofan885, abian, Aklapper, Invadibot, Devnull, maantietaja, Akuckartz, Nandana, skpuneethumar, Zylc, 1978Gage2001, Lahi, Operator873, Gq86, Bsandipan, GoranSMilovanovic, DSquirrelGM, Jayprakash12345, Chicocvenancio, QZanden, Tbscho, LawExplorer, JJMC89, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, Jitrixis, aude, Gryllida, scfc, Mbch331, Krenair ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T284850: Wikidata Concepts Monitor: usage numbers have shrunk considerably within a week
MisterSynergy added a comment. In T284850#7158957 <https://phabricator.wikimedia.org/T284850#7158957>, @GoranSMilovanovic wrote: > @MisterSynergy Could you please check the wdcm_topItems.csv <https://analytics.wikimedia.org/published/datasets/wmde-analytics-engineering/wdcm/etl/wdcm_topItems.csv> dataset now and let me know if it looks alright? Yes, it looks pretty much as previously right now, so I'm happy with it. TASK DETAIL https://phabricator.wikimedia.org/T284850 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: GoranSMilovanovic, MisterSynergy Cc: Manuel, RhinosF1, GoranSMilovanovic, Tobi_WMDE_SW, Lydia_Pintscher, Aklapper, MisterSynergy, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T284850: Wikidata Concepts Monitor: usage numbers have shrunk considerably within a week
MisterSynergy added a comment. In T284850#7152920 <https://phabricator.wikimedia.org/T284850#7152920>, @GoranSMilovanovic wrote: > @MisterSynergy > > Please share the previous version of `wdcm_topItems.csv` here. I am on it. Highest priority. Thank you for catching this. I don't have any previous versions available, just the current one. The Python bot script saves a local copy of the current toplist.csv file by overwriting the previous old revision and loads it then to a pandas DataFrame which is subsequently being evaluated. Pretty straigtforward and in fact rather simple; notably, nothing went wrong in the latest run, or has changed since the previous successful run. TASK DETAIL https://phabricator.wikimedia.org/T284850 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: GoranSMilovanovic, MisterSynergy Cc: RhinosF1, GoranSMilovanovic, Tobi_WMDE_SW, Lydia_Pintscher, Aklapper, MisterSynergy, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T284850: Wikidata Concepts Monitor: usage numbers have shrunk considerably within a week
MisterSynergy created this task. MisterSynergy added projects: Wikidata, WMDE-Analytics-Engineering. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION My adminbot protects "highly used item pages" in Wikidata per policy <https://www.wikidata.org/wiki/Wikidata:Page_protection_policy#Highly_used_items>, based on input from https://analytics.wikimedia.org/published/datasets/wmde-analytics-engineering/wdcm/etl/wdcm_topItems.csv. During the past update of that report (2021-06-07, 18:55), usage numbers have shrunk considerably so that the number of items with usage numbers greater than 500 have decreased from ~29867 to ~18896 within a week (-37%). Safety measures in my bot code prevented the bot from removing ~11.000 existing page protections for now. Is this some sort of a bug that led to an incomplete report, or has something been changed in the way how "item usage" is being determined? TASK DETAIL https://phabricator.wikimedia.org/T284850 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Aklapper, MisterSynergy, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T44362: skipped item IDs
MisterSynergy added a comment. Continuation of the table above (numbers taken from the revision history of https://www.wikidata.org/wiki/User:MisterSynergy/itemstats): | **Week ending ...** | **Total skipped items** | **weekly increase** | | 27 February 2021| 8542979 | | | 6 March 2021| 8550632 | +7653 | | 13 March 2021 | 8596041 | +45409 | | 20 March 2021 | 8630017 | +33976 | | 27 March 2021 | 8652766 | +22749 | | 3 April 2021| 8666101 | +13335 | | 10 April 2021 | 8679152 | +13051 | | 17 April 2021 | 8688972 | +9820 | | 24 April 2021 | 8704612 | +15640 | | 1 May 2021 | 8714560 | +9948 | | 7 May 2021 | 8724841 | +10281 | | 15 May 2021 | 8735465 | +10624 | | Looks fine to me. Maybe something happened during two weeks in March, but not excessively so that we would need to worry. TASK DETAIL https://phabricator.wikimedia.org/T44362 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Lucas_Werkmeister_WMDE, Addshore, MisterSynergy, Lea_Lacroix_WMDE, Bugreporter, StudiesWorld, ChongDae, Wikidata-bugs, jeblad, Legoktm, Nemo_bis, Merl, Lydia_Pintscher, jeremyb, Stryn, daniel, Invadibot, maantietaja, Akuckartz, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, aude, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T279829: Enable magic word SHORTDESC on German-language Wikipedia
MisterSynergy added a comment. @DannyH and others: German Wikipedia uses "flagged revisions" on all pages; changes are only being displayed to readers if they have been flagged/reviewed by an experienced editor. How would SHORTDESC interact with flagged revisions? Would it respect the review status so that it only displays short descriptions from flagged/reviewed revisions, or would always the short description from the latest revision be used in apps, mobile skins, and search regardless of a pending flagging process? TASK DETAIL https://phabricator.wikimedia.org/T279829 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Luke081515, MisterSynergy Cc: MisterSynergy, Carn, Schniggendiller, Urbanecm, Majavah, FriedhelmW, Ghilt, DannyH, Bugreporter, Count_Count, RhinosF1, Aklapper, XanonymusX, Zabe, Invadibot, LaMagiaaa, Lalamarie69, maantietaja, Alter-paule, Beast1978, Un1tY, Akuckartz, Hook696, CptViraj, Kent7301, Dibya, joker88john, 94rain, DannyS712, CucyNoiD, Nandana, Tks4Fish, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, Jayprakash12345, QZanden, Kizule, LawExplorer, Lewizho99, Maathavan, DatGuy, Devwaker, Niklitov, _jensen, rosalieper, JEumerus, Scott_WUaS, Ananthsubray, Superzerocool, Tulsi_Bhagat, Wong128hk, Luke081515, SimmeD, Wikidata-bugs, Snowolf, Base, aude, Dcljr, Addshore, Matanya, Mbch331, Jay8g, Krenair ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T281063: Wikidata Concepts Monitor: some datasets are empty
MisterSynergy added a comment. In T281063#7047547 <https://phabricator.wikimedia.org/T281063#7047547>, @GoranSMilovanovic wrote: > @MisterSynergy > > The WDCM system update should be in place now. > > Please let me know if the datasets <https://wikidata-analytics.wmcloud.org/app_direct/WikidataAnalytics/datasets.html> that you need are now complete. > > I apologize for any inconvenience. Please take into your consideration that we are operating Data Analytics in an extremely complex environment here: many things can go wrong for many different reasons - all of which depend on someone of a different (and probably unique) expertise. Thank you. Thanks, I have already seen it this night. My protection bot will run again next night and process the newest output of the topItems.csv file. In some sense I have been anticipating a situation like this, which is why my protection bot does not do anything in case it realized that something went wrong. Side notes: - your wikidata-analytics.wmcloud.org seems to be down currently, but I am accessing the topItems.csv file directly anyways - somewhat later I will likely report some minor problems with the topItems.csv file that I observe since I started to use it roughly two months ago; nothing serious to worry about, though TASK DETAIL https://phabricator.wikimedia.org/T281063 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: GoranSMilovanovic, MisterSynergy Cc: elukey, WMDE-leszek, GoranSMilovanovic, Manuel, Aklapper, MisterSynergy, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T281063: Wikidata Concepts Monitor: some datasets are empty
MisterSynergy created this task. MisterSynergy added a project: Wikidata. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION Some of the datasets provided via https://wikidata-analytics.wmcloud.org/app_direct/WikidataAnalytics/datasets.html seem to be empty since an update a couple of days ago. I am particularly looking at https://analytics.wikimedia.org/published/datasets/wmde-analytics-engineering/wdcm/etl/wdcm_topItems.csv, which I use to protect "highly used items" in Wikidata using a bot. Based on the raw file list at https://analytics.wikimedia.org/published/datasets/wmde-analytics-engineering/wdcm/etl/, I think there may be some other files affected by this as well (wdcm_category.csv, wdcm_project.csv, wdcm_project_category_item100.csv, and wdcm_topItems.csv). Proposed solution: - re-run the script for fresh datasets - ensure that it won't put empty datasets there in the future again TASK DETAIL https://phabricator.wikimedia.org/T281063 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Aklapper, MisterSynergy, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T279829: Enable magic word SHORTDESC on German-language Wikipedia
MisterSynergy added a comment. In T279829#7028342 <https://phabricator.wikimedia.org/T279829#7028342>, @XanonymusX wrote: > Yeah, as I proposed, we should choose a different path for that issue; I will specify my proposal very soon (was thinking about 90% of the 2.13 mln), and we will always offer the option of not getting rid of WD descriptions at all. Yes, but I am highly disappointing that the inappropriate 850k number is on the table now. It signals that WMF apparently does not care much about the lost descriptions and how they effectively improve their products (apps, skins, search, etc). It also might make it easy for hardliners to force us dumping Wikidata descriptions at an unreasonably early stage. TASK DETAIL https://phabricator.wikimedia.org/T279829 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: MisterSynergy, Carn, Schniggendiller, Urbanecm, Majavah, FriedhelmW, Ghilt, DannyH, Bugreporter, Count_Count, RhinosF1, Aklapper, XanonymusX, Zabe, Invadibot, LaMagiaaa, maantietaja, Akuckartz, CptViraj, Dibya, 94rain, DannyS712, Nandana, Tks4Fish, Lahi, Gq86, GoranSMilovanovic, Jayprakash12345, QZanden, Kizule, LawExplorer, DatGuy, Devwaker, Niklitov, _jensen, rosalieper, JEumerus, Scott_WUaS, Ananthsubray, Superzerocool, Tulsi_Bhagat, Wong128hk, Luke081515, SimmeD, Wikidata-bugs, Snowolf, Base, aude, Dcljr, Addshore, Matanya, Mbch331, Jay8g, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T279829: Enable magic word SHORTDESC on German-language Wikipedia
MisterSynergy added a comment. The German Wikipedia community has not yet even discussed whether Wikidata descriptions should be dumped completely, or which milestone would be appropriate. Some remarks: - In case this gets approved, there is a plan to add short descriptions from [[de:Vorlage:Personendaten]], which actually has systematic "short descriptions" for all biographies in German Wikipedia that would immediately qualify for use in SHORTDESC as well. With 870.000 transclusions, it alone would be sufficient to pass the 850.000 requirement, leaving all non-biographies without descriptions. - A couple of days ago, I queried the situation a bit. There were 2,56 million German Wikipedia articles (main namespace, no redirects), of which 2,13 million (83%) use a German description from Wikidata. This is considerably more than what we had three years ago for English Wikipedia. You propose to ignore 1,3 million existing descriptions from Wikidata. This is way too much, particularly considering that quite some editors have invested considerable time into adding Wikidata descriptions due to the way they have been used and exposed to readers in the past six years or so. It is also unclear at this point whether there is a desire to dump Wikidata descriptions entirely that is as strong as it was in English Wikipedia three years ago. TASK DETAIL https://phabricator.wikimedia.org/T279829 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: MisterSynergy, Carn, Schniggendiller, Urbanecm, Majavah, FriedhelmW, Ghilt, DannyH, Bugreporter, Count_Count, RhinosF1, Aklapper, XanonymusX, Zabe, Invadibot, LaMagiaaa, maantietaja, Akuckartz, CptViraj, Dibya, 94rain, DannyS712, Nandana, Tks4Fish, Lahi, Gq86, GoranSMilovanovic, Jayprakash12345, QZanden, Kizule, LawExplorer, DatGuy, Devwaker, Niklitov, _jensen, rosalieper, JEumerus, Scott_WUaS, Ananthsubray, Superzerocool, Tulsi_Bhagat, Wong128hk, Luke081515, SimmeD, Wikidata-bugs, Snowolf, Base, aude, Dcljr, Addshore, Matanya, Mbch331, Jay8g, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T278693: Manually purge obsolete/outdated entites from WDQS (2021-03)
MisterSynergy added a comment. I read the announcement and I am pretty excited about the improvements. The query-preview servers do not seem to have the problem that I have reported here, but I am not sure right now whether you have reloaded the entities there as well. Until now I have not used query-preview except for some tests, but I will have a closer look in the next time. The production query service seems fine again, at least with respect to the reported entities. We can close this ticket from my opinion. TASK DETAIL https://phabricator.wikimedia.org/T278693 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: dcausse, Aklapper, MisterSynergy, Invadibot, MPhamWMF, maantietaja, CBogen, Akuckartz, Nandana, Namenlos314, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T278693: Manually purge obsolete/outdated entites from WDQS (2021-03)
MisterSynergy created this task. MisterSynergy added projects: Wikidata-Query-Service, Wikidata. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION Similarly as in T239338 <https://phabricator.wikimedia.org/T239338>, I hereby request manually purging the following ~2000 entities on the Wikidata Query Service. They are either already deleted (but still available on WDQS), or redirects (which WDQS does not recognize), or outdated on WDQS: - Q10003038, Q10003550, Q100144553, Q10024637, Q100260420, Q100267082, Q100280201, Q100323422, Q10034173, Q100429023, Q100429053, Q100447507, Q100479984, Q10049041, Q10055417, Q100563033, Q100563959, Q100563963, Q100564301, Q100564308, Q100564317, Q100564328, Q100564346, Q100564946, Q100564950, Q100564953, Q100564987, Q100565127, Q100565142, Q100565499, Q100565503, Q100565508, Q100565823, Q100565831, Q100565839, Q100565919, Q100565925, Q100565932, Q100568466, Q100568588, Q100568597, Q100568602, Q100568609, Q100568613, Q100568717, Q100568785, Q100568791, Q100568802, Q100568803, Q100568839, Q100568845, Q100568883, Q100568893, Q100569160, Q100569164, Q100569169, Q100569239, Q100569259, Q100569350, Q100569352, Q100569356, Q100569408, Q100569413, Q100569418, Q100569432, Q100569524, Q100569562, Q100569568, Q100569621, Q100569717, Q100569730, Q100570029, Q100570044, Q100570084, Q100570140, Q100570145, Q100570165, Q100570201, Q100570314, Q100570319, Q100570329, Q100570335, Q100570348, Q100570364, Q100570399, Q100570453, Q100570557, Q100570572, Q100570600, Q100570616, Q100570737, Q100570743, Q100570748, Q100570755, Q10060016, Q10065436, Q100699595, Q100772713, Q10078693, Q100885427, Q10089612, Q100936828, Q100936895, Q100943922, Q100944023, Q100953368, Q100956346, Q100983441, Q100983959, Q101002260, Q101007397, Q101016321, Q101016333, Q101016917, Q101016918, Q101016924, Q101016943, Q101103330, Q101103338, Q10110773, Q101500214, Q101528128, Q10157435, Q10158182, Q101602068, Q10163690, Q10167411, Q101858245, Q101873793, Q10205638, Q102075833, Q102112815, Q102115480, Q102124515, Q102237118, Q102252429, Q102262426, Q102265709, Q102278211, Q102279052, Q102280104, Q102280938, Q102281844, Q102296427, Q102313158, Q102321145, Q102324896, Q102334054, Q102343997, Q102362031, Q102362723, Q102367789, Q102394571, Q102415030, Q102439000, Q102446523, Q102449225, Q102536861, Q102548672, Q102549618, Q102582065, Q10262211, Q102678169, Q102715729, Q102723274, Q102857682, Q102857724, Q102858070, Q102913676, Q102989555, Q103017576, Q10308373, Q103207113, Q103511238, Q10376723, Q103804859, Q103819110, Q103820157, Q103827447, Q10383872, Q103839063, Q103927826, Q103941130, Q104031414, Q104036099, Q104036118, Q104036560, Q104036562, Q104036809, Q104052481, Q104052617, Q104054028, Q104059805, Q104093127, Q104095875, Q104097196, Q104097432, Q104153194, Q104214863, Q104226046, Q104298727, Q104299309, Q104305636, Q104355777, Q104381244, Q104393142, Q104393722, Q104417606, Q104424289, Q104425205, Q104433304, Q104472115, Q104502935, Q104522264, Q104537158, Q104537464, Q104582257, Q104605834, Q104627033, Q104629041, Q104633909, Q104666312, Q104668119, Q104704297, Q104717478, Q104724689, Q104729094, Q104736318, Q104761224, Q104766538, Q104771717, Q104773413, Q104773561, Q104778034, Q104779102, Q104780653, Q104787631, Q104789170, Q104799226, Q104813475, Q104816463, Q104823365, Q104839757, Q104842457, Q104858127, Q104858129, Q104858360, Q104861514, Q104872944, Q104875837, Q104875838, Q104880179, Q104880653, Q104889604, Q105006908, Q105234213, Q105351873, Q105517743, Q105525632, Q105525728, Q105528813, Q105530813, Q105531514, Q105546049, Q105546580, Q105546724, Q105546909, Q105547592, Q105550911, Q105552960, Q105553110, Q105553940, Q105565231, Q105566236, Q105575941, Q105576108, Q105576517, Q105579906, Q105579930, Q105579953, Q105581066, Q105582279, Q105582461, Q105584361, Q105587874, Q105594360, Q105594629, Q105597066, Q105607388, Q105613630, Q105616267, Q105617103, Q105618758, Q105620060, Q105620992, Q105623923, Q105623956, Q105625251, Q105626290, Q105626409, Q105626433, Q105626773, Q105626783, Q105626848, Q105627247, Q105627391, Q105627870, Q105633769, Q105636014, Q105637101, Q105637163, Q105643901, Q105648695, Q105649328, Q105652140, Q105653321, Q105656121, Q10540, Q105670715, Q105672632, Q105675238, Q105682892, Q105687151, Q105687323, Q105687906, Q105691076, Q105693106, Q105694579, Q105695117, Q105695259, Q105699369, Q105699612, Q105701269, Q105702226, Q105702227, Q105706098, Q105707332, Q105711974, Q105712311, Q105713753, Q105715673, Q105715836, Q105716215, Q105716222, Q105719244, Q105719333, Q105719335, Q105719735, Q105720097, Q105721083, Q105722377, Q105723226, Q105724505, Q105724783, Q105724823, Q105726001, Q105726258, Q105726360, Q105727275, Q105727479, Q105727591, Q105728310, Q105728764, Q105730314, Q105732026, Q105737259, Q105737352, Q105742439, Q105743967, Q105744013, Q105744021, Q105744375, Q105
[Wikidata-bugs] [Maniphest] T276613: Changes in protection levels on Wikidata appear on Wikipedia watchlists
MisterSynergy added a comment. The bot job is on hold for a couple of days to see where this goes. If this ticket gets stalled, I will continue as this is strictly seen not a problem with my bot or its job. Aside from that, some observations: - I do see these protection log entries on my English Wikipedia watchlist, but not on my German Wikipedia watchlist (same watchlist settings in my preferences as much as I am aware, same protected Wikidata item+connected articles that happen to be on both of my watchlists). - My bot does have a botflag on Wikidata and the protection log entries are being marked as "bot edit", but this does apparently not propagate through to my English Wikipedia watchlist where I cannot filter these log entries away with the "Human (not bot)" watchlist filter. This is different from regular bot edits at Wikidata whose bot marker does propagate to the English Wikipedia watchlist and makes those edits filter-able. I have to mention that we have barely used the "page protection" functionality at Wikidata (~10k protection actions since 2012, around 50% of them in two automated efforts; in other words: the organic page protection rate at Wikidata is at ~2/day or so). This has clearly never been an issue that has annoyed anyone. My bot task is going to protect another 20k+ items, and there will subsequently be weekly update runs for a couple of hundred new cases that qualify for protection. I can imagine that this could now continuously annoy some folks. TASK DETAIL https://phabricator.wikimedia.org/T276613 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: MSGJ, Aklapper, Mike_Peel, MisterSynergy, OTichonova, caldera, maantietaja, NavinRizwi, Akuckartz, DannyS712, Nandana, kostajh, Jony, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Iniquity, _jensen, rosalieper, Taiwania_Justo, Scott_WUaS, abian, Wikidata-bugs, aude, Mbch331, Ltrlg ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T44362: skipped item IDs
MisterSynergy added a comment. | **Week ending ...** | **Total skipped items** | **weekly increase** | | 5 December 2020 | 8303905 | +1256459 | | 12 December 2020| 8351248 | +47343 | | 19 December 2020| 8380252 | +29004 | | 26 December 2020| 8420623 | +40371 | | 2 January 2021 | 8431286 | +10663 | | 9 January 2021 | 8459454 | +28168 | | 16 January 2021 | 8473979 | +14525 | | 23 January 2021 | 8487360 | +13381 | | 30 January 2021 | 8505173 | +17813 | | 6 February 2021 | 8514746 | +9573 | | 13 February 2021| 8524740 | +9994 | | 20 February 2021| 8535448 | +10708 | | 27 February 2021| 8542979 | +7531 | | This does not look overly concerning to me in the past weeks, and I do not see excessive streaks of skipped QIDs either. I have no further insight as to why these Q-IDs are being skipped, but I could provide lists with skipped QIDs if this helps. TASK DETAIL https://phabricator.wikimedia.org/T44362 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Lucas_Werkmeister_WMDE, Addshore, MisterSynergy, Lea_Lacroix_WMDE, Bugreporter, StudiesWorld, ChongDae, Wikidata-bugs, jeblad, Legoktm, Nemo_bis, Merl, Lydia_Pintscher, jeremyb, Stryn, daniel, Akuckartz, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, abian, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T268625: [20h] Investigate the significant number of skipped Item IDs for newly created Wikidata items
MisterSynergy added a comment. More: only 77 items have been created in the past 30 days using Relator (per recentchanges table), 67 of them by User:Animalparty [1]. This user also created some items related to "Edwin M. Post" recently [2][3][4]. The other Relator users are User:Ayack (5 creations on Dec 21/22 and Jan 05), User:Miraclepine (1 creation on Dec 23), User:Andrew_Gray (1 creation on Jan 10), and User:Ldhank (3 creations on Jan 13). I think the tool is to be blamed here, but maybe you might want to interview them to understand their workflow and ask for suspicious tool behavior that they might have experienced. [1] https://www.wikidata.org/w/index.php?target=Animalparty=all==1===100=Special%3AContributions [2] https://www.wikidata.org/wiki/Q104636500 [3] https://www.wikidata.org/wiki/Q104647694 [4] https://www.wikidata.org/wiki/Q104650032 TASK DETAIL https://phabricator.wikimedia.org/T268625 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucas_Werkmeister_WMDE, MisterSynergy Cc: MisterSynergy, Tonina_Zhelyazkova_WMDE, Addshore, Pablo-WMDE, Lucas_Werkmeister_WMDE, Lydia_Pintscher, WMDE-leszek, Aklapper, Alter-paule, Beast1978, Un1tY, Akuckartz, Hook696, Iflorez, Kent7301, alaa_wmde, joker88john, CucyNoiD, Nandana, Gaboe420, lucamauri, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T268625: [20h] Investigate the significant number of skipped Item IDs for newly created Wikidata items
MisterSynergy added a comment. Re. "Maggie Rogers": the request does not create an item since the input is not formatted correctly. If I throw this exact input to the API using pywikibot's editentity function [1], I get this error message: "WARNING: API error not-recognized-language: The supplied language code was not recognized." No idea whether this wastes a QID. The second item "Edwin M. Post" interestingly mentions "wikidata-todo". This is one of the Magnus tools which sometimes creates plenty of empty items without the user realizing it. We had a couple of incidents in the past months where something of the order of 1000 completely empty items had to be deleted that had been accidentally created by the some tool; IIRC, it was a very old QuickStatements version that is still online. Relator [2] is something else, but it apparently uses parts of the same code in the background. [1] https://public.paws.wmcloud.org/User:MisterSynergy/tmp/SkippedQIDs_testing.ipynb [2] https://wikidata-todo.toolforge.org/relator/#/ TASK DETAIL https://phabricator.wikimedia.org/T268625 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucas_Werkmeister_WMDE, MisterSynergy Cc: MisterSynergy, Tonina_Zhelyazkova_WMDE, Addshore, Pablo-WMDE, Lucas_Werkmeister_WMDE, Lydia_Pintscher, WMDE-leszek, Aklapper, Alter-paule, Beast1978, Un1tY, Akuckartz, Hook696, Iflorez, Kent7301, alaa_wmde, joker88john, CucyNoiD, Nandana, Gaboe420, lucamauri, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T268625: [20h] Investigate the significant number of skipped Item IDs for newly created Wikidata items
MisterSynergy added a comment. @Lucas_Werkmeister_WMDE: We have not seen excessive phases of QID skipping since the week ending December 5. We skip around 10k–50k QIDs per week since then which seems pretty "normal". However, some regions in the QID space are still only sparsely populated. In the week ending last Saturday January 9, 2021, 1:42 AM UTC, for instance, we managed to put only 55 items between Q104646000 and Q104647000. In other words: that range is only 5.5% populated. I think it would be worth to check what was going on there. TASK DETAIL https://phabricator.wikimedia.org/T268625 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucas_Werkmeister_WMDE, MisterSynergy Cc: MisterSynergy, Tonina_Zhelyazkova_WMDE, Addshore, Pablo-WMDE, Lucas_Werkmeister_WMDE, Lydia_Pintscher, WMDE-leszek, Aklapper, Alter-paule, Beast1978, Un1tY, Akuckartz, Hook696, Iflorez, Kent7301, alaa_wmde, joker88john, CucyNoiD, Nandana, Gaboe420, lucamauri, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T44362: skipped item IDs
MisterSynergy added a comment. New numbers from the past week, in order to keep the momentum here: Between 28 Nov 1:42 AM and 5 Dec 1:42 AM, around 1.250.000 QIDs have been skipped and around 175.000 new items have been created. The skip ratio on average over the entire week was ~87.5%. Related activity started on Nov 29, around noon, and ended on Dec 3 in the evening. The skip rate during that time was constantly somewhere between 3 and 4 QIDs per second. If anyone is interested, I would upload plots similar as previously here. TASK DETAIL https://phabricator.wikimedia.org/T44362 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Lucas_Werkmeister_WMDE, Addshore, MisterSynergy, Lea_Lacroix_WMDE, Bugreporter, StudiesWorld, ChongDae, Wikidata-bugs, jeblad, Legoktm, Nemo_bis, Merl, Lydia_Pintscher, jeremyb, Stryn, daniel, Akuckartz, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T268625: Investigate the significant number of skipped Item IDs for newly created Wikidata items
MisterSynergy added a comment. Following my report in T44362#6638174 <https://phabricator.wikimedia.org/T44362#6638174>, I looked into this a little more. From Wikidata's mediawiki database, I queried page creation times for the items created during the reported time period (14 Nov, 1:42 to 21 Nov, 1:42) and quickly plotted Q-ID vs. item creation timestamp. On the upper panel of the attached figure, you can see that there are two phases where the curve increases rapidly; a finer evaluation yields steep increases from 2020-11-14, 11:54 through 2020-11-16, 20:23, and another shorter period from 2020-11-18, 20:24 through 2020-11-18, 23:53. I also plotted the item creation rate (in 10 min bins) on the lower panel. F33924179: new_items_nov2020.png <https://phabricator.wikimedia.org/F33924179> We can also compare the Grafana charts on the Wikidata edits <https://grafana.wikimedia.org/d/00170/wikidata-edits?orgId=1=160531812=160592292> dashboard. Particularly during the first and longer period, there have been phases where not a single user has been editing at the rate limit (90/min). My findings are: - Skipped Q-IDs are not temporarily equally distributed over the one week period. It is reasonable to assume that someone triggers this with some sort of requests, and these requests are not coming in all the time. - The item creation rate (lower panel) looks perfectly sane, including during times when the curve on the upper panel increases quickly. This means that most of the Q-IDs are skipped during the steeper sections of the upper panel graph. - The two steep phases in the upper panel together comprise around 215.000 seconds. Considering we have lost ~450.000 Q-IDs mostly during that time period, it is reasonable to assume that Q-IDs are skipped/wasted at a rate of roughly 2/sec during these phases. This is above the rate limit (1.5/sec), but since no edits at all seem to go through, I think that the rate limit is likely not the cause for this problem. TASK DETAIL https://phabricator.wikimedia.org/T268625 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: MisterSynergy, Tonina_Zhelyazkova_WMDE, Addshore, Pablo-WMDE, Lucas_Werkmeister_WMDE, Lydia_Pintscher, WMDE-leszek, Aklapper, Akuckartz, Iflorez, alaa_wmde, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T44362: skipped item IDs
MisterSynergy added a comment. Reminder that this is still a thing: I maintain a weekly updated page that is tracking the number of skipped item IDs (among other things) at https://www.wikidata.org/wiki/User:MisterSynergy/itemstats. During the past week (diff <https://www.wikidata.org/w/index.php?title=User:MisterSynergy/sysop/pagedeleted_stats=78475153=1309905410=1306285530>), the QID counter was increased by 586.750 from Q101579998 to Q102166748. However, 450.082 (76.7%) were skipped QIDs, and only around 130.000 QIDs are actual new items. This means that more than three out of four QIDs were skipped over the period of the past week; it also means that we have increased the number of skipped QIDs by almost 7% within only one week to more than 7 million meanwhile. I know that we do not run out of QIDs and this seems not actually a very serious issue, but in some sense a densly packed QID space still seems desirable. I thus suggest to start another investigation how this can happen and eventually be mitigated. TASK DETAIL https://phabricator.wikimedia.org/T44362 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: MisterSynergy, Lea_Lacroix_WMDE, Bugreporter, StudiesWorld, ChongDae, Wikidata-bugs, jeblad, Legoktm, Nemo_bis, Merl, Lydia_Pintscher, jeremyb, Stryn, daniel, Akuckartz, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T261275: incorrect sitelink deletion behavior when page is moved to excluded (unsupported) namespace with "suppress redirect" option
MisterSynergy added a comment. In T261275#6616930 <https://phabricator.wikimedia.org/T261275#6616930>, @Lydia_Pintscher wrote: > | | **page is moved to an non-excluded namespace**| **page is moved to an excluded namespace** | > | **suppress redirect is checked** | sitelink on the Item is updated to the new target | sitelink is removed from the Item | > | **suppress redirect is not checked** | sitelink on the Item is updated to the new target | sitelink is untouched | > | > > But now I'm questioning myself on the bottom right cell. I agree with all four. Bottom right is indeed the complicated one; therein, the untouched sitelink is now a redirect and it points to a target that might not be very useful content-wise (as the page would not have been moved otherwise). Yet, I think the software should reliably manage that only **existing pages** are connected, not necessarily only **useful pages**. Once redirects are being permitted as regular sitelinks (without that ugly hack), we could also look into ways to add the already available redirect badges to those sitelinks. This would make the outcome much more managable for the community which then could decide whether the remaining redirect sitelink is actually useful, and not just existing. TASK DETAIL https://phabricator.wikimedia.org/T261275 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: MisterSynergy, Mike_Peel, noarave, ChristianKl, Mohammed_Sadat_WMDE, Aklapper, Lydia_Pintscher, Akuckartz, Iflorez, alaa_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T263730: Wikidata term store contains rows for deleted items
MisterSynergy added a comment. In T263730#6490727 <https://phabricator.wikimedia.org/T263730#6490727>, @Lucas_Werkmeister_WMDE wrote: > In other words, potentially affected is any item that was edited on 10 September between 11:06 and 15:58 (UTC) and then deleted before 7 October 13:27, if I’m not mistaken. MariaDB [wikidatawiki_p]> SELECT DISTINCT wbit_item_id, log_title, log_timestamp FROM wbt_item_terms JOIN logging ON wbit_item_id=SUBSTRING(log_title, 2) WHERE log_type='delete' AND log_action='delete' AND log_namespace=0 AND log_title NOT IN (SELECT page_title FROM page WHERE page_namespace=0) ORDER BY log_timestamp ASC; +--+---++ | wbit_item_id | log_title | log_timestamp | +--+---++ | 1798871 | Q1798871 | 20190908075346 | | 67206532 | Q67206532 | 20190910183620 | | 67206284 | Q67206284 | 20190910183629 | | 67205707 | Q67205707 | 20190910183639 | | 67205787 | Q67205787 | 20190910183649 | | 67205329 | Q67205329 | 20190910183659 | | 16376239 | Q16376239 | 20190910183709 | | 12865809 | Q12865809 | 20190910183719 | | 25667640 | Q25667640 | 20190910183731 | | 25667272 | Q25667272 | 20190910183740 | | 25664811 | Q25664811 | 20190910183750 | | 3546228 | Q3546228 | 20190910183800 | | 65175512 | Q65175512 | 20190910183810 | | 65051610 | Q65051610 | 20190910183820 | | 67205948 | Q67205948 | 20190910183830 | | 9307721 | Q9307721 | 20190910183840 | ... (skip plenty of rows here) ... | 30686328 | Q30686328 | 20191103185910 | | 25333226 | Q25333226 | 20191103194317 | | 8877061 | Q8877061 | 20191103194339 | | 60975079 | Q60975079 | 20191103194433 | | 8443133 | Q8443133 | 20191103194539 | | 70013783 | Q70013783 | 20191107163208 | | 74670014 | Q74670014 | 20191113061939 | | 74065265 | Q74065265 | 20191115121708 | | 74672773 | Q74672773 | 20191125085852 | | 74688761 | Q74688761 | 20191125090312 | | 74693264 | Q74693264 | 20191125090707 | | 74670082 | Q74670082 | 20191125093548 | | 74669422 | Q74669422 | 20191125093827 | | 74668425 | Q74668425 | 20191125185307 | | 74674299 | Q74674299 | 20191125234049 | | 74691179 | Q74691179 | 20191126080348 | | 74483053 | Q74483053 | 20191126101239 | | 74675327 | Q74675327 | 20191127111732 | | 74453398 | Q74453398 | 20191205123011 | | 74613482 | Q74613482 | 20191206010632 | | 74692551 | Q74692551 | 20191223084428 | | 87589401 | Q87589401 | 20200313152209 | +--+---++ 9594 rows in set (17 min 42.76 sec) Except for one entry, the problem starts indeed on the afternoon of 2019-10-09 (item deletion timestamp). However, there are plenty of entries until ~2019-11-03 in the evening (deletion time), and only 17 entries from a later deletion time. TASK DETAIL https://phabricator.wikimedia.org/T263730 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: MisterSynergy, Addshore, Aklapper, Lucas_Werkmeister_WMDE, Akuckartz, darthmon_wmde, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T259541: Can't see references in deleted revisions of items on Wikidata (again)
MisterSynergy created this task. MisterSynergy added a project: Wikidata. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION Steps to Reproduce: - Have admin rights at Wikidata - Open a revision of a deleted item in the Web UI (e.g. via a link like https://www.wikidata.org/w/index.php?title=Special:Undelete=Qxxx=MMDDHHMMSS ) Actual Results: - Interface says e.g. "1 reference" for a given claim, but the reference is not shown and there is no link to open it (unlike for regular items); I thus cannot review the content of references of a deleted item—I can only see that there are references. Expected Results: - Same as for regular items: there should be a clickable link to open the reference The issue had existed in the past per T196423 <https://phabricator.wikimedia.org/T196423>; no idea since when it is broken again. TASK DETAIL https://phabricator.wikimedia.org/T259541 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Aklapper, MisterSynergy, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T258354: create new rate-limited bot group for Wikidata
MisterSynergy added a comment. Regarding the proposed solution: - "flooders" should be treated the same as bots - I would like to see a way to limit all other unlimited users' edit rates as well (sysops, apparently global rollbackers, ...). When I use my sysop account with QuickStatements and run a single batch, it can easily go up to 400 or 500 edits per minute and there is no possibility for me to slow down. Not fair for all users without such elevated rights. It needs a thorough assessment which functionality categorically needs to be unlimited (mass message, nuke?, ...). Potential users of these functionality should be able to temporarily add no-ratelimit to their accounts *for the purpose of using these functions only*, and should remove it thereafter. TASK DETAIL https://phabricator.wikimedia.org/T258354 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Mohammed_Sadat_WMDE, Dipsacus_fullonum, Bugreporter, MisterSynergy, Lea_Lacroix_WMDE, Aklapper, Lydia_Pintscher, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T258354: create new rate-limited bot group for Wikidata
MisterSynergy added a comment. In T258354#6317978 <https://phabricator.wikimedia.org/T258354#6317978>, @Bugreporter wrote: > Before this we should: > > - Find all bots that edits more than 90/minute > - Communiate to them I am already monitoring user edit rates occasionally with a custom Python script <https://bitbucket.org/MisterSynergy/misc/src/master/wikidata_edit_rates.py> that reads the Wikimedia RC stream, and I have contacted several bot operators regarding their edit rates when I saw excessively high values. I wasn't particularly successful, I have to admit. Unfortunately the situation with maxlag>5 for considerable fractions of a day due to the WDQS bottleneck has brought us to a situation where there is sort of a competition for as many editing resources as possible among bot operators. As long as there is neither a policy enforcing a limit nor a hard technical limit, the greediest operator will simply win this competition. There are already quite some bot operators who challenge the Wikidata bot policy by editing up to maxlag=6 or even 7, as they probably think that nobody will notice. We also have to remember that exact throttling to a targeted edit rate is not simple at all. Some tools such as QuickStatements do not allow to control the edit rate at all and they just hammer as many edits as possible to the servers, particularly for users that are not rate limited; quite some bot operators simply use a framework such as Pywikibot and might not be overly proficient when it comes to throttling (although pywikibot in particular does not create that many issues I think); and finally, it is quite difficult to monitor the own edit rate at all, and to realize that one causes issues. I'm afraid I have to say that I do not see a chance for a fair distribution of our limited edit resources among users and bot operators as long as we do not have a hard technical edit rate limit. TASK DETAIL https://phabricator.wikimedia.org/T258354 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Mohammed_Sadat_WMDE, Dipsacus_fullonum, Bugreporter, MisterSynergy, Lea_Lacroix_WMDE, Aklapper, Lydia_Pintscher, Akuckartz, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T206392: Redesign rank icons for better visibility
MisterSynergy added a comment. @Lydia_Pintscher: Can we please push this a little more? According to this Grafana chart <https://grafana.wikimedia.org/d/00175/wikidata-datamodel-statements?panelId=8=1=155994480=1591653599000>, use of preferred+deprecated rank together went up significantly during the past year from ~720,000 claims (June 2019) to ~15,000,000 claims (June 2020). My personal impression is that use of ranks are much more often discussed controversially in recent months, as many users for instance prefer to remove deprecated claims as the deprecation is barely recognizable for many users. I think when many users make problematic editorial decisions due to a poor UI, it is about time to fix it. TASK DETAIL https://phabricator.wikimedia.org/T206392 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: MisterSynergy, Tkarcher, Kristbaum, Lydia_Pintscher, MichaelSchoenitzer, Aklapper, cristiana023, JanJaquemot, Demian, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, JGirault, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T229100: Links for feedback on protected Wikidata entities
MisterSynergy added a comment. If an editor cannot edit an entity due to a page protection, I think it would be the best to just replace all the "edit" links (in terms box, all statement boxes, sitelinks box) on the protected entity page with something useful, such as a link to an appropriate page, or a tooltip explaining the situation and indicating options for the editor. Currently those "edit" links are just missing if one is not allowed to edit the page which massively breaks the usual workflow and makes it difficult to figure our what options one still has. We currently have a "Protection indicators" gadget available that adds a lock icon on protected pages near the upper right corner of the viewport. I have it activated, but I barely take notice of these icons. Thus, I think there is no optimal place where a link should go, except for the places of the "edit" links that one usually expects to see on an unprotected page. Mind that the mockup in the task description above already shows how this could (roughly) look like. TASK DETAIL https://phabricator.wikimedia.org/T229100 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Sjoerddebruin, Multichill, Lydia_Pintscher, MisterSynergy, abian, Aklapper, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T242164: Retract revdel'ed Wikidata edits from Wikibase client watchlists
MisterSynergy created this task. MisterSynergy added projects: Wikidata, MediaWiki-extensions-WikibaseClient. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION Steps to Reproduce: - a user adds non-public identifying information about a subject to its Wikidata item - the edit is correctly being dispatched by the software to connected Wikibase clients immediately thereafter and appears on watchlists - an admin (or oversighter) revdels information from the edit in Wikidata (in particular "edit summary" or "revision text", in order to remove the non-public identifying information from Wikidata) Actual Results: - the edit continues to appear on Wikibase client watchlists after admin-revdel; the displayed text includes the revdel'ed content and there is no possibility to remove it from there Expected Results: - edits that were revdel'ed by admins or oversighters in Wikidata should no longer appear in Wikibase clients, no matter which part of the information of the edit was revdel'ed TASK DETAIL https://phabricator.wikimedia.org/T242164 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Aklapper, MisterSynergy, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T240316: Issue with QuickStatements "you are blocked on Wikidata"
MisterSynergy added a comment. Just want to mention that not all users are affected: https://www.wikidata.org/wiki/Special:RecentChanges?tagfilter=OAuth+CID%3A+1351=500=30=1=2 I was just able to load and execute a batch with the "new" QS tool in a newly loaded tab (I have sysop rights at Wikidata). User:Mahir256 can edit as well (another Wikidata sysop), and User:Alicia_Fagerving_(WMSE) (not a sysop) can also edit with QS. TASK DETAIL https://phabricator.wikimedia.org/T240316 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: MisterSynergy, Ladsgroup, Tohaomg, Bouzinac, Fnielsen, Jklamo, Jane023, Daniel_Mietchen, darthmon_wmde, WMDE-leszek, Magnus, Lydia_Pintscher, Lea_Lacroix_WMDE, Aklapper, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T239338: Manually purge obsolete entites from WDQS
MisterSynergy created this task. MisterSynergy added a project: Wikidata-Query-Service. Restricted Application added a subscriber: Aklapper. Restricted Application added a project: Wikidata. TASK DESCRIPTION As T237502 <https://phabricator.wikimedia.org/T237502> seems to be already stalled and the dev team is busy troubleshooting other WDQS problems, I'd like to request a manually triggered re-load of a list of Wikidata entites that have been deleted or redirected during the past months, but this was not done on WDQS. User:Smalyshev_(WMF) has done this several times in the past for me, roughly every couple of months. These entities are affected: - Deleted items that still reside on WDQS: Q9488709, Q17053133, Q22866888, Q6677897, Q25809019, Q66500406, Q4434305, Q1860304, Q6653678, Q8957508, Q25982427, Q25856828, Q22745333, Q6706183, Q25775982, Q25950985, Q25770821, Q6569418, Q25983031, Q22706445, Q24944042, Q25805639, Q7137, Q20701921, Q852302, Q6660013, Q25982568, Q6595635, Q26071898, Q26077705, Q26066838, Q25982466, Q22864486, Q26146984, Q7126, Q22874663, Q25968791, Q25977873, Q26169435, Q4763312, Q20065303, Q22834013, Q22833570, Q22864113, Q22847133, Q5962291, Q12053633, Q25897939, Q22873482, Q7654988, Q26174966, Q25879571, Q22864495, Q25806309, Q22846633, Q22839665, Q7654961, Q64759959, Q24938622, Q25773857, Q6575212, Q6812464, Q10537055, Q13277330, Q26003049, Q18480793, Q6652799, Q20755639, Q8263645, Q8850361, Q22711951, Q22745231, Q660, Q25812272, Q25955305, Q18476092, Q32124523, Q22878761, Q25982731, Q22708838, Q18129218, Q22849095, Q25806506, Q17099595, Q7120, Q26139757, Q22743556, Q22864544, Q4433803, Q6816333, Q13305595, Q25728537, Q26170531, Q6655902, Q19773826, Q25806029, Q25982408, Q22855059, Q7768087, Q15910857, Q20701409, Q20351654, Q4433802, Q22881364, Q25852615, Q4433789, Q6569420, Q26174622, Q22864529, Q8568485, Q6716462, Q7122, Q25773393, Q22743251, Q6653674, Q18481634, Q6656020, Q3745411, Q6640180, Q18480546, Q25982478, Q25982473, Q14447839, Q25810824, Q6619727, Q7121, Q17509725, Q25982334, Q26177522, Q22830582, Q22736822, Q22864549, Q22861615, Q6604473, Q4433793, Q22705140, Q25982442, Q25779929, Q8424121, Q27999403, Q4433790, Q25983236, Q66058184, Q22864593, Q739279, Q20364075, Q22877585, Q25982491, Q6656015, Q25983192, Q17986329, Q25978111, Q22873193, Q17444826, Q25340579, Q20327184, Q25954234, Q4433791, Q22846707, Q7654990, Q25810888, Q18128257, Q8387993, Q25855862, Q20158210, Q6716460, Q8809373, Q7654968, Q7655011, Q20047872, Q25770135, Q6816099, Q20701948, Q22864625, Q22714830, Q3833699, Q25990269, Q13751987, Q32759246, Q7138, Q22815887, Q66372254, Q22849222, Q22773429, Q25774794, Q22092252, Q20346743, Q25776676, Q26266949, Q25810415, Q22840362, Q25808234, Q25982406, Q22883616, Q18127071, Q44370922, Q22864658, Q25982344, Q6655832, Q7128, Q22708820, Q6573636, Q7116, Q6716463, Q6656018, Q6812233, Q25813629, Q8871852, Q25983148, Q22711495, Q66789304, Q18480655, Q6598243, Q32760444, Q25778106, Q66084766, Q25982456, Q22864670, Q6655831, Q18354650, Q22869981, Q7768084, Q26174615, Q6573002, Q22841314, Q25808809, Q59315405, Q22838289, Q22864648, Q8853676, Q7768088, Q18479570, Q4433788, Q8686740, Q4436754, Q6816340, Q25983150, Q22707194, Q22866397, Q26178438, Q31888351, Q8599905, Q25982395, Q22716259, Q20065302, Q25982360, Q20693337, Q18480559, Q22864613, Q26174620, Q22879047, Q25983068, Q26087063, Q22741867, Q22846832, Q26174915, Q18476438, Q25982461, Q25946656, Q20701402, Q25808502, Q26174611, Q22764833, Q22760280, Q22879056, Q7682112, Q7409230, Q25982362, Q20338515, Q22707183, Q22858550, Q33280334, Q3603056, Q25904144, Q4435851, Q26063838, Q20165915, Q6659718, Q6653676, Q22864603, Q25976458, Q22867618, Q6619825, Q22899112, Q66058182, Q25982340, Q20160117, Q20048971, Q25982398, Q22831042, Q22705649, Q2206292, Q22834661, Q25982514, Q25355641, Q49834454, Q22864511, Q25776522, Q20695143, Q20701937, Q6655411, Q22876086, Q22853812, Q13363111, Q25982351, Q22864522, Q3250790, Q22864566, Q6934762, Q25982369, Q26132219, Q17022145, Q6655829, Q3248945, Q25952732, Q22864860, Q66789462, Q22839654, Q6629376, Q20336981, Q6655833, Q26144599, Q56373893, Q2164830, Q76576923, Q65216698, Q12906192, Q76482129, Q65161037, Q67934127, Q69523205, Q65281132, Q65214809, Q65318428, Q12194106, Q67934365, Q61079619, Q25389125, Q65053938, Q75839926, Q12211369, Q65165414, Q60690919, Q76384841, Q55731234, Q25436883, Q73417963, Q20569235, Q30082265, Q63121573, Q69523190, Q65194701, Q12221765, Q54092604, Q3731421, Q8041502, Q18210498, Q74820417, Q65160564, Q73287897, Q60695802, Q16914014, Q56402768, Q69523187, Q68201689, Q12224800, Q65154415, Q20421337, Q65214346, Q24943555, Q32705680, Q55730555, Q57071945, Q63122442, Q55705641, Q72948922, Q20944292, Q56374511, Q18995379, Q61358618, Q57071835, Q75840487, Q65294020, Q65160276, Q61177076, Q68283787, Q76395468, Q68201698, Q32707356, Q63122731, Q1577, Q12
[Wikidata-bugs] [Maniphest] [Commented On] T237502: Provide public "reload entity to WDQS" API
MisterSynergy added a comment. In T237502#5639342 <https://phabricator.wikimedia.org/T237502#5639342>, @Addshore wrote: > But as said above right now this is something that needs to happen on every single query service server. If I understand correctly, the mentioned wikitechwiki page describes how this can be automated for all servers with one command. No idea how robust this is. On the other hand, as "reload entity to WDQS" is basically done after each Wikidata edit, it might be worth to have a look how it is being done for regular edits. Those need to be distributed to all servers as well. TASK DETAIL https://phabricator.wikimedia.org/T237502 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Addshore, Bugreporter, Aklapper, MisterSynergy, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T237502: Provide public "reload entity to WDQS" API
MisterSynergy added a comment. There is also https://wikitech.wikimedia.org/wiki/Wikidata_query_service#Manually_updating_entities with a description about that shell script. I used to ask Stas every couple of months in the past, in order to use that shell script for a couple of hundred items each time. IMO it does not make sense to waste technician time for such requests, and I would be willing to trigger the reloading by myself it I could. TASK DETAIL https://phabricator.wikimedia.org/T237502 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Bugreporter, Aklapper, MisterSynergy, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T237502: Provide public "reload entity to WDQS" API
MisterSynergy created this task.
MisterSynergy added projects: Wikidata, Wikidata-Query-Service.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
Wikibase edits are usually automatically dispatched to WDQS, but for some
reason the system occasionally misses a few onwiki changes. As a Wikidata user
it is difficult to solve this problem, as we cannot do "null-edits" to Wikidata
items.
I suggest to provide a public (MediaWiki?) API that takes entities as input
("Qxxx", "Pyyy", or "Lzzz"), and then pipes them to the internal "load entity
to WDQS" script or function that is used to dispatch edits to WDQS anyways.
This should also work for deleted entities which are sometimes not being
deleted on WDQS.
TASK DETAIL
https://phabricator.wikimedia.org/T237502
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: MisterSynergy
Cc: Aklapper, MisterSynergy, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86,
Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst,
LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll,
Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T237499: Sitelink tables corrupted after merge of items
MisterSynergy added a subscriber: Lydia_Pintscher. MisterSynergy added a comment. @Lydia_Pintscher: because you asked for this phab topic at https://www.wikidata.org/w/index.php?title=Wikidata:Contact_the_development_team=1045986007=1045871780 TASK DETAIL https://phabricator.wikimedia.org/T237499 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Lydia_Pintscher, Aklapper, MisterSynergy, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T237499: Sitelink tables corrupted after merge of items
MisterSynergy created this task. MisterSynergy added a project: Wikidata. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION There seems to be a problem with sitelinks after certain item mergers at Wikidata. Scenario: item A with sitelink "foo" is merged into item B with sitelink "bar". The corrupted post-merge situation is described as followed: - "foo" and "bar" appear in the merged item (Web UI, also JSON representation and so on) - "foo" does *not* appear in WDQS as a sitelink of any item, but "bar" does - "foo" does *not* appear in Wikidata's `wb_item_per_site` table, but "bar" does - "foo" does *not* appear in the local `page_props` table - page "foo" appears locally unconnected, and it can indeed be connected to another item than the merge target - page "bar" does see "foo" locally as an interwikilink The sitelink situation seems pretty corrupted. This has also been reported with specific examples at Wikidata:Contact the development team <https://www.wikidata.org/w/index.php?title=Wikidata:Contact_the_development_team=1045996541#Missing_sitelinks_after_merging>, including mentions of specific cases. TASK DETAIL https://phabricator.wikimedia.org/T237499 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Aklapper, MisterSynergy, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T235420: Create wikidata badges to indicate when sitelinks point to Wikipedia redirect pages
MisterSynergy added a comment. If we add those badges, we should remove the mechanism that prevents adding redirects as sitelinks (per 2017 redirect RfC). I can remember one situation in German Wikipedia where a user got in trouble because they disabled/re-enabled too many redirects to link them to Wikidata, and some community members including an admin considered that as vandalism that had to be stopped. Thus, if we do it, let's do it properly. Can someone link relevant phab topics? TASK DETAIL https://phabricator.wikimedia.org/T235420 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: agray, Lydia_Pintscher, MisterSynergy, Aklapper, Liuxinyu970226, Jheald, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T228420: Make EntitySchemas appear on Special:WhatLinksHere
MisterSynergy added a comment. Same as T224669 <https://phabricator.wikimedia.org/T224669> if I understand correctly. TASK DETAIL https://phabricator.wikimedia.org/T228420 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: MisterSynergy, Aklapper, abian, darthmon_wmde, pdehaye, Michael, Nandana, Sario528, Lahi, Gq86, Andrawaag, GoranSMilovanovic, QZanden, YULdigitalpreservation, LawExplorer, Salgo60, _jensen, rosalieper, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T225778: Define canonical URI for EntitySchemas
MisterSynergy created this task. MisterSynergy added projects: Shape Expressions, Wikidata. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION ShEx schemas at Wikidata reside at `https://www.wikidata.org/wiki/EntitySchema:Exxx`, but this is not a canonical URI. We should have a canonical URI (prefix), and I guess `http://www.wikidata.org/entity/` would do, just as for Items, Properties, and Lexemes. Once a URI prefix has been found: - it should be documented whereever necessary - `http://www.wikidata.org/entity/Exxx` (or whatever prefix is chosen) should redirect to actual content, as for Items, Properties, and Lexemes. A canonical URI would likely be required for T225701 <https://phabricator.wikimedia.org/T225701>, and the shex-simple tool could probably make use of it as well for relative URI resolution to a predictable absolute URI. TASK DETAIL https://phabricator.wikimedia.org/T225778 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Aklapper, MisterSynergy, darthmon_wmde, pdehaye, Michael, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, YULdigitalpreservation, LawExplorer, Salgo60, _jensen, rosalieper, abian, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T210830: Do not allow edits from the client for blocked users on the repository
MisterSynergy added a comment. Thanks, looks correct.TASK DETAILhttps://phabricator.wikimedia.org/T210830EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: Lydia_Pintscher, Mbch331, MarcoAurelio, Aklapper, MisterSynergy, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, D3r1ck01, Jonas, Wikidata-bugs, aude___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T210830: Blocked user can edit
MisterSynergy added a comment. AFAIK, if a user moves a page in a Wikipedia project, the sitelink in the connected Wikidata item is *not* updated (1) if the user is locally blocked at Wikidata—as in this case—or (2) if the user does not exist locally at Wikidata.TASK DETAILhttps://phabricator.wikimedia.org/T210830EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: Mbch331, MarcoAurelio, Aklapper, MisterSynergy, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, D3r1ck01, Wikidata-bugs, aude___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T210830: Blocked user can edit
MisterSynergy created this task.MisterSynergy added a project: Wikidata.Restricted Application added a subscriber: Aklapper. TASK DESCRIPTIONUser:Atobot at Wikidata made an edit last night in spite of being blocked indefinitely there since October 22. This should not be possible. Relevant links: https://www.wikidata.org/w/index.php?diff=802029768 (edit in question) https://www.wikidata.org/w/index.php?title=Special:Log/block=User%3AAtobot (user's block log) https://www.wikidata.org/wiki/Special:Contributions/Atobot (user contributions) https://www.wikidata.org/wiki/Wikidata:Administrators%27_noticeboard#Block_tool_broken? (discussion at the Administrators' noticeboard) TASK DETAILhttps://phabricator.wikimedia.org/T210830EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: Aklapper, MisterSynergy, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, D3r1ck01, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T198907: Visually distinguish deprecated statements in Wikidata UI
MisterSynergy created this task.MisterSynergy added projects: Wikidata, Wikidata-Frontend.Herald added a subscriber: Aklapper. TASK DESCRIPTIONCurrently statements with all possible ranks are displayed identically in the Wikidata web UI, which makes it difficult to distinguish deprecated (i.e. somewhat wrong) statements from correct ones. Statements with deprecated rank should be displayed clearly differently from non-deprecated statements (e.g. different background color, fat warning sign, etc.), in order to make sure that also casual Wikidata users understand the matter. There was T115112 (closed) and there is T87327 (stale) related to this task.TASK DETAILhttps://phabricator.wikimedia.org/T198907EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: Aklapper, MisterSynergy, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T196057: Dispatching of Wikidata changes to clients sometimes stucks
MisterSynergy added a comment. Seems to be a problem inside Wikidata as well: Q280658 was vandalized on June 14 (diff) Vandalism was reverted two days later (diff) Vandalized label still shows up in items on June 22, e.g. Q119349#P413 (claim P413: “position played on team / speciality”) TASK DETAILhttps://phabricator.wikimedia.org/T196057EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: Mahir256, Ymblanter, Aklapper, MisterSynergy, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T196423: Can't see references in deleted revisions of items on Wikidata
MisterSynergy created this task.MisterSynergy added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONWhen I open revisions of a deleted item in Wikidata, I cannot unfold the references to see what’s in them. This problem is probably related to T182767 and T129836 and T186006.TASK DETAILhttps://phabricator.wikimedia.org/T196423EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: Aklapper, MisterSynergy, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T196057: Dispatching of Wikidata changes to clients sometimes stucks
MisterSynergy created this task.MisterSynergy added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONIn the English Wikipedia RfC regarding Wikidata use in infoboxes, there are a couple of reports where Wikipedia pages have not been properly updated again after label-vandalism was reverted at Wikidata (section link to en:Wikipedia:Wikidata/2018_Infobox_RfC with examples). This resulted in a situation where bad labels were visible for a couple of days in infoboxes. I was able remove all bad labels from enwiki by performing null-edits to all affected pages, but this is not a viable solution for this problem. Wikidata edits, and reverts in particular, should always trigger all clients to update all affected pages.TASK DETAILhttps://phabricator.wikimedia.org/T196057EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: Aklapper, MisterSynergy, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T193728: Solve legal uncertainty of Wikidata
MisterSynergy added a comment. In T193728#4233267, @Denny wrote: … the practice of having processes that in bulk extract facts from Wikipedia articles … You probably need to describe how these processes look like, otherwise this question would be impossible to answer properly. To my knowledge there are on average ~0.66 imports per Wikipedia article (based on the fact that we have ~42M “imported from” references and ~64M sitelinks in Wikidata). The CC-BY-SA license applies to the works of individual Wikipedia articles, so a proper definition of “bulk extract” in the context of those numbers would be very important.TASK DETAILhttps://phabricator.wikimedia.org/T193728EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: ArthurPSmith, SimonPoole, Scott_WorldUnivAndSch, Micru, lisong, Lofhi, Nemo_bis, TomT0m, jrbs, EgonWillighagen, sarojdhakal, Agabi10, NMaia, Simon_Villeneuve, Jarekt, Rspeer, OhKayeSierra, AndrewSu, Mateusz_Konieczny, Maxlath, Huji, Glrx, Realworldobject, Ltrlg, Papapep, Tgr, Ayack, Gnom1, MichaelMaggs, MisterSynergy, Pasleim, Cirdan, 0x010C, Sylvain_WMFr, Denny, Ivanhercaz, Pintoch, Lydia_Pintscher, Lea_Lacroix_WMDE, Aklapper, Psychoslave, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, ZhouZ, Aschmidt, Mpaulson, Wikidata-bugs, aude, jayvdb, Slaporte, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T193728: Solve legal uncertainty of Wikidata
MisterSynergy added a comment. In T193728#4231813, @Psychoslave wrote: In T193728#4214437, @MisterSynergy wrote: If any of those happened (or had to happen), I’d be out here and I guess many other Wikidata editors would also discontinue their efforts. There is great support for CC0 in Wikidata, since anything else that required attribution would render it useless; large-scale purging would tear down so much content that we would basically have to start again from the beginning. We are 5.5 years into this project and many of us have spent thousands of hours of effort into it, based on the unchallenged assumption (by WMF) that Wikipedia imports as we are doing them are legally fine. How would it render it useless? Or more useless than today? For some actors like OSM it is useless because they don't trust Wikidata claim that this data can legally be released under CC-0. For those who don't care about acting legally, any license will make the same effect. Users of Wikidata can compile datasets of any form and content with the query service, and re-use it according to the CC0 license (i.e.: do whatever they want to, particularly without attribution). If there was a convolution of individual licenses per fact involved, it would be practically impossible to get this sorted so that use of data was in line with all the licenses involved; even if one would be able to manage this, one could easily end up in a situation where one has to display thousands of sources in some way. Databases with more restrictive licenses than CC0 are useless for re-users, and Wikidata just aims to be useful for re-users. I agree that we should ensure to put only compatible data into Wikidata, yet I am still not convinced that there is a systematic problem. From my point of view, there is no concern about the validity of Wikidata’s declaration that all content (in main and property namespace) is available under the CC0 license. Is there any official claim by the WMF that said this kind of import were legally fine? Before Wikidata was launched, @Denny used to agree that Wikipedia imports would not be possible including for legal reasons, that is at the time he was officially working for WMDE. If any official statement clearly exposed otherwise in the mid-time, it would be nice to highlight this information. Not being challenged by some entity doesn't mean what an action is legal, just as any legal infraction it doesn't become more legal because no one bother challenging the issue. We use imports from Wikidata for years now, and this is not a hidden activity than one could have missed. WMF definitely knows about this for years. There were occasionally some dissenting opinions (not by WMF, AFAIK), but I cannot remember that anyone was able to raise concern strong enough to reconsider the import practice. Until now, this has not changed in this conversation as well.TASK DETAILhttps://phabricator.wikimedia.org/T193728EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: ArthurPSmith, SimonPoole, Scott_WorldUnivAndSch, Micru, lisong, Lofhi, Nemo_bis, TomT0m, jrbs, EgonWillighagen, sarojdhakal, Agabi10, NMaia, Simon_Villeneuve, Jarekt, Rspeer, OhKayeSierra, Aschmidt, AndrewSu, Mateusz_Konieczny, Maxlath, Huji, Glrx, Realworldobject, Ltrlg, Papapep, Tgr, Ayack, Gnom1, MichaelMaggs, MisterSynergy, Pasleim, Cirdan, 0x010C, Sylvain_WMFr, Denny, Ivanhercaz, Pintoch, Lydia_Pintscher, Lea_Lacroix_WMDE, Aklapper, Psychoslave, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, ZhouZ, Mpaulson, Wikidata-bugs, aude, jayvdb, Slaporte, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T193728: Solve legal uncertainty of Wikidata
MisterSynergy added a comment. In T193728#4214033, @Denny wrote: My current goal to shepherd this bug to a closure is to agree with people who have a different point of view on a question or two to ask Gnom1, and then work on from his answer. In case of serious doubt it is more appropriate to ask WMF’s legal department to organize a professional opinion regarding open questions (elaborated in house or via some hired external expert), regardless of User:Gnom’s unquestionable knowledge in this field. (Yes it is great that he adds expert opinion, but as far as I understand it is all unpaid legal advice he provides, right?) If, for example, it turns out that the extraction that Wikidata has done from Wikipedia is deemed breaking the license of Wikipedia, then we should indeed purge Wikidata of any data taken from such a license breach or change Wikidata's license to CC-BY-SA. If any of those happened (or had to happen), I’d be out here and I guess many other Wikidata editors would also discontinue their efforts. There is great support for CC0 in Wikidata, since anything else that required attribution would render it useless; large-scale purging would tear down so much content that we would basically have to start again from the beginning. We are 5.5 years into this project and many of us have spent thousands of hours of effort into it, based on the unchallenged assumption (by WMF) that Wikipedia imports as we are doing them are legally fine.TASK DETAILhttps://phabricator.wikimedia.org/T193728EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: Micru, lisong, Lofhi, Nemo_bis, TomT0m, jrbs, EgonWillighagen, sarojdhakal, Agabi10, NMaia, Simon_Villeneuve, Jarekt, Rspeer, OhKayeSierra, Aschmidt, AndrewSu, Mateusz_Konieczny, Maxlath, Huji, Glrx, Realworldobject, Ltrlg, Papapep, Tgr, Ayack, Gnom1, MichaelMaggs, MisterSynergy, Pasleim, Cirdan, 0x010C, Sylvain_WMFr, Denny, Ivanhercaz, Pintoch, Lydia_Pintscher, Lea_Lacroix_WMDE, Aklapper, Psychoslave, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, ZhouZ, Mpaulson, Wikidata-bugs, aude, jayvdb, Slaporte, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T167989: Add “integer” constraint
MisterSynergy added a comment. Not sure. At this point I don’t know of any situation where we need integer values with non-integer constraints. This is also based on the observation that in 3.8M claims of 99 different quantity properties with integer constraint deployed, the situation of non-integer bounds does not occur. If anyone can come up with such an example where bounds are properly used, it would be great and I would immediately re-evaluate my position. If not, I think we need only one constraint with integer requirement for both amount and lowerBound/upperBound. Maybe it is worth to mention that as a physicist I have a rather scientific expectation about which purpose bounds should serve. However, the entire bounds concept is a scientific one, thus I think it is appropriate to use it scientifically in Wikidata as well. The constraint system has already become more and more complex, and even as an editor who constantly works with it, I find it hard to keep up with all the new possibilities. Let’s keep things simple, as long as there is no reason to add another constraint or option.TASK DETAILhttps://phabricator.wikimedia.org/T167989EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDE, MisterSynergyCc: Ladsgroup, gerritbot, MisterSynergy, Esc3300, thiemowmde, daniel, Jonas, Lydia_Pintscher, Aklapper, Lucas_Werkmeister_WMDE, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, lisong, Adik2382, Soteriaspace, Jayprakash12345, Th3d3v1ls, JakeTheDeveloper, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Agabi10, Wikidata-bugs, aude, TheDJ, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T167989: Add “integer” constraint
MisterSynergy added a comment. In T167989#4209937, @thiemowmde wrote: Let's say the size of a team was 50±0.5 people in 2017. Such a confidence interval tells me that there must have been some fluctuation over the year, but not a huge one. What’s the exact meaning of such “±0.5 bounds”? It just transports the qualitative notion of “some fluctuation over the year” with a meaningless quantitative number that you somehow found appropriate. Say you had a team size of 49 most of the year which suddenly increased to 52 shortly before end of the year, and you managed to somehow calculate the quantity as given above. Unfortunately, at no time ever there were 50 people in your team, also your team size has never been within the bounds, and there have never been half team members, as you state by yourself. This is a good example where bounds are (ab)used to replace either ranges (49–52), or where alternatively two independent claims (49 at beginning of the year, 52 at the end of the year) should be used instead. If you just wanted to state that the value is some approximation or estimation, we typically add qualifiers “sourcing circumstances (P1480): circa (Q5727902)” to the claim. This way we avoid to desperately quantify a qualitative claim. Why do you think "passenger" is not a valid unit? Countable sets such as “number of passengers/apples/…” do not have a unit (or better: have unit 1, in Wikidata in some situations represented as http://www.wikidata.org/entity/Q199). Constraints in Wikidata typically respect that (e.g. “number of participants” property at https://www.wikidata.org/wiki/Property:P1132, but have a look at the violations: https://www.wikidata.org/wiki/Wikidata:Database_reports/Constraint_violations/P1132#%22Units%22_violations).TASK DETAILhttps://phabricator.wikimedia.org/T167989EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDE, MisterSynergyCc: Ladsgroup, gerritbot, MisterSynergy, Esc3300, thiemowmde, daniel, Jonas, Lydia_Pintscher, Aklapper, Lucas_Werkmeister_WMDE, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, lisong, Adik2382, Soteriaspace, Jayprakash12345, Th3d3v1ls, JakeTheDeveloper, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Agabi10, Wikidata-bugs, aude, TheDJ, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T167989: Add “integer” constraint
MisterSynergy added a comment. Sorry for being late. I have now been working with quantity datatype properties a lot and I have to disagree here. I think that we should allow only integer bounds when the value is integer, as bounds cannot be non-integers in those cases. Let’s have a look at actual numbers: right now we have ~3.8M statements of quantity properties with integer constraint (~2.7M mainsnak, ~1.1M qualifier, barely any in reference). In exactly one case there is an integer value with non-integer bounds, which is the P1114 qualifier of https://www.wikidata.org/wiki/Q26882302#P186 – that claim has other isses anyway and needs to be fixed. (I removed ~10 other wrong uses of bounds this morning). Maybe I should add a more general rant about the quantity datatype here: users don’t understand it, which is why the vast majority of bounds and a substantial amount of units are wrong. Reasons: The meaning of bounds in quantity datatype properties is not well-defined (particularly here: https://www.wikidata.org/wiki/Help:Data_type#quantity and https://www.mediawiki.org/wiki/Wikibase/DataModel#Quantities). The term “uncertainty interval” indicates that it should be used as measurement uncertainty, confidence intervals, etc., but this is actually not the case in Wikidata. This leads to a situation where users use bounds as they personally prefer to, but one cannot rely on a particular meaning of any bounds given in Wikidata. This also encourages users to abuse bounds for other purposes, e.g. compensate the lack of other datatypes. General rule: valid bounds can also be found in the referenced sources of a claim. I’d say that clearly more than 95% of all bounds in Wikidata fail that criterion, as they are personal flavor of individual users or residuals of the automatic ±0 bounds addition of the software that we saw in the past. Due to the lack of a “range” datatype, users add bounds as follows: source A claims a person has 2 children, and source B claims the same person has 3 children. Users add: 2.5±0.5 children, as this covers the range of values found in sources. (Yet I am not sure whether we should have a “range” datatype; multiple claims and use of ranks are the solution here.) The lack of a “number” datatype makes the integer constraint necessary. This works out to some extent as we can see, but it is not optimal: A “number” datatype would make accidental decimal places impossible. A lot of wrong uses of units could be avoided as well (units such as “apple”, “passenger”, “train”, etc.) if the “number” datatype had a different kind of or even no unit attached. TASK DETAILhttps://phabricator.wikimedia.org/T167989EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDE, MisterSynergyCc: Ladsgroup, gerritbot, MisterSynergy, Esc3300, thiemowmde, daniel, Jonas, Lydia_Pintscher, Aklapper, Lucas_Werkmeister_WMDE, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Baloch007, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, lisong, Adik2382, Soteriaspace, Jayprakash12345, Th3d3v1ls, JakeTheDeveloper, Ramalepe, Liugev6, QZanden, LawExplorer, Lewizho99, Maathavan, Agabi10, Wikidata-bugs, aude, TheDJ, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T57755: allow time values more precise than day
MisterSynergy added a comment. According to mw:Wikibase/DataModel#Dates and times, there are already most requirements for timezone support contained in the data model. What prevents us from just activating it? Sure, there will be some GUI changes necessary to enable HH:MM:SS modifications, and to show a timezone selector, but it does not appear too complex to find something there. The highest precision should be seconds (precision=14) to my opinion, as already defined in the data model. An alternative approach with more required changes could be to save the timezone as URIs instead of “diff minutes to UTC”, akin to the calendarmodel approach. I am not sure whether that would really have advantages, though; maybe display would be easier, since times could be witten as “26 April 2018, 13:43:51 (MESZ / UTC+2)”, rather than “26 April 2018, 13:43:51 (UTC+2)”.TASK DETAILhttps://phabricator.wikimedia.org/T57755EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: MisterSynergy, Lea_Lacroix_WMDE, Realworldobject, Marsupium, robbi5, Andrei_Stroe, Jklamo, sladen, Liuxinyu970226, Esc3300, Edgars2007, ChristianKl, Saehrimnir, Jc3s5h, Mike_Peel, Thryduulf, Jobu0101, Laddo, Aklapper, MGChecker, Yair_rand, Apsdehal, Wikidata-bugs, Ricordisamoa, Lydia_Pintscher, Ltrlg, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T172649: Incomplete Wikidata mergers
MisterSynergy created this task.MisterSynergy added projects: Wikidata, Wikidata-Gadgets.Herald added subscribers: PokestarFan, Aklapper. TASK DESCRIPTIONThe item merge mechanism at Wikidata fails to work properly in many cases. It looks as if the item to be merged is not properly cleared, and thus no redirect is created thereafter, leaving an almost empty item behind. Can this be fixed in a way that the merge mechanism is more robust? The observed behavior appears to happen regardless of the tools used (i.e. with the Merge gadget as well as with QuickStatements, and probably with other tools as well). Examples: Merge gadget: Q32650964, Q32653805, Q32641999, (and many more) QuickStatements: Q32163668, Q32163680, Q32163692, (and many more) Affected items also appear on my “empty item” worklist at User:MisterSynergy/sysop/empty items (among non-affected items) Onwiki discussions: Wikidata:Project chat#Merge with quickstatements don't work? (started on August 6, 2017) Wikidata:Project chat/Archive/2017/07#Redirect creation failures… (started July 11, 2017; already archived) I have seen this problem for a while now by a lot of different users, but it has become much more frequent since roughly a week or so. I have no idea whether the merge activity has change recently.TASK DETAILhttps://phabricator.wikimedia.org/T172649EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: Aklapper, PokestarFan, MisterSynergy, GoranSMilovanovic, QZanden, dachary, Izno, Wikidata-bugs, aude, Ricordisamoa, Sjoerddebruin, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T172380: Query constraint violations with WDQS
MisterSynergy added a comment. I thought of a new SERVICE as well, but I actually do not really have a preference how this should be implemented. Devs will find the best solution, I guess…TASK DETAILhttps://phabricator.wikimedia.org/T172380EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: Esc3300, Aklapper, PokestarFan, MisterSynergy, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Gehel, Jonas, FloNight, Xmlizer, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T172380: Query constraint violations with WDQS
MisterSynergy created this task.MisterSynergy added projects: Wikidata, Wikidata-Query-Service, Wikibase-Quality-Constraints.Herald added subscribers: PokestarFan, Aklapper.Herald added a project: Discovery. TASK DESCRIPTIONNow that the constraints are machine-readable on property pages, it is a charming idea to query constraint violations on the fly using the Wikidata Query Service. It should be possible to identify items based on various criteria, such as: French painters with any type of constraint violation on any claim French painters with a specific constraint violation (e.g. single values constraint) on any claim French painters with any type of constraint violation on a claim of a specific property (e.g. P569) French painters with a specific constraint violation (e.g. single values constraint) on a claim of a specific property (e.g. P569) And so on… Right now we only have the possibility to work on all constraint violations of a given property (via covi pages), but it is not possible to limit this to sets of items in a given topical area (such as “French painters”). It should also be possible to equip the constraint boxes on property talk pages with SPARQL links that way. Right now we have to wait for daily KrBot updates, which slows down maintenance occasionally. The idea of this task is not new and has already been mentionend by several users, but I didn’t find a phabricator task yet. Still I hope it is not a duplicate.TASK DETAILhttps://phabricator.wikimedia.org/T172380EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: Aklapper, PokestarFan, MisterSynergy, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Gehel, Jonas, FloNight, Xmlizer, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T171928: Wikidata database locked
MisterSynergy added a comment. dewiki is read-only since 5:48 as well.TASK DETAILhttps://phabricator.wikimedia.org/T171928EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: MisterSynergy, TerraCodes, Jay8g, Liuxinyu970226, Lydia_Pintscher, Aklapper, Esc3300, PokestarFan, GoranSMilovanovic, QZanden, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T171263: Wikidata Dispatcher and Job Queue is overflowed
MisterSynergy added a comment. How much are we sure that this problem was predominantly caused by the recently “high” edit rate (or undesired number of parallel bot runs) at Wikidata? At Wikidata we are trying to get edit rates down, but I am uncomfortable with the notion that Wikidata operates already at the edge of what’s technically possible. Recent activity might have been pretty high, but not that much that I would have expected problems of that impact. I would like to point to the dispatch graphs [1] in Grafana as well. If you look closely, there seems to be a very clear singularity in many of the graphs on 2017-06-28, between 21:15 and 21:30 (Grafana time, no idea whether this is UTC). What happend at this time? If there was a software or hardware failure, it probably would have been noticed by today, but this does not seem to be the case according to the Grafana charts. I thus speculate that some very expensive new software was deployed at this singularity, or an update which is badly inefficient compared to the previous condition. The history of T151681 (and maybe other tasks) indicates that there was in fact activity in connection with the dispatcher around that time. [1] https://grafana.wikimedia.org/dashboard/db/wikidata-dispatch?refresh=1m=1TASK DETAILhttps://phabricator.wikimedia.org/T171263EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: MisterSynergy, Liuxinyu970226, daniel, Esc3300, XXN, Ladsgroup, Lydia_Pintscher, hoo, Bugreporter, Sjoerddebruin, Magnus, Emijrp, Mr.Ibrahem, Wikidata, Aklapper, PokestarFan, GoranSMilovanovic, QZanden, Vali.matei, Volker_E, Izno, Wikidata-bugs, aude, GWicke, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T170775: Feed Entity Suggester with ASCII equivalents of labels
MisterSynergy updated the task description. (Show Details) CHANGES TO TASK DESCRIPTION...I therefore propose to suggests an item based on the ASCII equivalent of the label(s) as wellTASK DETAILhttps://phabricator.wikimedia.org/T170775EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: Aklapper, MisterSynergy, GoranSMilovanovic, QZanden, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T170775: Feed Entity Suggester with ASCII equivalents of labels
MisterSynergy created this task.MisterSynergy added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONThe Wikidata Entity Suggester helps to identify items as values for claims at Wikidata, based on their labels. Unfortunately, this is difficult if the label contains special characters which might be difficult to enter if the keyboard does not provide direct input. I therefore propose to suggests an item based on the ASCII equivalent of the label(s) as well. Currently there is (approved) bot editing going on at Wikidata to add ASCII equivalents of labels as aliases (at least for languages en and es). This is also justified with the difficulties related to the Entity Suggester mentioned above. It appears to me that we are adding aliases here to compensate a functional deficit, not because the entity is actually known under the ASCII equivalent of the label.TASK DETAILhttps://phabricator.wikimedia.org/T170775EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: Aklapper, MisterSynergy, GoranSMilovanovic, QZanden, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T170610: Add “no bounds” constraint
MisterSynergy created this task.MisterSynergy added projects: Wikidata, Wikibase-Quality, Wikibase-Quality-Constraints.Herald added a subscriber: Aklapper. TASK DESCRIPTIONWe should have a new constraint type No bounds for quantity properties that are about non-physical quantities without uncertainty. This is in fact a substantial fraction of Wikidata quantity properties. Since use of bounds indicates uncertainty and we cannot use novalue for bounds, we need to indicate the absence of uncertainty by using no bounds at all, rather than ±0 bounds. Transferred to phabricator from wikidata.TASK DETAILhttps://phabricator.wikimedia.org/T170610EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: Aklapper, MisterSynergy, GoranSMilovanovic, QZanden, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T168041: Assign different favicons to query.wikidata.org and test.wikidata.org
MisterSynergy created this task.MisterSynergy added projects: Wikidata-Query-Service, Wikidata.Herald added a subscriber: Aklapper.Herald added a project: Discovery. TASK DESCRIPTIONWikidata Query Service and test.wikidata.org both use the same favion: https://www.wikidata.org/static/favicon/testwikidata.ico for query service https://test.wikidata.org/static/favicon/testwikidata.ico for Test.Wikidata The file is however apparently the same. Since this continuously confused me in my browser tabs, I suggest to use different favicons. I do not have a preference which one to keep and which one to change.TASK DETAILhttps://phabricator.wikimedia.org/T168041EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: Aklapper, MisterSynergy, GoranSMilovanovic, QZanden, EBjune, merbst, Avner, debt, Gehel, Jonas, FloNight, Xmlizer, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T167521: Simplify access to properties that currently require traversing numerous items
MisterSynergy added a comment.
The lack of powerful means to traverse the Wikidata knowledge tree within Lua modules is in fact a problem for Wikidata as well, not only for module coders on Wikipedia side. {{#property:}}/{{#statement:}} parser functions and Module:Wikidata allow simple data retrieval from the connected item, but any lookup of items (as indicated by Jarekt) is very difficult. Users deal with this problem by adding all information they want to access from a client (e.g. in an infobox) directly to the connected item—even if it is utterly misplaced there (for instance country qualifiers to place of birth data in an item about a person).
The most effective method to search in the Wikidata knowledge tree is likely a SPARQL query. It would thus be very useful if a SPARQL interface for item lookup was available in Lua.TASK DETAILhttps://phabricator.wikimedia.org/T167521EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: Agabi10, Liuxinyu970226, Paucabot, Vriullop, MisterSynergy, Pasleim, Aklapper, Jarekt, GoranSMilovanovic, QZanden, Izno, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T160281: URL-encoding of external-id values in Wikidata frontend breaks (some) links
MisterSynergy created this task.MisterSynergy added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONValues of external-id properties link to the external database entry from the Wikidata frontend. In some cases the external weblink is not working due to URL-encoding of special characters within the external identifier, such as %, &, =, and maybe others. An example is https://www.wikidata.org/wiki/Q325887#P3520 with the correct identifier W%D6LLEKLA01. The extra URL-encoding translates it to W%25D6LLEKLA01 which is not working. I originally requested an update at wikidata:MediaWiki talk:Gadget-AuthorityControl.js, but I learnt that this gadget is no longer responsible for the linking.TASK DETAILhttps://phabricator.wikimedia.org/T160281EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: Aklapper, MisterSynergy, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T153563: Consider switching to HTTPS for Wikidata query service links
MisterSynergy added a comment. In T153563#2949967, @Smalyshev wrote: each object has its own globally unique identifier, which is the full URI. Naïve question: does it necessarily have to be a single identifier? If each object had two globally unique identifiers (http and https), which problems would arise?TASK DETAILhttps://phabricator.wikimedia.org/T153563EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: Lydia_Pintscher, Jonas, Ricordisamoa, Lokal_Profil, DSGalaktos, MisterSynergy, Esc3300, Smalyshev, MZMcBride, Aklapper, Th3d3v1ls, EBjune, mschwarzer, merbst, Avner, Zppix, debt, Gehel, D3r1ck01, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Dinoguy1000, Manybubbles, faidon, Seb35, Mbch331, Jay8g, Krenair, fgiunchedi___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T153563: Consider switching to HTTPS for Wikidata query service links
MisterSynergy added a comment. FWIW: https://www.mediawiki.org/wiki/Talk:Wikidata_query_service#Links_in_query_results_should_be_https.2C_not_httpTASK DETAILhttps://phabricator.wikimedia.org/T153563EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MisterSynergyCc: MisterSynergy, Esc3300, Smalyshev, MZMcBride, Aklapper, Th3d3v1ls, EBjune, mschwarzer, Avner, Zppix, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Dinoguy1000, Manybubbles, faidon, Seb35, Mbch331, Jay8g, Krenair, fgiunchedi___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T103684: Order of interproject links in the left menu
MisterSynergy added a subscriber: MisterSynergy. TASK DETAIL https://phabricator.wikimedia.org/T103684 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: MisterSynergy, MGChecker, Aklapper, SJu, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T115272: Authority control gadget does not create a click-able link when authority control properties are used in references
MisterSynergy added a comment. Herald added a subscriber: StudiesWorld. Works now! :-) Did someone change anything? TASK DETAIL https://phabricator.wikimedia.org/T115272 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: StudiesWorld, Ricordisamoa, Mbch331, Aklapper, MisterSynergy, Wikidata-bugs, aude, Sjoerddebruin ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T54564: Allow sitelinks to redirect pages to fix the 'Bonnie and Clyde problem'
MisterSynergy added a subscriber: MisterSynergy. TASK DETAIL https://phabricator.wikimedia.org/T54564 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: MisterSynergy, Oliv0, JanusTroelsen, Blahma, MGChecker, MSGJ, Izno, Nnemo, bzimport, Unknown Object (MLST), DanielFriesen, Gymel, Denny, jeblad, Abraham, Addshore, SamB, Toru10, Wikidata-bugs, JAnD, Nemo_bis, He7d3r, -jem-, ValterVB, Filceolaire, Micru, JanZerebecki, matej_suchanek, Ricordisamoa, MZMcBride, Aklapper, Tgr, kaldari, Laddo, Lydia_Pintscher, Jane023, Ltrlg, JohnLewis, Fomafix, Zellfaze, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T117064: License note in footer of mobile Wikidata frontend does not provide any license
MisterSynergy added a comment. Seems to be fixed. TASK DETAIL https://phabricator.wikimedia.org/T117064 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: aude, hoo, Lydia_Pintscher, Aklapper, MisterSynergy, Wikidata-bugs, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T117064: License note in footer of mobile Wikidata frontend does not provide any license
MisterSynergy created this task. MisterSynergy added a subscriber: MisterSynergy. MisterSynergy added a project: Wikidata. Herald added a subscriber: Aklapper. TASK DESCRIPTION The footer of the mobile Wikidata frontend actually says: “Content is available under unless otherwise noted.” The CC0 license does not appear, not even in the HTML source. TASK DETAIL https://phabricator.wikimedia.org/T117064 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Aklapper, MisterSynergy, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T115272: Authority control gadget does not create a click-able link when authority control properties are used in references
MisterSynergy created this task. MisterSynergy added a subscriber: MisterSynergy. MisterSynergy added a project: Wikidata-Gadgets. Herald added a subscriber: Aklapper. Herald added a project: Wikidata. TASK DESCRIPTION As per https://www.wikidata.org/wiki/Help:Sources#Databases, authority control properties shall be used in references, if the database behind is used to source a statement. Unlike normal usage of authority control properties in statements, the “Authority Control gadget” unfortunately does not create a click-able link when used in references. Example: reference of Property:P1559 in Q521844. TASK DETAIL https://phabricator.wikimedia.org/T115272 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: Aklapper, MisterSynergy, Wikidata-bugs, aude, Ricordisamoa, Sjoerddebruin, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T90435: Wikidata watchlist integration (tracking)
MisterSynergy added a subscriber: MisterSynergy. TASK DETAIL https://phabricator.wikimedia.org/T90435 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: MisterSynergy, Lydia_Pintscher, Aklapper, daniel, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T46874: Full support for wikibase edits in enhanced changes format (Group changes by page in recent changes and watchlist [usenewrc])
MisterSynergy added a subscriber: MisterSynergy. TASK DETAIL https://phabricator.wikimedia.org/T46874 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign username. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MisterSynergy Cc: MisterSynergy, Conny, Reaper35, liangent, Jdforrester-WMF, Abraham, matmarex, Nemo_bis, Schnark, Tobi_WMDE_SW, He7d3r, aude, Liuxinyu970226, Tgr, Lydia_Pintscher, Ltrlg, Raymond, Wikidata-bugs ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
