Wikidata

Wikidata:Paper cuts/Archive/2015

< Wikidata:Paper cuts

Missing search results edit

Tracked in Bugzilla
Bug 42234

Some times, the search results page doesn't list obvious results, even when the AJAX popup already suggested them. This seems to be the case almost anytime (but not always) when searching for something containing special characters. E.g. if I search for "Röntgendenkmal", the AJAX dropdown lists dotzens of results, but when I click the search button, there are only 23. If I enter "Röntgendenkmal", there are two results suggested (Q2202687, Q2202689), but the result page is empty.

I think this is a problem
  1. --YMS (talk) 17:55, 23 August 2013 (UTC)[reply]
  2. --Izno (talk) 22:50, 23 August 2013 (UTC)[reply]
  3. --Sk!d (talk) 00:41, 24 August 2013 (UTC)[reply]
  4. --Stryn (talk) 06:56, 24 August 2013 (UTC)[reply]
  5. --Jklamo (talk) 13:40, 24 August 2013 (UTC)[reply]
  6. --Pasleim (talk) 14:11, 25 August 2013 (UTC)[reply]
  7. Sometimes it's the other way round. I type 'statehood'. the popup lists 5 pages called 'statehood day' (with no descriptions). I search for 'statehood' and the 'statehood day' results are on the second or third page, lost in a load of Category pages. Filceolaire (talk) 01:04, 26 August 2013 (UTC)[reply]
  8. If I search for "Cibodas, Lémbang, Bandung", it shows me Q12478751, but not Q13198881. This is because one contains special characters. (I will merge these two items eventually, just using them as an example for now). Del♉sion23 (talk) 23:32, 27 August 2013 (UTC)[reply]
  9. Pikolas (talk) 13:43, 31 October 2013 (UTC)[reply]

Look for Labels in other languages edit

Tracked in Phabricator
Task T76150

There are items that have labels in one language but not in another. When entering a value for a property, if the search has zero results, then other language labels should be searched too. For instance Berfull (Q3320306) has a label in Spanish but not in English, when I type "Berfull" in English as a property value the results are zero, at that point other languages should be searched for, which would make the item appear, thus avoiding repeated items.

I think this is a problem
  1. --Micru (talk) 17:13, 23 August 2013 (UTC)[reply]
  2. Agree. There are also a lot of problems with the way we handle closely related (en-gb, en-ca) language labels/settings. Andrew Gray (talk) 18:02, 23 August 2013 (UTC)[reply]
  3. GerardM (talk) 18:58, 23 August 2013 (UTC)[reply]
  4. --Izno (talk) 22:44, 23 August 2013 (UTC)[reply]
  5. --Jklamo (talk) 13:38, 24 August 2013 (UTC)[reply]
  6. --Rippitippi (talk) 23:26, 24 August 2013 (UTC)[reply]
  7. --Jane023 (talk) 09:50, 25 August 2013 (UTC)[reply]
  8. MichaelSchoenitzer (talk) 11:02, 29 August 2013 (UTC)[reply]
  9. --Jcornelius (talk) 22:05, 29 August 2013 (UTC)[reply]
  10. Aurora (talk) 15:09, 30 August 2013 (UTC)[reply]
  11. --Sannita - not just another it.wiki sysop 18:54, 30 August 2013 (UTC)[reply]
Comment

This is unfortunately quite tricky. We'll first need to have the language fallback system in place that liangent is working on as her Google Summer of Code project. --Lydia Pintscher (WMDE) (talk) 13:19, 13 September 2013 (UTC)[reply]

"Jump to: navigation, search" when copying label edit

Tracked in Bugzilla
Bug 54269

When copying the main label of a page (which is often wanted, e.g. for copying it to other languages, to use it to search for duplicate articles, to paste it in discussions, ...), it's likely to get "Jump to: navigation, search <Label>". (This seems to be a browser-specific problem, I could not reproduce it in Opera now, though it's highly likely to happen in Firefox.). If I copy a label from one of my babel language labels, or if I copy a sitelink title, it's likely to copy something like " <Label>", which may be inconvenient to paste somewhere.

I think this is a problem
  1. --YMS (talk) 22:29, 23 August 2013 (UTC)[reply]
  2. --Izno (talk) 22:46, 23 August 2013 (UTC)[reply]
  3. --Sk!d (talk) 00:47, 24 August 2013 (UTC)[reply]
  4. this has happened to me many times --Stryn (talk) 07:05, 24 August 2013 (UTC)[reply]
  5. Ljubinka (discuter) 13:41, 24 August 2013 (UTC)[reply]
  6. -- LaddΩ chat ;) 19:38, 24 August 2013 (UTC)[reply]
  7. --Vyom25 (talk) 06:20, 26 August 2013 (UTC)[reply]
  8. --AndreasPraefcke (talk) 07:36, 1 October 2013 (UTC) Many times, not only in Wikidata.[reply]
