Never show QID, always show human-readable text

[nicolas-raoul]

In Nearby, https://www.wikidata.org/wiki/Q11661218 is shown as "Q11661218" because no English name is available.
In non-English speaking countries, most items don't have an English name.
Showing a QID is the most user-unfriendly thing, we should always show human-readable text, in this order of preference:

• In the user's phone's language
• In the local language of the item (or one of the local languages, for multilingual places like Mauritius)
• In any language available. I believe all Wikidata items have at least a label in one language, the name of the article they were created from.

[misaochan]

Hm, the first few items of the Wiki Needs Pictures CSV file is in Japanese I think? Interesting that some items have a QID and some have the translated name.

Is this something we need to report to the Wiki Needs Pictures project, or can we fix it ourselves (say, by searching the Wikidata API for that QID or such?).

[nicolas-raoul]

I hadn't thought about implementation much.
We could either have only QIDs in the CSV file and then request Wikidata for local names, or embed all (or at least one) languages. If we (or wiki-needs-picture) build a dynamic server, we should be able to provide the user's preferred language in the web request.

We should indeed add an enhancement request to wiki-needs-picture once we agree on what we need.

[whym]

One quick option would be to dynamically retrieve sitelinks (and perhaps up-to-date labels) using the Wikidata API. [1]

For example, the jawiki sitelink of Q11661218 https://www.wikidata.org/w/api.php?action=wbgetentities&ids=Q11661218 gives you something similar to a Japanese label:

        "sitelinks": {
            "jawiki": {
                "site": "jawiki",
                "title": "\u9752\u5c71\u5186\u5f62\u5287\u5834",
                "badges": []
            }
        }

Even better, to avoid using data from every client, we could ask the project to include these sitelink titles in the CSV.

[1] https://www.wikidata.org/w/api.php?action=help&modules=wbgetentities

[tobias47n9e]

Another fallback would be to display the value of the p31 statement. Those should have the maximum amount of translations. So for a unknown bridge it would say:

