Wikidata:Contact the development team/Archive/2014/02

From Wikidata
Jump to navigation Jump to search

Wrong display of year

Tracked in Bugzilla
Bug 59766

It has been noticed on the Project chat in French and on the Hungarian WP technical Village Pump that this version of a WD element displays year 1557, though the data entered was 1558, which is the correct value (month and day unknown), of course in the Julian calendar used at this time. The 1st of January 1558 in our Gregorian calendar is in the Julian calendar about 10 days earlier in december 1557, but anyway something is wrong either in the display or in the way the data could be entered. This WD element has been fixed as 1558 Gregorian but this is not quite satisfactory since sources implicitly use Julian calendar for this time, and the problem may be present in other elements too. Oliv0 (talk) 13:40, 25 January 2014 (UTC)

Thanks. I will look into it some more but to be honest I currently have a hard time understanding the issue. Someone else around with more knowledge of calendar systems? --Lydia Pintscher (WMDE) (talk) 10:10, 26 January 2014 (UTC)
Simply, if the given date is specified without day or month, we must not display them in Julian system. For example if I enter "february 2014", I mean "1-28 february 2014", but WD stores "1 february 2014" and hides "1". But 1 february in Julian calendar is january, which is likely not correct. --BáthoryPéter (talk) 08:28, 28 January 2014 (UTC)
Have you had time to understand and report the issue? Oliv0 (talk) 22:28, 3 February 2014 (UTC)
I understood the issue now. This should be bugzilla:59766. --Lydia Pintscher (WMDE) (talk) 12:13, 7 February 2014 (UTC)
Thank you, I mention the bug number on the corresponding chat pages. Oliv0 (talk) 13:16, 7 February 2014 (UTC)

Bug

I've noticed that some longer pages are slow to load after the update today. Such pages are loaded without any text input boxes, source show/hide functions and items in claims are not hyperlinked (somewhat similar to the interface when javascript is disabled). I've tried opening the same page (Tongzhi Emperor (Q318811)) on Firefox and Chrome, and both have the same problems. --Wylve (talk) 15:05, 31 January 2014 (UTC)

Nevermind, that doesn't happen anymore. -Wylve (talk) 09:59, 1 February 2014 (UTC)

Local storage of pre-parsed entitiy objects

While playing a little bit with API and Ajax calls, I've been astonished fromm the complexity of the result of a single getEntity call; and many properties are simply otheir entities, each of them deserving another heavy call to be parsed and converted into human-readable and language-specific data.

This complexity explains, IMHO, why is so long to open here the page of any entity: I presume, it's really a heavy server work to get a simple and light result; since all the data (human usable) could be wrapped into a small JSON object if properties only are considered.

My question is: could be these small JSON objects pre-parsed and collected into local, language-specific repositories (wikipedia sites being IMHO the best candidates)? They will not be perfectly updated, but this is a common issue with many other cached data, and the issue could ne solved by some on demand purging call. To build a "local container" for such JSON data could encourage too, IMHO, the development of standard tools to read and parse them, and could encourage local projects do standardize their own data using read-only, wikidata-produced objects as a good model. Presently I can count half-a-dozen different styles to store local data. --Alex brollo (talk) 16:23, 4 February 2014 (UTC)

We are working on fixing this. Distributing the data is not the way to go however. It'd just create a whole load of new issues. --Lydia Pintscher (WMDE) (talk) 12:07, 7 February 2014 (UTC)
Thanks Lydia, Ricordisamoa just gave me a link to page about DWAP principle... so I'll. do. :-) --Alex brollo (talk) 13:26, 7 February 2014 (UTC)

Quantity precision

There seems to be consensus that the precision by default for integers should be zero (or no precision if that was possible) rather than one: see Wikidata:Project_chat#Precision_by_default.

Also, perhaps it is already known but when I change to a precision precision in the population of Singapore (Q334) (I can change the rest of the statement if I wait for long enough). --Zolo (talk) 07:21, 8 February 2014 (UTC)

Yeah we will definitely have to improve that. It's on my list. --Lydia Pintscher (WMDE) (talk) 18:17, 10 February 2014 (UTC)

IP reported problem

Today one IP reported a problem with text, see [1]. I don't know whether it is related with Wikidata and whether it's true, so I posted it here. Matěj Suchánek (talk) 17:31, 10 February 2014 (UTC)