Comments
  • I am trying to reproduce this in Firefox but it seems to be working fine for me. Here is what I am doing: Go to an item in English. Select the German label of the item in the babel box. Press Ctrl+C. Same with a sitelink for Wikipedia. All this seems to be working fine. What are you doing differently? This is in Firefox and Chrome. --Lydia Pintscher (WMDE) (talk) 14:21, 13 September 2013 (UTC)[reply]
I use the German user interface and Firefox 23 (on Windows 7, in case that's in any way OS-dependent). If I select the German label with the mouse (not just double-clicking, but click, hold and move from the left to the right, release) and start some pixels before the first letter, I get " Wechseln zu: Navigation, Suche Soennecken" (one space, that useless text, line break, the label) when copying it by Ctrl+C. If I select the English label and also start a bit too far on the left side, I get " Soennecken " (space, tab, label, space). The same for the sitelink titeles.
Like I said, the additional spaces and tabs are not too much of a problem, as at least Wikidata itself trims them if I paste them somewhere else. It does not, however, remove "Wechseln zu: Navigation, Suche" in any case... --YMS (talk) 14:33, 13 September 2013 (UTC)[reply]
Mpfh. I've been trying to do as you described it now for quite a few times. No problem for me in Firefox 23 on Linux. Frustrating. I will ask around in the office for someone else to try as well. --Lydia Pintscher (WMDE) (talk) 14:40, 13 September 2013 (UTC)[reply]
I've had 3 other people test this now and they're also not able to reproduce it :( We must be missing something. --Lydia Pintscher (WMDE) (talk) 14:54, 13 September 2013 (UTC)[reply]
I can reproduce it any time I try, as long as I start to select the text from outside the h1 heading with ID "wb-firstHeading-Q..." (just checked that with the Inspector tool from Firefox Developer Tools). This problem is not exclusive to entity labels, though - in some cases I also can reproduce it e.g. on your user page. There, however, it's much harder too achieve and not just the border of the h1 (I think it's some point in the upper-left corner of the "content" div where I have to start). Occasionally, some users also insert such strings into Wikipedia articles, even before Wikidata times. I failed to reproduce the problem on German Wikipedia, though. --YMS (talk) 14:57, 13 September 2013 (UTC)[reply]
Re-tested on Internet Explorer 9: Here I don't get "Jump to: navigation, search" as a prefix, here I only(!) get "Jump to: navigation, search" when trying to copy the label. However, it's not sufficient to start left of the h1 there, I have to start the selection above the label (which does work imn Firefox also). --YMS (talk) 15:12, 13 September 2013 (UTC)[reply]
Just a few examples of users inserting those strings as labels or descriptions: me, just now, Bullenwächter, Knopfkind, Billinghurst, QuiteUnusual, Thieol, Pyb, IP, IP, IP ... just to show that it's actually a problem for us, and that it's not limited to some really exotic system configuration. (I fixed all those edits, of course.) --YMS (talk) 13:21, 16 September 2013 (UTC)[reply]
No, no. I believe you that this is happening and it's obviously an issue. The problem is that to fix it we'll first need to be able to reproduce it. I'll keep poking people to try. --Lydia Pintscher (WMDE) (talk) 13:53, 16 September 2013 (UTC)[reply]
I think YMS is not doubting you but showing you that problem is widespread and faced by many. Most likely using different softwares and systems.--Vyom25 (talk) 13:59, 16 September 2013 (UTC)[reply]
Yeah, that's correct. Actually I just made that mistake myself (see first diff), then searched for some of those strings and easily found several items that used it, which I fixed. As I now had all those diffs anyway per my contribution list, I thought that it might be an idea to dump them here. It should not translate "Wah, nobody believes me :(". --YMS (talk) 14:05, 16 September 2013 (UTC)[reply]
Hehe alright ;-) --Lydia Pintscher (WMDE) (talk) 14:10, 16 September 2013 (UTC)[reply]
Finally! Denny came back today. He tried this and was able to reproduce it. I've filed it in bugzilla. --Lydia Pintscher (WMDE) (talk) 12:41, 18 September 2013 (UTC)[reply]

Add Qualifier when adding statement edit

Tracked in Bugzilla
Bug 52136

