[Wikidata-bugs] [Maniphest] [Commented On] T137810: [Task] Add monolingual language code mn-Mong
Nikki added a comment. This is a request for a new monolingual text language, not a request for a new project. The criteria for new monolingual text languages (described at https://www.wikidata.org/wiki/Help:Monolingual_text_languages#Requirements_for_a_new_language_code by someone working for WMDE) are explicitly different from the language criteria for adding new projects.TASK DETAILhttps://phabricator.wikimedia.org/T137810EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: NikkiCc: Nikki, thiemowmde, Liuxinyu970226, Lydia_Pintscher, GerardM, Aklapper, Zppix, Popolon, 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] T137810: [Task] Add monolingual language code mn-Mong
Nikki added a comment. @thiemowmde: The aim here, as I understand it, is to distinguish the two scripts, particularly because of the extra display support Mongolian script needs, not to distinguish the khk variety associated with Mongolia from the mvf variety associated with China. If that is right, I think having "mn-mong" would be the only option that fully meets the original aim. I don't know what the differences between khk and mvf are other than the preferred script, but I find it highly unlikely that separate codes would have been assigned if the only difference were the script. Mongolian script was previously used in Mongolia and it appears that there is also some modern usage of it (Mongolian bank notes and coins look to have Mongolian script on them). That implies that it would be wrong to assume all text using the Mongolian script is mvf which then implies that only having khk and mvf would be insufficient as a way to reliably distinguish scripts. It also seems to be very uncommon to specify which variety of Mongolian is being talked about when providing names (etc) in Mongolian script, judging by Wikipedia articles I've looked at. If the source only says that the name (etc) that I'd like to add is Mongolian in Mongolian script, I have no idea how I would determine that it is definitely khk or mvf - I would just be guessing and I'm sure I wouldn't be the only one. Without "mn-mong" and without sources providing enough information to select something more specific, people are likely to continue selecting "mn" for both Cyrillic and Mongolian script.TASK DETAILhttps://phabricator.wikimedia.org/T137810EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: NikkiCc: Nikki, thiemowmde, Liuxinyu970226, Lydia_Pintscher, GerardM, Aklapper, Zppix, Popolon, 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] T127213: [Bug] Merging doesn't always create a redirect
Nikki added a comment. @Esc3300: I'm not sure that it's a good idea to combine your case with the problem I originally reported where the merges should have been completed, not prevented. They have different expected behaviour and I think your case should be a higher priority, which I assume would need a separate ticket. For now I've edited the description to clarify that I'm not asking for all of the merges I originally listed to be prevented. (Phabricator doesn't clearly show that other people have edited the description, let alone added whole new paragraphs...)TASK DETAILhttps://phabricator.wikimedia.org/T127213EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: NikkiCc: Esc3300, Magnus, matej_suchanek, hoo, Mbch331, Aklapper, Nikki, StudiesWorld, D3r1ck01, Izno, Wikidata-bugs, aude___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T127213: [Bug] Merging doesn't always create a redirect
Nikki edited the task description. (Show Details) EDIT DETAILS...Looking at those examples, it seems like they all still have some descriptions set, even though most of the information was removed. even though most of the information was removed. Expected behaviour: The redirects are successfully created, like when using the merge gadget. Additional information added by Esc3300: Sitelink conflicts: Part of the merge is also performed when there is a sitelink conflict and a description conflict:...TASK DETAILhttps://phabricator.wikimedia.org/T127213EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: NikkiCc: Esc3300, Magnus, matej_suchanek, hoo, Mbch331, Aklapper, Nikki, StudiesWorld, D3r1ck01, Izno, Wikidata-bugs, aude___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T101086: Standardize invalid language codes for Babel extension
Nikki added a comment.
My understanding of the problem is that when someone uses {{#babel:zh-classical}}, the extension puts the user into "Category:User zh-classical" instead of into "Category:User lzh" even though they mean the same thing. Instead, it should understand that zh-classical is a legacy code and convert it to lzh, to avoid duplicate categories.
All the users in https://www.wikidata.org/wiki/Category:User_be-x-old, https://www.wikidata.org/wiki/Category:User_zh-classical and https://www.wikidata.org/wiki/Category:User_zh-yue are there because they used the Babel extension with an old code. Those categories duplicate https://www.wikidata.org/wiki/Category:User_be-tarask, https://www.wikidata.org/wiki/Category:User_lzh and https://www.wikidata.org/wiki/Category:User_yue. All six pages were created by the Babel AutoCreate account (before it got blocked).TASK DETAILhttps://phabricator.wikimedia.org/T101086EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: NikkiCc: Nemo_bis, Nikerabbit, Whatamidoing-WMF, Glaisher, MarcoAurelio, StudiesWorld, Ricordisamoa, Liuxinyu970226, Nikki, Aklapper, Bugreporter, D3r1ck01, Izno, Wikidata-bugs, aude, SPQRobin, Dereckson, Arrbee, KartikMistry, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T127435: Allow items in Cape Verdean Creole (kea) in Wikidata
Nikki added a comment. It's still not possible. If you try to actually save a value, it says "Unrecognized value for parameter 'language': kea"TASK DETAILhttps://phabricator.wikimedia.org/T127435EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: NikkiCc: thiemowmde, Lydia_Pintscher, Liuxinyu970226, adrianheine, Nikki, MF-Warburg, Ahoerstemeier, GerardM, waldyrious, Aklapper, StudiesWorld, Bugreporter, 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] T95425: [Bug] Quantity formatter rounding causes significant data loss
Nikki added a comment. This just came up on-wiki again at https://www.wikidata.org/wiki/Wikidata:Project_chat#Rounding_when_uncertainty_over_10_is_given where someone added a statement with 547±17 (which is 530-564) and instead it displays 550±20 (which is 530-570).TASK DETAILhttps://phabricator.wikimedia.org/T95425EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: NikkiCc: Srittau, Nikki, Thryduulf, Addshore, Lydia_Pintscher, Jc3s5h, Snipre, mgrabovsky, daniel, thiemowmde, Aklapper, 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] T138725: Special:NewItem and Special:NewProperty allow creation of items with term language as any string
Nikki added a comment. It seems I also can't remove the bad terms, when I tried to delete the "Türkçe" description on https://www.wikidata.org/wiki/Q6052351, I get "Unrecognized value for parameter 'language': Türkçe"TASK DETAILhttps://phabricator.wikimedia.org/T138725EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: NikkiCc: Nikki, Urbanecm, TerraCodes, Luke081515, hoo, daniel, aude, Lydia_Pintscher, adrianheine, Aklapper, Addshore, Zppix, D3r1ck01, Izno, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T138725: Special:NewItem and Special:NewProperty allow creation of items with term language as any string
Nikki added a comment. I tested it on test.wikidata.org too and it seems that it uses whatever you type if you don't explicitly select an option. For example, if I type "English" and submit the form, it uses "English" as the language code. On top of that, filtering only seems to work if you type a language code, so typing "hr" will highlight Croatian, but typing "Croatian" does nothing. If you do explicitly select something, it only displays the language code which also might encourage people to try to "fix" it by entering the language name instead.TASK DETAILhttps://phabricator.wikimedia.org/T138725EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: NikkiCc: Nikki, Urbanecm, TerraCodes, Luke081515, hoo, daniel, aude, Lydia_Pintscher, adrianheine, Aklapper, Addshore, Zppix, D3r1ck01, Izno, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T138499: Adding a reference with no content will block save button (unlike adding a qualifier)
Nikki added a comment. Both qualifiers and references disable the save button if you select a property but don't enter a value. Should that also be changed?TASK DETAILhttps://phabricator.wikimedia.org/T138499EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lydia_Pintscher, NikkiCc: Nikki, thiemowmde, Jonas, adrianheine, Aklapper, Zppix, Jan_Dittrich, D3r1ck01, Izno, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T115794: Gadgets and common.js things which touch the statement section do not work reliably anymore
Nikki added a comment. A while ago (I forget when), there was some change (something to do with how the HTML is rendered I think) and since then I've noticed that using a statement sorting script no longer corrupts the page. However, the general problem still remains, I'm missing links for coordinates on many pages unless I refresh and the things in my common.js which touch the statement section usually fail to apply unless I refresh. And people are still reporting issues with the Commons category links: https://www.wikidata.org/wiki/Wikidata:Project_chat#Active_links_for_commons_categories TASK DETAIL https://phabricator.wikimedia.org/T115794 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Liuxinyu970226, matej_suchanek, StudiesWorld, Mineo, Ricordisamoa, Sjoerddebruin, DSGalaktos, Aklapper, Nikki, 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] T137063: Signature section does not use babel-languages from global page
Nikki added a comment. What do you mean by "signature section"? TASK DETAIL https://phabricator.wikimedia.org/T137063 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Aklapper, jeblad, Zppix, 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] T136841: The web interface for inserting the coordinates does not allow to specify planetographic coordinates, increasing to the West.
Nikki added a comment. I'm not sure how the first example ended up saying east, it was apparently imported from itwiki which had (and still has) -48.5, -35.6 in the page source. We //still// don't have a way to set the globe via the web interface, so I think we're unlikely to get a way to specify the coordinate system in the web interface any time soon. TASK DETAIL https://phabricator.wikimedia.org/T136841 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, ValterVB, Aklapper, Zppix, Rotpunkt, 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] T136479: Allow cancelling / aborting queries
Nikki added a comment. I usually end up right clicking the tab and duplicating it, that way I don't lose what I currently have on the clipboard. :) I suppose refreshing the page would work too but I never trust browsers/pages to not lose something if I do that. Also, I didn't mention why what I suggested would be ideal (for me): Most of the options (deciding to sit and wait (and succeeding in doing that without getting distracted by something else ;)), clicking a stop button, refreshing or opening a new tab) need some kind of deliberate action from me, which interrupts what I'm doing. What I suggested would be unobtrusive - I could just continue editing and running the query until I get the results I want without it interrupting me. TASK DETAIL https://phabricator.wikimedia.org/T136479 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Deskana, Smalyshev, Nikki, Aklapper, Zppix, WikidataFacts, Avner, debt, Gehel, D3r1ck01, FloNight, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T136479: Allow cancelling / aborting queries
Nikki added a comment. I wanted to ask for pretty much the same thing. :) I often make stupid mistakes that mean my query will either time out or return far too many results. It used to be possible to just click "Run" again, but now that button gets disabled until it returns results or times out, so once I've fixed the mistake, there's a long delay before I can run my new query. I'm not really bothered about specifically having a button to stop a query, but I would really like to be able to start the new query without a long delay. For me, it would be ideal if the "Run" button were re-enabled when the query changes (and if the user runs the new query before the old one finishes/times out, silently cancel the old query). TASK DETAIL https://phabricator.wikimedia.org/T136479 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Aklapper, Zppix, WikidataFacts, Avner, debt, Gehel, D3r1ck01, FloNight, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T136530: Show QIDs in diffs to distinguish items with the same label
Nikki created this task. Herald added subscribers: Zppix, Aklapper. TASK DESCRIPTION This came up recently at https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team/Archive/2016/05#display_.28and_link.29_Q_numbers_in_diffs and I just saw the same problem again on https://www.wikidata.org/w/index.php?diff=341423600 In English, the old value is displayed as "foot" and the new value is also displayed as "foot". Without hovering over the links, you can't see that they are different items. That's a problem because the point of the diff is to see what changed. I think the QID should be shown too, e.g. using the same format as Template:Q like suggested in the discussion. TASK DETAIL https://phabricator.wikimedia.org/T136530 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Aklapper, Nikki, Zppix, 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] T136528: Precision of a quantity value changed when only editing the unit
Nikki created this task. Herald added subscribers: Zppix, Aklapper. TASK DESCRIPTION See https://www.wikidata.org/w/index.php?diff=341423600 I only changed the unit, but when I saved the edit, it changed the precision too. TASK DETAIL https://phabricator.wikimedia.org/T136528 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Aklapper, Nikki, Zppix, 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] T136270: "No label defined" incorrectly shown in the page title after merging
Nikki added a comment. I'm not sure if it's the same as that or not, I haven't noticed any strange behaviour in the table, only in the heading above it. I just got something similar after doing a rollback (this edit <https://www.wikidata.org/w/index.php?diff=340544116>), the heading showed the old value, the table showed the new value: F4060543: beethoven.png <https://phabricator.wikimedia.org/F4060543> (I've already purged the page to fix it since this isn't some obscure item) TASK DETAIL https://phabricator.wikimedia.org/T136270 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: matej_suchanek, Lydia_Pintscher, hoo, aude, Aklapper, Zppix, Nikki, D3r1ck01, Izno, Wikidata-bugs, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T136270: "No label defined" incorrectly shown in the page title after merging
Nikki added a comment. Here's a screenshot of what I mean: F4055726: nolabeldefined.png <https://phabricator.wikimedia.org/F4055726> TASK DETAIL https://phabricator.wikimedia.org/T136270 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Aklapper, Zppix, Nikki, 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] T136270: "No label defined" incorrectly shown in the page title after merging
Nikki created this task. Herald added subscribers: Zppix, Aklapper. TASK DESCRIPTION I have my UI language set to English. Today I merged several items which had English labels into items which did not have English labels. I noticed at least 4 times that, after the merge, the page title (the one just above the table with the labels/descriptions/aliases) still showed "No label defined" instead of the English label. Refreshing the page didn't help, only purging the page fixed it. I'm not sure if it happens every single time, but I was also able to reproduce it on test.wikidata.org on my first try at https://test.wikidata.org/wiki/Q2426 TASK DETAIL https://phabricator.wikimedia.org/T136270 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Aklapper, Zppix, Nikki, 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] T135826: Priority match the wikicode instead of names
Nikki added a comment. I'm not sure what you mean by a selector. What would people select there? I think just altering the order of the matches would make more sense than adding more options though because even with the proposed change, it would continue to work mostly the same as it does now (e.g. "en" already matches "English (en)", "de" already matches "Deutsch (de)", "port" already matches "português (pt)"). It would only be different when the code match is not the first match in the predefined list. TASK DETAIL https://phabricator.wikimedia.org/T135826 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Liuxinyu970226, Nikki, Aklapper, revi, YFdyh000, Zppix, 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] T135826: Priority match the wikicode instead of names
Nikki added a comment. This catches me out a lot. I'm used to using the language codes to refer to sites (it's in the URL, it's used when making a link to another wiki, it's even shown right next to the sitelink), so I expect the language code to also select the right site when adding sitelinks. It does work for most of them and when I come across one where it doesn't, it often takes several attempts to select the right site (I press tab before I can stop myself). Preferring language codes would mean there is always a short and predictable way to select any site, regardless of how many similarly-named languages there are. Preferring language names like it does now makes some sites harder to select than others: For some, you have to either type enough of the name to make it the first result or explicitly select something other than the first result (nowiki is a good example), whereas for other sites you can just enter the language code and press tab. TASK DETAIL https://phabricator.wikimedia.org/T135826 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Aklapper, revi, YFdyh000, Zppix, 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] [Updated] T135589: No unit is not consistently represented in JSON
Nikki added a project: Wikidata. TASK DETAIL https://phabricator.wikimedia.org/T135589 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Aklapper, Nikki, Zppix, 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] T115966: Show map for coordinate diffs
Nikki added a comment. I created https://www.wikidata.org/wiki/User:Nikki/CoordinateDiffMap.js if anyone wants to test it. I've tried to address all the bullet points in the description (e.g. it now uses maps.wikimedia.org and loads Leaflet from there too). Setting the zoom level from the precision doesn't work as well as I'd hoped, but at least it means that the map doesn't end up being zoomed really far in for coordinates which are only specified to the nearest degree or so. @Sjoerddebruin: I think I've managed to fix that. Couple of example diffs if you don't have any handy: https://www.wikidata.org/w/index.php?diff=108698259 https://www.wikidata.org/w/index.php?diff=330618596 (the globe changed, so you should only see a map for the old value) TASK DETAIL https://phabricator.wikimedia.org/T115966 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Lydia_Pintscher, Sjoerddebruin, Ricordisamoa, Nikki, Aklapper, 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] T134017: Create Wikipedia Jamaican
Nikki added a comment. In the description, it says the project namespace should be called "Wikipidia", but on jam.wikipedia.org it seems to still be "Wikipedia" TASK DETAIL https://phabricator.wikimedia.org/T134017 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Lydia_Pintscher, StevenJ81, hoo, aude, Multichill, VIGNERON, Nikki, chasemp, yuvipanda, Andrew, Volans, Stashbot, MZMcBride, zhuyifei1999, Meno25, Dereckson, Mtherwjs, Glaisher, Liuxinyu970226, Dzahn, Ebe123, gerritbot, jcrespo, Krenair, SPQRobin, Aklapper, Matanya, JEumerus, MF-Warburg, Lewizho99, Maathavan, Urbanecm, D3r1ck01, Tulsi_Bhagat, Izno, Luke081515, biplabanand, Wikidata-bugs, Snowolf, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T110043: [Bug] When typing fast an old parsed value is saved
Nikki added a comment. And again <https://www.wikidata.org/w/index.php?title=Q15881941=next=335337968> and again <https://www.wikidata.org/w/index.php?title=Q15876105=335338142=335338133> and again <https://www.wikidata.org/w/index.php?title=Q15874845=335338272=335338266>... :( This time I pasted the URL, double clicked the ID in the URL to select it, pressed ctrl-c ctrl-a ctrl-v and then pressed enter with the same hand (which meant moving it across the keyboard - I couldn't have pressed enter before pressing ctrl-v). This behaviour looks like the same problem I was encountering (@Sjoerddebruin too) a lot around the same time last year, but it had stopped happening for me for quite a while. TASK DETAIL https://phabricator.wikimedia.org/T110043 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Liuxinyu970226, Nikki, adrianheine, Jonas, thiemowmde, Lydia_Pintscher, Sjoerddebruin, Candalua, Aklapper, 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] T110043: [Bug] When typing fast an old parsed value is saved
Nikki added a comment. It also saved an old value for an external-id field for me a few days ago, I caught the 4 on the number pad when trying to press enter, deleted it, it still saved the extra 4 - https://www.wikidata.org/w/index.php?title=Q3042964=prev=333181418 :( TASK DETAIL https://phabricator.wikimedia.org/T110043 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Liuxinyu970226, Nikki, adrianheine, Jonas, thiemowmde, Lydia_Pintscher, Sjoerddebruin, Candalua, Aklapper, 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] T134017: Create Wikipedia Jamaican
Nikki added a comment. @aude: It does show up for me if I add ?debug=true to the URL TASK DETAIL https://phabricator.wikimedia.org/T134017 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Lydia_Pintscher, StevenJ81, hoo, aude, Multichill, VIGNERON, Nikki, chasemp, yuvipanda, Andrew, Volans, Stashbot, MZMcBride, zhuyifei1999, Meno25, Dereckson, Mtherwjs, Glaisher, Liuxinyu970226, Dzahn, Ebe123, gerritbot, jcrespo, Krenair, SPQRobin, Aklapper, Matanya, JEumerus, MF-Warburg, Lewizho99, Maathavan, Urbanecm, D3r1ck01, Tulsi_Bhagat, Izno, Luke081515, biplabanand, Wikidata-bugs, Snowolf, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T134017: Create Wikipedia Jamaican
Nikki added a comment. In https://phabricator.wikimedia.org/T134017#2282715, @Krenair wrote: > T117332: Links tables are sometimes not being populated <https://phabricator.wikimedia.org/T117332>? Possibly, although it seems like I'm seeing two things because purging the page will fix any templates or normal links which are incorrectly showing up as red links, but only a null edit fixes the categories. TASK DETAIL https://phabricator.wikimedia.org/T134017 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Lydia_Pintscher, StevenJ81, hoo, aude, Multichill, VIGNERON, Nikki, chasemp, yuvipanda, Andrew, Volans, Stashbot, MZMcBride, zhuyifei1999, Meno25, Dereckson, Mtherwjs, Glaisher, Liuxinyu970226, Dzahn, Ebe123, gerritbot, jcrespo, Krenair, SPQRobin, Aklapper, Matanya, JEumerus, MF-Warburg, Lewizho99, Maathavan, Urbanecm, D3r1ck01, Tulsi_Bhagat, Izno, Luke081515, biplabanand, Wikidata-bugs, Snowolf, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T134017: Create Wikipedia Jamaican
Nikki added a comment. I've also noticed that there are a lot of pages not appearing in the categories they're supposed to be in (compare these search results <https://jam.wikipedia.org/w/index.php?title=Special:Search=default=Search=insource%3A%22Category%3APravins+a+Soria%22=cfav6mp7pa62cbd5vj91ogeyn> with what is shown in the category itself <https://jam.wikipedia.org/wiki/Category:Pravins_a_Soria>) and a lot of pages which have templates showing up as red links. Doing a null edit on a page fixes it for that page, is there a script which can be run to fix it for all of them? TASK DETAIL https://phabricator.wikimedia.org/T134017 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Lydia_Pintscher, StevenJ81, hoo, aude, Multichill, VIGNERON, Nikki, chasemp, yuvipanda, Andrew, Volans, Stashbot, MZMcBride, zhuyifei1999, Meno25, Dereckson, Mtherwjs, Glaisher, Liuxinyu970226, Dzahn, Ebe123, gerritbot, jcrespo, Krenair, SPQRobin, Aklapper, Matanya, JEumerus, MF-Warburg, Urbanecm, D3r1ck01, Tulsi_Bhagat, Izno, Luke081515, biplabanand, Wikidata-bugs, Snowolf, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T134017: Create Wikipedia Jamaican
Nikki added a comment. I can add jamwiki links using QuickStatements (e.g. https://www.wikidata.org/w/index.php?diff=334730538) but if I try and do it on Wikidata itself, it doesn't find anything for "jam" and won't give me an input field to enter the page name. I tried a forced refresh and I tried clearing local storage like suggested on https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team/Archive/2016/02#Add_support_for_ady: but still no luck. :/ TASK DETAIL https://phabricator.wikimedia.org/T134017 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: StevenJ81, hoo, aude, Multichill, VIGNERON, Nikki, chasemp, yuvipanda, Andrew, Volans, Stashbot, MZMcBride, zhuyifei1999, Meno25, Dereckson, Mtherwjs, Glaisher, Liuxinyu970226, Dzahn, Ebe123, gerritbot, jcrespo, Krenair, SPQRobin, Aklapper, Matanya, JEumerus, MF-Warburg, Urbanecm, D3r1ck01, Tulsi_Bhagat, Izno, Luke081515, biplabanand, Wikidata-bugs, Snowolf, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T110673: [Story] Meaningful ranking for the selectable units
Nikki added a comment. For a unit suggester, I think doing that independent of the property wouldn't produce very good results and aiming straight for per-property would be better even if it takes longer. Doing it independent of the property sounds like every property would get a weird mixture of units - some properties might get a couple of units in the results which are suitable (but it would still be fairly meh, since the list would be mostly unsuitable units), other properties wouldn't have any useful units there at all. For search results, boosting the ranking of items which are used fairly often as units seems like it could work quite well independent of the property because it would presumably only affect things which already match your search terms (e.g. if I enter "km", the most likely thing I'm looking for is kilometre even if kilometre hasn't been used for that property yet... it's certainly a more likely option than Comoros, which is the current top result). TASK DETAIL https://phabricator.wikimedia.org/T110673 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Bugreporter, Ricordisamoa, Aklapper, Lydia_Pintscher, 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] T109572: [Bug] Expert extender re-position does not work in all cases
Nikki added a comment. Herald added a subscriber: TerraCodes. I'm not sure if it's quite the same or not, but I just had a similar issue with the coordinate field. I accidentally pasted a longer string into the field instead of what I intended, which made the value wrap onto a new line. Instead of moving down when the field resized, the floating box stayed where it was and ended up covering a lot of the field. I had to unfocus and refocus the field again to make it move out of the way. TASK DETAIL https://phabricator.wikimedia.org/T109572 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, TerraCodes, Jonas, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, TheDJ, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T110673: [Story] Meaningful ranking for the selectable units
Nikki added a comment. Is this suggesting that the search results should be ordered by how commonly used the units are, or is it suggesting that there should be a "unit suggester" like the property suggester which suggests the most common units for that property without having to search? The latter sounds like it would be really nice. TASK DETAIL https://phabricator.wikimedia.org/T110673 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Bugreporter, Ricordisamoa, Aklapper, Lydia_Pintscher, 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
Nikki added a comment. I'm not Bene, but I understood it to mean that it would only be shown after you click "More languages". TASK DETAIL https://phabricator.wikimedia.org/T126510 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: 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
[Wikidata-bugs] [Maniphest] [Commented On] T132839: Property suggester suggests human properties for non-human items
Nikki added a comment. The suggestions right now seem to be better than before, e.g. for the example in the description I get `P131`, mouth of the watercourse, sex or gender, date of birth. That still includes human properties, but at least mouth of the watercourse actually shows up now. Not quite the same, but presumably caused by how it decides which properties to select: I also often see country-specific properties for large countries show up as suggestions for items in other countries, e.g. https://www.wikidata.org/wiki/Q504582 currently suggests "China administrative division code" despite the item having the country set to the USA. If there's a change that would improve things like that too, that would be awesome. :) TASK DETAIL https://phabricator.wikimedia.org/T132839 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: daniel, mkroetzsch, Stashbot, thiemowmde, JanZerebecki, Lydia_Pintscher, hoo, Sjoerddebruin, Nikki, Aklapper, 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] T56097: [Story] allow to select globe in the UI
Nikki added a comment. Oh, cool :) Would it be possible to run it daily? There's a few that haven't been fixed, it seems their globes aren't in the supported list? TASK DETAIL https://phabricator.wikimedia.org/T56097 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Smalyshev, Nikki, Aklapper, Liuxinyu970226, Wikidata-bugs, Micru, Ricordisamoa, Lydia_Pintscher, D3r1ck01, Izno, aude, TheDJ, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T56097: [Story] allow to select globe in the UI
Nikki added a comment. I've added a bot request here: https://www.wikidata.org/wiki/Wikidata:Bot_requests#Fix_globes_for_non-Earth_coordinates I think someone might have already fixed some of them (the number seems a lot lower than I remember), but I'm not sure who. TASK DETAIL https://phabricator.wikimedia.org/T56097 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Smalyshev, Nikki, Aklapper, Liuxinyu970226, Wikidata-bugs, Micru, Ricordisamoa, Lydia_Pintscher, D3r1ck01, Izno, aude, TheDJ, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T133860: Missing result in Wikidata query
Nikki added a comment. I'm also having this problem (reported originally at https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team#Items_vanishing_from_SPARQL_query_results) There was a big removal for https://www.wikidata.org/w/index.php?title=Wikidata:Database_reports/Identified_duplicates=history as well. TASK DETAIL https://phabricator.wikimedia.org/T133860 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Smalyshev, Aklapper, Fnielsen, Avner, debt, Gehel, D3r1ck01, FloNight, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T133314: [Bug] Special:EntityData redirects to JSON in Edge
Nikki added a comment. That spec also says "If more than one media range applies to a given type, the most specific reference has precedence.". From the example it gives, it sounds like text/html should be preferred over */* for the accept header Edge sends, not because of the order but because text/html is more specific. I don't have access to any copies of IE, but searching for what accept headers it sends, it seems it also sends */* without any q parameters, so I'm guessing it's also affected by this. TASK DETAIL https://phabricator.wikimedia.org/T133314 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: daniel, Nikki, Aklapper, 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] T102417: Give Commons its own Wiki box rather than forcing it under Other sites
Nikki added a comment. On https://www.wikidata.org/wiki/Wikidata:Project_chat#Other_sites two suggestions were "other Wikimedia sites" and "other sister sites". TASK DETAIL https://phabricator.wikimedia.org/T102417 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Romaine, Ricordisamoa, Liuxinyu970226, Mike_Peel, daniel, Steinsplitter, Aklapper, Reguyla, 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] T93570: [Bug] deleting text of value and then clicking remove hangs UI
Nikki added a comment. I just got this with an identifier. I also tested with string, monolingual text, URL, Commons media and mathematical expression and the same happens for those (contrary to what the description says). TASK DETAIL https://phabricator.wikimedia.org/T93570 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, matej_suchanek, aude, adrianheine, thiemowmde, Aklapper, Lydia_Pintscher, D3r1ck01, Izno, Wikidata-bugs, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T133314: Special:EntityData redirects to JSON in Edge
Nikki edited the task description. TASK DETAIL https://phabricator.wikimedia.org/T133314 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Aklapper, 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] T133314: Special:EntityData redirects to JSON in Edge
Nikki created this task. Herald added a subscriber: Aklapper. TASK DESCRIPTION Originally reported by someone else on https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team#Identify_the_unit but I can reproduce it too: Using Edge in Windows 10, URLs like http://www.wikidata.org/entity/Q550207 and http://www.wikidata.org/Special:EntityData/Q550207 redirect to the JSON version (i.e. http://www.wikidata.org/Special:EntityData/Q550207.json). In other browsers, I get the HTML version (i.e. http://www.wikidata.org/wiki/Q550207), as expected. The accept header Edge sends is `Accept: text/html, application/xhtml+xml, image/jxr, */*`. I'm not sure if there's any other information that would be useful. TASK DETAIL https://phabricator.wikimedia.org/T133314 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Aklapper, 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] T101086: Standardize invalid language codes for Babel extension
Nikki added a comment. That sounds like a different issue, wep is already a valid language code. TASK DETAIL https://phabricator.wikimedia.org/T101086 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Whatamidoing-WMF, Glaisher, MarcoAurelio, StudiesWorld, Ricordisamoa, Liuxinyu970226, Nikki, Aklapper, Bugreporter, D3r1ck01, Izno, Wikidata-bugs, aude, SPQRobin, Dereckson, Arrbee, KartikMistry, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T133042: Quantity datatype precision (tracking)
Nikki added a comment. I'm not sure how to link it, but there's https://phabricator.wikimedia.org/T112247 asking for counts to have their own datatype. TASK DETAIL https://phabricator.wikimedia.org/T133042 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Stryn, Lydia_Pintscher, Liuxinyu970226, Snipre, Event, Ash_Crow, mgrabovsky, Micru, Denny, He7d3r, Bene, Wikidata-bugs, Ricordisamoa, Kelson, MSGJ, Klortho, Wolfvoll, Aklapper, Darkdadaah, DixonD, jeblad, Tobi_WMDE_SW, thiemowmde, JanZerebecki, TerraCodes, daniel, D3r1ck01, Izno, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T112247: [RFC] Create a "number" datatype for exact values
Herald added a subscriber: TerraCodes. TASK DETAIL https://phabricator.wikimedia.org/T112247 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, TerraCodes, JohnLewis, JanZerebecki, Micru, mkroetzsch, thiemowmde, Ricordisamoa, daniel, Lydia_Pintscher, Liuxinyu970226, Snaterlicious, jayvdb, SPQRobin, Wikidata-bugs, DSGalaktos, Bugreporter, geraki, Ayack, Gareth, kaldari, Smalyshev, Izno, AmaryllisGardener, Sjoerddebruin, Mbch331, Stryn, Denny, Jc3s5h, Aklapper, D3r1ck01, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T120198: More efficient SPARQL queries for sitelinks
Nikki added a comment. What is `?sitelink schema:inLanguage "en"` for in that query, and why do I get different numbers with (7167) and without (8375) it? TASK DETAIL https://phabricator.wikimedia.org/T120198 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, Nikki Cc: Nikki, Smalyshev, Aklapper, Steinsplitter, StudiesWorld, Jheald, Avner, debt, Gehel, D3r1ck01, FloNight, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T132839: Property suggester suggests human properties for non-human items
Nikki added a comment. Its obsession with human properties does seem to be quite recent and noticeable. If it had been like this all along, I'm not sure why I would suddenly be noticing it so much now. I'm not sure how your suggestion would work. None of the suggestions for the example I gave are identifiers and if you want to add "mouth of the watercourse" (which is also not an identifier), wouldn't you still get the same set of suggestions? Personally I really like that I don't have to use specific "add" buttons to add specific types of statements. I don't pay any attention to which one I click (actually, most of the time I use the KeyShortcuts gadget and press "a", which appears to trigger the one in the identifiers section), they're all just statements to me and if I'm adding a bunch of them, I don't mentally filter them into different groups first. TASK DETAIL https://phabricator.wikimedia.org/T132839 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Lydia_Pintscher, hoo, Sjoerddebruin, Nikki, Aklapper, 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] T132839: Property suggester suggests human properties for non-human items
Nikki created this task. Herald added a subscriber: Aklapper. TASK DESCRIPTION The property suggester keeps suggesting completely inappropriate human properties to me on items which are not humans. For example, right now, https://www.wikidata.org/wiki/Q504582 has the properties - `P31` (instance of) - `P373` (Commons category) - `P625` (coordinate location) - `P17` (country) - `P18` (image) - `P935` (Commons gallery) - `P885` (origin of the watercourse) - `P1599` (GeoNames ID) - `P646` (Freebase ID) - `P214` (VIAF ID) Of those, 6 are generic and can apply to a variety of items, 3 are specific to geographical features and 1 is fairly generic but not usually found on humans. Despite that, if I go to add a new property, the suggested properties are: - `P131` (located in the administrative territorial entity) - `P21` (sex or gender) - `P569` (date of birth) - `P735` (given name) - `P27` (country of citizenship) - `P106` (occupation) - `P19` (place of birth) The first of these would be a good property. The other 6 are all specific to humans (and other living beings) and should definitely //not// be added to rivers. I can't see why it's so biased towards human properties here. I would expect to see properties relating to rivers (e.g. `P403` (mouth of the watercourse) would actually be a useful suggestion) or at least properties relating to geographical features rather than humans. TASK DETAIL https://phabricator.wikimedia.org/T132839 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Aklapper, 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] T132291: Support fractional quantities
Nikki created this task. Herald added a subscriber: Aklapper. TASK DESCRIPTION Some quantities can be expressed exactly as fractions but only approximately as decimal values because they have recurring digits. Examples: - An inch <https://en.wikipedia.org/wiki/Inch> is exactly 1/12 of a foot but 1/12 is 0.83... - A minute <https://en.wikipedia.org/wiki/Minute> is exactly 1/60 of an hour but 1/60 is 0.016... - A foot <https://en.wikipedia.org/wiki/Foot_(unit)> is exactly 1/3 of a yard but 1/3 is 0.3... - A top quark <https://en.wikipedia.org/wiki/Top_quark> has an electric charge of exactly 2/3 e. but 2/3 is 0.6... - A pre-decimal British halfpenny <https://en.wikipedia.org/wiki/Halfpenny_(British_pre-decimal_coin)> was worth exactly 1/480 of a pound but 1/480 is 0.02083... - Some gramophone records <https://en.wikipedia.org/wiki/Gramophone_record> have a rotational speed of 33 1/3 rpm but 33 1/3 is 33.3... There are also cases where values can be turned into decimal numbers but they would normally be represented as fractional quantities, e.g. the spin of a top quark is normally written 1/2 rather than 0.5 and the value of the pre-decimal halfpenny is normally written 1/2d rather than 0.5d (example of a 2½d stamp <https://commons.wikimedia.org/wiki/File:Stamp_Bermuda_1936_2.5p.jpg>). Fractions can of course be negative too, e.g. the electric charge of a strange quark <https://en.wikipedia.org/wiki/Strange_quark> is -1/3 e. I would expect to be able to input simple fractions (e.g. "1/3"), top-heavy fractions (e.g. "4/3") and mixed fractions (e.g. "33 1/3"). I would also expect Unicode fraction characters (¼ ½ ¾ ⅐ ⅑ ⅒ ⅓ ⅔ ⅕ ⅖ ⅗ ⅘ ⅙ ⅚ ⅛ ⅜ ⅝ ⅞) and the fraction slash (U+2044, e.g. "1⁄4") to be recognised when entering values on the website so that copying a value from a source which uses one of those characters does not produce an error. Previously mentioned at https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team#Quantity_datatype TASK DETAIL https://phabricator.wikimedia.org/T132291 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Aklapper, 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] T131920: DuplicateReferences doesn't show insert reference button
Nikki added a comment. It's still not working for me :( If I try to copy an existing reference, the text changes to "copied" but no "insert reference" links appear. In the console, I get `VM6563:219 Uncaught TypeError: Cannot set property '_hash' of undefined`. If I try to copy a newly added reference, I do get "insert reference" links, but when I click one of them, the text changes to "copied" (for some reason) and no reference appears. In the console, I get `VM6563:220 Uncaught TypeError: Cannot read property 'className' of undefined` TASK DETAIL https://phabricator.wikimedia.org/T131920 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Ricordisamoa, adrianheine, Aklapper, Bene, Sjoerddebruin, 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] [Updated] T131665: [Bug] Geohack link ignores globe in coordinates
Nikki added a comment. I created https://phabricator.wikimedia.org/T105321 ages ago for the AuthorityControl gadget, is this the same thing? TASK DETAIL https://phabricator.wikimedia.org/T131665 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Ricordisamoa, Nikki Cc: Nikki, thiemowmde, Ricordisamoa, Aklapper, Smalyshev, Lewizho99, D3r1ck01, Izno, Wikidata-bugs, aude, Sjoerddebruin, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T131550: Table sorting fails when a column contains blank values
Nikki created this task. Herald added a subscriber: Aklapper. Herald added projects: Wikidata, Discovery. TASK DESCRIPTION Clicking the headers to sort table columns doesn't work if the column contains blank values. For example, this query: https://query.wikidata.org/#select%20*%20where%20%7B%0Avalues%20%3Fitem%20%7B%20wd%3AQ2%20wd%3AQ183%20wd%3AQ513%20%7D%0A%3Fitem%20wdt%3AP646%20%3Ffreebase%20.%0Aoptional%20%7B%20%3Fitem%20wdt%3AP30%20%3Fcontinent%20.%20%7D%0A%7D The "freebase" column contains no blank values and clicking the header works fine to change the sorting. The "continent" column does contain blank values and if I click the "continent" heading, nothing changes. In the console in Chromium I get `TableResultBrowser.js:88 Uncaught TypeError: Cannot read property 'value' of undefined`. In Firefox, `TypeError: data1 is undefined TableResultBrowser.js:88:3` TASK DETAIL https://phabricator.wikimedia.org/T131550 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Aklapper, Avner, debt, Gehel, D3r1ck01, FloNight, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T55562: [Bug] Special:UnconnectedPages lists connected pages
Nikki added a comment. It seems like there's still some issues. I see "1692 nî Sūi-tián" listed here <https://zh-min-nan.wikipedia.org/w/index.php?title=Tek-pia%CC%8Dt:%E7%84%A1%E9%80%A3%E6%8E%A5%E9%A0%81%E9%9D%A2=20=120=0> even though the page itself <https://zh-min-nan.wikipedia.org/wiki/1692_n%C3%AE_S%C5%ABi-ti%C3%A1n> shows the page as being connected to Wikidata. TASK DETAIL https://phabricator.wikimedia.org/T55562 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Ladsgroup, Aklapper, Kwgulden, Krenair, Wikidata-bugs, He7d3r, Sjoerddebruin, Samat, matej_suchanek, Ricordisamoa, Vriullop, Yamaha5, Multichill, Tgr, Lydia_Pintscher, hoo, D3r1ck01, Izno, aude, TheDJ, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T131002: Wikidata: quantity datatype and strange rouding
Nikki added a comment. This looks like the same problem as https://phabricator.wikimedia.org/T95425 to me. TASK DETAIL https://phabricator.wikimedia.org/T131002 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Srittau, Aklapper, 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] T130797: In WDQS GUI, each keystroke now produces new history entry
Nikki added a comment. It actually breaks the history for me, I can press the back button once and it deletes the last letter I typed, but pressing it again does nothing (in all the browsers I tried, including two versions of Chromium, Firefox and Vivaldi). Another problem which I'm assuming is also caused by this (since it updates the URL on every keystroke) is that after I run a query in Chromium or Vivaldi (presumably any Blink-based ones), typing in the textarea is laggy. I couldn't reproduce it in Firefox and aude couldn't reproduce it at all, but it happens on both of my computers on all the queries I've tried so far (it seems to be worse after queries returning lots of results, so maybe try something like https://query.wikidata.org/#SELECT%20%3Fitem%20WHERE%20%7B%0A%3Fitem%20wdt%3AP17%20wd%3AQ17%0A%7D%20limit%201 if you want to see if you can reproduce it) TASK DETAIL https://phabricator.wikimedia.org/T130797 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jonas, Nikki Cc: Nikki, Aklapper, Smalyshev, debt, Gehel, D3r1ck01, FloNight, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T115792: [Bug] Language selector in [[Special:NewItem]] doesn't recognize certain languages
Nikki added a comment. This also seems problematic for other tools, e.g. as I explained in https://www.wikidata.org/wiki/Topic:Szxlu94k4l8qx7zx, Duplicity doesn't work very well for zh_min_nanwiki right now. To fix it, it would currently need to use "nan" as the language code for the API and "zh-min-nan" for Special:NewItem. It would be better if the same code could be used in both places. TASK DETAIL https://phabricator.wikimedia.org/T115792 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, adrianheine, Stigmj, Cocu, jeblad, StudiesWorld, Liuxinyu970226, hoo, Sjoerddebruin, jhsoby, Aklapper, 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] T130644: SPARQL query returns old data
Nikki created this task. Herald added a subscriber: Aklapper. Herald added projects: Wikidata, Discovery. TASK DESCRIPTION https://query.wikidata.org/#SELECT%20%3Fitem%20%3Fid%0AWHERE%0A%7B%0Avalues%20%3Fitem%20%7B%20wd%3AQ2894345%20wd%3AQ1197352%20%7D%20.%0A%3Fitem%20wdt%3AP345%20%3Fid%20.%0A%7D This query is currently returning both `tt0030848` and `turkce` for Q1197352 and `tt1473150` and `http://www.imdb.com/title/tt1473150/` for Q2894345 for me. The first item was edited about 12 hours ago in https://www.wikidata.org/w/index.php?title=Q1197352=314530266=314529782 The second item was edited about 3 days ago in https://www.wikidata.org/w/index.php?title=Q2894345=313650078=313266933 TASK DETAIL https://phabricator.wikimedia.org/T130644 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Aklapper, debt, Gehel, D3r1ck01, FloNight, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T130428: Handle non-Earth coordinates in Maps view
Nikki added a comment. @Smalyshev: Agreed, that's what I meant by my first line. :) Should I make a new ticket for displaying maps of other globes? @Jonas: For supporting multiple maps, the most obvious option to me would be: When there are non-earth coordinates in the results, change "Map" in the display menu to "Map (Earth)" and add similar options (e.g. "Map (Moon)") for the other supported globes which are in the results. TASK DETAIL https://phabricator.wikimedia.org/T130428 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jonas, Nikki Cc: daniel, Nikki, Aklapper, Smalyshev, debt, Gehel, D3r1ck01, FloNight, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T56097: [Story] allow to select globe in the UI
Nikki added a comment. https://phabricator.wikimedia.org/T127950 has been created for celestial coordinate support (which needs more than just changing the globe). Is this likely to be fixed any time soon? I've noticed some people have been adding coordinates for non-Earth objects despite not being able to change the globe. I've been reluctant to do that, but looking at the age of this ticket, I'm thinking it might be more productive to add them without changing the globe and convince someone to run a bot to fix them (using the https://www.wikidata.org/wiki/Property:P376 statements). TASK DETAIL https://phabricator.wikimedia.org/T56097 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Aklapper, Liuxinyu970226, Wikidata-bugs, Micru, Ricordisamoa, Lydia_Pintscher, D3r1ck01, Izno, aude, TheDJ, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T130428: Handle non-Earth coordinates in Maps view
Nikki added a comment.
The UI will of course need to handle globes it doesn't understand so the
following is possibly going off on a tangent a bit, but I wanted to share it
anyway in case it's useful to anyone. :)
GeoHack can show maps of the moon (e.g.
https://tools.wmflabs.org/geohack/geohack.php?pagename=Hooke_%28lunar_crater%29=41.2_N_54.9_E_globe:Moon_type:landmark),
as well as various other non-earth things (I assume everything listed in
https://en.wikipedia.org/wiki/Category:GeoTemplates). It uses a single image
for each globe and I guess it just positions the coordinates relative to the
dimensions of the image.
It appears the WDQS UI is using Leaflet. Leaflet can do image overlays and
there's no reason why a single image (like the ones GeoHack uses) couldn't be
set to overlay the entire globe. I know very little about map projections and
stuff like that, but it seemed like it shouldn't be that hard to replace tiles
with a full-globe overlay and I was also curious, so I played around and
eventually came up with the following little HTML/JS thing:
http://cdn.leafletjs.com/leaflet/v0.7.7/leaflet.css; />
http://cdn.leafletjs.com/leaflet/v0.7.7/leaflet.js"</a>;>
var bounds = L.latLngBounds([[-90, -180], [90, 180]]); // the image
overlays the whole globe
var map = L.map('mapid', {
maxZoom: 3,
minZoom: 2,
center: [0, 0],
zoom: 3,
crs: L.CRS.EPSG4326 // magic stuff that makes it 2x1
});
var objects = Array(
// Moon
{ lat: 41.2, lon: 54.9, name: 'Hooke' }, //
<a rel="nofollow" href="https://tools.wmflabs.org/geohack/geohack.php?pagename=Hooke_%28lunar_crater%29¶ms=41.2_N_54.9_E_globe:Moon_type:landmark">https://tools.wmflabs.org/geohack/geohack.php?pagename=Hooke_%28lunar_crater%29¶ms=41.2_N_54.9_E_globe:Moon_type:landmark</a>
{ lat: 4.1, lon: 132.9, name: 'Green' }, //
<a rel="nofollow" href="https://tools.wmflabs.org/geohack/geohack.php?pagename=Green_%28lunar_crater%29¶ms=4.1_N_132.9_E_globe:Moon_type:landmark">https://tools.wmflabs.org/geohack/geohack.php?pagename=Green_%28lunar_crater%29¶ms=4.1_N_132.9_E_globe:Moon_type:landmark</a>
{ lat: 28.1, lon: 109.1, name: 'Espin' }, //
<a rel="nofollow" href="https://tools.wmflabs.org/geohack/geohack.php?pagename=Espin_%28crater%29¶ms=28.1_N_109.1_E_globe:Moon_type:landmark">https://tools.wmflabs.org/geohack/geohack.php?pagename=Espin_%28crater%29¶ms=28.1_N_109.1_E_globe:Moon_type:landmark</a>
{ lat: 86.1, lon: -61.8, name: 'Gore' } //
<a rel="nofollow" href="https://tools.wmflabs.org/geohack/geohack.php?pagename=Gore_%28crater%29¶ms=86.1_N_61.8_W_globe:Moon_type:landmark">https://tools.wmflabs.org/geohack/geohack.php?pagename=Gore_%28crater%29¶ms=86.1_N_61.8_W_globe:Moon_type:landmark</a>
// Mars
// { lat: 34.67, lon: 144.23, name: 'Fenagh' }, //
<a rel="nofollow" href="https://tools.wmflabs.org/geohack/geohack.php?pagename=Fenagh_%28crater%29¶ms=34.67_N_215.77_W_globe:Mars_type:landmark">https://tools.wmflabs.org/geohack/geohack.php?pagename=Fenagh_%28crater%29¶ms=34.67_N_215.77_W_globe:Mars_type:landmark</a>
// { lat: 33.7, lon: -81.9, name: 'Nipigon' } //
<a rel="nofollow" href="https://tools.wmflabs.org/geohack/geohack.php?pagename=Nipigon_%28crater%29¶ms=33.7_N_81.9_W_globe:Mars_type:landmark">https://tools.wmflabs.org/geohack/geohack.php?pagename=Nipigon_%28crater%29¶ms=33.7_N_81.9_W_globe:Mars_type:landmark</a>
// Europa
// { lat: -25.2, lon: 88.6, name: 'Pwyll' } //
<a rel="nofollow" href="https://tools.wmflabs.org/geohack/geohack.php?pagename=Pwyll_%28crater%29¶ms=25.2_S_271.4_W_type:landmark_globe:europa">https://tools.wmflabs.org/geohack/geohack.php?pagename=Pwyll_%28crater%29¶ms=25.2_S_271.4_W_type:landmark_globe:europa</a>
);
objects.forEach(function (obj) {
var marker = L.marker([obj.lat, obj.lon]).addTo(map);
marker.bindPopup(obj.name);
});
var url =
'<a rel="nofollow" href="https://upload.wikimedia.org/wikipedia/commons/d/db/Moonmap_from_clementine_data.png">https://upload.wikimedia.org/wikipedia/commons/d/db/Moonmap_from_clementine_data.png</a>';
// Moon
//var url =
'<a rel="nofollow" href="https://upload.wikimedia.org/wikipedia/commons/b/b7/Mars_G%C3%A9olocalisation.jpg">https://upload.wikimedia.org/wikipedia/commons/b/b7/Mars_G%C3%A9olocalisation.jpg</a>';
// Mars
//var url =
'<a rel="nofollow" href="https://upload.wikimedia.org/w
[Wikidata-bugs] [Maniphest] [Commented On] T127014: Empty result on a tree query
Nikki added a comment. I'm having this problem with various queries too. It seems to happen a lot with sitelink queries, e.g. https://query.wikidata.org/#SELECT%20%3Fitem%20%3Farticle%0AWHERE%0A%7B%0A%09%3Farticle%20schema%3Aabout%20%3Fitem%20.%0A%09FILTER%20(SUBSTR(str(%3Farticle)%2C%201%2C%2035)%20%3D%20%22https%3A%2F%2Fspecies.wikimedia.org%2Fwiki%2F%22)%0A%7D%0ALIMIT%205000 It also seems to happen quite easily if I try to select too many items with a label in a particular language, e.g. https://query.wikidata.org/#SELECT%20%3Fitem%20%3Fsqlabel%0AWHERE%0A%7B%0A%3Fitem%20rdfs%3Alabel%20%3Fsqlabel%20filter%20(lang(%3Fsqlabel)%20%3D%20%22sq%22)%20.%0A%7D%0Alimit%202000%0A TASK DETAIL https://phabricator.wikimedia.org/T127014 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Mbch331, Magnus, JanZerebecki, Smalyshev, Aklapper, StudiesWorld, Bugreporter, debt, Gehel, D3r1ck01, FloNight, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T127950: Support celestial coordinates
Nikki added a comment. This was created after a question at https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team/Archive/2016/02#Celestial_coordinates I also just came across https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team/Archive/2013/09#Celestial_coordinate_system and found a mention of celestial coordinates on https://phabricator.wikimedia.org/T56097. Regarding Lydia's question on the first link. I think it can't be done satisfactorily by simply using the existing coordinates implementation with a different globe because of the different expectations for inputting/outputting values, but it seems like it could probably be done by extending the existing coordinates support. The things I can see that are clearly missing are: - support for inputting values in the expected format - support for outputting values in the expected format - support for changing the globe (https://phabricator.wikimedia.org/T56097) - an agreement on what to use as a globe I'm not an expert on the subject though, so maybe I'm missing something. :) On a related note, https://en.wikipedia.org/wiki/Template:Infobox_supernova includes Galactic coordinates (e.g. https://en.wikipedia.org/wiki/SN_1885A). As I understand it, those use a system with 0° to 360° for longitude and 90° to -90° for latitude - closer to geographic coordinates but still with different expectations for input/output. TASK DETAIL https://phabricator.wikimedia.org/T127950 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Jc3s5h, Swpb, Nikki, Aklapper, Micru, StudiesWorld, 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] T56097: [Story] allow to select globe in the UI
Nikki added a comment. Oh, and here's a query <https://query.wikidata.org/#SELECT%20%3Fitem%20%3Fbody%20%3Fglobe%20%0AWHERE%0A%7B%0A%3Fitem%20wdt%3AP376%20%3Fbody%20.%0A%0A%3Fitem%20p%3AP625%20%3Fcoordinate%20.%0A%3Fcoordinate%20psv%3AP625%20%3Fv%20.%0A%3Fv%20wikibase%3AgeoGlobe%20%3Fglobe%20.%0A%0Afilter%20(%3Fglobe%20!%3D%20%3Fbody)%20.%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%0A%7D> for items where the coordinate globe doesn't match the `P376` statement. TASK DETAIL https://phabricator.wikimedia.org/T56097 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Aklapper, Liuxinyu970226, Wikidata-bugs, Micru, Ricordisamoa, Lydia_Pintscher, D3r1ck01, Izno, aude, TheDJ, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T106670: Make beta-version of labelLister default
Nikki added a comment. Prompted by something that just came up on IRC: Another thing the labelLister gadget can do is delete all aliases for a language at once. While you can do that without the gadget from Special:SetLabelDescriptionAliases, that page isn't very easy to find and the normal UI doesn't have anything for deleting aliases, other than manually selecting and deleting the text for each one by one. I'm not sure if deleting all aliases at once is something we'd want to be there by default, but it might be something for a new gadget. TASK DETAIL https://phabricator.wikimedia.org/T106670 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Jitrixis, matej_suchanek, Ricordisamoa, Mbch331, Sjoerddebruin, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T128851: https://query.wikidata.org/ loads old queries instead of starting a new query
Nikki added a comment. Sorry, this got a bit long... I don't find the clear button very intuitive as a way to start a new query. I'm having trouble explaining why, but I can try: It's quite far down the page below the textarea (often off the bottom of the screen on my laptop since the query pushes it even further down), so it's not very easy to spot (assuming it's on the screen at all). It also doesn't work with how I actually react to things: When I go to the page, my intention is to start a new query and if there's an existing query there, my instinct isn't to go down the page (past the stuff I don't even want) to find a clear button at the bottom of the form, it's to abandon the current page in favour of a new one (e.g. by clicking a link back to the main page... which in this case would only lead me into an infinite loop :)). When I have no choice but to clear the form, I end up doing it manually, because it never occurs to me to start by going to the end of the form - by the time I notice/remember there's a clear button, it's too late. I think adding a hash to the end of the URL might be a bit too subtle. I can see why you suggest that, but a stray hash at the end of the URL normally has no effect on the page and it's also not obviously saying "this creates a new query", so I think it could be a bit confusing (e.g. in particular, if some people link to it with the hash and some without, someone loading the page would sometimes see an old query and sometimes a blank query, unless you spot the pattern, it will just appear inconsistent). I think if we want a URL explicitly for new queries, something like /new would be better. Referring to what aude said, I think the lack of a history is another problem with loading old queries. The current behaviour gets in my way because I don't have any use for loading the last query I ran: I can't be sure I won't accidentally run another query after closing a query (e.g. one of the other queries I have open or a query someone else is asking for help with), so if I want to save a query, I'll either leave it open in a tab or create a bookmark, then when I want that query again, I'll just open the tab/bookmark, not go to the main page. That means that when I do go to the main page, it's only to start a new query, and having to clear the form ends up being an extra step every single time. I also find it weird because I don't use any other site which does anything like that, which makes it unexpected behaviour for me. The closest thing I know of is the way Phabicator saves unfinished comments, but those are specific to individual tickets and go away once saved. I would prefer a way to make it never load the last query (since as I explained above, I have no use for it), but if people don't want that, I would at least appreciate some way of getting a page which defaults to a blank query. TASK DETAIL https://phabricator.wikimedia.org/T128851 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Jonas, Nikki Cc: aude, Smalyshev, Nikki, Aklapper, debt, Gehel, D3r1ck01, FloNight, Izno, jkroll, Wikidata-bugs, Jdouglas, Deskana, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T129450: Save link does not become active when removing a sitelink
Nikki created this task. Herald added a subscriber: Aklapper. TASK DESCRIPTION Reported at https://www.wikidata.org/wiki/Wikidata:Project_chat#Cannot_remove_an_entry and on IRC by Harmonia_Amanda When you click the icon to remove a sitelink, the row is removed, but the save link does not become active, so the change can't be saved. TASK DETAIL https://phabricator.wikimedia.org/T129450 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Aklapper, 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] [Updated] T128947: Query returns deleted items
Nikki added a project: Wikidata-Query-Service. Herald added projects: Wikidata, Discovery. TASK DETAIL https://phabricator.wikimedia.org/T128947 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Aklapper, Nikki, debt, Gehel, D3r1ck01, FloNight, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T128851: https://query.wikidata.org/ loads old queries instead of starting a new query
Nikki created this task. Herald added a subscriber: Aklapper. Herald added projects: Wikidata, Discovery. TASK DESCRIPTION When I go to https://query.wikidata.org/, instead of getting an empty textarea to start a new query like I used to, it now loads some old query that I happened to run at some point in the past. There's no obvious way to start a new query either. That's really annoying behaviour for me because I only go to https://query.wikidata.org/ to start a new query (or occasionally to paste an existing query, which I would also want an empty textarea for). TASK DETAIL https://phabricator.wikimedia.org/T128851 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Aklapper, debt, Gehel, D3r1ck01, FloNight, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T110043: [Bug] When typing fast an old parsed value is saved
Nikki added a comment. I'm not sure if it's a separate issue or not but I'm having a similar problem with it saving (or trying to save) old or incomplete values with monolingual text languages. For example, I typed "ale" (the start of a language name). It didn't find any results, so I backspaced and typed "mis" instead, added a qualifier and only then tried to save. That gave me an error saying that "ale" is not a valid code, even though that's not what was in the field. I clicked back into the value field so the language popup would reappear, cleared the text in the language field, retyped "mis" and clicked save again. That time it saved it successfully... as Maori (code "mi"). TASK DETAIL https://phabricator.wikimedia.org/T110043 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, adrianheine, Jonas, thiemowmde, Lydia_Pintscher, Sjoerddebruin, Candalua, Aklapper, 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] T127858: Add Noongar (nys) as a language which can be used for labels (etc)
Nikki created this task. Herald added subscribers: StudiesWorld, Aklapper. TASK DESCRIPTION Requested at https://www.wikidata.org/wiki/Wikidata:Project_chat#New_language Language code: nys Name: Noongar (variations on the name exist: the English Wikipedia uses Nyungar, ISO 639-3 uses Nyunga) Script: Latin Used by: Noongar people in Western Australia Wikidata link: https://www.wikidata.org/wiki/Q7049771 TASK DETAIL https://phabricator.wikimedia.org/T127858 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Aklapper, Nikki, StudiesWorld, 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] T127435: Allow items in Cape Verdean Creole (kea) in Wikidata
Nikki added a comment. This is already one of the languages listed as missing on https://phabricator.wikimedia.org/T74126. TASK DETAIL https://phabricator.wikimedia.org/T127435 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, MF-Warburg, Ahoerstemeier, GerardM, waldyrious, Aklapper, StudiesWorld, Bugreporter, 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] T127213: Merging doesn't always create a redirect
Nikki created this task. Nikki added a subscriber: Nikki. Nikki added a project: Wikidata. Herald added subscribers: StudiesWorld, Aklapper. TASK DESCRIPTION When checking items which have no statements or sitelinks, I keep coming across items which were merged but not redirected, leaving behind an empty item. I'm not sure how the users are creating the edits, but it seems like unintended behaviour. Some examples from this month: https://www.wikidata.org/w/index.php?title=Q9919933=history https://www.wikidata.org/w/index.php?title=Q10055090=history https://www.wikidata.org/w/index.php?title=Q9956781=history https://www.wikidata.org/w/index.php?title=Q9964632=history https://www.wikidata.org/w/index.php?title=Q9924553=history https://www.wikidata.org/w/index.php?title=Q9826553=history It doesn't appear to be a new problem though, I'm also finding items where the merge took place months ago, e.g. https://www.wikidata.org/w/index.php?title=Q9918772=history (November) https://www.wikidata.org/w/index.php?title=Q12296651=history (October) https://www.wikidata.org/w/index.php?title=Q12149749=history (August) Looking at those examples, it seems like they all still have some descriptions set, even though most of the information was removed. TASK DETAIL https://phabricator.wikimedia.org/T127213 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Aklapper, Nikki, StudiesWorld, 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: Allow adding arbitrary languages in the interface
Nikki added a comment. Another two uses I just had: Someone entered a label and description using the wrong language code. I can remove them from the wrong code, but I need labelLister to add them to the right code. Some sitelinks had been added some time ago. Usually a bot will add labels when that happens, but sometimes things seem to get skipped so I wanted to just add the labels myself, but I needed labelLister to do it. TASK DETAIL https://phabricator.wikimedia.org/T126510 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Izno, Lydia_Pintscher, Mbch331, Aklapper, matej_suchanek, StudiesWorld, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T127045: Interlanguage links cannot be added to pages in ady.wikipedia.org
Nikki added a subscriber: Nikki. TASK DETAIL https://phabricator.wikimedia.org/T127045 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, aude, hoo, StudiesWorld, MarcoAurelio, Mbch331, MF-Warburg, daniel, Krenair, Amire80, Aklapper, Izno, Wikidata-bugs ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126510: Allow adding arbitrary languages in the interface
Nikki added a subscriber: Nikki. Nikki added a comment. I often want to do this, because Wikipedia articles will normally include the name in the original/native/local language(s) and I'd like to add those as labels too. Related to what @Izno said, if you move a sitelink to another item, the item won't automatically have a label in the language. You can remove the label from the old item, but you can't add it to the new item. I do find it rather strange that I can do pretty much anything independently of the UI language except for adding new terms. I'm not restricted in which sitelinks I can add, I'm not restricted in which monolingual text statements I can add and now I'm not even restricted in which labels I can see, edit or remove, but adding new labels? There's no obvious way to do that, the best option I have is a not very user friendly gadget that isn't enabled by default. I'm not sure how we can accurately analyse how often it happens. We could figure out how many new labels were added using the labelLister gadget from the history, but that wouldn't tell us how many labels people wanted to add but didn't. TASK DETAIL https://phabricator.wikimedia.org/T126510 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Izno, Lydia_Pintscher, Mbch331, Aklapper, matej_suchanek, StudiesWorld, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T125073: [Story] Replace bad, but currently necessary language codes
Nikki added a comment. @XXN: I had seen that, although as I described above, the current situation in Wikidata is different, since we have a mixture of Latin script and Cyrillic script terms for `mo` (where the Latin ones largely come from a bot copying the `ro` label and the Cyrillic ones largely come from mowiki page names). What do you think of what I proposed? (move Cyrillic terms to `ro-cyrl`, merge Latin terms with `ro`) TASK DETAIL https://phabricator.wikimedia.org/T125073 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: XXN, Liuxinyu970226, Nikki, Fomafix, adrianheine, Aklapper, 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] T125913: Capitalize property headings in the Special:AboutTopic view
Nikki added a subscriber: Nikki. Nikki added a comment. Some property names start with an intentional lowercase letter, e.g. https://www.wikidata.org/wiki/Property:P1117 and https://www.wikidata.org/wiki/Property:P2281 (in English) I have no idea how the ucfirst method works, but I think for some African languages, it's not always the first letter that's capitalised (e.g. some of the headings on https://ss.wikipedia.org/wiki/Likhasi_Lelikhulu start with "iWikipedia") TASK DETAIL https://phabricator.wikimedia.org/T125913 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Dereckson, Nikki Cc: Nikki, SPQRobin, Ricordisamoa, Lucie, gerritbot, Aklapper, StudiesWorld, Dereckson, Izno, Wikidata-bugs, aude, Gryllida, Shizhao, Arrbee, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T126001: Create wikidata-imports mailing list
Nikki added a subscriber: Nikki. TASK DETAIL https://phabricator.wikimedia.org/T126001 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, johl, HakanIST, Esh77, Lydia_Pintscher, Aklapper, Mrjohncummings, StudiesWorld, Izno, Barras, Wikidata-bugs, aude, Jalexander, JohnLewis, Mbch331, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T125073: [Story] Replace bad, but currently necessary language codes
Nikki added a comment. Yeah, `ckb-x-zam` and `roa-x-tara` should be valid (I tested them on http://r12a.github.io/apps/subtags/ and it agrees). For Serbian, even if the comments in one of the source files say it's supposed to be the Ekavian variety, I would expect users to go by what the user interface says (which doesn't seem to mention Ekavian anywhere). It'd be helpful if we could find a Serbian speaker who would know whether it really is only used for Ekavian... I was mostly talking about terms because they're more common than monolingual text statements. :) I can't think of anything where I would expect them be treated differently though, other than the special codes (`mul`, `zxx`, etc) which don't make much sense for terms. I remembered some more invalid codes: `de-formal`, `nl-informal` and `simple`. They're UI languages but occasionally people use them for content. If they stop being allowed for content, we should replace them with `de`, `nl` and `en` respectively. If they continue being allowed for content, `simple` would become `en-simple`, but there are no subtags for formal/informal, so I guess they would have to be something like `de-x-formal` and `nl-x-informal`. By the way, language names are not always localised (e.g. in English `nl` shows up as "Dutch" but `nl-informal` shows up as "Nederlands (informeel)"), is that a bug or do they need translating somewhere? (and if so, where?) TASK DETAIL https://phabricator.wikimedia.org/T125073 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Fomafix, adrianheine, Aklapper, 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] T125299: Using VALUES causes the query to fail because the URL is too long
Nikki created this task.
Nikki added a subscriber: Nikki.
Nikki added a project: Wikidata-Query-Service.
Herald added subscribers: StudiesWorld, Aklapper.
Herald added projects: Wikidata, Discovery.
TASK DESCRIPTION
I am trying to select some information about approximately 1000 items which
were edited by the same person. I can't select the IDs using statements, so I
tried to enter the IDs using VALUES ?item { wd:Q... wd:Q... etc } but that
fails because the URL is too long:
```
ERROR:
414 Request-URI Too Large
414 Request-URI Too Large
nginx/1.9.3
```
TASK DETAIL
https://phabricator.wikimedia.org/T125299
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Nikki
Cc: Aklapper, Nikki, StudiesWorld, debt, jkroll, Smalyshev, Wikidata-bugs,
Jdouglas, aude, Deskana, Manybubbles, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T47839: [Bug] All language links not showing up, manual purge required
Nikki added a subscriber: Nikki. Nikki added a comment. Another example: https://en.wikipedia.org/wiki/Bangor,_Gwynedd currently has no interwiki links or Wikidata link, last edited 3 days ago. The Wikidata item is https://www.wikidata.org/wiki/Q234178 TASK DETAIL https://phabricator.wikimedia.org/T47839 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Liuxinyu970226, MaxBioHazard, matmarex, Schnark, Glaisher, StudiesWorld, Base, Josve05a, Malenki, TTO, revi, YMS, IKhitron, Amire80, thiemowmde, hoo, Bugreporter, Aklapper, FriedhelmW, wikibugs-l-list, Wikidata-bugs, Abraham, Nemo_bis, Silvonen, aude, Lydia_Pintscher, Stryn, UV, Unknown Object (MLST), Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T125073: [Story] Replace bad, but currently necessary language codes
Nikki added a subscriber: Nikki. Nikki added a comment. There's also: - `nrm` - currently described as Norman, but that code is assigned to Narum. It's not clear whether Norman has its own code. The closest is `nrf` (Jèrriais, Guernésiais) which are two of the dialects. It was created in http://www-01.sil.org/iso639-3/chg_detail.asp?id=2014-024 where someone requested `jrs` for Jèrriais but ISO 639 decided against assigning a code specifically for Jèrriais because they consider it and Guernésiais to be dialects of the same language. Instead they created `nrf`. That implies to me that `nrf` is supposed to mean Norman even if that's not one of the names they list for the language. - `cbk-zam` - Chavacano de Zamboanga, a variety of Chavacano that doesn't have its own code or language subtag - `roa-tara` - Tarantino, which also doesn't have its own code or language subtag The code for Serbian is `sr` (or `srp` for the 3-letter version, but we currently use 2-letter codes when available). `src` is Logudorese Sardinian. :) The labels for `sr-el` and `sr-ec` are simply "Serbian (Latin script)" and "Serbian (Cyrillic script)", I would have expected `sr-latn` and `sr-cyrl` because it doesn't say it has to be the Ekavian variant and there are no options for other variants. The country code for Moldova is `MD` (`MO` is Macau). The situation for `mo` is kinda weird. The (now closed) Moldovan Wikipedia is entirely in Cyrillic, and apparently the pages were copies of articles from the Romanian Wikipedia converted to Cyrillic, so any of the labels which came from there are `ro-cyrl`. Then there are a couple of thousand Latin labels for `mo`, most of which are identical to the current Romanian label. All the ones I've looked so far which aren't the same are cases where a bot copied `ro` to `mo` ages ago and `ro` was later updated. I wonder if it would actually be better to create `ro-cyrl` for the Cyrillic ones and merge the remaining `mo` things into `ro`? (in most cases we don't have separate variants for different countries, and in the few cases we do, they're really hard to maintain, so I would be in favour of avoiding `ro-md` unless it's really needed) TASK DETAIL https://phabricator.wikimedia.org/T125073 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Fomafix, adrianheine, Aklapper, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T121863: [Story] Allow labels with diacritics to be found when searching using plain ascii
Nikki added a subscriber: Nikki. TASK DETAIL https://phabricator.wikimedia.org/T121863 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Agabi10, Lydia_Pintscher, Aklapper, StudiesWorld, daniel, 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] T122693: Interwiki links block the "link with page" dialog
Nikki added a subscriber: Nikki. Nikki added a comment. I wouldn't really say they're duplicates, although they are clearly related. This ticket is mainly about the popup dialog not working at all when there are local interwiki links (which is annoying and I hope it will get fixed :)). The other ticket seems to be asking for new features like removing local interwiki links (which might be nice, although YiFeiBot is already removing them on a lot of wikis). TASK DETAIL https://phabricator.wikimedia.org/T122693 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Lucie, hoo, Aklapper, SJu, StudiesWorld, 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] T121978: Label of Wikidata item is not changed by rename of the source article
Nikki added a subscriber: Nikki. Nikki added a comment. Automatically updating labels seems quite problematic to me. What happens if the existing label does not match the old page name? What about if the existing label still matches a page name for another project in the same language? How do we know when an alias for the old name should be added? How do we avoid adding disambiguation information to labels? A checkbox would be useful for some people, but people moving pages won't necessarily be familiar with Wikidata's guidelines for labels. TASK DETAIL https://phabricator.wikimedia.org/T121978 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Sjoerddebruin, hoo, Aklapper, SJu, StudiesWorld, 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] T115794: Gadgets and common.js things which touch the statement section do not work reliably anymore
Nikki added a comment. Two more similar reports: https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2015/12#Commons_category_format and https://www.wikidata.org/wiki/Wikidata:Project_chat#Findagrave_not_appearing_as_a_link TASK DETAIL https://phabricator.wikimedia.org/T115794 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Liuxinyu970226, matej_suchanek, StudiesWorld, Mineo, Ricordisamoa, Sjoerddebruin, DSGalaktos, Aklapper, Nikki, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T123828: DuplicateReference gadget on Wikidata does not give the copy link on references on claims anymore
Nikki added a subscriber: Nikki. TASK DETAIL https://phabricator.wikimedia.org/T123828 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Aklapper, Mippzon, StudiesWorld, Wikidata-bugs, aude, Ricordisamoa, Sjoerddebruin, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T74590: [Bug] Monolingual code is missing for Kvensk (fkv), Romani (rom) and Scandoromani (rmg-variant)
Nikki added a comment. What translation is needed and why does it have to be done before the codes can be added? We do need most of ISO 639-3 (if nothing else, so that we can say what a language is called in the language itself). There has to be a better solution than doing requests one by one and waiting months if not years before they can be used... :/ TASK DETAIL https://phabricator.wikimedia.org/T74590 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Nemo_bis, Filceolaire, Ricordisamoa, Aklapper, jeblad, thiemowmde, adrianheine, Luke081515, Wikidata-bugs, aude, Arrbee, KartikMistry, Mbch331, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T74590: [Bug] Monolingual code is missing for Kvensk (fkv), Romani (rom) and Scandoromani (rmg-variant)
Nikki added a subscriber: Nikki. Nikki added a comment. https://phabricator.wikimedia.org/T74126 is the one where we've been collecting requests. Out of the ones listed on these two tickets, goh, kea, lkt, rom, smj, smn and sms are listed on that CLDR page and ett, fkv, lld, koy, rmd, rmg, rmu, sia, sjd, sje, sjk, sjt, sju and tzl are not. ko-kore and sv-fi are also not listed, rmg-variant is not a valid language tag (as far as I'm aware), and sr-cyrl seems to duplicate sr-ec. Of course, that's only the ones that people have explicitly mentioned here, there are plenty of others which are also missing. TASK DETAIL https://phabricator.wikimedia.org/T74590 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Nemo_bis, Filceolaire, Ricordisamoa, Aklapper, jeblad, thiemowmde, adrianheine, Luke081515, Wikidata-bugs, aude, Arrbee, KartikMistry, Mbch331, Krenair ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T122015: Multiple language codes for Northern Sami
Nikki added a subscriber: Nikki. Nikki added a comment. You still haven't answered hoo's question, what are you asking for? "se" and "sme" are equivalent (just different versions of ISO 639) and only mean Northern Sami. Anything labelled as "se" or "sme" when it's not Northern Sami is incorrectly labelled. Whether you use "se" or "sme" is also largely irrelevant, since they mean the same thing and you can't stop things from converting one to the other whenever they want. TASK DETAIL https://phabricator.wikimedia.org/T122015 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, hoo, Aklapper, jeblad, StudiesWorld, 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] T121851: Editing a label gives an error saying another item has the same description when it doesn't
Nikki created this task. Nikki added a subscriber: Nikki. Nikki added a project: Wikidata. Herald added subscribers: StudiesWorld, Aklapper. TASK DESCRIPTION I tried to edit the English label (to remove the bit in brackets) on https://www.wikidata.org/wiki/Q15869633 but it gives an error claiming that https://www.wikidata.org/wiki/Q138280 has the same description, when it doesn't. The exact error message: Item Q138280 already has label "Alaşehir" associated with language code en, using the same description text. TASK DETAIL https://phabricator.wikimedia.org/T121851 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Aklapper, Nikki, StudiesWorld, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T115794: Gadgets and common.js things which touch the statement section do not work reliably anymore
Nikki added a comment. Herald added a subscriber: StudiesWorld. There are more reports of the AuthorityControl gadget not working consistently at https://www.wikidata.org/wiki/Wikidata:Project_chat#Commons_category_format TASK DETAIL https://phabricator.wikimedia.org/T115794 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: StudiesWorld, Mineo, Ricordisamoa, Sjoerddebruin, DSGalaktos, Aklapper, Nikki, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T115552: Allow copying a new reference with the DuplicateReferences gadget without reloading the page
Nikki closed this task as "Resolved". Nikki claimed this task. Nikki added a comment. This seems to be working now. TASK DETAIL https://phabricator.wikimedia.org/T115552 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Sjoerddebruin, Nikki, Aklapper, 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] T115112: Hide deprecated statements by default
Nikki added a comment. I started a new section on the project chat page: https://www.wikidata.org/wiki/Wikidata:Project_chat#The_meaning_of_the_deprecated_rank TASK DETAIL https://phabricator.wikimedia.org/T115112 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: StudiesWorld, Lydia_Pintscher, Mineo, Nikki, Aklapper, Snaterlicious, thiemowmde, adrianheine, Liuxinyu970226, Bene, MGChecker, Ricordisamoa, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T115112: Hide deprecated statements by default
Nikki added a comment. Herald added a subscriber: StudiesWorld. @adrianheine: By the way, a number of people are already using (and telling other people to use) the deprecated rank for redirected identifiers, see for example https://www.wikidata.org/wiki/Wikidata:Project_chat#One_item.2C_two_IMDb_identifier_.28P345.29 and https://www.wikidata.org/wiki/Wikidata:Project_chat#How_to_make_.22unique_value.22_constraint_violations_report_ignore_deprecated_values_.3F - If you think it's semantically wrong, maybe you'd like to start an on-wiki discussion about it. Personally I don't think people will stop using it that way though, unless they're given another way (e.g. another rank) to mark statements as being true but no longer current (it's not just redirected identifiers either, I've also seen people mark historical population values and old software versions as deprecated). TASK DETAIL https://phabricator.wikimedia.org/T115112 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: StudiesWorld, Lydia_Pintscher, Mineo, Nikki, Aklapper, Snaterlicious, thiemowmde, adrianheine, Liuxinyu970226, Bene, MGChecker, Ricordisamoa, 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] T118322: [Story] Merging wizard shouldn't allow dissimilar items to be merged
Nikki added a comment. If there's an ignore option, it sounds fine to me too. The only thing I can think of where it might be a bit annoying is when people add "said to be the same as" to two items which need merging but originally couldn't be merged because of interwiki conflicts - the statements saying the items are the same are the ones which would make the merge fail. That's pretty minor though, since those statements need removing anyway if the items are being merged. TASK DETAIL https://phabricator.wikimedia.org/T118322 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Addshore, Bene, hoo, Ricordisamoa, Nikki, Multichill, Sjoerddebruin, Lydia_Pintscher, agray, I9606, Aklapper, Fnielsen, StudiesWorld, 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] T118230: Incorrect GeoHack URL when coordinates are used as qualifiers
Nikki created this task. Nikki added a subscriber: Nikki. Nikki added a project: Wikidata-Gadgets. Herald added subscribers: StudiesWorld, Aklapper. Herald added a project: Wikidata. TASK DESCRIPTION See https://www.wikidata.org/w/index.php?title=Q4115189=270323178 The main coordinate location statement links 1N 1E to https://tools.wmflabs.org/geohack/geohack.php?language=en=1_N_1_E_globe:earth which works fine The qualifier links 52N 5E to https://tools.wmflabs.org/geohack/geohack.php?language=en=52%C2%B0N,%205%C2%B0E which doesn't work. I would expect the qualifier to link to https://tools.wmflabs.org/geohack/geohack.php?language=en=52_N_5_E_globe:earth TASK DETAIL https://phabricator.wikimedia.org/T118230 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Aklapper, Nikki, StudiesWorld, Wikidata-bugs, aude, Ricordisamoa, Sjoerddebruin, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T117763: Small feature request: recognize bracketed IDs as valid IDs
Nikki added a subscriber: Nikki. TASK DETAIL https://phabricator.wikimedia.org/T117763 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nikki Cc: Nikki, Pigsonthewing, Aklapper, StudiesWorld, agray, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