I see the issue. This might however be an issue of the font not supporting those characters? Anyone here who knows more about the script? --Lydia Pintscher (WMDE) (talk) 18:22, 10 February 2014 (UTC)

Search result limit

Tracked in Bugzilla
Bug 61021
Resolved fixed

Since a few days, it's no more possible to get search result pages with more than 500 results using the limit=xxx parameter. That's especially annoying as the ranking of the search result changes when using the pagination. So if I go to page 2 of the search result, I am likely to see again some of the results from page 1, and therefore probably missing other ones that moved to some other page. Is this taking so many resources that it has to be turned off? (I use large search result pages a lot, especially as it's not possible to narrow your search e.g. on the English descriptions. So if you search for a certain English description, you will get tons of results where your search term is in the English label, the French description, Spanish sitelinks and so on. Or if you'd like to search for all items that are related to e.g. the Rolling Stones to check for possible duplicates, you'd like to have all results on one page for a better overview.) --YMS (talk) 09:56, 1 February 2014 (UTC)

This might be something the Foundation changed recently when working on Cirrus Search. I will bring it up with the right people. --Lydia Pintscher (WMDE) (talk) 13:01, 3 February 2014 (UTC)
I just stumbled upon the regarding change: [2]. So it's nothing specific with Wikidata. It would be nice if you could address it anyway. You don't need to mention that "5000 search results in a single page is too many to be useful" is the most idiotic commit message I've ever heard, though. --YMS (talk) 20:14, 6 February 2014 (UTC)
I've brought it up in the call last night and was asked to report a bug. It's at bugzilla:61021. --Lydia Pintscher (WMDE) (talk) 12:06, 7 February 2014 (UTC)
Thank you very much, Lydia. --YMS (talk) 12:59, 8 February 2014 (UTC)

The change has been reverted. So thanks again, Lydia, and also Ricorisamoa and of course Chad. --YMS (talk) 12:04, 12 February 2014 (UTC)

Bug or error?

I'm trying to change Q4167836 labels with labels tool but it don't work and if you see item history I think there are errors --Rippitippi (talk) 03:37, 26 January 2014 (UTC)

I unfortunately can't see what the issue was from the history. --Lydia Pintscher (WMDE) (talk) 10:15, 26 January 2014 (UTC)
The issue is that I can't change label, and in history you can see partial restore, db error --Rippitippi (talk) 16:37, 26 January 2014 (UTC)
Other problems with Q4167836 are discussed above. -- Lavallen (talk) 17:12, 26 January 2014 (UTC)
And I want to add a statement to this......--GZWDer (talk) 04:47, 27 January 2014 (UTC)

up --Rippitippi (talk) 13:46, 3 February 2014 (UTC)

Has one of you tried restoring the version of Dec 27th? --Lydia Pintscher (WMDE) (talk) 12:11, 7 February 2014 (UTC)

No --Rippitippi (talk) 05:38, 11 February 2014 (UTC)

Wikipedia Watchlists

Hi, on a chat on french WP ( fr:Wikipédia:Sondage/Wikidata Phase 2‎ ) a fair number of users are concerned about modification tracking. They seem OK with tracking throught Wikipedia watchlist, but have a number of concerns:

  1. The possible flood with datas that are not really used in the article
  2. The lack of details there is now.

I personaly am quite confident that both points will get better when performance issues will be solved to use other data items, but it's a littlé short to answer the concern, could Lydia tell here what is going on, so we have a formal link to put in those discussions ? TomT0m (talk) 13:35, 9 February 2014 (UTC)

I do want to improve this because the trust in our data by the Wikipedians is obviously crucial. My issue is that I am not sure what exactly they'd like to see. So if we could gather some input on this that'd be ideal and move this forward. --Lydia Pintscher (WMDE) (talk) 18:19, 10 February 2014 (UTC)
Hi, requests from O.Taris (I translate) :
We should be notified in the Watchlist of all modifications wikidata that impacts a followed wikipedia article, and only those one. To achieve that, if we follow article X in Wikipedia, we should be informed by watchlist :
  • of the change of a a data of the wikidata item X if and only if a is actually used in the Wikipédia article on X ;
  • of the change of a b date on the item Y if and only if b is actually used in an article on another X topic.
[snip he thinks that's not possible - I reply it will be probably possible when we will be able to use any data in the article because you will implement some kind of data usage tracking] TomT0m (talk) 22:00, 10 February 2014 (UTC)

Hi, there are similar issues on german and english WP. [3][4][5] There are 3 levels to the problem:

  • 1) "show wikidata" on WP watchlist doesn't actually show wikidata changes. Doesn't work on deWP and enWP. Or maybe sometimes it does show and sometimes not. Or it works for some users and others not? "show wikidata" does work on WP recent changes though, it seems.
  • 2) "show wikidata" floods the WP watchlist / recent change with cryptic changes.
    • the wikidata edit comment shown on WP is quite useless, it's either "The wikidata object was changed" or "2 changes" (or 3, 4, etc.). You have to click on the diff to find out more on wikidata. And I really don't care if some wikidata label was changed in 1 of 250 languages - and since i feel like 99% of those "wikidata changes" are not relevant, i don't bother to click on those diffs.
    • The wikidata history shows better edit comments, a little less useless:
  • Goldzahn (talk | contribs)‎ . . (11,457 bytes) (+284)‎ . . (‎Created claim: Property:P1101: 77±1) (undo | thank) (restore)
  • OC Ripper (talk | contribs)‎ . . (11,173 bytes) (+74)‎ . . (‎Added link to [shwiki]: Chrysler Building) (undo | thank) (restore)
  • KrBot (talk | contribs)‎ . . (11,099 bytes) (+141)‎ . . (‎Added reference to claim: Property:P227: 4390482-8) (undo) (restore)
  • Legobot (talk | contribs)‎ . . (10,958 bytes) (+393)‎ . . (‎Added reference to claim: Property:P646: /m/01zmd) (undo) (restore)
