Wikidata:Contact the development team/Archive/2013/09

From Wikidata
Jump to navigation Jump to search

Wikidata map not loading

I've been using the Wikidata map to correct some wrongly imported coordinates, but it suddenly stopped working...--Micru (talk) 18:24, 30 August 2013 (UTC)

Yeah something broke 2 days ago with the analysis. Denny is investigating but doesn't yet know what is wrong. --Lydia Pintscher (WMDE) (talk) 11:14, 3 September 2013 (UTC)

Translation extension

Tracked in Bugzilla
Bug 46716

Whenever a new page is available for translation and all parts are translated, there is allways one part left over in the statistics to translate. However all pages are translated and you can not access the missing page as it is reported. The same happens as a page is updated by fuzzybot. If there is only one section to be updated and you save the new translation, there is still one section left over for translation reported in the statistics. It does not matter how often you reload the page or if you wait some days. The only way to resolve the problem is to open one of the sections of the page, ad a charakter, delete it and save it again (nulledit). You can not save it unless you changed something in the section. After that hit the reload button and then the statistics are updated properly and all sections are marked as translated. If you do all the translations + a nulledit to an allready translated section it also has no effect and still the wrong information is shown in the language statistics. You must make the nulledit after you have translated and reloaded the page.--Giftzwerg 88 (talk) 00:37, 2 September 2013 (UTC)

I don't think the Wikidata developers can do anything about this since it is caused by the translate extension, not Wikidata. However, the bug has been reported on Bugzilla. The Anonymouse (talk) 17:52, 2 September 2013 (UTC)
Thank you. --Giftzwerg 88 (talk) 09:21, 3 September 2013 (UTC)

reordering properties?

Is there a way to reorder properties? Sometimes the date of birth is after date of death and so on. One way is to edit the source code, the other way is to use a filter which reorders all properties to a predefinded order each time a property is added. A predefined order makes overview for human readers more easy and avoids double properties by overlooking existant entries. --Giftzwerg 88 (talk) 09:39, 3 September 2013 (UTC)

It's being worked on. Please subscribe to bugzilla:44678 if you want to be kept up-to-date on the progress. --Lydia Pintscher (WMDE) (talk) 11:06, 3 September 2013 (UTC)

continent (P30) with English GUI: edit mode for alias active

Tracked in Bugzilla
Bug 53337

Somehow this page appears in edit mode for the alias .. I need to click "cancel" first. It doesn't seem happen with new properties w/o alias. --  Docu  at 15:45, 24 August 2013 (UTC)

This edit might have caused it. --  Docu  at 15:47, 24 August 2013 (UTC)

Strange... Thanks for the note. I've reported it as bugzilla:53337. --93.220.81.151 09:45, 26 August 2013 (UTC)
I have fixed Property:P30 for now by doing this and this. After a bug fixed a few week or so ago it is now impossible to add empty aliases so this particular problem should no longer exists. ·addshore· talk to me! 08:22, 27 August 2013 (UTC)
Fixing that property is easy, but I wonder if it was empty or if there was just some control character. --  Docu  at 16:49, 27 August 2013 (UTC)
It was empty in the database dump.
I made a small change (so small that I forgot to change the headings) to the code that generates User:Byrial/Long texts so it now also lists all empty labels, descriptions and aliases for items and properties. Byrial (talk) 17:53, 29 August 2013 (UTC)
Not sure if property descriptions can be too long. Maybe it should rather list those that are too short, e.g. less than 50 characters. --  Docu  at 05:30, 4 September 2013 (UTC)

Red error messages for coordinates

Tracked in Bugzilla
Bug 53391
Tracked in Bugzilla
Bug 53520

Here and there some error red messages seem to appear on items with coordinate location (P625). Given that edit histories don't tell much about coordinates, I can't say if they were wrong before or if the error message just appeared through other edits to the items.

In any case, it might be worth adding these items into a maintenance category. --  Docu  at 04:13, 27 August 2013 (UTC)

Could you provide a link to one of the items? ·addshore· talk to me! 08:17, 27 August 2013 (UTC)
I have found one here. This is due to the coordinate value being out of a specified range as the error suggests. Patching now! ·addshore· talk to me! 08:59, 27 August 2013 (UTC)
Another one is at http://www.wikidata.org/wiki/Q711 probably caused by http://www.wikidata.org/w/index.php?title=Q711&diff=51486201&oldid=50258670 --Lydia Pintscher (WMDE) (talk) 10:31, 27 August 2013 (UTC)
Just for the record, this was fixed on Tuesday. The precision parameter in the globecoordinate datavalue can be null again, so that there are no issued with resaving any claims in wikidata that have null precision. It is discouraged for new data to set precision to null and it probably will become required again at some point (with improved backwards compatibility). There were 641 affected items that had their datavalue type set to "bad" instead of "globecoordinate" because the software failed to "parse" them on re-save. In my non-working time, I had my bot change the affected geocoordinate claims from data value type = " bad" back to data value type = "globecoordinate". This fixed the affected items. Aude (talk) 06:49, 29 August 2013 (UTC)
But there is about 18000 coordinate values without proper indication of the globe. If I understood things correctly, they will be changed from data value type "globecoordinate" to "bad" at next edit to the items.
I hope these 18.000 coordinates are not lost? Many of these are imported by my bot, there were no errors in the format in the past, except that the globe was not specified (empty) since the default 'Earth' was accepted. Can someone correct these coordinates, or make the empty globe parameter by default earth? Michiel1972 (talk) 08:52, 30 August 2013 (UTC)
Nothing is lost :) All of the data is still there! ·addshore· talk to me! 16:36, 3 September 2013 (UTC)
There is a report with some of them at Wikidata:Project_chat#Database_errors. --  Docu  at 20:52, 3 September 2013 (UTC)