When I want to add a statement with an qualifier to an object, I have to add the statment first, save it without qualifier and then edit it again. The 'add qualifier'-link should be available already when creating the statement.

I think this is a problem
  1. MichaelSchoenitzer (talk) 18:37, 26 August 2013 (UTC)[reply]
    I am not a dev but you can't: for the qualifier you need a claim ID and to have a claim ID you need to have a created claim. So you need 2 steps in the qualifier creation. Snipre (talk) 09:34, 28 August 2013 (UTC)[reply]
    It's not a problem. It all depends on the API, it's just parameters to a call. You can have a way to pass the future property and the future qualifier on one step and let the server do the two step itself. Or do the first step and immediatly propose dynamically the possibility to do the second step in the UI. It's no problem.
  2. Nice interface enhancement, database manipulations can be boring and wanting to through your computer by the window, so we need those kind of enhancements. TomT0m (talk) 12:49, 28 August 2013 (UTC)[reply]
  3. --Jklamo (talk) 13:00, 28 August 2013 (UTC)[reply]
  4. --Sannita - not just another it.wiki sysop 18:57, 30 August 2013 (UTC)[reply]
  5. We expect casual wikipedia editors to be able to add sources but this won't happen unless this is sorted. They need to be able to see all the boxes. Filceolaire (talk) 21:40, 30 August 2013 (UTC)[reply]
  6. AVRS (talk) 14:46, 30 September 2013 (UTC)[reply]
  7. — Ayack (talk) 16:29, 16 October 2013 (UTC)[reply]
  8. Pikolas (talk) 13:39, 31 October 2013 (UTC)[reply]
  9. --Micru (talk) 23:43, 25 November 2013 (UTC)[reply]
  10. Izno (talk) 22:55, 27 November 2013 (UTC)[reply]
  11. --geraki talk 08:43, 9 April 2014 (UTC)[reply]
  12. seems to be working as requested now :) - thanks --Hsarrazin (talk) 09:31, 25 April 2015 (UTC)[reply]

Treat same date in different calendars as different values edit

Tracked in Bugzilla
Bug 59766

Same date but in different calendars is treated as same value. Saving is disabled.

I think this is a problem
  1. EugeneZelenko (talk) 14:21, 28 October 2013 (UTC)[reply]
Comment
For Russian Empire (and probably other countries) topics dates in Julian calendar are necessary. Infoboxes display dates in both calendars, but it's necessary to indicate such presentation. Bots often import date in Gregorian calendar. Changing calendar is not possible because date is same.
Date recalculation to different calendar functionality in Wikidata GUI is better solution, but will require more efforts to implement.
EugeneZelenko (talk) 14:21, 28 October 2013 (UTC)[reply]

Unknown language edit

Tracked in Bugzilla
Bug 36430

If an item doesn't have a label in my selected language, a label from a fallback language is displayed. Great, but there is no indication what language it's from, or even that it's not from "my" language.

I think this is a problem
  1. --YMS (talk) 17:55, 23 August 2013 (UTC)[reply]
  2. --Izno (talk) 22:49, 23 August 2013 (UTC)[reply]
    To expand on this problem, Special:Search without a fallback language present pulls up (No name) (QNNNNNNNNN), which is fine. When the fallback language is present, the output is "FallbackName" (QNNNNNNNN), when in my mind it should be (No name) (QNNNNNNNNN) - FallbackName FallbackLanguageCode. Or something like that. --Izno (talk) 22:49, 23 August 2013 (UTC)[reply]
  3. There should be a small language code if there is a label in a fallback language shown. --Sk!d (talk) 00:39, 24 August 2013 (UTC)[reply]
  4. As above. --Stryn (talk) 06:55, 24 August 2013 (UTC)[reply]
  5. --Vyom25 (talk) 11:21, 24 August 2013 (UTC)[reply]
  6. Ljubinka (discuter) 13:37, 24 August 2013 (UTC)[reply]
  7. --Jklamo (talk) 13:40, 24 August 2013 (UTC)[reply]
  8. --Littledogboy (talk) 10:05, 27 August 2013 (UTC)[reply]
  9. Aurora (talk) 15:11, 30 August 2013 (UTC)[reply]
  10. --AVRS (talk) 15:17, 30 September 2013 (UTC)[reply]
  11. GerardM (talk) 08:43, 22 October 2013 (UTC)[reply]
Comment

Right. We'll need to look at this again when liangent is finished with her Google Summer of Code project. --Lydia Pintscher (WMDE) (talk) 13:24, 13 September 2013 (UTC)[reply]

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Paper_cuts/Archive/2015&oldid=1102157232"