But to understand those wikidata changes, I would still need to learn by heart what Property:P1101 is (and thousands of other properties) or click through to wikidata? That should be easier to understand. Those wikidata changes would still be too many for my watchlist convenience (wikidata bots!).
  • 3) "show relevant wikidata" (similar to requests from O.Taris above) meaning: show only changes of wikidata that is used in the WP. Most important example now: if the interwiki is removed/vandalised on wikidata. Or maybe in the future, coordinates from wikidata, etc.

Another 4th issue is flagged revisions. German Wikipedia reviews changes to commons-files that are included in WP articles [6]. A vandalised image isn't immediately shown live on deWP, a trusted user has to review the change. This could be a model for wikidata inclusion on deWP. Best, --Atlasowa (talk) 10:23, 13 February 2014 (UTC)

sk:Prometheus (časopis) is present in both Q12774688 and Q13538701. How is this possible and how should it be fixed? It's the first time I see something like that. --Canyq (talk) 05:47, 12 February 2014 (UTC)

It sporadically happens, see Wikidata:True duplicates. --YMS (talk) 06:56, 12 February 2014 (UTC)
I wasn't aware of that. Thank you very much for the info. --Canyq (talk) 16:02, 12 February 2014 (UTC)

Thought on the automated move function

(I hope this comes out sounding intelligible.) This may be a nice-to-have...

On the client, when a page is moved, Wikibase (usually) updates the local link here to point to the new location. What would be nice is, if the item's previous title in the language of the affected page matches the previous article's title, that the item's title in that language also be changed.

For example, a number of ship class items right after import into Wikidata went from (on enwiki) "classname class type" to "classname-class type". On Wikidata, their title had been imported as "classname class type", and this was not updated when the pages on the client were moved.

Thoughts? --Izno (talk) 15:08, 12 February 2014 (UTC)

This sounds like an option. However if pages are moved to disambiguate (for example from "Berlin" to "Berlin (Album)") then the label shouldn't change to that. --Lydia Pintscher (WMDE) (talk) 15:16, 12 February 2014 (UTC)
I think that might provide too many false positives to consider—there are more than a few pages with params as part of the article title. Hmm…. --Izno (talk) 16:09, 12 February 2014 (UTC)

Deleted item still in search results

I found that deleted item Q9028640 can be found still in search results (try). I don't know is it related to Wikidata, MediaWiki or CirrusSearch. --Stryn (talk) 19:59, 16 February 2014 (UTC)

I've reported it at bugzilla:61464. The search guys are usually very responsive so I expect a comment there soon. --Lydia Pintscher (WMDE) (talk) 14:47, 17 February 2014 (UTC)

To edit a number datatype