User on the Finnish project chat wrote that it's not possible to edit/add links on Wikidata. User also deleted all gadgets, but it didn't helped. Also when s/he is logged out, it's not possible to add links. Another user on the Finnish Wikipedia told about the same problem. --Stryn (talk) 21:24, 1 September 2013 (UTC)

And the problem seems to be with IE 8, works with IE 9. --Stryn (talk) 14:44, 2 September 2013 (UTC)

Same problem reported here at least two times before this where users can't contribute while logged in and can do it while logged out.--Vyom25 (talk) 17:27, 2 September 2013 (UTC)
See here and here.--Vyom25 (talk) 17:31, 2 September 2013 (UTC)
I know, but I thought that those problems were fixed already. By the way, user told that this problem started just few days ago. --Stryn (talk) 17:35, 2 September 2013 (UTC)
Especially after second discussion where several users pointed to it I also thought it was solved. And yeah in first discussion the problem also started afterwards not straight away.--Vyom25 (talk) 19:44, 2 September 2013 (UTC)
We unfortunately don't know what's wrong there. Resetting the preferences seems to help. If anyone knows which preference is causing the issue please let me know. --Lydia Pintscher (WMDE) (talk) 12:40, 8 September 2013 (UTC)

uselang? not working when using special:itemByTitle

For example I would have expected this link to set the user interface language, generated by a template on french Wikipedia. Is it expected behavior, a bug, or is there another way to do the same thing which would respect the user choices in any case ? (doing this would force the interface in french ...) TomT0m (talk) 14:08, 2 September 2013 (UTC)

I guess the bug here is that &uselang is not passed on by the redirect, but I'm not sure that it should be. Maybe you want to use &setlang=fr? Legoktm (talk) 07:05, 3 September 2013 (UTC)
Oh thanks, that works. Out of curiosity, what's the difference ? uselang is temporary and setlang is not ? TomT0m (talk) 11:35, 3 September 2013 (UTC)
Yes, exactly. uselang is only applied whenever you have that in the url, whereas setlang actually modifies your preferences. Legoktm (talk) 12:00, 8 September 2013 (UTC)

Undo error

While trying to undo this edit (addition of (incorrect) [ru] alias) i get this error message: * A length constraint is triggered for language code "hi". * A length constraint is triggered for language code "ckb". * There is a constraint violation for description "विकिमीडिय...; له‌ به‌ریتانیا..." for language code "hi; ckb". --Jklamo (talk) 16:42, 2 September 2013 (UTC)

This means the description in that language is too long. Switch to the language and remove it (or use the label lister gadget to make it easier). Then you can add the language you want. Sorry this is causing issues. I just checked the history and this long description shouldn't have been possible to add. I will investigate further. Thanks for the hint. --Lydia Pintscher (WMDE) (talk) 11:04, 3 September 2013 (UTC)
OK, but why i am unable to edit description in "ru" while error is in "hi" and "ckb"? And why later edits of another users of en description and revert itself were possible (and still these long "hi" and "ckb" descriptions are not fixed)? --Jklamo (talk) 16:49, 3 September 2013 (UTC)
The length restrictions are currently checked when entering new data so that is why you get the error. The reset probably was possible because the length constraint isn't checked on rested to an older revision. --Lydia Pintscher (WMDE) (talk) 12:44, 8 September 2013 (UTC)
BTW isn't the limit for Russian for example too short? Littledogboy (talk) 15:35, 6 September 2013 (UTC)
It might be. It'd be useful to get some feedback from the Russian users. --Lydia Pintscher (WMDE) (talk) 12:44, 8 September 2013 (UTC)

Century-precise dates in French

Hello,

When we have a date that is only precise to the century level (eg RandomRomanCitizen was born in the 1st century and dead in the 2nd), dates appear as "1. Century", "2. Century in French, it should be "1er siècle", "2e siècle" and so on. -Ash Crow (talk) 23:29, 15 August 2013 (UTC)

