Wikidata:Contact the development team/Archive/2017/12
|
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion. |
Formatting in image legends
What would it take to have simple formatting in image legends? For example, on Anthidiellum (Q14458686), the legend is "Anthidiellum strigatum (male)", which should obviously be rendered as "Anthidiellum strigatum (male)". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:29, 1 December 2017 (UTC)
- Hello Andy, I think I understand what you mean.
- The name of the image comes directly from Commons and is a simple string of text. The value of the property "media legend" is also a monolingual text string, without possiblity to add format, wikitext, etc. The reason for that is that we want to keep the content as simple and non-formatted as possible, so the potential reusers of the data can use it easily and format it as they want.
- If you want to see the legend formatted, I assume one could create a gadget to display it as you want. I'm wondering though how the program could analyze this string of text to automatically render it according to the standards. For the taxon names, it could be a rule like "format in italic from the beginning to the first bracket" but what about the other types of legends?
- Cheers, Lea Lacroix (WMDE) (talk) 18:00, 1 December 2017 (UTC)
- I don't think that would work; the legend could be, say "Anthidiellum strigatum - male". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:07, 2 December 2017 (UTC)
- There are two possibilities.
- You program the gadget that reads the image label to be smart enough that it picks up the fact that Anthidiellum strigatum is the name of the species and therefore renders italics.
- You store the information inside the text field. Unicode itself doesn't have a way to represent italics. We would need to decide on an understanding that strings in general should be understood as being formatted in a certain way. Wikitext itself is very complex and as a result it's bad for data reusers to declare that our strings are generally Wikitext. One possible solution would be to declare our strings to follow Markdown. Given that it's a significant shift in our data model I think if we want to go that route we should have a RfC about it. ChristianKl (✉) 16:59, 5 December 2017 (UTC)
- „obviously be rendered“? Where? In our UI? --Succu (talk) 22:27, 6 December 2017 (UTC)
Weekly dump
No Weekly dump this week? --ValterVB (talk) 18:49, 1 December 2017 (UTC)
- There will be no dumps this week due to phab:T181385. Sjoerd de Bruin (talk) 19:29, 1 December 2017 (UTC)
Automatic label & description
Is there any gadget by which I import label from Wikipedia & add description automatically in similar pages?--Prateek MalviyaTalk 12:32, 6 December 2017 (UTC)
- There is label suggester based on name of page at wikipedia at User:Joern/altLabels.js, for descriptions there is a nice tool Descriptioner.--Jklamo (talk) 23:35, 6 December 2017 (UTC)
Lag till new item can be selected
It used to be that I could instantly add a newly created item as a statement on another item. Now, I have to wait. I'm not exactly sure when the change happened but it might be another thing that was broken through the "birthday present" of the new search (which still doesn't consider male (Q6581097) to be the best value for sex or gender (P21). ChristianKl (✉) 21:52, 30 November 2017 (UTC)
- @ChristianKl: Could you give some specific examples of the lag you are perceiving? I.e. which item did you add, how long it took until you saw it in the search? There's slight delay because of ElasticSearch index updates being batched to happen every 30s, and there can be another delay due to job queue, but I'd like to evaluate how bad that is and if it's permanent or temporary. Smalyshev (WMF) (talk) 21:15, 4 December 2017 (UTC)
- It's like 10 till 15 seconds for me. Every second of lag can be annoying for power users. Sjoerd de Bruin (talk) 21:17, 4 December 2017 (UTC)
- Having the update happen every 30s (+ job queue) is consistent with my observations and the 10 till 15 seconds that Sjoerddebruin reports. If I create a new item I generally want to be able to add immediately add it to another item.
- It's particularly annoying because the system doesn't tell me when it's finished and I have to try multiple times and hope each time that the system is done with it's processing and if I try too early the system rejects me.
- As far as examples go a typical one is creating a item that's to be used with stated in (P248) as a reference. When creating such an item it's usually desireable to link it immediately. ChristianKl (✉) 21:37, 4 December 2017 (UTC)
It seems like everything is slow these days.
--- Jura 10:01, 8 December 2017 (UTC)
Item compare special page
For merging and other cases, it would be interesting to have a special page that compares two (or maybe more) items (or entities).
The display could be similar or more compact than item pages. Instead of one columns with values there could be several. Maybe columns with identical values could be merge or, optionally, not displayed at all.
To some extent one can do that with (e.g.) TAB, but that requires to list/know the properties beforehand.
--- Jura 12:05, 8 December 2017 (UTC)
- Did you already see http://tools.dicare.org/wikidata-diff ? --Lydia Pintscher (WMDE) (talk) 12:13, 8 December 2017 (UTC)
- Such a view should also allow an easy way to copy statements from one item to another. ChristianKl (✉) 12:50, 8 December 2017 (UTC)
- I think there used to be a prototype that planned to do that. One could move statements between items displayed.
- Even an improved MediaWiki diff function could work. Here is one comparing two different pages with content model "Wikibase item": https://www.wikidata.org/w/index.php?diff=517493521&oldid=517492815
- I think it needs to be part of MediaWiki.
--- Jura 11:00, 11 December 2017 (UTC)
Articles not searchable by author
Now that Harej et al. built us such a nice article database, I just noticed that we can't actually search it by author. Author strings are not indexed. Could you do something about it?
--- Jura 22:45, 5 November 2017 (UTC)
- Hello Jura, this type of search would require to search in the labels of the value of a statement, and it's not planned so far. You can search by creating a list with the Query Service, and then search inside the results. Lea Lacroix (WMDE) (talk) 09:41, 6 November 2017 (UTC)
- I think it is or was planned and is being done for P31/P279. Could you investigate and prioritize it, because I don't think query service is suitable for string search and the large amount of items this concerns make it more important. The property that needs to be added to the search index is author name string (P2093).
--- Jura 09:50, 6 November 2017 (UTC)- what's the progress on this?
--- Jura 09:15, 3 December 2017 (UTC)- @Smalyshev (WMF): Can you have a look? --Lydia Pintscher (WMDE) (talk) 11:29, 14 December 2017 (UTC)
- what's the progress on this?
- I think it is or was planned and is being done for P31/P279. Could you investigate and prioritize it, because I don't think query service is suitable for string search and the large amount of items this concerns make it more important. The property that needs to be added to the search index is author name string (P2093).
Performance effects of a special flag for bots adding certain statements to living people
I'm currently writing a draft for a living people policy. As one clause the policy proposes a new flag that restricts certain edits: https://www.wikidata.org/wiki/Wikidata:Living_people_(draft)#Bot_interaction_with_items_for_living_people Before proposing it this way in an RfC I would like to know whether introducing such a filter would have significant performance effects. ChristianKl (✉) 16:37, 7 December 2017 (UTC)
- @Lea Lacroix (WMDE): Given that I'm now through the OTRS burocracy, this request for information is the main bottleneck before I can start the RfC on the Living Persons policy. It would be useful to have developer feedback in the following days. ChristianKl (✉) 23:48, 13 December 2017 (UTC)
- I just asked and it seems it will indeed cause trouble in the current setup :/ The table where this is stored is pretty bad. However it seems the collaboration team is looking into improving it. Their ticket for it is phabricator:T91535. --Lydia Pintscher (WMDE) (talk) 11:27, 14 December 2017 (UTC)
Number jump
When a new item or property is created, it will jump if there is an item with this label and recognition. For example; Q456, Q457, Q458 .... However, if we make a mistake that there is an existing element, Q459 is not created in this case. Q460 is jumping. Why is this happening? The same applies in Property. Thanks. --İncelemeelemani (talk) 19:04, 8 December 2017 (UTC)
- I'm not sure what you are talking about Plovdiv (Q459) is a valid item. In general some items and properties do get deleted and as a reason there's no item at that number. ChristianKl (✉) 14:45, 10 December 2017 (UTC)
- Thank you. But this is an example. My English is inadequate. Can you report this to the Wikibase team? --İncelemeelemani (talk) 13:51, 17 December 2017 (UTC)
- Some IDs get skipped and some are not used anymore because the item they represented was deleted. It isn't great but also not a big deal. --Lydia Pintscher (WMDE) (talk) 17:44, 17 December 2017 (UTC)
- Hmm, thank you. --İncelemeelemani (talk) 18:03, 17 December 2017 (UTC)
- Some IDs get skipped and some are not used anymore because the item they represented was deleted. It isn't great but also not a big deal. --Lydia Pintscher (WMDE) (talk) 17:44, 17 December 2017 (UTC)
- Thank you. But this is an example. My English is inadequate. Can you report this to the Wikibase team? --İncelemeelemani (talk) 13:51, 17 December 2017 (UTC)
Autocomplete search does not truncate trailing spaces
In the previous search engine I could copy the string "John Smith " and paste it into the search box to find items called "John Smith". The new search engine doesn't allow this anymore. I noticed multiple times that this chance annoys me, even when there might be some cases where people welcome it. ChristianKl (✉) 17:55, 15 December 2017 (UTC)
- Looks like it happens because "John Smith " implies there is something besides John Smith in the string. But looks like it's not the way it works on enwiki, etc., so we may want to change this. Smalyshev (WMF) (talk) 01:59, 16 December 2017 (UTC)
- The old search engine felt like it had a bunch of customizations for Wikidata. I have the impression that the new one doesn't. In many cases it's expected that people type input into a serach box. In the case of Wikidata data often get's copy-pasted. Copy-pasting inturn can frequently add additional whitespace. I think there's some argument to b made to rank "John Smith Foundation" before "John Smith" when the user types "John Smith " but if you want to keep it simple stripping out whitespace (spaces aren't the only whitespace that gets copypasted) is likely a good idea. ChristianKl (✉) 14:33, 17 December 2017 (UTC)
hif.wiktionary (2)
@aude, Lydia Pintscher (WMDE): any progress with linking hif.witionary through wikidata? JAn Dudík (talk) 20:46, 16 December 2017 (UTC)
- Sorry this slipped through. I pinged people who can look at it now. --Lydia Pintscher (WMDE) (talk) 17:41, 17 December 2017 (UTC)
References not viewable in page history?
It seems it's not possible to view the references when viewing a historic version of an item: https://www.wikidata.org/w/index.php?oldid=580195666
Workaround seems to be to do a diff, but that might be complicated on items with a longer or more complex history.
--- Jura 12:48, 16 December 2017 (UTC)
- Something in MediaWiki core changed. The ticket for fixing it is phabricator:T182767. --Lydia Pintscher (WMDE) (talk) 17:38, 17 December 2017 (UTC)
Geographic coordinates display
Re: this diff
The lat/long coordinates for this item are formatted in dms as "45°33'1"N, 123°4'45"W", both before and after the coordinates were edited. These dms coordinates are also not equivalent to the dec coordinates - neither before nor after. When clicking on the link in item view, the Geohack page shows the correct "after" coordinates, both dec and dms. --Ipoellet (talk) 22:31, 13 December 2017 (UTC)
- Can you please say what you would expect on the left and right side of the diff? --Lydia Pintscher (WMDE) (talk) 17:43, 17 December 2017 (UTC)
- I'm a little bit uncertain about this, because I'm relatively new to Wikidata and unsure of exactly which format is used to store the data in the db. But here's my best answer to your question: I would have expected the dms coordinates in the diff to read (assuming rounding to the nearest second - the decimal coordinates have higher precision):
- On the left: 45°32'54"N, 123°4'23"W
- On the right: 45°32'53"N, 123°4'28"W
- — Ipoellet (talk) 02:51, 19 December 2017 (UTC)
Items missing from Wikidata search index
From the Project Chat:
- I have noticed an issue with some recent items which return "no match found" in the "Search Wikidata" box - using both their label and their Q-ID - although they clearly exist. This also makes it impossible to set some property's value to them. Examples are Pierre Fouchet (Q45825730), Pochi (Q45825741), district mayor of Tiergarten (Q45825742) or Dörre Wieslein (Q45825750). The affected items are not continuous in ID (e.g. Erick Guerrero (Q45825749) works fine). The issue persists both when switching browsers and when logging out.--Pfadintegral (talk) 11:14, 17 December 2017 (UTC)
ChristianKl (✉) 12:39, 17 December 2017 (UTC)
- @Smalyshev (WMF): Can you have a look please? --Lydia Pintscher (WMDE) (talk) 17:39, 17 December 2017 (UTC)
- Indeed, for some reason these do not seem to appear in the index. I'll check what could be the cause. Smalyshev (WMF) (talk) 21:14, 17 December 2017 (UTC)
- Preliminary report - looks like indexing of these items failed due to some kind of lock issues, which likely were caused by DB problems. I see two spikes of such errors, on December 12th and 16th. We may need to see how to mitigate this - while we can't do much with database refusing to talk to us on the search side, maybe we could have it to be more resilient to such issues so they do not persist long-term. Smalyshev (WMF) (talk) 21:22, 18 December 2017 (UTC)
- In the meantime, I've manually reindexed all items I could see affected in the logs, so the items now should be fine. But I'll keep an eye on more instances of this issue and more long-term solutions to it. Smalyshev (WMF) (talk) 22:12, 18 December 2017 (UTC)
Mobile first
Ein Großteil der Nutzer greift im 21. Jhd. Mit Smartphones und Tablets auf Webseiten zu. Leider funktioniert aber Copy&Paste in Textfeldern bei Wikidata nicht im mobilen Safari oder Firefox auf iOS. Ich denke eine bessere Unterstützung auf mobilen Geräten wäre Zeitgemäß und fänd es sehr hilfreich, wenn diese Hürde abgebaut werden könnte. Ogmios (Tratsch) 16:49, 23 December 2017 (UTC)
- C&P im mobilen Android-Firefox funktioniert durchaus, es fehlt allerdings die Möglichkeit, Aussagen zu ergänzen/verändern/löschen. Das Wikidata Web-Frontend ist allerdings vornehmlich ein Werkzeug für die hier aktiven Editoren, und die werden vorwiegend am Desktop arbeiten. Anders als die Leser der Wikipedia sind die typischen Datennutzer von Wikidata aber nicht im Web-Frontend unterwegs, so dass hier Mobilfähigkeiten der Oberfläche nicht so wichtig wie bei Wikipedia sind. —MisterSynergy (talk) 17:04, 23 December 2017 (UTC)
- Also nehme am Wochenende und auf Reisen gerne nur das Tablet mit oder füge Informationen auch mal vom Smartphone hinzu. Und die schlechte Unterstützung der mobile Browser stört mich dabei gewaltig. Mag ja sein, dass die Masse durch Imports beigetragen wird aber die Usabilitybedürfnisse so abzutun halte ich für falsch. Offensichtlich ist ja diese Art des Beitragens erwünscht, sonst würde man dieses Frontend nicht bereitstellen und kontinuierlich verbessern und erweitern. Falls ich das doch falsch einschätze; sorry, dass ich diesen Bug gemeldet habe. Ogmios (Tratsch) 20:31, 23 December 2017 (UTC)
- Ich meine durchaus, dass man auch mobil alles an Wikidata-Objekten verändern können muss, und wenn das zurzeit nicht läuft, dann ist das ein Problem das eine Meldung hier verdient. Allerdings ist hier „mobile first“ einfach das falsche Stichwort, denn letztlich müssen hier bei Wikidata zuerst die APIs und dann die Desktop-Version gepflegt und optimiert werden, weil sie einfach um Größenordnungen wichtiger als das mobile Frontend sind. —MisterSynergy (talk) 20:54, 23 December 2017 (UTC)
- Es gibt im phabricator-Task phab:T95878 eine Timeline mit Aktivitäten zum Thema. Außerdem gab es diesen Vorschlag bei der 2016 Community Wishlist Survey im metawiki. —MisterSynergy (talk) 21:26, 23 December 2017 (UTC)
- Ich meine durchaus, dass man auch mobil alles an Wikidata-Objekten verändern können muss, und wenn das zurzeit nicht läuft, dann ist das ein Problem das eine Meldung hier verdient. Allerdings ist hier „mobile first“ einfach das falsche Stichwort, denn letztlich müssen hier bei Wikidata zuerst die APIs und dann die Desktop-Version gepflegt und optimiert werden, weil sie einfach um Größenordnungen wichtiger als das mobile Frontend sind. —MisterSynergy (talk) 20:54, 23 December 2017 (UTC)
- Also nehme am Wochenende und auf Reisen gerne nur das Tablet mit oder füge Informationen auch mal vom Smartphone hinzu. Und die schlechte Unterstützung der mobile Browser stört mich dabei gewaltig. Mag ja sein, dass die Masse durch Imports beigetragen wird aber die Usabilitybedürfnisse so abzutun halte ich für falsch. Offensichtlich ist ja diese Art des Beitragens erwünscht, sonst würde man dieses Frontend nicht bereitstellen und kontinuierlich verbessern und erweitern. Falls ich das doch falsch einschätze; sorry, dass ich diesen Bug gemeldet habe. Ogmios (Tratsch) 20:31, 23 December 2017 (UTC)
Search in text fields
Is it a bug that I cannot use simple search field for searching string values? For examples, [1] doesn't give me Karpinsk (Q145406). --Infovarius (talk) 12:08, 28 December 2017 (UTC)
- Those aren't indexed (yet). See phab:T163642. Sjoerd de Bruin (talk) 12:45, 28 December 2017 (UTC)