A bridge (from p31 = Q12280; https://www.wikidata.org/wiki/Property:P31 and https://www.wikidata.org/wiki/Q12280).

[tobias47n9e]

I am wondering if it would be easier to switch to query.wikidata because we can customize the query in more ways, then through the list.

This for example would allow more fallback languages and the user specifying the distance they want to search:

https://query.wikidata.org/#%23%20Show%20the%20object%20missing%20images%20within%20500%20m%20of%20the%20user%0A%23defaultView%3AMap%0ASELECT%20%3Fplace%20%3FplaceLabel%20%3Ftype%20%3FtypeLabel%20%3Flocation%20WHERE%20%7B%0A%20%20wd%3AQ64%20wdt%3AP625%20%3FcustomLoc%20.%20%20%23%20Replace%20with%20current%20location%0A%20%20SERVICE%20wikibase%3Aaround%20%7B%20%0A%20%20%20%20%20%20%3Fplace%20wdt%3AP625%20%3Flocation%20.%20%0A%20%20%20%20%20%20bd%3AserviceParam%20wikibase%3Acenter%20%3FcustomLoc%20.%20%0A%20%20%20%20%20%20bd%3AserviceParam%20wikibase%3Aradius%20%220.5%22%20.%20%23%20km%20Radius%20for%20search%0A%20%20%7D%20%0A%20%20%3Fplace%20wdt%3AP31%20%3Ftype%20.%20%20%20%20%23%20Has%20a%20instance%20of%20statement%0A%20%20FILTER%20NOT%20EXISTS%20%7B%20%3Fplace%20wdt%3AP18%20%3Fimage%20%7D%20%23%20Has%20no%20image%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%0A%20%20%20%20bd%3AserviceParam%20wikibase%3Alanguage%20%22de%2Cen%22%20.%20%23%20de%20label%20has%20priority%2C%20en%20is%20fallback%0A%20%20%7D%0A%7D

We also get the instance-of target item, so we can match the Q-ID to the icon. It would also allow for really easy filtering. Only museums for example (in a 5 km radius):

https://query.wikidata.org/#%23%20Show%20the%20object%20missing%20images%20within%20500%20m%20of%20the%20user%0A%23defaultView%3AMap%0ASELECT%20%3Fplace%20%3FplaceLabel%20%3Ftype%20%3FtypeLabel%20%3Flocation%20WHERE%20%7B%0A%20%20wd%3AQ64%20wdt%3AP625%20%3FcustomLoc%20.%20%20%23%20Replace%20with%20current%20location%0A%20%20SERVICE%20wikibase%3Aaround%20%7B%20%0A%20%20%20%20%20%20%3Fplace%20wdt%3AP625%20%3Flocation%20.%20%0A%20%20%20%20%20%20bd%3AserviceParam%20wikibase%3Acenter%20%3FcustomLoc%20.%20%0A%20%20%20%20%20%20bd%3AserviceParam%20wikibase%3Aradius%20%225%22%20.%20%23%20km%20Radius%20for%20search%0A%20%20%7D%20%0A%20%20%3Fplace%20wdt%3AP31%20wd%3AQ7075%20.%20%20%20%20%23%20Has%20a%20instance%20of%20statement%0A%20%20FILTER%20NOT%20EXISTS%20%7B%20%3Fplace%20wdt%3AP18%20%3Fimage%20%7D%20%23%20Has%20no%20image%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%0A%20%20%20%20bd%3AserviceParam%20wikibase%3Alanguage%20%22de%2Cen%22%20.%20%23%20de%20label%20has%20priority%2C%20en%20is%20fallback%0A%20%20%7D%0A%7D

[nicolas-raoul]

(edited) My comment here was rather unrelated to QIDs, so I posted as a new issue:

#289

[whym]

I think the Wikidata approach is promising.

Some optimization/caching strategies might have to be devised to reduce the frequency of querying, though. It seems that Wikidata queries take some time for the server to compute, not just the client to retrieve.

It might be reasonable to do a "mid-size" query initially to construct a prefecture/city level table. The app can then show the (possibly a bit inaccurate) near-by list of the current location without delay, while simultaneously issuing a new query to update it and make it more accurate.

It should also be possible to combine the current implementation and the idea of updating. Having two kinds of backends might be more complicated, though.

[nicolas-raoul]

@whym : Is it really too slow?
If you have time, would you mind running queries in a few places and posting here the time it took? Thanks a lot!

[whym]

Okay, with a more close look, it seems mostly workable without complicated caching. It just can be slow, depending on the query.

http://tinyurl.com/hzt8glu 5 km radius for "Tokyo" - 1201 Results in 3881 ms
http://tinyurl.com/zuujxes 5 km radius for "Berlin" - 920 Results in 6887 ms

It appears a bottleneck is the number of results. As tobias47n9e suggested, if you add a filter (like "musely only"), the results will be less and the response quicker.

If we can allow the user to choose from various filters including entity types and radius sizes interactively, that would be great. (maybe with a hard limit on the number of results.) A 5 km radius might be too large (and too slow) for place like Berlin and Tokyo, while it shouldn't be too large for areas less covered by Wikidata.

[nicolas-raoul]

I asked about universal fallback but no satisfying answer yet:
https://www.wikidata.org/wiki/Wikidata:Project_chat#Label_language:_How_to_fallback_to_ANY_language.3F

[nicolas-raoul]

Sample showing how to get a Wikidata item's label in English if available and in any other language if no English label is available:
https://query.wikidata.org/#SELECT%20%3Fitem%20%28SAMPLE%28coalesce%28%3Fen_label%2C%20%3Fitem_label%29%29%20as%20%3Flabel%29%20WHERE%20%7B%0A%20%20%3Fitem%20wdt%3AP31%20wd%3AQ22674925%20.%0A%20%20optional%20%7B%3Fitem%20rdfs%3Alabel%20%3Fen_label%20.%20filter%28LANG%28%3Fen_label%29%20%3D%20%22en%22%29%7D%0A%20%20optional%20%7B%3Fitem%20rdfs%3Alabel%20%3Fitem_label%7D%0A%7D%20group%20by%20%3Fitem

[nicolas-raoul]

alemela/wiki-needs-pictures#20

[LarsSimonsen]

I believe there's room in the UI for more data anyway. Some properties are more useful than others for identifying an object. Here are a few suggestions:

*Label (if present; if not, try to find a label in a different language, or even resort to an Interwiki link)
*P21 (instance of, if present)
*P361 (part of, if present)
*P527 (has part, if present)
*P462 (color, if present)
*P465 (hex color, if present, perhaps displayed as a colored area on screen)

In the unlikely event that all these properties are present, maybe drop the least important ones. Or maybe just make more room vertically on the screen?

PS: An option to open the Wikidata item in the browser, if all else fails, would also be welcome.

[nicolas-raoul]

Thanks for the feedback, good ideas!

Note: Room in the UI is not a big problem. To get more space, when the item is clicked, a "details view" could open containing as many details as we want (Wikipedia article in a WebView frame, Wikidata properties in another tab, links to various map and streetview-type services, maybe even nearby existing Commons images, etc)

[nicolas-raoul]

@whym You will probably be interested in #289. I have found that SPARQL wikibase:box is much faster than AROUND. Let's continue the discussion over there.

[misaochan]

This should have been fixed, yeah?

[nicolas-raoul]

Yes, this is fixed!
I created a much lower-priority enhancement for the details: #729