Please provide a link to an example so I can have a look at it in detail. --Lydia Pintscher (WMDE) (talk) 16:38, 16 August 2013 (UTC)
I can find 66 time values with precison = century in the latest database dump. Examples: Q25445 (137th c. BC), Q42887 1st c., Q72 (15th c., qualifier (takes very long time to load at my computer)) Q3204226 (18th c., qualifier), Q4503364 (16th c., source (mistake which should be corrected). Byrial (talk) 17:32, 16 August 2013 (UTC)

This issue was raised three weeks ago. Why is there no answer from the development team? We've come to the point where "we don't care about French, get lost" would be a better answer than this. Ljubinka (discuter) 08:08, 8 September 2013 (UTC)

I'm really sorry about this. It simply slipped through while I was super busy :( I checked this now and the same issue happens in German. It might be that we didn't make it translateable in the source code. I filed bugzilla:53910 so someone checks this. --Lydia Pintscher (WMDE) (talk) 12:58, 8 September 2013 (UTC)
Thank you. Please note that this is not only the word "century", but also the way ordinal numbers are written (in French it is for example "18e" and not "18."), and "BCE" should also be translated. An option to use Roman numerals would also be a good localization practice: while they are (if I am right) never used for centuries in German, most French writings do use them - but some people don't like them, so being able to choose would be a good thing. Ljubinka (discuter) 13:06, 8 September 2013 (UTC)

Same for italian --Rippitippi (talk) 13:42, 8 September 2013 (UTC)

Year-less dates

Could we define a datetime without specifying the year, to indicate it's recurring, as "Magnus Manske Day (Q10995651) → 25 January"? --Ricordisamoa 02:22, 30 August 2013 (UTC)

What about make separate property Day which could link to items like February 30 (Q37096). This property should be useful for feasts, names and famous days. JAn Dudík (talk) 06:10, 30 August 2013 (UTC)
There is a property proposal for periodic occurrences. Is that what you mean? The problem of this property is that it is not really searchable (it won't show up when looking for events on a certain event that happens every year). One possible solution could be to fill up items like February 30 (Q37096) with "points in time", but maybe that is too much of a hack...--Micru (talk) 18:31, 30 August 2013 (UTC)

I think we already have an item for each of these 366 days. We also have already got 355 items for the days in the arabic year (though these items only have articles in Arabic and Farsi). We can create items for all the "third tuesday in march" type dates, though it will be interesting to think up what properties are needed to be able to convert these to dates in particular years (day of week; earliest date; latest date?). We also need items for each day in en:Lent, from Mardi Gras to Easter sunday - about 50 items. Items for each day in a lunar cycle might be useful for something too - 29 items. No datatype needed. Filceolaire (talk) 19:57, 30 August 2013 (UTC)

I remember adding this somewhere... where was that... oh, here Q2723440. It seems to work...? Littledogboy (talk) 20:49, 30 August 2013 (UTC)
I am afraid, that there is august in year 19 JAn Dudík (talk) 20:58, 30 August 2013 (UTC)
Oh, stupid me. Thank you JAn. Littledogboy (talk) 14:10, 9 September 2013 (UTC)

Wikidata:Property_proposal/Event#day_in_year_for_periodic_occurrence is a proposal for a property to link to these items for the various days. If this is approved then we can have the statement

World Humanitarian Day (Q2723440) -> 'day in year' -> August 19 (Q2829) Filceolaire (talk) 21:02, 31 August 2013 (UTC)

Maybe we could use an additional time/date-based datatype which could work as the string described at WD:Property_proposal/Event#Reoccurring_date_in_machine_readable_format. --  Docu  at 06:15, 3 September 2013 (UTC)

I don't suppose it would be possible to set the default user signature to just transclude a system message for the talk link, so that it would just show the word "talk" in whatever the viewer's language is? The current system is quite a mess, where a Hebrew-speaking user's signature on an entirely Hebrew discussion page shows the English word "talk" when being viewed by a person whose user language is set to Hebrew. Sprinkling bits of English across the site like this is quite problematic. (The signature date has the same problem, though I imagine that that would be rather harder to fix.) --Yair rand (talk) 13:40, 3 September 2013 (UTC)

Is the system Commons: any better ? Then I suppose we could simply implement the solution suggested by user:Slomox on MediaWiki_talk:Common.js#localize talk links in signatures. --Zolo (talk) 13:59, 3 September 2013 (UTC)
That would require modifying the default signature anyway, as we don't have a special span with the class "signature-talk" around every talk link here. If we're already modifying it, it would be kind of ridiculous to just change it to a special JS-based localizing system when we could just use a system message to have the text localized on the server side. --Yair rand (talk) 14:18, 3 September 2013 (UTC)
Ohh, I always thought everbody here was so fond of talc (Q134583), that they had put it in their signature by choise! :D -- Lavallentalk(block) 14:30, 3 September 2013 (UTC)
Huh, it actually looks like this can be accomplished just by editing MediaWiki:Signature. Any objections to replacing the content of that page with [[{{ns:user}}:$1|$2]] ([[{{ns:user_talk}}:$1|{{nosubst/open}}int:Talkpagelinktext}}]]) ? (Thanks to MatmaRex for use of his test wiki to figure this out :) ) . --Yair rand (talk) 21:03, 8 September 2013 (UTC)
Will maybe work, but is it possible to modify the details in talk? - The Swedish version: "Diskussion" takes more space than I like. "disk" would be enough as an abbr, look at svwp, it works well there. -- Lavallentalk(block) 14:39, 9 September 2013 (UTC)
Certainly possible (Mediawiki:Talkpagelinktext/sv), though this would also affect the display of talk links on pages like Special:RecentChanges. Note that "disk" is not the default signature talk link for Swedish wikis. The Swedish Wikipedia specifically changed it, and other Swedish wikis have the full word spelled out. --Yair rand (talk) 14:48, 9 September 2013 (UTC)
Would look fully understandable in RC too. WP is the only sv-project with a larger amount of contributions. I myself is active on Wikisource too, but there are not so many "diskussioner" to worry about. -- Lavallentalk(block) 15:09, 9 September 2013 (UTC)
Okay. ✓ Done. The change is easily revertible without problems, in case anyone objects later on. --Yair rand (talk) 15:21, 9 September 2013 (UTC)
I've made the change, and it seems to work. --Yair rand (talk) 14:50, 9 September 2013 (UTC)

A small thing – it used to be that when you tried to roll back sitelink removal, but the pages in Wikipedias had been deleted, it wouldn't restore them. Now it does restore them even if deleted. Or should this go to Paper cuts? Thanks, Littledogboy (talk) 14:13, 9 September 2013 (UTC)

I've made Bugzilla:52942. Not sure if anyone of the dev. team have seen it. --Stryn (talk) 14:16, 9 September 2013 (UTC)
OK, thank you Stryn. It would take me ages before I'd get familiar with Bugzilla, and learned how to create a bug myself. Littledogboy (talk) 15:34, 9 September 2013 (UTC)
Though my English is too bad for explaining things, I understood better your comment here than my comment on Bugzilla, lol. Btw you only have to make an account there and after it you can report, comment, vote and follow bugs. --Stryn (talk) 15:57, 9 September 2013 (UTC)

