[Wikidata-bugs] [Maniphest] T341766: Undoing edit rolls back all subsequent edits of the same claim
Mormegil updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T341766 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Aklapper, Mormegil, Danny_Benjafield_WMDE, 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] T341766: Undoing edit rolls back all subsequent edits of the same claim
Mormegil created this task. Mormegil added projects: Wikidata, MediaWiki-extensions-WikibaseRepository. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION When a single claim had multiple edits, attempt to undo one of those edits undoes also all subsequent edits of the same claim. **Steps to replicate the issue** (include links if applicable): - Make multiple edits of a single claim (e.g. change its rank, save; add a qualifier, save; add a reference, save). - Go to history, click on a diff of a single of those edits (e.g. changing the rank), see the correct diff of the single change <https://test.wikidata.org/w/index.php?title=Q226474&diff=prev&oldid=648260>. - Click on the undo link. **What happens?**: You see all later edits of the claim are to be reverted as well <https://test.wikidata.org/w/index.php?title=Q226474&diff=prev&oldid=648260> instead of just the rank change (and they will be, if you confirm). **What should have happened instead?**: Only the rank change (displayed in the previous diff) should be undone. TASK DETAIL https://phabricator.wikimedia.org/T341766 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: 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] T270717: “Add links” automatically merges incompatible items on Wikidata
Mormegil renamed this task from "“Add links” automatically merges categories with subject items on Wikidata" to "“Add links” automatically merges incompatible items on Wikidata". Mormegil updated the task description. TASK DETAIL https://phabricator.wikimedia.org/T270717 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil 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] T270717: “Add links” automatically merges categories with subject items on Wikidata
Mormegil added a comment. @Vojtech.dostal Using CSS? No way; the link is added to the page whenever there are no interlanguage links on the page, without further regard to the content of the (possibly) linked item. Even the linking dialog seems not to load the content of the referenced entities until the user presses the button. After that, the dialog could/should check the items and reject to merge them when there are any statements. (Or… at least… ask for explicit confirmation? Maybe not, doing the merge directly on Wikidata would be easier/more comfortable in that case, anyway.) TASK DETAIL https://phabricator.wikimedia.org/T270717 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil 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] T299828: mkwiki pages missing langlinks entries even though linked with a Wikidata item
Mormegil closed this task as "Resolved". Mormegil added a comment. The links were correctly updated and seem to be correct now, thanks! TASK DETAIL https://phabricator.wikimedia.org/T299828 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Michael, Lydia_Pintscher, Manuel, Aklapper, Mormegil, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, TTO, 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] T307601: Reversed ordering of autocomplete suggestions in search bar in mobile Wikidata Firefox
Mormegil added a comment. The fix seems to work fine in production. Should I closed this as fixed, or is it going through some process on WMF side? TASK DETAIL https://phabricator.wikimedia.org/T307601 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Edtadros, Mormegil Cc: MPhamWMF, ovasileva, Jdlrobson, Aklapper, Mormegil, Astuthiodit_1, Nishu02, karapayneWMDE, bwang, cjming, Invadibot, maantietaja, CBogen, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, mojoaxel, GoranSMilovanovic, QZanden, EBjune, LawExplorer, Winter, _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] T307601: Reversed ordering of search results in mobile Wikidata
Mormegil added a comment.
Oh, great, that at least explains why I’m the first the report and fix this.
Yeah, the implementation-defined
<https://tc39.es/ecma262/multipage/indexed-collections.html#sec-sortindexedproperties>
behavior of `array.sort` when given an inconsistent comparator (I mentioned it
in the commit message) is obviously in play here: I’m using Firefox where the
sort results are reversed, while in Chrome, Chromium-based browsers (I tested
Edge), and in IE, the “always return +1” broken comparator results in the
original sorting order (while “always return -1” results in the reversed order).
You can try `[1,2,3,4].sort(function(){return 1})` in a browser console:
Firefox gives `[4,3,2,1]`, Chromium and IE give `[1,2,3,4]`.
TASK DETAIL
https://phabricator.wikimedia.org/T307601
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Mormegil
Cc: ovasileva, Jdlrobson, Aklapper, Mormegil, Fernandobacasegua34,
Astuthiodit_1, Nishu02, 786, Suran38, Biggs657, karapayneWMDE, bwang, cjming,
Invadibot, Lalamarie69, MPhamWMF, maantietaja, Juan90264, Alter-paule,
Beast1978, CBogen, ItamarWMDE, Un1tY, Akuckartz, Hook696, Kent7301,
joker88john, CucyNoiD, Nandana, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86,
Af420, mojoaxel, Bsandipan, GoranSMilovanovic, QZanden, EBjune, LawExplorer,
Winter, Lewizho99, Maathavan, _jensen, rosalieper, Neuronton, 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] T307601: Reversed ordering of search results in mobile Wikidata
Mormegil created this task. Mormegil added projects: Wikidata, MobileFrontend, Discovery-Search. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION **List of steps to reproduce** (step by step, including full links if applicable): - Go to https://m.wikidata.org/ (let’s say in a private window, to be sure) - Write something reasonable into the top search bar; let’s say //obama//. **What happens?**: Notice the results start with many less important items without an image (some Obama’s ancestor in Q96197836, fictional spy car in Q91269986, …), and, finally, //at the very end//, the 44th president of the United States (Q76). **What should have happened instead?**: Barrack Obama is an obvious candidate to be the first search result for the “obama” query; definitely it should not be the //last// result. The mobile search results on Wikidata are so obviously wrong I have sometimes sadly remarked it seems they are shown reversed. I did not know this was //literally true//! The client-side mobile frontend displays the results in a reversed order than what it has received from the search API! (It seems unbelievable nobody have reported that yet, but… I guess everyone is so used to less-then-stellar quality of search on Wikimedia projects… Dunno, but I could not find an existing report for this.) TASK DETAIL https://phabricator.wikimedia.org/T307601 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Aklapper, Mormegil, Astuthiodit_1, karapayneWMDE, Invadibot, MPhamWMF, maantietaja, CBogen, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, mojoaxel, GoranSMilovanovic, QZanden, EBjune, 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] T299828: mkwiki pages missing langlinks entries even though linked with a Wikidata item
Mormegil added a comment. In T299828#7653095 <https://phabricator.wikimedia.org/T299828#7653095>, @Michael wrote: >> Purging some of the pages? > > Purging the pages in mkwiki should always fix these things. “These”? Meaning “interwiki links are correctly displayed in the sidebar, but are not present in the sitelinks table and the API does not return them”? OK, so I went ahead and purged the mkwiki category page. It dit not fix the problem. In T299828#7653178 <https://phabricator.wikimedia.org/T299828#7653178>, @Michael wrote: > Though it might take a while for them to actually appear on the mkwiki page. Well, as the links have been visible on the mkwiki page from the very beginning, it’s probably not very surprising the interwiki links do still appear on the category page, but the API request still does not return them. TASK DETAIL https://phabricator.wikimedia.org/T299828 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Michael, Lydia_Pintscher, Manuel, Aklapper, Mormegil, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, TTO, 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] T299828: mkwiki pages missing langlinks entries even though linked with a Wikidata item
Mormegil created this task. Mormegil added projects: Wikidata, Wikimedia-Interwiki-links. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION TL;DR: 1. See mk:Категорија:Леднички земјишни облици <https://mk.wikipedia.org/wiki/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%98%D0%B0:%D0%9B%D0%B5%D0%B4%D0%BD%D0%B8%D1%87%D0%BA%D0%B8_%D0%B7%D0%B5%D0%BC%D1%98%D0%B8%D1%88%D0%BD%D0%B8_%D0%BE%D0%B1%D0%BB%D0%B8%D1%86%D0%B8> and the correctly displayed language links there (and the corresponding Wikidata item <https://www.wikidata.org/wiki/Q7037550>). 2. Compare with an API example <https://mk.wikipedia.org/w/api.php?action=query&format=json&prop=langlinks&titles=Category%3AЛеднички земјишни облици> reporting the page has //no// language links. (And the same shows in the langlinks database replica on Toolforge.) I have received an error report <https://www.mediawiki.org/wiki/User_talk:Mormegil#Category_completer_not_functioning_for_new_categories> about my Toolforge tool not working <https://mormegil.toolforge.org/catcompleter/?project=mk&catname=Леднички земјишни облици> for some recently created categories on mkwiki. The problem seems to be that some pages on mkwiki are missing entries in the langlinks table, even though the page is linked with a Wikidata item with many sitelinks, and the Wikipedia category page even displays those links correctly <https://mk.wikipedia.org/wiki/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%98%D0%B0:%D0%9B%D0%B5%D0%B4%D0%BD%D0%B8%D1%87%D0%BA%D0%B8_%D0%B7%D0%B5%D0%BC%D1%98%D0%B8%D1%88%D0%BD%D0%B8_%D0%BE%D0%B1%D0%BB%D0%B8%D1%86%D0%B8>. However, there are no langlink rows for the page in the Toolforge database replica, and the mkwiki API returns no langlinks for the page as well: See an API example <https://mk.wikipedia.org/w/api.php?action=query&format=json&prop=langlinks&titles=Category%3A%D0%9B%D0%B5%D0%B4%D0%BD%D0%B8%D1%87%D0%BA%D0%B8%20%D0%B7%D0%B5%D0%BC%D1%98%D0%B8%D1%88%D0%BD%D0%B8%20%D0%BE%D0%B1%D0%BB%D0%B8%D1%86%D0%B8%7CCategory%3A%D0%91%D0%BE%D0%BB%D0%B5%D1%81%D1%82%D0%B8%20%D0%BD%D0%B0%20%D1%86%D1%80%D0%BD%D0%B8%D0%BE%D1%82%20%D0%B4%D1%80%D0%BE%D0%B1> contrasting the missing langlinks with another recently created category, which lists them correctly. I guess this probably comes from some issue when syncing/updating changes in Wikidata to the local wiki database. It might be the same or similar issue as reported in T297238 <https://phabricator.wikimedia.org/T297238>? (In that case, feel free to mark this a duplicate.) However, even though I understand distributed systems will necessarily experience similar issues, I am not sure if there is any remedy available: Would any edit to the respective Wikidata item help force the refresh? Or removing and re-adding the corresponding mkwiki sitelink from Wikidata? Purging some of the pages? Something else? TASK DETAIL https://phabricator.wikimedia.org/T299828 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Aklapper, Mormegil, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, TTO, 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] T292705: Some entities with changed descriptions have old descriptions in WQS and search
Mormegil added a comment. > please let me know if you want me to force refresh this specific item. That’s not necessary for me, thanks! TASK DETAIL https://phabricator.wikimedia.org/T292705 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: dcausse, Gehel, Aklapper, Mormegil, Invadibot, MPhamWMF, maantietaja, CBogen, Akuckartz, Nandana, Namenlos314, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T292705: Some entities with changed descriptions have old descriptions in WQS and search
Mormegil created this task. Mormegil added projects: Wikidata-Query-Service, Wikidata. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION I have changed the Czech descriptions of some Wikidata entities. And later, I have found that a few of these changed entities still show old (pre-edit) descriptions in WQS and in search results on Wikidata. Take a look at this WQS query <https://w.wiki/4BYC> which shows the Czech descriptions of four affected entities. All of the displayed descriptions read //“rozcestník”//. Compare it with one of those entities <https://www.wikidata.org/wiki/Q356870?uselang=cs> which in fact has //“rozcestník na projektech Wikimedia”// (changed in this edit <https://www.wikidata.org/wiki/Special:Diff/1502388913>). The same old description is displayed as a snippet in the full-text search results <https://www.wikidata.org/w/index.php?title=Special:Search&search=Q356870&fulltext=Search&uselang=cs&ns0=1> (API <https://www.wikidata.org/w/api.php?action=query&format=json&uselang=cs&list=search&srsearch=Q356870&srlimit=1>). On the other hand, the search box suggestion dropdown shows the correct updated text (API <https://www.wikidata.org/w/api.php?action=wbsearchentities&format=json&uselang=cs&search=Q356870&language=cs>?) This is not really a big problem for me. I am not sure if it is worthwhile to create a bugreport for it or it should fix itself in some time (it’s been almost two weeks and it did not fix itself yet). And if it is normal and well-known that WQS sometimes gets out of sync or this is a special terrible bug worth fixing. :-) So – yeah, do anything you consider useful with this report, close it as uninteresting if you want, whatever. TASK DETAIL https://phabricator.wikimedia.org/T292705 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Aklapper, Mormegil, Invadibot, MPhamWMF, maantietaja, CBogen, Akuckartz, Nandana, Namenlos314, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T285694: Highlighting for currently selected statement makes property unclickable and causes overlap with constraint violations popup
Mormegil added a comment. Oh, sure, I did not want to imply it should just be removed. It was only an observation intended to help with localizing the bug. (Even though probably unnecessary/self-evident, I guess, especially in this task where the original commit introducing the problem has been correctly identified already.) TASK DETAIL https://phabricator.wikimedia.org/T285694 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Mormegil, Michael, Lucas_Werkmeister_WMDE, Aklapper, Invadibot, maantietaja, Akuckartz, Eihel, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, Esc3300, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, abian, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T291609: Deleted Wikidata items still returned by WQS
Mormegil added a comment. Yep, the claims disappeared, thanks! The timestamps remain but I don’t care about those and if you say this is OK, no problem for me. (I guess this task can be closed as resolved?) TASK DETAIL https://phabricator.wikimedia.org/T291609 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: dcausse, Mormegil Cc: dcausse, Aklapper, Mormegil, Invadibot, MPhamWMF, maantietaja, CBogen, Akuckartz, Nandana, Namenlos314, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T285694: Highlighting for currently selected statement makes property unclickable and causes overlap with constraint violations popup
Mormegil added a comment. Just copying a note from my duplicate bug: The problem seems to be impacted by a `z-index: 1` declaration in the `.wikibase-statementgrouplistview .wikibase-statementlistview .wikibase-statementview:target` CSS rule. When I disable the z-index, the link becomes clickable. TASK DETAIL https://phabricator.wikimedia.org/T285694 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Mormegil, Michael, Lucas_Werkmeister_WMDE, Aklapper, Invadibot, maantietaja, Akuckartz, Eihel, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, Esc3300, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, abian, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T290228: Wikidata property label is unclickable when linked using statement ID
Mormegil closed this task as a duplicate of T285694: Highlighting for currently selected statement makes property unclickable and causes overlap with constraint violations popup. TASK DETAIL https://phabricator.wikimedia.org/T290228 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Aklapper, Mormegil, Invadibot, maantietaja, 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] T285694: Highlighting for currently selected statement makes property unclickable and causes overlap with constraint violations popup
Mormegil merged a task: T290228: Wikidata property label is unclickable when linked using statement ID. TASK DETAIL https://phabricator.wikimedia.org/T285694 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Mormegil, Michael, Lucas_Werkmeister_WMDE, Aklapper, Invadibot, maantietaja, Akuckartz, Eihel, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, Esc3300, LawExplorer, _jensen, rosalieper, Agabi10, Scott_WUaS, abian, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331 ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T234079: Highlight individual statements when selecting them in the URL
Mormegil added a comment. Note that the property label of the target statement is unclickable now, see T290228 <https://phabricator.wikimedia.org/T290228>. TASK DETAIL https://phabricator.wikimedia.org/T234079 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: abian, Mormegil Cc: Mormegil, alaa_wmde, Lydia_Pintscher, Hanna_Petruschat_WMDE, Lucas_Werkmeister_WMDE, Aklapper, Invadibot, Manishagoenka, maantietaja, cristiana023, Akuckartz, JanJaquemot, Iflorez, Nandana, lucamauri, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, JGirault, 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] T290228: Wikidata property label is unclickable when linked using statement ID
Mormegil added a project: MediaWiki-extensions-WikibaseRepository. TASK DETAIL https://phabricator.wikimedia.org/T290228 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Aklapper, Mormegil, Invadibot, maantietaja, 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] T291609: Deleted Wikidata items still returned by WQS
Mormegil created this task. Mormegil added a project: Wikidata-Query-Service. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION **List of steps to reproduce** (step by step, including full links if applicable): Try a WQS query <https://w.wiki/47GU> looking for Q531659 and Q21504507 (where I noticed the problem). **What happens?** The query returns a lot of claims for those two items. **What should have happened instead?** The query should have found nothing, these two items have been deleted three days ago: https://www.wikidata.org/wiki/Q531659, https://www.wikidata.org/wiki/Q21504507 (Note that when testing the query, once it returned just two rows with one `wikibase:timestamp` claim for each item; no idea if the result depends on the serving server from a cluster or what.) TASK DETAIL https://phabricator.wikimedia.org/T291609 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Aklapper, Mormegil, MPhamWMF, CBogen, Namenlos314, Gq86, Lucas_Werkmeister_WMDE, EBjune, merbst, Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles ___ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
[Wikidata-bugs] [Maniphest] T290228: Wikidata property label is unclickable when linked using statement ID
Mormegil created this task. Mormegil added a project: Wikidata. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION When a link to a specific statement on Wikidata is used, the property label of the target statement cannot be clicked, selected or interacted with. **List of steps to reproduce** - Go to e.g. https://www.wikidata.org/wiki/Q42395533#Q42395533$a0188262-4839-1157-97b8-6b1a7d31a354 - Try to click on the “Commons category” label in the highlighted statement. (Or, try to drag-select the text of the label.) **What happens?** Nothing, the click is ignored, the text is not selected. (When trying to inspect the link element, the DOM inspector displays a `.wikibase-statementview-mainsnak-container` element instead.) **What should have happened instead?** The link should have worked normally, the text should have been selected. **Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc** Tested on Firefox 91.0.2 on Windows and Edge 92.0.902.84 on Windows. The problem seems to be impacted by a `z-index: 1` declaration in the `.wikibase-statementgrouplistview .wikibase-statementlistview .wikibase-statementview:target` CSS rule. When I disable the z-index, the link becomes clickable. TASK DETAIL https://phabricator.wikimedia.org/T290228 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Aklapper, Mormegil, 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] T270717: “Add links” automatically merges categories with subject items on Wikidata
Mormegil created this task. Mormegil added projects: Wikidata, MediaWiki-extensions-WikibaseClient. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION The “Add links” tool on the client wikis allows the wiki editors to simply add a sitelink to the current page to Wikidata. As I have just learned, it is even capable of //merging// already existing items: when the current page is linked to an item with no other sitelinks, the tool allows to “add a link” to another wiki by _merging_ the current item with the item containing the //destination// sitelink. This seems useful and mostly it is. However, the current practice of linking Wikinews _categories_ to Wikipedia _articles_ (and Wikidata subject items) <https://www.wikidata.org/wiki/Wikidata:Wikinews/Development> causes trouble here. When a Wikinews category has a Wikidata item with the singular sitelink (e.g. [[n:pt:Categoria:Atentados de 13 de novembro de 2015 en Île-de-France]]) and a user on Wikinews clicks on the “Add links” tool (“Please select a site and a page that you want to link to this page.”) and enters the name of the corresponding category on another-language Wikinews site (e.g. [[n:fr:Catégorie:Attentats du 13 novembre 2015 en Île-de-France]]), the tool finds the current page’s Wikidata item (Q34178806, a category item) has a single sitelink and it finds the French Wikinews category is already linked to Q21479779 (a subject item), shows you a completely acceptable notice (“The page you have chosen is already associated to an item on our central data repository. Please confirm that the pages shown below are the ones that you want to link to this page.” Yes, that’s exactly what I’d like.) and proceeds to //merge// those two items which is wrong and results in a mess of wrong descriptions and instance-of statements. I have tested the problem by “adding a link” from n:pt:Categorie:Mosul <https://pt.wikinews.org/wiki/Categoria:Mosul> to n:en:Category:Mosul <https://en.wikinews.org/wiki/Category:Mosul>, resulting in this merge <https://www.wikidata.org/w/index.php?diff=1327034047> (which I have reverted and fixed the problem manually, obviously). However, it’s not very obvious what should be done here. I understand there is no obvious //bug// in the tool. However, the result of using it is wrong. And the users of the tool cannot be blamed for it, really. Maybe the best option would be just to refuse to merge two items which //both// have //any// statements; leaving this merging usage only for the bare sitelink items auto-created by various bots and leaving the proper complex merges to be done on Wikidata? Or, disable the merging behavior altogether on Wikinews which is the different animal here? That would be at least a good temporary patch. Or should the tool check for those wrong merges specifically? That would mean hardcoding those Wikidata specific items (like “instance-of Wikimedia category” means something more special than “instance-of country”)? Not sure if that is a good path anywhere. TASK DETAIL https://phabricator.wikimedia.org/T270717 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Aklapper, Mormegil, 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 https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T237543: Double escaping in autoformatted comments
Mormegil created this task. Mormegil added a project: Wikidata. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION It seems `AutoCommentFormatter` double-escapes HTML in message arguments. See e.g. this Wikidata diff <https://www.wikidata.org/wiki/Special:Diff/1044675751> where [[User:&beer&love]]’s doubly-escaped name breaks the contributions link. The database contains just `/* restore:0||1029390786|&beer&love */` which gets broken by the auto-formatting. Maybe connected with T182800 <https://phabricator.wikimedia.org/T182800>? TASK DETAIL https://phabricator.wikimedia.org/T237543 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Aklapper, Mormegil, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T235540: SPARQL query causes StackOverflowError and fails to execute
Mormegil added a comment.
I found this bug only after reducing my broken query until only this was left:
SELECT (MIN(?name) AS ?name) WHERE {
}
Also, I noticed COUNT and SAMPLE work fine, while the other aggregate
functions do not support this aliasing. If it is an error, a better error
message would definitely come handy.
TASK DETAIL
https://phabricator.wikimedia.org/T235540
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Mormegil
Cc: Mormegil, TomT0m, Lea_Lacroix_WMDE, Tagishsimon, Envlh, Mathew.onipe,
Smalyshev, Lucas_Werkmeister_WMDE, Igorkim78, Aklapper, Evilricepuddin,
darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden,
EBjune, merbst, LawExplorer, _jensen, rosalieper, Jonas, Xmlizer, jkroll,
Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T221097: The most commonly used date format in the Czech Republic produces wrong date when used as a value in Wikidata
Mormegil added a project: I18n. TASK DETAIL https://phabricator.wikimedia.org/T221097 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Mormegil, Blahma, Urbanecm, JAnD, Wesalius, Aklapper, Vojtech.dostal, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, Jayprakash12345, QZanden, LawExplorer, _jensen, rosalieper, 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] [Commented On] T221097: The most commonly used date format in the Czech Republic produces wrong date when used as a value in Wikidata
Mormegil added a comment. In T221097#5118415 <https://phabricator.wikimedia.org/T221097#5118415>, @Urbanecm wrote: > Possible solutions: > > - decline this task Wat. > - (no geodata) a preference saying "my dates are always in DD. MM. Right. Which we basically have <https://www.mediawiki.org/wiki/Manual:Date_formatting>; even though I would say you should not choose “my date format”, you should choose your language. Which you do, obviously. And it is completely obvious what date was meant by any Czech-speaking user who wrote “7. 1. 1967”. > - geodata and priority of formats based on source country. We don’t do i18n based on geolocation, I believe. And I see no reason why we should. (See also sortable tables with dates in them <https://meta.wikimedia.org/wiki/Help:Sorting#Dates>.) TASK DETAIL https://phabricator.wikimedia.org/T221097 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Mormegil, Blahma, Urbanecm, JAnD, Wesalius, Aklapper, Vojtech.dostal, 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] T232214: Undo links disappeared from Wikidata diffs
Mormegil created this task. Mormegil added projects: Wikidata, MediaWiki-History-and-Diffs. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION Wikidata diffs now do not display //(undo)// links. See e.g. a random diff <https://www.wikidata.org/w/index.php?title=Q860&diff=977373122&oldid=946512615> which displays a //(restore)// link but not //(undo)//. My personal suspect: rMW6906a7728cf5447d30da6c7a51add936f469978a#change-op58PNimx6Sc <https://phabricator.wikimedia.org/rMW6906a7728cf5447d30da6c7a51add936f469978a#change-op58PNimx6Sc> started to check for `ContentHandler::supportsDirectEditing()` but I don’t think Wikibase entity handler returns true there (and I am not sure it should). TASK DETAIL https://phabricator.wikimedia.org/T232214 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Aklapper, Mormegil, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, WMDE-Fisch, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T228886: Wikidata main page can't be accessed using non-English language
Mormegil added a comment. OK, I have fixed the problem for cs by purging https://www.wikidata.org/wiki/MediaWiki:Mainpage/cs but that’s not a great solution… TASK DETAIL https://phabricator.wikimedia.org/T228886 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Mormegil, Michael, Lydia_Pintscher, matej_suchanek, Liuxinyu970226, Aklapper, Urbanecm, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, 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] [Updated] T228640: WDQS missing some particular data (property P6885)
Mormegil added a comment. Possibly related? We have found a similar problem with missing P6736 <https://phabricator.wikimedia.org/P6736> data: Q38192330 has P6736 <https://www.wikidata.org/wiki/Q38192330#P6736> (since 2019-07-03), but it cannot be found using WQS <https://w.wiki/6Ne>. TASK DETAIL https://phabricator.wikimedia.org/T228640 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Mormegil, Aklapper, Vojtech.dostal, Cyberpower678, matej_suchanek, darthmon_wmde, Nandana, Sario528, Lahi, Gq86, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, _jensen, rosalieper, Jonas, Xmlizer, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T227814: [Regression wmf.13] Wikidata localisation is broken
Mormegil added a comment. Once again, this solved itself by purging the page, probably just a cached version of the broken state. TASK DETAIL https://phabricator.wikimedia.org/T227814 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: greg, Mormegil Cc: Premeditated, Michael, Lucas_Werkmeister_WMDE, Lea_Lacroix_WMDE, greg, Agusbou2015, Tacsipacsi, Liuxinyu970226, thcipriani, Krinkle, Jdforrester-WMF, Aklapper, Mormegil, darthmon_wmde, Nandana, Imarlier, Lahi, Gq86, GoranSMilovanovic, Jayprakash12345, QZanden, LawExplorer, Vali.matei, _jensen, rosalieper, Srdjan_m, MuhammadShuaib, LNDDYL, Psychoslave, Wikidata-bugs, aude, Gryllida, Shizhao, Arrbee, Mbch331, Jay8g, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T227814: [Regression wmf.13] Wikidata localisation is broken
Mormegil added a comment. Test Wikidata works fine for me, the broken display disappeared on purge. TASK DETAIL https://phabricator.wikimedia.org/T227814 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: greg, Mormegil Cc: Lucas_Werkmeister_WMDE, Lea_Lacroix_WMDE, greg, Agusbou2015, Tacsipacsi, Liuxinyu970226, thcipriani, Krinkle, Jdforrester-WMF, Aklapper, Mormegil, darthmon_wmde, Nandana, Imarlier, Lahi, Gq86, GoranSMilovanovic, Jayprakash12345, QZanden, LawExplorer, Vali.matei, _jensen, rosalieper, Srdjan_m, MuhammadShuaib, LNDDYL, Psychoslave, Wikidata-bugs, aude, Gryllida, Shizhao, Arrbee, Mbch331, Jay8g, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T227815: Message wikibase-sitelinks-wikipedia missing from wikidata.org
Mormegil added a comment. I just reported T227814 <https://phabricator.wikimedia.org/T227814>. TASK DETAIL https://phabricator.wikimedia.org/T227815 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Mormegil, Jdforrester-WMF, Aklapper, darthmon_wmde, Nandana, Imarlier, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Vali.matei, _jensen, rosalieper, D3r1ck01, Nirmos, Wikidata-bugs, aude, Dinoguy1000, Mbch331, Jay8g, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T227814: Wikidata localization is broken
Mormegil created this task. Mormegil added projects: Wikidata, I18n. Restricted Application added a subscriber: Aklapper. TASK DESCRIPTION Wikidata localization seems to be broken quite a lot; when viewing in (e.g.) Czech (as always), I notice many broken things everywhere (e.g. a completely random example <https://www.wikidata.org/wiki/Q12050227?uselang=cs>): - the sitelinks box is captioned “⧼wikibase-sitelinks-wikipedia⧽” - date statements show “http://www.wikidata.org/entity/Q1985727” instead of the calendar name - history <https://www.wikidata.org/w/index.php?title=Q12050227&action=history&uselang=cs> displays things like “wbcreateclaim-create:1|” instead of the human-readable text The same happens when I use e.g. `uselang=de`; on the other hand, the page looks fine <https://www.wikidata.org/wiki/Q12050227?uselang=en> with `uselang=en`. TASK DETAIL https://phabricator.wikimedia.org/T227814 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Aklapper, Mormegil, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, Jayprakash12345, QZanden, LawExplorer, _jensen, rosalieper, 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] [Commented On] T86799: resource loader &debug=1 results in JavaScript error
Mormegil added a comment. Came here with the same problem, and indeed, uBlock Origin blocks fingerprint.js as well. TASK DETAIL https://phabricator.wikimedia.org/T86799 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JanZerebecki, Mormegil Cc: Mormegil, adrianheine, JanZerebecki, Aklapper, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T206826: [Bug] TypeError thrown when loading page: wb.datamodel.Fingerprint is not a constructor
Mormegil added a comment. I’ve had the same problem, turned out some ad-/privacy-blockers block the loading of `fingerprint.js`, see also T86799 <https://phabricator.wikimedia.org/T86799>. After adding an exception for wikidata.org to uBlock Origin I use, everything works fine. TASK DETAIL https://phabricator.wikimedia.org/T206826 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Mormegil, Aklapper, Niedzielski, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic, Jayprakash12345, QZanden, LawExplorer, _jensen, rosalieper, Wong128hk, 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] T135744: Save action is still disabled after an invalid sitelink is removed
Mormegil added a comment. Well, it is different now. Arguably better, but not great either. It seems when you remove all text from a sitelink (and the Publish button gets disabled), the trashcan icon for the cleared sitelink gets disabled as well. So that saves you from the dead end reported in this bug. However, I don’t see why the trashcan icon is disabled; when a user does not know the “proper” way to remove a sitelink is to click the trashcan icon and removes all text from the sitelink as the first step, why disallow clicking on the trashcan to remove the whole sitelink row? Note that using the workaround from the original report (write anything into the “new project” field and remove it), the Publish link will get enabled even with an empty sitelink field, and by publishing, the sitelink gets removed correctly. Expected behavior: You can click a trashcan to remove a sitelink row even if the field containing the title of the linked article is currently empty. Writing text into the new sitelink wiki field and removing it again is a no-op, does not do anything; specifically, it does not cause a disabled Publish link to be changed to enabled. TASK DETAILhttps://phabricator.wikimedia.org/T135744EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MormegilCc: Greta_Doci_WMDE, Aklapper, Zppix, Mormegil, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T135744: Save action is still disabled after an invalid sitelink is removed
Mormegil created this task. Herald added subscribers: Zppix, Aklapper. TASK DESCRIPTION When editing sitelinks in Wikidata, removing all text from a sitelink causes the //Save// link to be disabled, which is fine. However, after clicking on the trashcan icon next to the cleared sitelink (or pressing //Backspace// once again, thus removing it, does not re-enable to //Save// link, leaving the user unable to save the sitelink removal. (A workaround: Click into the “new project” text box, write something and remove it, the //Save// link will be enabled.) TASK DETAIL https://phabricator.wikimedia.org/T135744 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Mormegil Cc: Aklapper, Zppix, Mormegil, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331, matej_suchanek ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