RE:[7] When I edit a number datatype with the GUI, the number is in the UI written like 6 627 (it's the normal format in Swedish), but I cannot save after I have changed it to the value I desired (6 618). This since the UI does not accepts any spaces when I save. I have to remove the space between the two sixes. This is very natural, but why is there a cosmetic space in the number when I edit in the first place? -- Lavallen (talk) 08:22, 22 February 2014 (UTC)

Thanks. I can reproduce it. Will file a bug after lunch. --Lydia Pintscher (WMDE) (talk) 11:53, 25 February 2014 (UTC)
It's now at bugzilla:61911. --Lydia Pintscher (WMDE) (talk) 14:45, 25 February 2014 (UTC)

@Lydia Pintscher (WMDE): Now it looks even worse. Now I sometimes read 6 618 and that is even worse to edit. -- Lavallen (talk) 06:57, 26 February 2014 (UTC)

Ewwww! I've raised the importance of the bug and left a comment. I hope Adam can have a look at it today. --Lydia Pintscher (WMDE) (talk) 07:44, 26 February 2014 (UTC)

Page move logged as 127.0.0.1 edits in AbuseLog

See [8]. And these edits don't get tagged.--GZWDer (talk) 14:49, 25 February 2014 (UTC)

bugzilla:57815 --Lydia Pintscher (WMDE) (talk) 14:54, 25 February 2014 (UTC)

Label in the old version shows always the current label

If I change a label in some item, then I can see the same label also when I look at the old version. E.g. here English label is at the moment "Sandbox", but if I change the label now from "Sandbox" to some other, then also that label on the old version has updated. Is it a bug? --Stryn (talk) 16:05, 26 February 2014 (UTC)

Jep. I'd say that's a bug :D I don't know how easy it is to fix it. I've filed it as bugzilla:61954. --Lydia Pintscher (WMDE) (talk) 16:24, 26 February 2014 (UTC)
We do have pretty much the same behaviour in much more basic parts of MediaWiki. For example, an old version of a Wikipedia article includes the current revisions of all images and templates used, replaces all magic words with their current value and colors the link according to the current existence of those other pages. Sometimes this is confusing, sometimes it would be confusing if it would be the other way round. And without a proper "time machine" integrated into MediaWiki, such a "look back" would always be a quite random snapshot anyway (e.g. if item A is named "A" on day 1 when it's linked from item X (version 1), but renamed to "B" on day 2, while the next change on item X (version 2) is on day 30, what label should version 1 of X show on day 31? "A", as it was when version 1 was created, or "B", as it was most of the time of version 1's existence?). --YMS (talk) 16:47, 26 February 2014 (UTC)
Right. I think those cases you mentioned are a bit different though from the label/title of an item. --Lydia Pintscher (WMDE) (talk) 17:10, 26 February 2014 (UTC)

Rydaholm (Q2577791)

Does the source to the P131-statement look correct to you in the UI? I read only "stated in (P248):        ", until I edit. -- Lavallen (talk) 09:32, 26 February 2014 (UTC)

It does look fine here, yes. Have you tried purging the page? --Lydia Pintscher (WMDE) (talk) 10:11, 26 February 2014 (UTC)
Looks fine for me, too. However, when I add some new value anywhere, today for a second, this new value is not displayed. I also see that you added this source yourself, so maybe this is the same effect (with your second probably being a bit longer ;)). --YMS (talk) 17:15, 26 February 2014 (UTC)
One day long, I added this yesterday, and removed the "imported from" today. And I can see others on WD:PC having the same kind of problem in different places. -- Lavallen (talk) 18:53, 26 February 2014 (UTC)
@Lavallen, YMS, Lydia Pintscher (WMDE): I found the same problem. see subgenus (Q3238261).--GZWDer (talk) 11:17, 27 February 2014 (UTC)
I can reproduce it now. We're looking into it. --Lydia Pintscher (WMDE) (talk) 11:22, 27 February 2014 (UTC)
We found the issue and have a patch. Waiting for deployment. Hopefully out today or tomorrow. --Lydia Pintscher (WMDE) (talk) 16:39, 27 February 2014 (UTC)
A fix was deployed last night. --Lydia Pintscher (WMDE) (talk) 10:00, 28 February 2014 (UTC)

Multiple sources are not always shown

Sometimes multiple sources are not shown: only first one is complete, others doesn't show value. I observed thin on sex property on Q60584 and other items. I use Firefox 27 on Windows 7. Seems that this happened after last update. --EugeneZelenko (talk) 15:57, 27 February 2014 (UTC)

See two above :) --Lydia Pintscher (WMDE) (talk) 16:40, 27 February 2014 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Contact_the_development_team/Archive/2014/02&oldid=114634537"