Celestial coordinate system

What kind of solution can be expected to represent celestial bodies positions in a celestial coordinate system? Will it be a new datatype, the geographic coordinate with a celestial globe, or will the number datatype be used instead? The most popular celestial coordinate system is the Equatorial coordinate system and, similarly to the geographic coordinate data type, it requires of two angles, right ascension and declination. You can see an example on Sirius. The nomenclature is a bit different using hour angles (hours ( h ), minutes ( m ), and seconds ( s )) instead of degrees (degree, (°) minute ('), second ('')), which means that a circumference is 24h instead of the customary 360°--Micru (talk) 16:01, 4 September 2013 (UTC)

You are aware of that "degree, (°) minute ('), second ('')" only is a part of the User Inteface, the data is stored as decimal? -- Lavallentalk(block) 17:01, 6 September 2013 (UTC)
No, I was not aware of that. I think the geographic coordinates have some constraints that would be different.--Micru (talk) 18:29, 6 September 2013 (UTC)
As part of the coordinates you have to specify a 'sphere'. Currently items used for this include 'earth', 'moon' etc. celestial sphere (Q12134) isn't used but I can't see any reason why it shouldn't be. Filceolaire (talk) 22:07, 10 September 2013 (UTC)

Page not rendering

Tracked in Bugzilla
Bug 53997

Somehow I can't display Q14274. I had undone two edits. --  Docu  at 18:32, 9 September 2013 (UTC)

Error message displayed:

Extended content
 
Unexpected non-MediaWiki exception encountered, of type "InvalidArgumentException"
exception 'InvalidArgumentException' with message '$pageName needs to be a string' in /usr/local/apache/common-local/php-1.22wmf15/extensions/WikibaseDataModel/DataModel/SimpleSiteLink.php:31
Stack trace:
#0 /usr/local/apache/common-local/php-1.22wmf15/extensions/WikibaseDataModel/DataModel/Entity/Item.php(75): Wikibase\DataModel\SimpleSiteLink->__construct('dewiki', Array)
#1 /usr/local/apache/common-local/php-1.22wmf15/extensions/Wikibase/repo/includes/ItemView.php(71): Wikibase\Item->getSimpleSiteLinks()
#2 /usr/local/apache/common-local/php-1.22wmf15/extensions/Wikibase/repo/includes/ItemView.php(50):  Wikibase\ItemView->getHtmlForSiteLinkGroup(Object(Wikibase\ItemContent), 'wikipedia', Object(Language), true)
#3 /usr/local/apache/common-local/php-1.22wmf15/extensions/Wikibase/repo/includes/ItemView.php(30): Wikibase\ItemView->getHtmlForSiteLinks(Object(Wikibase\ItemContent), Object(Language), true)
#4 /usr/local/apache/common-local/php-1.22wmf15/extensions/Wikibase/repo/includes/EntityView.php(146): Wikibase\ItemView->getInnerHtml(Object(Wikibase\ItemContent), Object(Language), true)
#5 /usr/local/apache/common-local/php-1.22wmf15/extensions/Wikibase/repo/includes/EntityView.php(278): Wikibase\EntityView->getHtml(Object(Wikibase\ItemContent), NULL, true)
#6 /usr/local/apache/common-local/php-1.22wmf15/extensions/Wikibase/repo/includes/content/EntityContent.php(148): Wikibase\EntityView->getParserOutput(Object(Wikibase\ItemContent), Object(ParserOptions), true)
#7 /usr/local/apache/common-local/php-1.22wmf15/includes/WikiPage.php(3514): Wikibase\EntityContent->getParserOutput(Object(Title), 69321513, Object(ParserOptions))
#8 /usr/local/apache/common-local/php-1.22wmf15/includes/PoolCounter.php(222): PoolWorkArticleView->doWork()
#9 /usr/local/apache/common-local/php-1.22wmf15/includes/Article.php(708): PoolCounterWork->execute()
#10 /usr/local/apache/common-local/php-1.22wmf15/extensions/Wikibase/repo/includes/actions/ViewEntityAction.php(229): Article->view()
#11 /usr/local/apache/common-local/php-1.22wmf15/extensions/Wikibase/repo/includes/actions/ViewEntityAction.php(156):  Wikibase\ViewEntityAction->displayEntityContent(Object(Wikibase\ItemContent))
#12 /usr/local/apache/common-local/php-1.22wmf15/includes/Wiki.php(440): Wikibase\ViewEntityAction->show()
#13 /usr/local/apache/common-local/php-1.22wmf15/includes/Wiki.php(305): MediaWiki->performAction(Object(Article), Object(Title))
#14 /usr/local/apache/common-local/php-1.22wmf15/includes/Wiki.php(588): MediaWiki->performRequest()
#15 /usr/local/apache/common-local/php-1.22wmf15/includes/Wiki.php(459): MediaWiki->main()
#16 /usr/local/apache/common-local/php-1.22wmf15/index.php(55): MediaWiki->run()
#17 /usr/local/apache/common-local/w/index.php(3): require('/usr/local/apac...')
#18 {main}
I am curious how this was able to happen with undo. This item includes new structure to accommodate badges. I think the rendering will get "fixed" when new version of the extensions get deployed, which probably will be later today (Tuesday). The new code is able to handle this structure for site links and we should double check that there are no issues with undo. Aude (talk) 01:57, 10 September 2013 (UTC)
I hope this issue is fixed soon, since another user just reported it on the project chat. The Anonymouse (talk) 04:21, 10 September 2013 (UTC)

It happened of four other items my bot edited. I stopped it afterwards, but couldn't restore the old version. It didn't happen before with the same python code and hasn't happened since:

Extended content
 

18:20, 9 September 2013 (diff | hist) . . (+1,039)‎ . .  Ammerswil (Q65198) ‎ (‎Created claim: country (P17):) (current)
18:20, 9 September 2013 (diff | hist) . . (+252)‎ . .  Aarburg Castle (Q673786) ‎ (‎Created claim: is in the administrative unit (P131):) (current)
18:20, 9 September 2013 (diff | hist) . . (+428)‎ . .  Aarburg Castle (Q673786) ‎ (‎Created claim: country (P17):)
18:20, 9 September 2013 (diff | hist) . . (+251)‎ . .  Aarburg (Q64165) ‎ (‎Created claim: is in the administrative unit (P131):) (current)
18:20, 9 September 2013 (diff | hist) . . (+1,255)‎ . .  Aarburg (Q64165) ‎ (‎Created claim: country (P17):)
18:20, 9 September 2013 (diff | hist) . . (+251)‎ . .  Aarau (Q14274) ‎ (‎Created claim: is in the administrative unit (P131):)
18:20, 9 September 2013 (diff | hist) . . (+2,659)‎ . .  Aarau (Q14274) ‎ (‎Created claim: country (P17):)
18:20, 9 September 2013 (diff | hist) . . (+251)‎ . .  List of cultural property of national significance in Switzerland: Aargau (Q664331) ‎ (‎Created claim: is in the administrative unit (P131):) (current)
18:20, 9 September 2013 (diff | hist) . . (+411)‎ . .  List of cultural property of national significance in Switzerland: Aargau (Q664331) ‎ (‎Created claim: country (P17):)

Maybe deleting the item and restoring everything, but the last versions works. --  Docu  at 04:34, 10 September 2013 (UTC)

Here is another one Q173183. I added a sitelink, but after that I decided to rename article in my wikipedia (lvwiki). --Papuass (talk) 10:37, 10 September 2013 (UTC)

Thank you! We are working on it and hopefully have a fix deployed in the next hour or two. Sorry for the issue. --Lydia Pintscher (WMDE) (talk) 18:05, 10 September 2013 (UTC)
Seems to work again. Thanks for fixing it! --  Docu  at 18:17, 10 September 2013 (UTC)
Yes, those items are working again. Thanks! The Anonymouse (talk) 18:22, 10 September 2013 (UTC)

qualifiers-order

In the api, I today find things like: qualifiers-order. Can you explain it's purpose? -- Lavallentalk(block) 07:22, 11 September 2013 (UTC)

This is the beginning of the support for sorting qualifiers and statements in an item. Not working yet but we're getting there :) --Lydia Pintscher (WMDE) (talk) 12:21, 11 September 2013 (UTC)
Can we use a javascript for this sorting in order to allow everyone to choose its own qualifiers-order ? This sorting is just a display feature so do we really need to implement that in the wikidata code ? Just a question. Snipre (talk) 12:37, 11 September 2013 (UTC)
It'll probably be easy enough to manipulate this via JS, yes. However we need this sorting for ranks later. So it'll need to be in the Wikibase software directly. --Lydia Pintscher (WMDE) (talk) 13:01, 11 September 2013 (UTC)

problem with coordinate location

There is a problem with coordinate location for the item Syracuse University. May some one have a look at it, please. -دوستدار ایران بزرگ (talk) 13:24, 11 September 2013 (UTC)

Tracked in Bugzilla
Bug 53521
Last month they changed the geo format requirement (without backwards compatibility..), so this message appears when the 'globe' parameter is empty (https://bugzilla.wikimedia.org/show_bug.cgi?id=53521). 139.63.60.122 13:33, 11 September 2013 (UTC)

Did the JSON-based structure for entities change with the latest release? Now I'm seeing "links / lawiki / name" in diffs instead of "links / lawiki", and this edit is being shown as "+1,863" while it has actually removed a claim. Was this necessary? --Ricordisamoa 20:57, 11 September 2013 (UTC)

Yes, this is because empty arrays are being added in to support badges. Legoktm (talk) 03:32, 12 September 2013 (UTC)
When will this be actually available? --Ricordisamoa 05:33, 12 September 2013 (UTC)
It's not clear yet since the guy who did awesome work on the backend for this unfortunately doesn't have time to finish the frontend work. Not sure when we'll be able to finish this up. To stay up-to-date on it please follow bugzilla:40810. If anyone else wants to work on this please let me know. --Lydia Pintscher (WMDE) (talk) 09:34, 12 September 2013 (UTC)

Item size changes after adding and revering a claim.

(noticed by user:Oliv0) After adding coordinates and then reverting here the item size is not the same as it was before. Is that intended ? --Zolo (talk) 20:35, 13 September 2013 (UTC)

It is probably related to #Change in sitelinks structure. --Ricordisamoa 06:39, 14 September 2013 (UTC)

Tab and selecting properties

Hello, legoktm suggested I leave a note here... Before, when adding a statement, I could type the property ID and then press tab, which would select the property and switch to the text field for the value. Today it seems to no longer work, if I press tab, it tabs elsewhere on the page, and instead I have to press down, enter and then tab for it to work. That's using Opera 12.14 in OSX. --Nikki (talk) 05:19, 12 September 2013 (UTC)

Yeah others have also told me about this already. I've reported it at bugzilla:54072 now. Thanks for poking. --Lydia Pintscher (WMDE) (talk) 09:40, 12 September 2013 (UTC)
I had this problem as well. If you press tab it jumps to 'cancel' instead of the value box and no Value box appears.
I found that if you go back and try it again it often works the second (or third) time. You get a Value box and tab jumps to it.
It seems (to me) to be a performance issue. If your network connection (or the server) isn't fast enough then it fails to confirm the property is valid and doesn't show the Value box. Filceolaire (talk) 13:38, 12 September 2013 (UTC)
I definitely think this is a performance issue, as I've only sporadically seen this be an issue. --Izno (talk) 21:29, 15 September 2013 (UTC)

Is Slovenia a real place or is it part of Second life

Tracked in Bugzilla
Bug 53666

So I hit the random page button and came to Janov krik (Q6155308) - a novel by Slovenian author Marinka Fritz Kunc.

So I tried to add the author property but couldn't find a page for this woman.

No problem. I slid across to the sl:wikipedia and sure enough there she was sl:Marinka Fritz Kunc but this doesn't have a wikidata item.

So I go to Special:NewItem and enter the language 'slovenščina (slwiki)' and the page 'Marinka Fritz Kunc' and search. It doesn't find that page but gives me the option to create an item for slwiki:Marinke+Fritz+Kunc. I click on that link and I'm taken to the second life wiki and invited to create a page there!

Has someone messed up the wikilinks? Filceolaire (talk) 20:32, 13 September 2013 (UTC)

See Wikidata:Project chat/Archive/2013/09#Bug on Special:ItemByTitle? and bugzilla:53666. --Ricordisamoa 06:42, 14 September 2013 (UTC)
It should be FIXED/INVALID now: see bugzilla:53666#c3. --Ricordisamoa 02:44, 16 September 2013 (UTC)

Search malfunction

this search brings no results. However there is Alternative for Germany (Q6721203) that matches the search string in de:. My language setting is to de, if the setting is to en there will be an error message. --Giftzwerg 88 (talk) 21:17, 7 September 2013 (UTC)

If your language is set to en it will search for labels in en. We might be able to do something with fallback languages later but at the moment this is it. --Lydia Pintscher (WMDE) (talk) 12:46, 8 September 2013 (UTC)
The problem is the German search string does not find the matching german label, even when language setting is to German. Not even if I copy the label to the search box. Is it the Umlaut?--Giftzwerg 88 (talk) 16:20, 9 September 2013 (UTC)
Unfortunately, yes. We're waiting for the new search backend that people at the foundation are working on. They got it to a stage for initial testing roll-out now. I hope Wikidata will be able to use it soon too. Then this and similar issues should be fixed. --Lydia Pintscher (WMDE) (talk) 09:44, 16 September 2013 (UTC)

URL validation

Is this a valid URL? --Ricordisamoa 06:38, 14 September 2013 (UTC)

It seems that only the protocol is validated. BTW at diff, the URL might have had a linefeed at the end. --  Docu  at 20:02, 14 September 2013 (UTC)
Hey :) Yeah we don't have any restrictions there other than the protocol and a :// after that. When you use this URL in wikitext it is linked too. I don't think we should act differently there. Does that make sense? --Lydia Pintscher (WMDE) (talk) 14:16, 19 September 2013 (UTC)

Internationalisation and Coord-datatype

I guess you sooner or later will allow other things than "E/W/N/S" in the coord-datatype, depending on the prefered language in the GUI. Is it possible to let the English letters work together with the Swedish, since English "E and W" is still widly used in Swedish-speaking areas? It is only some months ago we changed those letters in the Swedish coord-template on svwp for example. -- Lavallen (talk) 09:01, 15 September 2013 (UTC)

Be careful with allowing multiple types, e.g. in czech language there are letters SJVZ, where S(ever) means North. JAn Dudík (talk) 07:41, 16 September 2013 (UTC)
I understand that this can be troublesome in some languages, but since you have to allow both "Ö(st)" and "O(st)" in Swedish, I think it also would be possible to add "E(ast)" to that. -- Lavallen (talk) 08:34, 16 September 2013 (UTC)
I'll try to keep that in mind. Thank you. I'm unsure at the moment if this is a good idea in general - among other things because of the reason JAn mentioned. But will discuss this when the time comes for that. --Lydia Pintscher (WMDE) (talk) 14:24, 19 September 2013 (UTC)

Time datatype

What is the problem with the time value of the second source of the first claim here? Is says "The value does not comply with the property's definition. The value's data value type "ununserializable" does not match the property's data type's data value type "time"." The English error message does not help me and the German translation is even worse.  — Felix Reimann (talk) 08:56, 18 September 2013 (UTC)

A difference there between the problematic value for publication date (P577) and the normally displayed value for point in time (P585) is the precision: the former includes hours:minutes:seconds (in the source with Ctrl-U: +00000002001-06-11T15:51:51Z). Oliv0 (talk) 10:14, 18 September 2013 (UTC)
But the precision is set correctly to 14 (seconds) instead of 11 (days). Does the property only accept values of lower precision? If yes, where is this defined? How can you see which precision is allowed? And why does the API accepts those values then?  — Felix Reimann (talk) 11:22, 18 September 2013 (UTC)
Is it possible that the GUI does not allow such details yet? -- Lavallen (talk) 12:13, 18 September 2013 (UTC)
Yes that's unfortunately the case. The UI can't handle below days. Which is bad if you can enter them via the API. I filed a bug at bugzilla:54333. --Lydia Pintscher (WMDE) (talk) 15:56, 19 September 2013 (UTC)

'0' key in Lua tables

The most standard Lua tables are "sequence" where the key are natural numbers starting from 1, but Wikibase tables seem to have a key "0". It is a bit annoying. According to the documentation, "Many Lua functions operate only on sequences, and ignore non-positive-integer keys." For instance, the number of claims for a property, as given by #entity.claims.pXX is one less than expected. --Zolo (talk) 09:49, 19 September 2013 (UTC)

Thanks. I've filed it at bugzilla:54324. --Lydia Pintscher (WMDE) (talk) 14:36, 19 September 2013 (UTC)

Qualifiers

When I propose using a qualifier to make a property more flexible so it can be used in more ways I often get the comment that having information in qualifiers means it is more difficult to access.

If this is so then we should establish a principle that the important information is available from the property and the qualifier is only used for additional information. This is pretty much how we have done things till now. For instance we have a 'key event' property which needs a date qualifier but we have separate properties for 'date of birth' and 'date of death'.

If this isn't so then we don't need to follow that principle.

Is there anyone here who can advise on whether this is or isn't so? Filceolaire (talk) 20:58, 11 September 2013 (UTC)

Can you give a concrete example maybe? That'd probably make it easier to answer your question. --Lydia Pintscher (WMDE) (talk) 09:35, 12 September 2013 (UTC)
At present we have
If we replace this with
Would that be a problem? Filceolaire (talk) 13:27, 12 September 2013 (UTC)
At present we have

We could replace this (and many other 'authority control' properties) with

Discussion about qualifiers in general
Would it be a problem for bot queries if important info is in qualifiers, as these examples, instead of in the main property? Filceolaire (talk) 20:38, 13 September 2013 (UTC)

Hey :) Sorry for only getting back to this now. I had a chance to talk to the team about this and since you ask for a preference: From our point of view it doesn't make too much sense to move to things like "key event" and then "birth" as the value and a date as a qualifier. It'd make things less nice to use and harder to read for no apparent benefit. It'd also make using the data more cumbersome in the future. It's also not quite what qualifiers are meant for. They're meant to qualify a statement that is able to stand on its own. --Lydia Pintscher (WMDE) (talk) 14:09, 19 September 2013 (UTC)

Thanks Lydia. I will ammend Help:Qualifiers accordingly. Filceolaire (talk) 17:19, 19 September 2013 (UTC)
Discussion about the particular examples
I am not worried about the second example, but I am worried about the first. It demands us to be consistent in the use of "birth" everywhere. It's even worse with the "birth" of organisations, buildings etc, since which item you will choose will depend on your personal references, the language of the editor and the nature of the item. For example, when was the "birth" of an administrative unit? When the law regarding them was confirmed by the parlament/king, at the first general assembly, when the law came in force or when the organisation was registred? We have had large problems describing such things in pure text on svwp, since the "key event" is different depending on the nature of the organisation, and which era it took place. To be able to describe it correctly here, I think we need special properties for such things as inception (P571). "Place of birth" is also such a property, since it depends on how the laws works in the nation. "place of birth" in Sweden today is always the locality where the mother lived at birth, not the hospital the "event" took place. -- Lavallen (talk) 15:00, 12 September 2013 (UTC)
@Lavallen Please have a look at the talk page of significant event (P793) to the number of properties you need to create. It is not a big problem I agree but for contibutors it can be. Snipre (talk) 12:31, 13 September 2013 (UTC)
I see no limits at all from the developers point of view (even if I am not a developer), it's the maintainance here and the interpretation in the modules/templates in the client that will be the challenge. So, go ahead if you like, but be very carefull, otherwise will this information never reach Wikipedia! -- Lavallen (talk) 13:14, 13 September 2013 (UTC)
The number of properties is not a technical problem, it's a human problem: how to know all properties and then select the appropriate one ? For a new contributor and even for one with a little experience the huge amount of properties is challenging. And I am waiting for the number datatype properties to see the final properties number. If I have to do an estimation, I expect around 2000 properties for the end of the year. And as we choose to have qualifier in the data structure we have to have a code which can deal with that data structure for every possible use. If you have some doubt about qualifier better launch a RfC to delete this feature than saying don't use it and at the same time let it available. Snipre (talk) 14:17, 13 September 2013 (UTC)
So is also the use of qualifers in each property a human problem, that we need tools to handle. Another challenge is to see how we should know what statements that make sense to add in a infobox. A flag of a Swedish County or Municipality does not make sense to put in any infobox, but there are several on Commons and some of them are here. -- Lavallen (talk) 15:17, 13 September 2013 (UTC)
By my count we have about 886 properties [1] at the moment with about 100 pending - less than 1000 total.
Of these about 160 are catalog type properties (most of the properties with 'string' datatype) most of which might be deleted if the second proposal above were adopted, reducing the total to about 850.
It's not unreasonable to suppose the final number might be double this - 1700.
Usage of these properties will likely follow the usual power law with 20% of the properties (about 350 properties) doing 80% of the work. Filceolaire (talk) 19:00, 14 September 2013 (UTC)
I guess some others can also be merged, like the municipality-codes/FIPS/NUTS etc. But I think it would be more instructive to do so after working templates for that have been designed at WP, and a good working system for constraints has been developed. Otherwise will it be hard to get acceptance from the community to do so, since it will look like information is lost. -- Lavallen (talk) 19:29, 14 September 2013 (UTC)
The example with GND is very easy to understand. For now we need a property for each and every database one for GND one for Viaf and so on and for many other databases to come. It can be more easy: One Property as a catch all, lets call it Property:Database Numbers. Then you can ad qualifiers for GND, Viaf .... and every other database. You need one qualifier, an item for each database (exists allready) and you can link it by qualifier with a string including the number. The same for all library catalogues, yon just need the item for the library and can add the catalogue numbers of Congress library or any national library. One day there will be one wikidata item linked in every library catalogue to get all authority controll numbers and all library numbers in all languages.--Giftzwerg 88 (talk) 10:44, 16 September 2013 (UTC)
And we can also add new catalogs/databases with maybe only a few related items here, without a Property-proposal-process. -- Lavallen (talk) 10:51, 16 September 2013 (UTC)
We also dont need to argue about the importance of a database. Even very specialised databases can be linked. For astronomical object you can link the different cataloges.--Giftzwerg 88 (talk) 11:10, 16 September 2013 (UTC)
I agree with the idea of many properties made into one with different qualifiers. The problem is that Wikipedia templates and modules are beginning to use Wikidata properties but not qualifiers: maybe it is still time to change. Oliv0 (talk) 19:20, 19 September 2013 (UTC)
The problem with Wikipedia templates is the use of wiki syntax instead of a full lua template. Snipre (talk) 21:14, 19 September 2013 (UTC)

Wikidata coordinates are not "primary tags"

Not sur it is a bug, maybe I just missed something but if you add two "primary tags" to a Wikipedia page, you get an error message: "{{#coordinates:}}: cannot have more than one primary tag per page". Yet, when the coordinates come from Wikidata, the message seems to disappear. Compare [2] (error message towards the bottom of the text) and [3] (no error message). ---Zolo (talk) 13:20, 16 September 2013 (UTC)

This seems to be an error from the maps gadget that isn't really aware of Wikidata? Can you poke them about this? --Lydia Pintscher (WMDE) (talk) 14:30, 19 September 2013 (UTC)
My mistake, the error message was because the two sets coordinates provided were different. When Wikidata was used, consistency was restored and things went right. :)--Zolo (talk) 08:46, 21 September 2013 (UTC)

