[Wikidata-bugs] [Maniphest] T363721: Show "small logo or icon" as fallback image in search
ChristianKl added a comment. I'm not focused on the images within wikidata.org. If I search on en.wikipedia.org I get: F53792940: image.png <https://phabricator.wikimedia.org/F53792940> If my proposal would be implemented, the icon for John Smith's disambiguation page would be: F53793248: image.png <https://phabricator.wikimedia.org/F53793248> The icon for all the entries in the list that would be humans would be: F53793359: image.png <https://phabricator.wikimedia.org/F53793359> This would look better than the status quo and be helpful to users because they don't have to read the text to understand that the first entry is a disambiguation page and which articles are humans. TASK DETAIL https://phabricator.wikimedia.org/T363721 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl Cc: thiemowmde, Aklapper, ChristianKl, Danny_Benjafield_WMDE, S8321414, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, NavinRizwi, ItamarWMDE, Akuckartz, Dringsim, Nandana, Amorymeltzer, Lahi, Gq86, GoranSMilovanovic, QZanden, KimKelting, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Dinoguy1000, Mbch331, Jay8g ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T219037: Display constraint clarifications in violation messages
ChristianKl added a comment.
I would prefer wikitext over normal text, so that it would be "Use {{unknown
value}} instead of anonymous when the author is unknown." in the example. New
users might not know what "unknown value" happens to be and the wikitext
template gives the user the link to the page that explains it in more detail.
TASK DETAIL
https://phabricator.wikimedia.org/T219037
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: ChristianKl
Cc: ChristianKl, Arian_Bozorg, Sarai-WMDE, Michael, Naseweis520,
Lydia_Pintscher, Lectrician1, Moebeus, Thadguidry, Esc3300,
Lucas_Werkmeister_WMDE, Aklapper, ArthurPSmith, Astuthiodit_1, karapayneWMDE,
Invadibot, maantietaja, ItamarWMDE, Akuckartz, Eihel, Nandana, Lahi, Gq86,
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10,
Scott_WUaS, abian, 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] T270717: “Add links” automatically merges categories with subject items on Wikidata
ChristianKl added a comment. I agree that this behavior is problematic. Merging items that already have statements should not happen without the user investigating the items in question. TASK DETAIL https://phabricator.wikimedia.org/T270717 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl Cc: ChristianKl, Vojtech.dostal, Aklapper, Mormegil, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, lucamauri, 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] T318072: Wikidata should normalize data entered for the language code of Monolingual text as lower case
ChristianKl created this task. ChristianKl added a project: Wikidata. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION Currently, the user has to write "en" or "de" as language code while entering "EN", "En", "De" and "DE" don't find the corresponding language codes. Given that there aren't language codes where capitalization makes a semantic difference normalizing the data entry as lower case to search for the right code would make it easier to use. I'm writing this ticket because a user asked at https://www.wikidata.org/wiki/Wikidata:Forum#Qualifikator_%22Sprache%22_bei_Adresse_(P6375)_unm%C3%B6glich_einzugeben why they were unable to enter the language code when they tried to enter "De". While this is a minor detail, it seems to trip up users and the fix likely takes little work. TASK DETAIL https://phabricator.wikimedia.org/T318072 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl Cc: Aklapper, ChristianKl, 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
ChristianKl added a comment. @MisterSynergy : The point of restrictions is that a user should not create a sitelink to a redirect without explicitly intending to do so. This was supposed to counteract the concerns that a lot of sitelinks to redirects will be created in a fashion that's problematic for Wikidata which some people in the RfC believed. TASK DETAIL https://phabricator.wikimedia.org/T278962 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl 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] T278962: Allow redirects and the target article as independent sitelinks if redirect badge is used
ChristianKl added a comment. In T278962#8128218 <https://phabricator.wikimedia.org/T278962#8128218>, @Lucas_Werkmeister_WMDE wrote: > What if you have a sitelink to a redirect without a badge, and you try to edit unrelated badges (add, remove or replace non-redirect badges)? Should that be allowed or prevented? Most of the other non-redirect badges we currently have are about marking articles that are good. If they are added to redirect pages someone made an error. Therefore, I would disallow adding them in cases where there's no redirect badge given that the behavior likely is not intentional. TASK DETAIL https://phabricator.wikimedia.org/T278962 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl 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] T207705: Implement the Extended Date/Time Format Specification
ChristianKl added a comment. RE:request for feedback on #3: I would want that in the typical case the user interface shows the EDTF value and that it's easy to enter dates in that format. In most cases, a user should just be able to input dates without worrying about qualifiers. The user should not have to worry about Wikidata having its own time system that differs from the ISO-supported EDTF. As far as what happens on the backend, I can see that it might make sense sometimes to store two values. If we for example have dates in the Julian calendar storing that date both in the Julian calendar and also in Gregorian EDTF would make it easier to sort dates while still being able to display the Julian date. I believe that the longer Wikidata doesn't fix this issue the more times people will make errors when entering dates because they are not thinking about the conversion between how Wikidata's idea of time differs from the ISO standard. TASK DETAIL https://phabricator.wikimedia.org/T207705 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl Cc: ChristianKl, Jheald, Moebeus, Epidosis, SilentSpike, So9q, Lectrician1, GreenReaper, Spinster, mxn, Lydia_Pintscher, Marsupium, Jc3s5h, Mvolz, Liuxinyu970226, Pigsonthewing, 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] T278962: Allow redirects and the target article as independent sitelinks if redirect badge is used
ChristianKl added a comment. I do think that RfC's and the Wishlist should be prioritized much higher than what happens at events and Telegram. If I look at Community_Wishlist_Survey_2021, the highly upvoted tasks are "Edit Wikidata in a map!", "Link red links to Wikidata, for future reference and more benefits", "Anti-vandalism tools for Wikidata", "Duplicates and merge candidates", "Time and date handling improvements", "Support ISO 8601-2:2019 to specify uncertainty about times" and "Link Wikipedia redirects to Wikidata items". Out of that https://wdvd.toolforge.org/index.php might be handling the call for more anti-vandalism tools but otherwise, all the tasks seem to be still undone. "Duplicates and merge candidates" might be a quite big task but otherwise, a single programmer might implement "Time and date handling improvements", "Support ISO 8601-2:2019 to specify uncertainty about times", "Edit Wikidata in a map!", "Link red links to Wikidata, for future reference and more benefits", and "Link Wikipedia redirects to Wikidata items" in one year. That would mean tasking one programmer out of the WMDE Wikidata team with fulfilling community wishes. In the past, the wishes of the community got less attention. Instead, WMDE spent development resources on free Wikibase installation in the cloud and prevented other commercial players from doing commercial Wikibase hosting to grow the ecosystem. TASK DETAIL https://phabricator.wikimedia.org/T278962 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl Cc: 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] T278962: Allow redirects and the target article as independent sitelinks if redirect badge is used
ChristianKl added a comment. In T278962#7985878 <https://phabricator.wikimedia.org/T278962#7985878>, @Manuel wrote: > Hi @William_Cheselden this task has a pretty high priority and will likely be tackled within the next few weeks. About your general question on why this takes so long: The main challenge is that there are so many important things to do but we have only limited development resources to actually do them. This is why we tried to get relatively small tasks (like this one) done whenever a developer has some time outside of the big sprints. Unfortunately, this hasn't always worked well and we are already thinking about making improvements to the process and making it easier to follow. Given that you express it like this, a better way to ask the question would be: Why are so little development resources devoted to tasks the community asks for in RfC's and on the Wishlist, even when WMDE believes the tasks to be relatively small and thus easy to do? TASK DETAIL https://phabricator.wikimedia.org/T278962 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl Cc: 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] T278962: Allow redirects and the target article as independent sitelinks if redirect badge is used
ChristianKl added a comment. > Very good. Both the interwiki bots before 2013 and 2017, and the current "solution" requiring to trash the redirect in order to be able to connect to WikiData have or had potential for starting conflicts or the WWIII. Yes, I don't think the status quo is good. I created the RfC that's the basis for finally creating change. At the moment you are the person who stalls the change by voicing doubt about whether it's the correct way forward. > That's why caching has been available and used for a long time. ;-) Caching technically means that Wikidata has to store the information about which items are redirects somewhere. Storing them as batches is as complex as storing that information somewhere else. Cache invalidation takes time. If you invalidate the cache once per day, you achieve the same turnaround that Wikidata shows the redirects that you get with the batch + bot solution. > "Those that have a WikiData Q-item to connect to. A concept sufficienty notable to have a Q-item but not having a page on that wiki at the moment. If the redirect is turned into a primary topic or vice versa then the link to wikidata remains functional." Have you actually read the RfC's that are the basis for this change and understand both sides? The question of what's "sufficienty notable" is quite unclear and has to be decided somewhere. Claiming authority for Wikidata's policies to determine text on the Wikipedia's goes against the current separation of concerns and overstepping the current lines can create pushback. One thing I didn't yet mention is that we want the ability to run queries to list items with redirects that are not yet tagged as an intentional redirect for humans to look at them and see what should be done with them. Having the information about the redirects on badges within Wikidata allows for that to happen. If the information is stored in a cache that can't be accessed via SPARQL queries that's not possible. TASK DETAIL https://phabricator.wikimedia.org/T278962 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl Cc: 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] T278962: Allow redirects and the target article as independent sitelinks if redirect badge is used
ChristianKl added a comment. @Bugreporter If you say "we should tag" then who do you think should do the tagging? If you expect Wikipedia editors to do that, how do you think they learn that they are not supposed to put __VALIDREDIRECT__ on redirects that are not eligible for an independent Wikidata item? If I would be a Wikipedia editor and see __VALIDREDIRECT__ on one redirect page, my natural impression would be that __VALIDREDIRECT__ is supposed to be put on all redirect pages that conform with the redirect policy of the Wikipedia. It's even policy that someone makes an RFC that calls for that on enWiki which would invite us into another conflict between Wikidata and Wikipedia where I don't want to explain to the enWiki audience that they are supposed to respect Wikidata policy in regards to texts they put on enWiki pages. As a guiding principle for Wikidata development "Don't do anything that has a potential for starting conflicts with other Wikimedia projects" is useful. If there's a desire on the Wikipedia side to later make it visible that this is a local redirects eligible for an independent Wikidata item, that's an policy decision that can be made via RFC on those projects and a bot could create them based on the badges. In the future badges might also be automatically created in specific cases to improve user experience, but for today simply the solution as detailed in the starting post and approved by @Manuel is the right way to go. TASK DETAIL https://phabricator.wikimedia.org/T278962 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl 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] T278962: Allow redirects and the target article as independent sitelinks if redirect badge is used
ChristianKl added a comment. Re-running the bot costs performance but not a kind of performance that matters. It doesn't increase page loading time and most of the bot activity is reading not writing so it also doesn't go produce problems with creating too many edits. "Let wikidata autodetect" is very imprecise. When do you think Wikidata should do that autodetection? Do you believe that if someone opens a Wikidata item with 100 sitelinks, Wikidata should query all 100 Wikipedia projects every time? Besides the technical, there's also the question of what we mean by "valid redirects". I believe that a valid redirect is one that's in line with Wikidata policy on which redirects we want to list on Wikidata. Spelling mistakes are for example not valid redirects according to our Wikidata policy. A redirect for a spelling mistake is on the other hand, perfectly in line with Wikipedia policy, so having to explain to the Wikipedians (in every project) that they should not put VALIDREDIRECT on their redirect pages with spelling mistakes has the potential for a lot of conflicts. TASK DETAIL https://phabricator.wikimedia.org/T278962 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl 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] T278962: Allow redirects and the target article as independent sitelinks if redirect badge is used
ChristianKl added a comment. I agree that the feature should be implemented as laid out in the introduction. The badges within Wikidata are useful for addressing the concerns of those who opposed allowing site links to redirect in the RFC. They make it visible within Wikidata whether an item is linked to proper Wikipedia pages which matters for notability. After a bot adds sitelink to redirect (Q70893996) to all existing redirects without badges, we can list those via SPARQL queries and can either remove the link when they aren't pointing to valid redirects or change them to intentional sitelink to redirect (Q70894304)). Adding Wikidata badges in Wikidata via a bot needs one bot approval within Wikidata. Adding a magic word to existing redirects would require a bot request on every Wikimedia project. The magic word solution also has the problem that if the information about the nature of the links is not stored in Wikidata requests to Wikipedia have to be made whenever a Wikidata page with sitelinks is loaded. Increasing the number of requests that have to be done when a Wikidata page is loaded is bad for performance. TASK DETAIL https://phabricator.wikimedia.org/T278962 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl 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] T297393: Implement basic version of mul language code and deploy to Test Wikidata
ChristianKl added a comment. The point of having 'mul' is to be able to reduce edits/per item. A person doesn't have a different name in Vietnamese than they have in English and thus storing the name in 'mul' instead of storing it in both 'en' and 'vi' saves edits. We are not displaying either the English or the Vietnamese name but something that's true for both (multiple) languages. Saving edits are valuable because of technical performance limits. It's also valuable because those edits take up space on the watchlist and the history of the items. 'mul' is not designed for storing information about Unicode emoticons. It's by it's nature designed for content that's language. 'zxx' would be the official code for the content that's not in any language like Unicode emoticons. Currently, when I search on test.Wikidata https://test.wikidata.org/w/index.php?search=John+Doe+II=John+Doe+II=Special%3ASearch=Go=1=1 for an item that only has a name "John Doe II" in 'mul' but not in any other language its name gets displayed on the search page as "John Doe II multiple languages (Q57591)". It would be desirable to not display "multiple language" here and present the item the same way it would have been if "John Doe II" would be the English label of the item. TASK DETAIL https://phabricator.wikimedia.org/T297393 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucas_Werkmeister_WMDE, ChristianKl Cc: ChristianKl, Bugreporter, Aklapper, Lydia_Pintscher, Manuel, Lucas_Werkmeister_WMDE, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, RhinosF1, Nandana, Lahi, Gq86, GoranSMilovanovic, Mahir256, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Nikki, 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] T285810: Enable a method of recording fair use images on Wikidata
ChristianKl added a comment. There's no such thing as a fair use image. There's fair use of images but no image has a property of being a fair use image. Integrating images from other Wikipedia's this way has the potential of making some of their images uses that are currently fair use not fair use anymore because it adds uses to the images. Such a functionality would infringe on the independence of other Wikiprojects. Hosting an image for the purpose of being referenced from elsewhere is not a purpose that's protected under US fair use law. We had a lot of discussions on Wikidata about the properties regarding fair use images we want to have and none of this discussions lead to having one to link to images stored in individual Wiki's that aren't stored in commons. If WMDE would create a functionality as you request, there's a good chance that the functionality wouldn't be used by Wikidata. It's bad form to search changes on Phabricator that go against consensus on Wikidata. The way we interact with Commons files works because there's only one Commons location. Any system that would allow multiple projects would need a way to specify which project is meant and URLs already do that. TASK DETAIL https://phabricator.wikimedia.org/T285810 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl Cc: ChristianKl, Lydia_Pintscher, Bugreporter, Tagishsimon, Sdkb, Aklapper, 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] T285810: Enable a method of recording fair use images on Wikidata
ChristianKl added a comment. In T285810#7185851 <https://phabricator.wikimedia.org/T285810#7185851>, @Sdkb wrote: > The note at WD:Talk seems premised on the idea that I'm proposing to host fair use images on Wikidata, not just link to them. That's a misunderstanding. There's no reason to create a Phabrictor request when you want the ability to link to images. URL is already an existing datatype in Wikidata. The decision about what properties get created isn't one that belongs on Phabrictor but is made via property proposals. TASK DETAIL https://phabricator.wikimedia.org/T285810 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl Cc: ChristianKl, Lydia_Pintscher, Bugreporter, Tagishsimon, Sdkb, Aklapper, 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] T236295: integrate exceptions as part of Wikibase datamodel of the entity concerned
ChristianKl added a comment. I still believe that is_exception_to_constraint in the reference section would be the best way. (I create the property proposal) TASK DETAIL https://phabricator.wikimedia.org/T236295 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl Cc: ChristianKl, Esc3300, Lucas_Werkmeister_WMDE, Aklapper, Bugreporter, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, abian, 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] T182147: more convenience functions for Lua
ChristianKl added a comment. mw.wikibase.getAliasesByLang would be useful, so that it's not necessary to load the whole item to access the aliases. TASK DETAIL https://phabricator.wikimedia.org/T182147 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl Cc: ChristianKl, Thayts, Simon_Villeneuve, Pigsonthewing, Lea_Lacroix_WMDE, jberkel, RolandUnger, Agabi10, RexxS, Vriullop, MisterSynergy, Ghuron, Uzume, putnik, Jonas, aude, hoo, Ladsgroup, Tpt, thiemowmde, eranroz, Aklapper, Lydia_Pintscher, Akuckartz, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T182147: more convenience functions for Lua
ChristianKl added a comment. It would be great to have a getValidStatements() function that works the same as getAllStatements() but filters out deprecated statements. Deprecated Wikidata statements are often of no use outside of Wikidata and usecases like listing the children of a person outside of Wikidata shouldn't list deprecated children. Without a decidated function there are plenty fo cases where users will forgot to filter out deprecated statements and then show Wikipedia users data Wikidata knows to be false as valid data. TASK DETAIL https://phabricator.wikimedia.org/T182147 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl Cc: ChristianKl, Thayts, Simon_Villeneuve, Pigsonthewing, Lea_Lacroix_WMDE, jberkel, RolandUnger, Agabi10, RexxS, Vriullop, MisterSynergy, Ghuron, Uzume, putnik, Jonas, aude, hoo, Ladsgroup, Tpt, thiemowmde, eranroz, Aklapper, Lydia_Pintscher, Akuckartz, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T43807: Support for pseudo-language "mul" to indicate multilingual content
ChristianKl added a comment. The main intention is to have Wikidata Labels and Aliases in //mul//. I would expect that Wikilambda will also lead to Wiki-pages that are best classified as //mul// but this can be it's own task when it's needed. TASK DETAIL https://phabricator.wikimedia.org/T43807 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl Cc: Lydia_Pintscher, Infovarius, Multichill, ChristianKl, jhsoby, adrianheine, Aklapper, Logicwiki, Nikola_Smolenski, liangent, Wikidata-bugs, siebrand, Nemo_bis, SPQRobin, Denny, iecetcwcpggwqpgciazwvzpfjpwomjxn, DanielFriesen, Liuxinyu970226, Nikerabbit, daniel, Seb35, Af420, MuhammadShuaib, LNDDYL, Psychoslave, Arrbee, KartikMistry, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T212313: Add monolingual language code en-in (Indian English)
ChristianKl added a comment. Wikidata has lexemes in addition to items. Lexemes need language codes to express to which language a lexeme belongs. To create lexemes that tell us that vote banks is a term in en-in that corresponds to vote block in en-us we need lexemes. TASK DETAIL https://phabricator.wikimedia.org/T212313 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl Cc: ChristianKl, Nirmos, Amire80, MJL, 1234qwer1234qwer4, Ammarpad, Marsupium, Jdickins42, Liuxinyu970226, Mbch331, jhsoby, GerardM, Manu1400, Aklapper, Bluerasberry, Annysah01, Rohitgeddam, Akuckartz, Soda, Chaytanya, wiki-helenatxu, Viztor, 94rain, Dinadineke, DannyS712, Nandana, Kieubinhtb, Tks4Fish, lucamauri, Mh-3110, tabish.shaikh91, Asad_Ali_Palijo, Lahi, Gq86, GoranSMilovanovic, Soteriaspace, Jayprakash12345, JakeTheDeveloper, QZanden, merbst, LawExplorer, _jensen, rosalieper, xSavitar, Scott_WUaS, MuhammadShuaib, Nikki, Tmalhotra, SimmeD, Wikidata-bugs, Snowolf, aude, Shizhao, TheDJ, Rxy ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] T191831: Track implicit use of non-overridden wikidata description
ChristianKl added a comment. The ticket looks to me more like it's about the option of filtering within Wikibase which is a slightly different concern then the filtering over at Wikipedia. At Wikipedia we have the situation that plenty of editors don't want to see Wikidata changes that don't affect Wikipedia. It might be that there's a shared foundation for both but the user experience needs are different. TASK DETAIL https://phabricator.wikimedia.org/T191831 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl Cc: ChristianKl, Zache, Nirmos, Lydia_Pintscher, Masssly, Lucas_Werkmeister_WMDE, Ladsgroup, hoo, TomT0m, Bencemac, Addshore, Lea_Lacroix_WMDE, Aklapper, Tgr, 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] T191831: Track implicit use of non-overridden wikidata description
ChristianKl added a comment. The acceptance criteria doesn't specify how this feature interacts with "Show Wikidata edits in your watchlist". I assume it's bundled into that option, but it would be nice to be explicit about that. It's unclear to me whether it's good to bundle all the Wikidata edits into the same option on the watchlist. Given experienced Wikipedia users options to configure a feature like this to show them the edits that they want to see and not those that they don't want to see helps with acceptance of Wikidata in the Wikipedia's even if it bloads the UI and makes the configuration more complicated for new users. It might be possible to convince a wiki like dewiki to activate showing changes in German Wikipedia descriptions by default but not to convince them to show edits to Wikidata statements by default (especially as long as the statements can't be filted for those that affect Wikipedia). TASK DETAIL https://phabricator.wikimedia.org/T191831 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl Cc: ChristianKl, Zache, Nirmos, Lydia_Pintscher, Masssly, Lucas_Werkmeister_WMDE, Ladsgroup, hoo, TomT0m, Bencemac, Addshore, Lea_Lacroix_WMDE, Aklapper, Tgr, 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] T235420: Create wikidata badges to indicate when sitelinks point to Wikipedia redirect pages
ChristianKl added a comment. Given that we now have the badges, I think it would make sense to automatically apply the batch when creating a sidelink to a redirect and not just allow people to create unbadged sitelinks to redirects. TASK DETAIL https://phabricator.wikimedia.org/T235420 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Ladsgroup, ChristianKl Cc: ChristianKl, seav, kaldari, Eugene, Naseweis520, DemonDays64, DannyS712, Ladsgroup, Gamaliel, Fuzheado, ItamarWMDE, JAnD, Hsarrazin, deryckchan, agray, Lydia_Pintscher, MisterSynergy, Aklapper, Liuxinyu970226, Jheald, Alter-paule, Hazizibinmahdi, Beast1978, Un1tY, Akuckartz, Hook696, Iflorez, darthmon_wmde, Kent7301, alaa_wmde, joker88john, CucyNoiD, Nandana, Gaboe420, 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] T261275: incorrect sitelink deletion behavior when page is moved to non-supported namespace with "suppress redirect" option
ChristianKl added a comment. I'm not sure this is the best way to frame the problem. The acceptance criteria don't cover the case where an article gets deleted but the redirect stays. I think the core problem is that it's currently unknown to Wikidata whether a sitelink points to a normal page, a redirect or to a nonexisting page. Ideally, it would be both visible when visiting an item and looking at the list of sitelinks and via SPARQL. Then a normal Wikidata bot could clean up. It's worth noting that not every Wikipedia admin who deletes a page necessarily has the right to edit the respective Wikidata item as he might not be autoconfirmed on Wikidata and the page is protected. As such the user account can't remove links in all cases when a bot on Wikidata could. TASK DETAIL https://phabricator.wikimedia.org/T261275 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl Cc: ChristianKl, Mohammed_Sadat_WMDE, Aklapper, Lydia_Pintscher, 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] T206392: Redesign rank icons for better visibility
ChristianKl added a comment. Ordering is generally useful (but can create issues as pointed out by @MichaelSchoenitzer) but it doesn't help a user to understand the concept of deprecated statements and why we have wrong data on Wikidata that we mark as deprecated. The ordering issues could be worked out by allowing ordering to order statements with higher //point in time// over statements with lower //point in time//. I'm unsure about whether it makes sense to program a new ordering solution that only takes in account ranks but not qualifiers (and a syntax that allows Wikidata users to specify which qualify should affect the ranking in what way). Intuitively, I don't think using color to express the ranks is a good idea. The watermarks also don't look good to me. Bolding/normal text/strike-through seems to me like it would be easily understood by new users. Using strikethrough to mark deprecation is an existing UX pattern that Intellij already uses and even users who don't understand it in the formal meaning as deprecation can easily understand that Wikidata doesn't claim that a statement is true when it gets shown with strikethrough. I do think we need an icon even for the default rank because clicking on the icon is necessary to change the rank. If there's no icon it's harder to discover how to change the rank. I have doubts that the icons that we have are ideal. I think it would be great to have usability tests with new users to see whether the alternative icons proposed by Michael could be an improvement about the status quo (of course other icon sets could be even better). TASK DETAIL https://phabricator.wikimedia.org/T206392 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl Cc: ChristianKl, MathTexLearner, Moebeus, Salgo60, Lea_Lacroix_WMDE, Mattia_Capozzi_WMDE, MisterSynergy, Tkarcher, Kristbaum, Lydia_Pintscher, MichaelSchoenitzer, Aklapper, cristiana023, Akuckartz, 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] [Created] T254434: Provide a list instead of "Warning: Other pages link to or transclude the page you are about to delete."
ChristianKl created this task. ChristianKl added a project: Wikidata. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION Currently, when deleting a page on Wikidata the deletion interface shows "Warning: Other pages link to or transclude the page you are about to delete" when other pages link to the page. The intention of this feature is to warn an admin who deletes an item that a page might be needed elsewhere. Many pages that we want to delete are linked from other pages like the list of request for deletions and https://www.wikidata.org/wiki/User:Pasleim/notability . It would be great if whenever there are other pages a list of the first five pages could be shown on the deletion page with a link titled "See more" when there are more then five pages that link to the page that is to be deleted. This would speed up the deletion workflow because it will take less effort to always visit the page that lists the incoming links and it will also prevent pages that shouldn't be deleted from being accidently deleted. TASK DETAIL https://phabricator.wikimedia.org/T254434 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl Cc: Aklapper, ChristianKl, 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] T43807: Support for pseudo-language "mul" to indicate multilingual content
ChristianKl added a comment. This task was opened a while ago, but stalled. I think currently, we have a consensus on Wikidata that it would be desireable to have "mul" and "mul-Latn" as languages within Wikidata. Some discussions: https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2019/08#Biggest_missing_feature https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2019/06#Multiple_languages https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2019/06#Multilanguage_label TASK DETAIL https://phabricator.wikimedia.org/T43807 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl Cc: ChristianKl, jhsoby, adrianheine, Aklapper, Logicwiki, Nikola_Smolenski, liangent, Wikidata-bugs, siebrand, Nemo_bis, SPQRobin, Denny, iecetcwcpggwqpgciazwvzpfjpwomjxn, DanielFriesen, Liuxinyu970226, Nikerabbit, daniel, Seb35, Af420, MuhammadShuaib, LNDDYL, Psychoslave, Arrbee, KartikMistry, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T236490: WD's summary message for an automatic replication of a WP's update should credit bot-like instead of original WP editor
ChristianKl added a comment. If a bot would make this job, the bot could be able to also move the page when the item is semiprotected which would be desirable. TASK DETAIL https://phabricator.wikimedia.org/T236490 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: ChristianKl Cc: ChristianKl, Pigsonthewing, MisterSynergy, Aklapper, ContributorQ, 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] [Created] T230134: {{Ping project|}}-template bugs
ChristianKl created this task.
ChristianKl added a project: Wikidata.
Restricted Application added subscribers: Liuxinyu970226, Aklapper.
TASK DESCRIPTION
The {{Ping project|}}-template frequently lists all the participants on the
page where the ping is made. For example at
(https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/contact_area_count=993832658)
this error seems to happen sometimes and not at other times. Given that
ping-project is an important way of communication for Wikidata it would be
great if it's functionality could be updated to avoid this bug.
While we are at the functionality of the template, the alert the user gets an
alert like " Eihel mentioned you on Wikidata:Property proposal/MESH Concept
ID in "Discussion"." for being pinged as being part in Wikiproject Medicine
(https://www.wikidata.org/wiki/Wikidata:Property_proposal/MESH_Concept_ID#Discussion).
It would be great if the text of the notification could related to the
Wikiproject instead of saying "mentioned you".
TASK DETAIL
https://phabricator.wikimedia.org/T230134
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: ChristianKl
Cc: Aklapper, ChristianKl, Liuxinyu970226, 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] [Commented On] T214355: Improve wording of page connection notification
ChristianKl added a comment. Given that this message is likely for many people the first time they get in contact with Wikidata it would be good to have it be friendly in addition to reciting correct facts. We might even have a "Read more" link in it to allow the recipient of the message to inform themselves better about Wikidata in case they are curious.TASK DETAILhttps://phabricator.wikimedia.org/T214355EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ammarpad, ChristianKlCc: ChristianKl, Lydia_Pintscher, Lucas_Werkmeister_WMDE, Ammarpad, Aklapper, matej_suchanek, Nandana, Lahi, Gq86, GoranSMilovanovic, Jayprakash12345, QZanden, LawExplorer, _jensen, Srdjan_m, MuhammadShuaib, LNDDYL, Psychoslave, Wikidata-bugs, aude, Gryllida, Shizhao, Arrbee, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T212422: Request deletion should create {{Q|Q12345}} instead of {{Q|Q12345}} as the title of deletion requests
ChristianKl created this task.ChristianKl added a project: Wikidata.Restricted Application added a subscriber: Aklapper. TASK DESCRIPTIONCurrently, the titles of the deletion requests for items on Wikidata aren't human-readable. Having them human readable by using the template would make it easier to engage with the deletion requests.TASK DETAILhttps://phabricator.wikimedia.org/T212422EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] [Commented On] T193728: Address concerns about perceived legal uncertainty of Wikidata
ChristianKl added a comment. I'm linking to a page on OpenStreetMap.TASK DETAILhttps://phabricator.wikimedia.org/T193728EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: ChristianKl, Alsee, Aklapper, Huji, ArthurPSmith, SimonPoole, Scott_WorldUnivAndSch, Micru, lisong, Lofhi, Nemo_bis, TomT0m, jrbs, EgonWillighagen, sarojdhakal, Agabi10, NMaia, Simon_Villeneuve, Jarekt, Rspeer, OhKayeSierra, AndrewSu, Mateusz_Konieczny, Maxlath, Glrx, Realworldobject, Ltrlg, Papapep, Tgr, Ayack, Gnom1, MichaelMaggs, MisterSynergy, Pasleim, Cirdan, 0x010C, Sylvain_WMFr, Denny, Ivanhercaz, Pintoch, Lydia_Pintscher, Lea_Lacroix_WMDE, Psychoslave, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, D3r1ck01, 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: Address concerns about perceived legal uncertainty of Wikidata
ChristianKl added a comment. On the copyright of maps OpenStreetMap suggests: Instead courts now instead look closely for evidence of originality in either the aesthetic choices made in rendering the map or in the selection of aspects included. Note, however, that mere color choices or basic styling of components of the map are not themselves significant enough to warrant protection. [...] In instances when contributions come in the form of raw GPS paths, they are unlikely to be deemed independently copyrightable given that they are simply a set of GPS coordinates. I don't see why the extra 6 digits of information should be regarded as aesthetic choices or selection of aspects of a map. They are more like the simple set of GPS coordinates.TASK DETAILhttps://phabricator.wikimedia.org/T193728EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: ChristianKl, Alsee, Aklapper, Huji, ArthurPSmith, SimonPoole, Scott_WorldUnivAndSch, Micru, lisong, Lofhi, Nemo_bis, TomT0m, jrbs, EgonWillighagen, sarojdhakal, Agabi10, NMaia, Simon_Villeneuve, Jarekt, Rspeer, OhKayeSierra, AndrewSu, Mateusz_Konieczny, Maxlath, Glrx, Realworldobject, Ltrlg, Papapep, Tgr, Ayack, Gnom1, MichaelMaggs, MisterSynergy, Pasleim, Cirdan, 0x010C, Sylvain_WMFr, Denny, Ivanhercaz, Pintoch, Lydia_Pintscher, Lea_Lacroix_WMDE, Psychoslave, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, D3r1ck01, 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] [Created] T198466: Show the names of items in the Notification list
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONF23071869: image.png This is how the Notification list currently looks for me. It would be really great if instead of showing the numbers it would show me the actual name of the items in question.TASK DETAILhttps://phabricator.wikimedia.org/T198466EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] T54564: Allow sitelinks to redirect pages to fix the 'Bonnie and Clyde problem'
ChristianKl added a comment. The constraint that it has to be symmetric would be removed by the RfC through allowing the redirect links. One those links are there it would be possible to provide additional links via a plugin to link from an English "Bonnie and Clyde" article to a German "Bonnie" and a German "Clyde" article provided there's no German "Bonnie and Clyde" article.TASK DETAILhttps://phabricator.wikimedia.org/T54564EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Alsee, Capankajsmilyo, Eugene, PokestarFan, ArthurPSmith, Pasleim, StudiesWorld, daniel, Metamorforme42, JEumerus, Harmonia_Amanda, Ash_Crow, DannyH, Agabi10, Choomaq, IKhitron, QZanden, thiemowmde, Toto256, Acer, Elitre, Sylvain_WMFr, Lea_Lacroix_WMDE, Schlum, TomT0m, Thryduulf, Rich_Farmbrough, Zppix, ChristianKl, Mike_Peel, Wittylama, Liuxinyu970226, SebastianHelm, 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, Lahi, Gq86, GoranSMilovanovic, LawExplorer, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T183341: New item fails (Special and WEF tool)
ChristianKl added a comment. Could there be an option that a limit only kicks in when there's no free server capacity? It seems to me like we need a limit at times where no free server capacity is available but don't need it other times.TASK DETAILhttps://phabricator.wikimedia.org/T183341EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: ChristianKl, daniel, Lydia_Pintscher, Daniel_Mietchen, mark, jcrespo, Marostegui, Ladsgroup, Aklapper, Billinghurst, Rayssa-, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T183243: The fulltext search engine should rank items with human edits higher than bot edits
ChristianKl added a comment. Scientific articles are one class of entities where this problem exists and given that they have more words in the title and we have >10 million of them they are the most important. In the past with the old search I however remember similar issues with songs and geonames derived geographic items as well. If we would import those 2 million German companies, they would likely also produce a lot of hits. I'm okay, with fixing it by deranking scientific articles specifically but I would expect that even if we derank any class of entries that are problematic at the moment sooner or later we will add a new big dataset by bot that brings up search results that would be better to not outrank human created items.TASK DETAILhttps://phabricator.wikimedia.org/T183243EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Lydia_Pintscher, Sjoerddebruin, Smalyshev, Aklapper, ChristianKl, Lahi, Gq86, GoranSMilovanovic, QZanden, EBjune, LawExplorer, Avner, Gehel, FloNight, 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] T183243: The fulltext search engine should rank items with human edits higher than bot edits
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONWikicite created many Wikidata items and that's great but sometimes that makes searching hard. If I type "heart rhythm" in the newly proposed search engine it doesn't manage to list the correct item at the top. There are similar concerns for other bot created articles in geology, musical songs and films. I think a good solution would be to store the amount of human edits that each item gets as a variable that's meaningful for the search ranking. Items about scientific articles that don't have any human edit should be downranked as a result.TASK DETAILhttps://phabricator.wikimedia.org/T183243EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, Lahi, Gq86, GoranSMilovanovic, QZanden, 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] T183135: The webfrontend of the query service doesn't honor precision
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONIn https://www.wikidata.org/wiki/Wikidata:Project_chat#Precision_of_date a user describes that he would have expected "publication date = 2013" in the normal Wikidata interface to be also shown as 2013 in the webinterface of the query service. Currently, the webfrontend however ignores the data about the precision completely and outputs "Jan 1, 2013" Example query: https://query.wikidata.org/#SELECT%20%3Finstance_of%20%3Fpublication_date%20WHERE%20%7B%0A%20%20%3Finstance_of%20wdt%3AP31%20wd%3AQ26973022.%0A%20%20%3Finstance_of%20wdt%3AP50%20wd%3AQ44942293.%0A%20%20OPTIONAL%20%7B%20%3Finstance_of%20wdt%3AP577%20%3Fpublication_date.%20%7D%0A%7D%0ALIMIT%2050TASK DETAILhttps://phabricator.wikimedia.org/T183135EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, Lahi, Gq86, GoranSMilovanovic, QZanden, 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] T183100: Restrict the ability of users to choose enwiki Draft: namespace for Wikidata interwiki links
ChristianKl added a comment. From Lydia: I believe we can restrict links to specific namespaces in the config. I think that would be better than an abuse filter for performance reasons. Anyone up for creating a ticket? It might be useful to replace the existing abuse filters for user pages, template subpages and files as well with limits via config if that's good for performance reasons.TASK DETAILhttps://phabricator.wikimedia.org/T183100EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: ChristianKl, Aklapper, Billinghurst, Lahi, Gq86, GoranSMilovanovic, QZanden, 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] T54971: [Goal] Sitelinks to Incubator, OldWikisource and BetaWikiversity
ChristianKl added a comment. I'm of the opinion, that it's not our role of Wikidata to create pseudo-fake websites. In most of the relevant cases it would make sense to actually have real websites. The langcom policy that prevents the creation of those sites is the core problem and a meta RfC to change it would be the best way forward. C933103 already started a draft for the RfC. As far as mul.ws goes, can you point to examples where we have Wikidata items that would want to multiple pages on mul.ws?TASK DETAILhttps://phabricator.wikimedia.org/T54971EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Sannita, Superchilum, ChristianKl, daniel, Bugreporter, PokestarFan, gh87, Koavf, StevenJ81, Samwilson, Esc3300, srishakatux, C933103, Stashbot, hoo, aude, JanZerebecki, TTO, Liuxinyu970226, Accurimbono, Aklapper, Ricordisamoa, Purodha, liangent, Wikidata-bugs, Vogone, Candalua, SPQRobin, mxn, Filceolaire, jayvdb, Micru, revi, Billinghurst, Lydia_Pintscher, MF-Warburg, zhuyifei1999, Tpt, Abo00tamr, Lahi, Gq86, GoranSMilovanovic, QZanden, Wong128hk, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T91535: Performance issues with tags
ChristianKl added a comment. I'm not sure why Lydia linked to this task. If you think that the proposed check causes no performance that would be great. If it produces other performance issues it would be good to know.TASK DETAILhttps://phabricator.wikimedia.org/T91535EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Cenarium, ChristianKlCc: ChristianKl, daniel, Trizek-WMF, Tbayer, aaron, matej_suchanek, Liuxinyu970226, gerritbot, TTO, Cenarium, Aklapper, Cpaulf30, Lahi, Gq86, Baloch007, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Vali.matei, Lewizho99, Maathavan, Volker_E, MGChecker, Luke081515, 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] [Commented On] T91535: Performance issues with tags
ChristianKl added a comment. Lydia linked me here. In my current draft for a living persons policy (https://www.wikidata.org/wiki/Wikidata:Living_persons_(draft)) I have a portion that suggests that for every bot edit that a bots that doesn't have a specific "living persons" flag, the bot is supposed to check whether the item is about a living person and if so check whether the property that gets added subclasses Q44597997 or Q44601380. I don't want to write policy that produces major scalability problems. Do you think it's doable to change the software in a way that such a check isn't a performance problem or would you recommend to skip that part of the policy?TASK DETAILhttps://phabricator.wikimedia.org/T91535EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Cenarium, ChristianKlCc: ChristianKl, daniel, Trizek-WMF, Tbayer, aaron, matej_suchanek, Liuxinyu970226, gerritbot, TTO, Cenarium, Aklapper, Cpaulf30, Lahi, Gq86, Baloch007, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Vali.matei, Lewizho99, Maathavan, Volker_E, MGChecker, Luke081515, 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] [Created] T181911: Allowing new Wikibase instances to use Wikidata Q numbers in addition to their own identifiers for items
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONOne of the core issues we had when discussing FactGrid was, that there's an interest to integrate as much as possible of Wikidata into FactGrid but this will likely lead to having items inside the database that aren't well maintained. One solution would be to have FactGrid give it's own items numbers like F1234. A statement that links to a new item could link either to FXXX or to QXXX. In any search for a new item all the FXXX items could simply be made to outrank the FXXX items. There could be a one-click way to copy a QXXX item into the FXXX namespace. Native properties could go to the G namespace. In the short term this is likely more development effort than writing bots to copy over specific information to FactGrid. More long-term it could however be very benefitial because it reduces data rod and a once developed extension could be used in the future also by other Wikibase installations.TASK DETAILhttps://phabricator.wikimedia.org/T181911EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, Lahi, Gq86, GoranSMilovanovic, QZanden, 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] T181910: Native support of merging inside of Wikidata
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONCurrently, merging in Wikidata happens through a combination of a Gadget and a bot. The gadget has to be enabled via the settings. After an item gets merged it takes some time and then KrBot replaces links to the obsolate item with links to the item in which both items get merged. This hacky way has two problems: New Wikibase editions that don't have KrBot, won't get the same merging. Undoing merging takes a lot more than one click. Given that undoing merging takes more than one click, we make merging harder for newbies by not activating the merging function by default and as a result we get less merging than is desireable. Our new item creation dialog suggests that a newbe who accidently created a dublicate item isn't supposed to merge it but is to request deletion of the item. Given that WMDE recently made a strategic decision to push secondary Mediawiki installations and a project like FactGrid likely need merging from time to, it seems to me that this task deserves more development priority then it would otherwise have. Having a functionality that bundles multiple content changes together to one merge that can be undone with one click might need new core functionality. That core functionality might be designed in a way that also always the undoing of a batch of QuickStatements with one click. Even when working on that level is hard because it goes into deeply into what the unit of an edit happens to be in MediaWiki I think it's worth to look at this because it will make scaling in general easier.TASK DETAILhttps://phabricator.wikimedia.org/T181910EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, Lahi, Gq86, GoranSMilovanovic, QZanden, 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] T181331: The echo-notifications for an item that links to an item you created currently only show IDs instead of the label
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONF10993374: echonotification.bmp On Wikidata echo-notifications tell you if someone links to an item that you created. Currently, the notification only shows the ID of the label so that it's necessary to actually click through to the actual item to know what links to what. I would recommend to show the labels of the items instead of the IDs.TASK DETAILhttps://phabricator.wikimedia.org/T181331EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, Lahi, Gq86, GoranSMilovanovic, QZanden, 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] T180460: Preselect the unit with units used for this property (P2237) prefered rank when entering new values
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONI'm in the process of entering information for payload mass (P4519). Currently, I copy paste the information in the form of "13,150 kg". When I paste it into the statement I can't immediately click save. First I have to remove the kg. Then I have to click on the field for the unit. After writing kg I have to select the second choice (the system things Kazakhstan could be my first choice for a unit). This process is needlessly complex given that kg (kilogram) is already set as preferred "used for this property (P2237)".TASK DETAILhttps://phabricator.wikimedia.org/T180460EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, Lahi, GoranSMilovanovic, QZanden, 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] T180311: Deleting a page that's on a deletion list gives a warning that other pages link to it
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONI chose to delete Q43024662. When I click on the deletion action I get shown: "Warning: Other pages link to or transclude the page you are about to delete." When I click on the list it shows: Wikidata:Requests for deletions (← links | edit) Wikidata:Requests for deletions/All (← links | edit) User:MisterSynergy/sysop/empty items (← links | edit) Those three aren't reasons to warn me and a lot of deletion candidates show up on those links. The fact that the lists trigger the warning creates a lot of false alarms and thus it encourages admins to simply ignore the warning. It would be good to have a list of websites that get ignored for the purposes of the deletion warning.TASK DETAILhttps://phabricator.wikimedia.org/T180311EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, Lahi, GoranSMilovanovic, QZanden, 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] T137810: [Task] Add monolingual language code mn-Mong
ChristianKl added a comment. I there a reason against creating the language as mvf with the name Peripheral Mongolian?TASK DETAILhttps://phabricator.wikimedia.org/T137810EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: ChristianKl, C933103, jhsoby, thiemowmde, Liuxinyu970226, Lydia_Pintscher, GerardM, Aklapper, Zppix, Popolon, Lahi, GoranSMilovanovic, QZanden, 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] T179792: Watching more pages in Wikidata
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONOne of Wikidata core problems at the moment is that it doesn't have enough review of edits and thus vandalism doesn't often takes a while to get reverted. This is partly because information is spread over more different pages than on Wikipedia. If you imagine that you have 10 Wikidata items that got each edited by 3 people for a total of 10 edits each on the one hand and one Wikipedia article with 100 edits by 30 people, the amount of edits that both pages have is the same. The Wikipedia article is on the watchlist of many people and on the other hand the Wikidata items are only watched by three people. What could be done to change this? Currently, pages are put on a watchlist if new statements get created however only the page on which the statement is made is added to the watchlist. We need more event where pages get added to watchlists: Adding properties to the watchlist when they are used Add the linked property to the watchlist That means when I add the statement "hand" "anatomical location" "free upper limb" I add all the pages to my watchlist plus the relevant talk pages. At the time of this writing the talk page for "anatomical location" has a "Number of page watchers who visited recent edits" of 4. That means that it's not possible to have a discussion about how the property should be used with other people who use the property. When we automatically add the property when it gets used to the watchlist this suddenly means it's possible to have a discussion about how "anatomical location" should be used that gets seen by the people who use the property. That's valuable for standardizing it's usage. It will get new users sooner into contact with discussions with other users. The second issue that gets solved is the ability to clean up vandalism to the labels of highly used properties and items fast. As Wikidata gets used more it becomes also more unacceptable that it takes hours to revert vandalism on the item of a country. This change would increase the watchers of such highly used pages enough that the vandalism reverting will get fast. Does this create a watchlist overload? There should be the possibility on "Preferences/Watchlist" to turn off this feature. Having the option is in line with the current ability to manage which pages get added to the watchlist. This possibility will allow high activity users to solve the problem for them. On the other hand, this feature might increase the need for the ability to filter the watchlist by language. If you have 5,000 people following the item Germany and you have 20 seldomly used languages who add labels to it, it's likely not efficient that 5,000 people who can't read the language see the item. The work required for filtering seems doable and not directly urgent.TASK DETAILhttps://phabricator.wikimedia.org/T179792EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, Lahi, GoranSMilovanovic, QZanden, 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] T175230: Wikidata identifier links don't respect nofollow configuration
ChristianKl added a comment. Quora links to us with do-follow and we link to them with do-follow. In this case, I don't see a problem.TASK DETAILhttps://phabricator.wikimedia.org/T175230EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: ChristianKl, Nemo_bis, Aklapper, Lahi, GoranSMilovanovic, QZanden, 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] T168936: SPARQL shouldn't display more digits of accuracy than are available
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONNew York has an area of 1,214±1 square kilometres and a population of 8,405,837±0. The given that only 4 digits of accuracy are known for the area the resulting division for the density that's displayed in http://tinyurl.com/y7m8u7c9 shouldn't show more than 4 digits of accuracy. Currently, it shows the value "7043.16803953871499" and that's a lot of digits than warrented.TASK DETAILhttps://phabricator.wikimedia.org/T168936EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] T168772: Display mathematical formula correctly in the query service
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper.
TASK DESCRIPTIONCurrently, the query https://query.wikidata.org/#SELECT%20%3Fitem%20%3FitemLabel%20%3Fvalue%20%3FvalueLabel%0A%7B%0A%09%3Fitem%20wdt%3AP4020%20%3Fvalue%20.%0A%09SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22en%2Cen%22%20%20%7D%20%20%20%20%0A%7D%0ALIMIT%201000 shows:
L 3 {\displaystyle L^{3}}
instead of rendering the formula.TASK DETAILhttps://phabricator.wikimedia.org/T168772EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] T165600: Template to ping everybody who participated in a discussion
ChristianKl added a comment. I don't see a reason why VisualEditor should be tagged. If Template is the wrong group to ping for issues about templates I'm sorry.TASK DETAILhttps://phabricator.wikimedia.org/T165600EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Izno, Esanders, Aklapper, ChristianKl, Robinma, GoranSMilovanovic, QZanden, merbst, Wess, Jrf, Husun1297, Wikidata-bugs, aude, Mvolz, Swainr, Jdforrester-WMF, Mbch331, Jay8g, Ltrlg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T54564: Allow sitelinks to redirect pages to fix the 'Bonnie and Clyde problem'
ChristianKl added a comment. I created an RFC: https://www.wikidata.org/wiki/Wikidata:Requests_for_commentTASK DETAILhttps://phabricator.wikimedia.org/T54564EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Agabi10, Choomaq, IKhitron, QZanden, thiemowmde, Toto256, Acer, Elitre, Sylvain_WMFr, Lea_Lacroix_WMDE, Schlum, TomT0m, Thryduulf, Rich_Farmbrough, Zppix, ChristianKl, Mike_Peel, Wittylama, Liuxinyu970226, SebastianHelm, 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, GoranSMilovanovic, aude, Jackmcbarn, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T166464: Display the Links to Wiki that are in a language that I speak with a different shade of gray
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONWhen it comes to a list of 30 interwiki links it's costs a bit of time to scan the list to find [de] and [en]. Those are the languages I speak and care about. I think it would be valuable if [de] and [en] would have a lighter shade of gray as background, so that they are easier to spot. The color change could be done client-side after the rest of the page has loaded, so it doesn't add to page loading time.TASK DETAILhttps://phabricator.wikimedia.org/T166464EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] T54564: Allow sitelinks to redirect pages to fix the 'Bonnie and Clyde problem'
ChristianKl added a comment. @Agabi10 I don't think that's an issue in practice. Wikipedia tells a user on top of the page that they are redirected. I have created dozen's of redirects and haven't seen one getting removed. Redirects aren't only useful for the Bonnie and Clyde for interwiki links. Even if all languages decides to have "Bonnie and Clyde" articles instead of separate "Bonnie" and Clyde" articles it's still useful for a user who browses the Wikidata entry of "Bonnie" to go via the redirect to the "Bonnie and Clyde" article. Take an article like https://de.wikipedia.org/wiki/Liste_der_Stra%C3%9Fen_und_Pl%C3%A4tze_in_Berlin-Halensee that lists individual streets in a small part of Berlin. The individual streets are notable according to Wikidata standards but not notable according to de.Wikipedia standards. Finally, if you think that's a problem that there's no indicator in Wikidata that it's a redirect link, that problem is easily solved by adding an icon in front of the link that indicates that it's a redirect.TASK DETAILhttps://phabricator.wikimedia.org/T54564EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Agabi10, Choomaq, IKhitron, QZanden, thiemowmde, Toto256, Acer, Elitre, Sylvain_WMFr, Lea_Lacroix_WMDE, Schlum, TomT0m, Thryduulf, Rich_Farmbrough, Zppix, ChristianKl, Mike_Peel, Wittylama, Liuxinyu970226, SebastianHelm, 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, GoranSMilovanovic, aude, Jackmcbarn, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T166431: Write out the name of the language when adding a new label
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONCurrently, the summary for adding a new alias in Wikidata for Macedonian in the watchlist is: (Added Macedonian alias: XY) The summary for changing a label is: (Changed Macedonian label: XY) However, the summary for adding a new label is: (Added [mk] label: XY) In many cases, the language code isn't easy for humans to understand and the name of the language is more valuable, therefore I think it would be good if the language would also be written out for adding a label.TASK DETAILhttps://phabricator.wikimedia.org/T166431EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] [Updated] T166211: The request for deletion page should use the {{Q|...}} template for listing the items
ChristianKl added a comment. It might be possible to simply change the https://www.wikidata.org/wiki/Template:Rfd_links template. If it's changed it might also be helpful to include the item description, P31/P279 when available, a statement count and an identifier count.TASK DETAILhttps://phabricator.wikimedia.org/T166211EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] T166211: The request for deletion page should use the {{Q|...}} template for listing the items
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper.
TASK DESCRIPTIONCurrently, https://www.wikidata.org/wiki/Wikidata:Requests_for_deletions lists the items by their number and doesn't show the name. The page would be more user-friendly if it would simply use the standard {{Q|...}} template.TASK DETAILhttps://phabricator.wikimedia.org/T166211EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] T165946: The property proposal overview should show the number of open proposals
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONCurrently it's not easy to see whether we make progress in reducing the amount of open proposals at https://www.wikidata.org/wiki/Wikidata:Property_proposal/Overview . Having a count at the top of the page would be motivating to get the count down.TASK DETAILhttps://phabricator.wikimedia.org/T165946EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] T165600: Template to ping everybody who participated in a discussion
ChristianKl created this task.ChristianKl added projects: TemplateData, Wikidata.Herald added a subscriber: Aklapper.Herald added a project: VisualEditor.
TASK DESCRIPTIONWhen new properties are on Wikidata it's a custom to ping all people who were involved in the discussion. There are also cases where a specific discussion is stalling and needs more input from everybody in the discussion.
It would be great if there would be a {{ping discussion}} template, that runs a regex over the text, grabs all the usernames of the people involved in the discussion and pings everybody.
I would expect that it's also useful on Wikipedia talk pages to have an easy way to ping everybody who's involved in a specific discussion.TASK DETAILhttps://phabricator.wikimedia.org/T165600EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, Robinma, GoranSMilovanovic, QZanden, merbst, Wess, Izno, Jrf, Husun1297, Wikidata-bugs, aude, Mvolz, Swainr, Jdforrester-WMF, Mbch331, Jay8g, Ltrlg___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T165301: SPARQL based list of recent changes
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONCurrently, there are mostly two ways to browse changes: Either you go to the general recent change list or you go to your own watchlist with the items to which you are subscribed. I myself would be interested in seeing the recent changes in all items that subclass Unfortunately, it's not easy to browse the recent changes in all items that are subclass "anatomical structure" but there's currently no way for me to do so. Our new property Wikidata SPARQL query equivalent (P3921) could also allow to help Wikipedia by providing Wikipedia editors with a way to the the recent changes in the Wikipedia that happen in a Category like Category:Ugandan writers.TASK DETAILhttps://phabricator.wikimedia.org/T165301EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] T165035: Property creation should use the current en-label in the proposal
ChristianKl added a comment. I think that this is case is the standard for property proposals and if the script could handle this case it would be a huge improvement.TASK DETAILhttps://phabricator.wikimedia.org/T165035EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: matej_suchanek, Aklapper, ChristianKl, 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] T165035: Property creation should use the current en-label in the proposal
ChristianKl added a comment. And is it really impossible to operate on the information in that in the text in which the template was inserted for the purpose of the template engine?TASK DETAILhttps://phabricator.wikimedia.org/T165035EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: matej_suchanek, Aklapper, ChristianKl, 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] T165035: Property creation should use the current en-label in the proposal
ChristianKl added a comment. Okay, I think I understand the problem. It seems we would need to move the label inside the property proposal template for it to be accessible in the same way the description is accessible. Is there a good reason against doing so?TASK DETAILhttps://phabricator.wikimedia.org/T165035EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: matej_suchanek, Aklapper, ChristianKl, 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] T165035: Property creation should use the current en-label in the proposal
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONCurrently when I click on "Create" in a property proposal the feature doesn't copy the label but headline. If I have the proposal "Wikidata:Property proposal/ALPG ID" on the page https://www.wikidata.org/wiki/Wikidata:Property_proposal/ALPG_ID the correct up-to-date label is "ALPG golfer ID" but that's not automatically copied. What's copied is "ALPG ID". This both produces additional work and opens up the possibility for making mistakes.TASK DETAILhttps://phabricator.wikimedia.org/T165035EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] T164931: Changing headline of property talk pages from "Property talk:P3915" to "Property talk:P3915 - Athletics Australia athlete ID"
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONWhen I look at my watchlist I see many changes in property talk pages. Unfortunately, they use only the ID of the property and say nothing about the name of the property. It would be great if we could change the headline from "Property talk:P3915" to "Property talk:P3915 - Athletics Australia athlete ID".TASK DETAILhttps://phabricator.wikimedia.org/T164931EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] T164392: [feature] Add notification when a page is disconnected from the item
ChristianKl added a comment. I'm also not sure what's meant with "creator of the page". There's a person who created the item. There's a person who created the article and then there's a person who added the link from the item to the article. Notifying the person who created the item doesn't seem right, given that they might not speak the relevant language.TASK DETAILhttps://phabricator.wikimedia.org/T164392EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: ChristianKl, Framawiki, Aklapper, matej_suchanek, Lydia_Pintscher, aude, Quiddity, Trizek-WMF, Liuxinyu970226, Ladsgroup, gerritbot, Stashbot, Mbch331, thiemowmde, Lea_Lacroix_WMDE, QZanden, TerraCodes, Johan, Izno, Luke081515, Wikidata-bugs, TheDJ, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T141866: Provide a way to filter Wikidata's recent changes for language-dependent content in specific languages
ChristianKl added a comment. From a privacy standpoint, I don't see why the language of an editor should be a secret. It's valuable information that helps other users to connect with the user. If I review language-agnostic content from users with whom I share no common language, my only choice is to revert the content or let it stand. I have no opportunity to explain the user why I reverted his edits. I would expect to allow non-English speaking people to focus on engaging with people with they share a common language to help them integrate themselves into Wikidata. Of course, I would also appreciate if a limited version of this request gets implemented that only focuses on the language specific content (label/description/alias).TASK DETAILhttps://phabricator.wikimedia.org/T141866EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Elitre, Tbayer, Jura1, Lydia_Pintscher, Aklapper, ChristianKl, 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] T163774: The query services seems to have a problem with the new geoshape datatype
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONIf I go to https://www.wikidata.org/wiki/Property_talk:P3896 and click on "Current Usage" the query finds no data, even though at least Q11299 uses the new property.TASK DETAILhttps://phabricator.wikimedia.org/T163774EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] T138295: [Task] Change Special:NewProperty to not have a datatype selected by default
ChristianKl added a comment. The standard way to create properties seems to be to click on "Create" in the property proposal. That automatically copies the description and the datatype. It's supposed to also copy the property name and actually copies the name of the property proposal page into the name field (when the name isn't changed in the property proposal discussion that's usually the name that the property should have). It might be that I misunderstood and you just change the behavior of SpecialNewProperty when that page is manually opened and not over the "Create" link?TASK DETAILhttps://phabricator.wikimedia.org/T138295EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, ChristianKlCc: gerritbot, ChristianKl, Micru, Lydia_Pintscher, daniel, Sjoerddebruin, Bugreporter, thiemowmde, Jonas, Aklapper, Zppix, Jan_Dittrich, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Lewizho99, Maathavan, SamanthaNguyen, JGirault, 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] T138295: [Task] Change Special:NewProperty to not have a datatype selected by default
ChristianKl added a comment. I'm not sure that this will reduce the amount of errors. Currently, the person who proposes the property sets the datatype. Afterwards, there are seven days where people can object to the proposal and the datatype that was selected. It takes at least one person to support the proposal the way it is. There's consensus for the datatype at the time it get's created. This proposal is basically about making it easier to create properties that don't have the datatype on which there's community consensus. Sometimes this will mean that the property creator reflects about the property again and recognizes that the community consensus is bad. Other times this will mean that the creator doesn't correctly copy the agreed upon consensus. What's your reasoning for believing that there will result in total in less errors? Especially given that it adds another manual action to the process.TASK DETAILhttps://phabricator.wikimedia.org/T138295EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, ChristianKlCc: ChristianKl, Micru, Lydia_Pintscher, daniel, Sjoerddebruin, Bugreporter, thiemowmde, Jonas, Aklapper, Zppix, Jan_Dittrich, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Lewizho99, Maathavan, SamanthaNguyen, JGirault, 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] T159600: The language list on top of Wikidata community pages should be able to be collapsed
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONA lot of screen real-estate on the top of https://www.wikidata.org/wiki/Wikidata:Project_chat and https://www.wikidata.org/wiki/Wikidata:Community_portal is spend on the list of languages. It would be great if it would be possible for a user to collapse the list. By default it might only list the languages that the user speaks in the same way that Wikidata items only show the labels in those languages.TASK DETAILhttps://phabricator.wikimedia.org/T159600EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] T139898: New gadget to aid property creation process
ChristianKl added a comment.
@Lydia_Pintscher Currently when I click on "Create property" the name that was used to create the property proposal get's copied into the English name category.
The actual name it's in the property proposal get's ignored. If the name changed during the property discussion, it's required to manually copy paste the new name.
The names and descriptions in other languages are currently completely ignored and have to be manually copied. A bot could copy them automatically.
Currently it's necessary to copy paste the {{property proposal}} template and rename it into {{property documentation}}. This task could be done by a bot.
Afterward, it's necessary to manually copy data from the {{property documentation}} and convert that data into Wikidata statements. In many cases this task could be done by a bot.
After a property proposal is either marked "done" or "not done" we have a custom to ping all involved participants. This currently has to be done manually and could be done via a bot.TASK DETAILhttps://phabricator.wikimedia.org/T139898EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: ChristianKl, Micru, Lydia_Pintscher, Josve05a, Edgars2007, Aklapper, Zppix, Bugreporter, dachary, D3r1ck01, 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] [Created] T158182: Provide a way to avoid loading all statements when opening a new Wikidata item
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONCurrently, we have items on Wikidata that contains tons of different properties that have the subproperty "Wikidata property for authority control". I think it would be great to be able to collapse all 'Wikidata properties for authority control' so that the page loading time is faster for a person who wants to browse the item without caring about the authority control statements. Apart from authority control, it seems to me like this would be useful for the items for countries as there are a lot of different statistics associated with a country.TASK DETAILhttps://phabricator.wikimedia.org/T158182EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] [Created] T157859: Allow normal users to tell StrepHit how to import data from a website for which a authority control property exists
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONOne thing that Wikidata does well at the moment is adding external ids for many items do to external databases. As far as I understand StrepHit paid in the past for data annotation and it's developer focused on getting the data import from specific websites and properties to work. This might not be a scalable way to solve the problem given that we add many new authority control properties every week. This means that many properties that are in the long tail currently don't get a benefit from StrepHit. The long tail is also a place where there's a higher chance that we develop data that Wikipedia doesn't already have than at a domain like football that's already well covered.TASK DETAILhttps://phabricator.wikimedia.org/T157859EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] T156470: Undo edits in Wikidata should automatically count as patrolled
ChristianKl added a comment. I have asked for rollback. At the same time I don't only think about myself ;)TASK DETAILhttps://phabricator.wikimedia.org/T156470EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Lydia_Pintscher, Dalba, wikibugs-l-list, JackPotte, Catrope, JeanFred, Krinkle, Nemo_bis, Ricordisamoa, bzimport, Pasleim, Sjoerddebruin, Micru, Aklapper, ChristianKl, 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] [Created] T156470: Undo edits in Wikidata should automatically count as patrolled
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONCurrently it's necessary to mark an edit as patrolled after having undone the edit because it's vandalism. That's unnecessary work. Edits should be automatically marked as patrolled when they are undone in Wikidata.TASK DETAILhttps://phabricator.wikimedia.org/T156470EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] T152019: Decide whether a Lexeme's lemma can have multiple representations for the same language code.
ChristianKl added a comment. Is a dialect a language for the purposes of this discussion?TASK DETAILhttps://phabricator.wikimedia.org/T152019EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: ChristianKl, Yair_rand, Jakob_WMDE, Denny, aude, Ladsgroup, thiemowmde, WMDE-leszek, Aklapper, daniel, D3r1ck01, Izno, Wikidata-bugs, Darkdadaah, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T150935: Make Alt+Shift+S work at more places
ChristianKl added a comment. I'm sorry I meant Alt+Shift+S. A lot of Alt+Shift hotkeys aren't used by the browswer or the operation system. Wikipedia assigns that hotkey traditionally to various functions. There's "Alt+Shift+S" to save a page that you edit. "Alt+Shift+E" to edit the page. "Alt+Shift+T" to go to the talk page. "Alt+Shift+C" to go to the article page. "Alt+Shift+V" to go to the visual editor. (You can see these by hovering about the buttons in Wikipedia) Wikidata directly copies some of those hotkeys. In many cases however Wikidata has functions that aren't mapped to hotkeys. Given that "Alt+Shift+S" is in general supposed to save statements, I think that hotkey should work more widely within Wikidata. I think it would be easy to make it work in those two instances.TASK DETAILhttps://phabricator.wikimedia.org/T150935EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Wikidata-bugs, Aklapper, ChristianKl, D3r1ck01, Izno, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T150935: Make Alt+Shift+S work at more places
ChristianKl changed the title from "Make Alt+Control+S work at more places" to "Make Alt+Shift+S work at more places".ChristianKl edited the task description. (Show Details) EDIT DETAILSThe standard way to save a page in Wikipedia is Alt+Control+SShift+STASK DETAILhttps://phabricator.wikimedia.org/T150935EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Wikidata-bugs, Aklapper, ChristianKl, D3r1ck01, Izno, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T150935: Make Alt+Control+S work at more places
ChristianKl created this task.Herald added a subscriber: Aklapper. TASK DESCRIPTIONThe standard way to save a page in Wikipedia is Alt+Control+S. It woud be great if the hotkey works to safe the Labels/description/alias list. It would also be great if it would be linked to the Create button for the formula to create new items.TASK DETAILhttps://phabricator.wikimedia.org/T150935EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Wikidata-bugs, Aklapper, ChristianKl, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T149616: Prevent duplicate properties and items from getting created
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONMultiple times I created a property and for some reason Wikidata created the property three times. The latest example is "P3312", "P3313 " and "P3314". I think it would be good if Wikidata would reject the attempt to create additional items/properties with the same name and description as an existing one.TASK DETAILhttps://phabricator.wikimedia.org/T149616EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] T148279: Allow the history of deleted Wikidata items to be visible for a month
ChristianKl added a comment. @Lydia_Pintscher : Wikipedia articles have a name that's human-readable and when they are deleted it's clear what the article is about. That's not true for Wikidata items where the item ID doesn't tell a user what the item is about. Additionally many items do get deleted in Wikidata without noticing the person who created the item beforehand in a way that's not typical for Wikipedia.TASK DETAILhttps://phabricator.wikimedia.org/T148279EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Izno, Lydia_Pintscher, Mbch331, Sjoerddebruin, Aklapper, ChristianKl, 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] T148570: Allow "Page link" to be shown in the Watchlist instead of being shown in the Notification bar
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONWhen creating an item that's going to be linked 1000 times the setting that every page link creates a notification is very annoying and unfortunately the feature doesn't look like it can be disabled on a per item basis.TASK DETAILhttps://phabricator.wikimedia.org/T148570EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] [Created] T148149: Provide a way to collapse overlapping claims
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONIt's possible that one source says "John Doe" was born in 1966 and another says that he was born "May 1st, 1966". Currently the UI per default shows both of those claims. I think it would be helpful if there would be a toggle to collapse the claims and show the information together. The same goes for one source saying that a person was born in Chicago and another saying the person was born in Illinois. Given that Chicago is in Illinois it's would be easy to collapse the two claims and only show that the person is born in Illinois. This would allow to accurate represent what the sources say but not have a mess with duplicated claims.TASK DETAILhttps://phabricator.wikimedia.org/T148149EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] T146318: DuplicateReferences doesn't support adding a second copied reference to the same statement
ChristianKl added a comment. It seems to me like this just made the tool more broken than it was before. The tool worked better last week than it works currently. How about having actual tests to not break the tool?TASK DETAILhttps://phabricator.wikimedia.org/T146318EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jonas, ChristianKlCc: ChristianKl, Sjoerddebruin, Jonas, Aklapper, dachary, D3r1ck01, Izno, Wikidata-bugs, aude, Ricordisamoa, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T147037: When Strings that end in "\n" get entered into the string interface Wikidata should simply strip the "\n" away instead of throwing an error
ChristianKl added a comment. I agree that (b) is likely the way to go.TASK DETAILhttps://phabricator.wikimedia.org/T147037EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Esc3300, Aklapper, ChristianKl, 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] [Retitled] T147037: When Strings that end in "\n" get entered into the string interface Wikidata should simply strip the "\n" away instead of throwing an error
ChristianKl changed the title from "Malformed input error" to "When Strings that end in "\n" get entered into the string interface Wikidata should simply strip the "\n" away instead of throwing an error". TASK DETAILhttps://phabricator.wikimedia.org/T147037EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] T147037: Malformed input error
ChristianKl added a comment. I think it might be do to the copied string ending in \n or something like this. It shouldn't be hard for Wikidata to accept the copy pasted string.TASK DETAILhttps://phabricator.wikimedia.org/T147037EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] [Created] T147037: Malformed input error
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONAt the moment I'm using Google Chrome on Windows 10 to fill FMA data on https://www.wikidata.org/wiki/Q27050939. I take the FMA ID data from http://xiphoid.biostr.washington.edu/fma/fmabrowser-hierarchy.html?search=Anterior%20ramus%20of%20spinal%20nerve=none=false I copy paste and get: Could not save due to an error. Malformed input: 8733 If I put the number in a box and again copy pasted it I can successfuly put it into the box. I guess there's some invisible formatting copied that prevents the data input from working immediately.TASK DETAILhttps://phabricator.wikimedia.org/T147037EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] [Created] T146954: The item search for statements should ignore signs like | - etc
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONI really like the fact that the item search now ignores ')' and finds an item even when the ')' is added. I think it would be good if the normalizing function also removes signs like | and - (and the other dashes). / and \ are likely also safely ignored.TASK DETAILhttps://phabricator.wikimedia.org/T146954EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] [Created] T146782: Ability to specify that a reference only covers some of the qualifiers for a statement
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONWhen entering information about an alma mater of a person the source that gives the start and end dates of attendence don't have to be the same. The thesis might again have another reference. Currently it's not possible to specify exactly which reference is responsible for what qualifier. To me that seems bad, because it makes it less clear what the references support and what they don't.TASK DETAILhttps://phabricator.wikimedia.org/T146782EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] [Created] T146684: Allow Quickstatements to find enwiki article with different capitalization
ChristianKl created this task.ChristianKl added a project: Wikidata-Gadgets.Herald added a subscriber: Aklapper.Herald added a project: Wikidata. TASK DESCRIPTIONI entered unsuccessfully: stomach P927 Q682466 S854 Q27031918 S304 5 Then I entered successfully: Stomach P927 Q682466 S854 Q27031918 S304 5 I think Quickstatements should be changed to also be able to handle the first case.TASK DETAILhttps://phabricator.wikimedia.org/T146684EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, dachary, D3r1ck01, 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] [Created] T146653: Datatype for timespans
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONWhen it comes to birthdates frequently it's possible to know that a person might be born between 1750 and 1850. Currently it's only possible to record such a value with a precision of thousand years. If it would be possible to state a timespan it would be much better. The same goes for events where we know that a person was age X at year Y. In those cases we know their age with more precision than a decade and it would be good to state it with that precision.TASK DETAILhttps://phabricator.wikimedia.org/T146653EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] [Created] T146626: QuickStatements should accept strings that represent time the same way the string would be handled when entered via the UI
ChristianKl created this task.ChristianKl added a project: Wikidata-Gadgets.Herald added a subscriber: Aklapper.Herald added a project: Wikidata. TASK DESCRIPTIONEntering timestatements via QuickStatements would be easier if it could parse strings the same way the strings are parsed by the UI.TASK DETAILhttps://phabricator.wikimedia.org/T146626EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, dachary, D3r1ck01, 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] [Created] T146533: Wizard for creating new items for new statements
ChristianKl created this task.ChristianKl added a project: Wikidata.Herald added a subscriber: Aklapper.
TASK DESCRIPTIONI want to enter the husband of {{Q|56185}}. My source tells me:
"At the age of 25 she marries the electrical engineer Walter F. Demmerle (born in 1893), a friend of the family. Because she had earned her PhD under her maiden name, she kept it. Their marriage lasts until her husband’s death in 1947."
I click on spouse and I enter Walter F. Demmerle. Wikidata shows me no search results. Unfortunately it doesn't allow me a fast way to create the item for Walter F. Demmerle.
I think it would be great if there's a button in this case that a can click and that serves up a wizard. The wizard has a few fields:
Name: X
Gender: (autofilled as male because Ida Rolf is female but possible to change.
Date of marriage: X
Place of marriage: X
Date of birth: X
Place of birth: X
Date of death: X
Place of death: X
Button:"Create new item"
The wizard could automatically fill "instance_of":human.
I think such a wizard would reduce the time to enter this claim to a third that it currently takes. There could be a similar wizard for entering mother and father of a person.TASK DETAILhttps://phabricator.wikimedia.org/T146533EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: Aklapper, ChristianKl, 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] T126510: [Story] Allow adding additional languages in the terms box
ChristianKl added a comment. Given that @Lydia_Pintscher wants use cases: At the moment there's a user having problems with the issue at the project chat and asking about the ability to add a language: Can't add new languages When i try to create a new item in order to add new languages to an existing item, it shows up as a completely different page instead. How do i add new languages (not wikipedia links, but spaces to add label, description etc.) to an existing page? The main wikidata page says as soon as an item is created in a different language it can be edited in all languages, but that's not what happened. YuriNikolai (talk) 18:34, 29 August 2016 (UTC) I myself observed that when creating new properties I only create them in the names that I have in my babel box even when there might be others in the property proposal because there's no straightforward way to add the label.TASK DETAILhttps://phabricator.wikimedia.org/T126510EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ChristianKlCc: tfmorris, ChristianKl, Bene, Nikki, Izno, Lydia_Pintscher, Mbch331, Aklapper, matej_suchanek, StudiesWorld, D3r1ck01, Wikidata-bugs, aude___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