Don't automatically update when moving some page like en:Wikipedia:Goings-on

This page is archived weekly on en.Wikipedia by moving the page, so can wikidata don't automatically update when moving some page like en:Wikipedia:Goings-on?--GZWDer (talk) 15:12, 19 September 2013 (UTC)

Could you solve this in a similar way to en:Portal:Current events? I don't see how we can fix this in the software without shooting ourself in the foot at the moment. --Lydia Pintscher (WMDE) (talk) 12:39, 23 September 2013 (UTC)
Perhaps a "dirty trick" will do by writing protection on the corresponding items? --Giftzwerg 88 (talk) 15:42, 23 September 2013 (UTC)
Someone suggested an edit filter a while back. Is that possible? The Anonymouse (talk) 16:15, 23 September 2013 (UTC)

Wikidata news

Why do you update out-of-date news in wikidata main page? Should I translate them again? –دوستدار ایران بزرگ (talk) 16:45, 21 September 2013 (UTC)

This is not done by the development team, sorry. The news are community-maintained. --Lydia Pintscher (WMDE) (talk) 09:15, 23 September 2013 (UTC)

Hello,

I've tried many times to edit a link, but I always had in return the message "An error ocurred, etc.".

I had to delete the wrong link, to try to create the new one, but again the same message.

It is in Q1318295, and I try to link this to the correct French article, "Nouvelle".

Can someone explain to me why I may have these problems, and anyway proceed to the correction?

Thank you very much. Best regards, --Daehan (talk) 08:39, 23 September 2013 (UTC)

Hi, fr:Nouvelle is already at Q149537. You should first delete the link from Q149537 and then add it to Q1318295. We also have a "move" gadget, which you can move links to another item. Also, when you deleted fr:Narration from Q1318295, you should add it somewhere else, or make a new item for it, if there is not yet item for it. --Stryn (talk) 08:46, 23 September 2013 (UTC)
Hi, thank you for your answer.
Indeed, I made a mistake : this item has to be linked to fr:Récit, as "Nouvelle" is - and has to be - linked to "Novella".
So, now the problem is different. "Récit" appears to be linked to en:Story, a disambiguation page. It has to be linked to en:Narrative (Q1318295). So I removed the links to allow this new association. But it doesn't seem to have succeed, and from the "Récit" page, I can't access the wikidata link... I'm sorry if it's confusing. --Daehan (talk) 09:24, 23 September 2013 (UTC)
First I deleted interwiki links from fr:Récit (see this, links still existed on the article's code). When the links were deleted from the article, it was possible to connect this page to the corresponding item via the left panel (Ajouter des liens) --Stryn (talk) 09:36, 23 September 2013 (UTC)
Thank you very much : I assumed it had been removed as in other articles... Thank you for your patience. Best regards, --Daehan (talk) 09:46, 23 September 2013 (UTC)

Interwikis in File namespace on Commons

If individual files are not notable on Commons, why there is Add link on file pages? --EugeneZelenko (talk) 14:18, 25 September 2013 (UTC)

Because the team hasn't been asked to make this restriction :) If this should be done like for the User namespace please get a few people to agree and we can probably do it. --Lydia Pintscher (WMDE) (talk) 09:20, 26 September 2013 (UTC)
This question was also discussed on commons:Commons:Village pump#Wikidata is here!. --EugeneZelenko (talk) 14:27, 26 September 2013 (UTC)
The general question of interwiki links from File pages was also discussed (and decided against) back in 2008, commons:Commons:Village pump/Archive/2008/10#Interwiki linking policy. Files not on Commons were ruled non-notable in this Wikidata RFC. But I guess those are both somewhat distinct questions from whether Commons files can be linked here. --Avenue (talk) 17:16, 26 September 2013 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Contact_the_development_team/Archive/2013/09&oldid=1102549181"