Is it possible to see the result of autosuggest from Wikidata reconciliation in a language other than English?

Hello,

Does anybody know if it is possible to see the result of autosuggest from Wikidata reconciliation in a language other than English? I tried typing in a few languages for input.
A few European language and Japanese work OKish as input (see screenshots below), if not perfect, but my main concern is the result is always English (by default). Maybe there is a way to specify the output language (i.e. entity, and more importantly description), which I do not know?

If this function is not implemented, I personally think it is a very important one, especially Wikidata tries to be language-independent (e.g. in terms of entity URIs), but user interfaces should support multilingualism.

Thanks for your attention!

Hi,

In the URL there is a lang code that you can change :

That is interesting, Nicolas. At what point should I perform that language customization in the URL? The window after the "Start reconciling..."? (> "Add standard service")

Iñaki

Yes, in the dialog where you are asked to select the service, you can also add a new service with the language of your choice.

We are aware that this isn't a great user experience as the feature is quite hidden. There is ongoing work on this:

Note: if you change the language of OpenRefine's UI, it should also automatically register a new version of the reconciliation service with the chosen language.

Thank you @Nicolas_VIGNERON and @antonin_d for support. Great. I managed to reconcile in different languages!

Last question: is is somehow much slower to get the results, if the language is other than English?

Similarly, it seems 1) is often much quicker than 2), probably because the latter is more complex:

  1. https://wikidata.reconci.link/en/suggest/entity?prefix={term}
  2. https://wikidata.reconci.link/en/api?queries={{"q0":{{"query":"{term}","type": ["Q6256"]}}}}

I understand 2) is slow (although the speed is not satisfactory in my experience), but is it so for the languages? Do you have similar experience?

I wouldn't expect the choice of language to make any difference in terms of performance.

Among the two requests you list, there is indeed a big performance difference, because they do different things: query 1 is just looking for any item whose label starts with the given term, whereas query 2 does a more thorough search (not just prefix) and adds type filtering (which is also costly).

@antonin_d Thank you. Maybe it was just a hicckup or my dev environment.

For the 1) and 2), I understand there is technical difference. BUT, from a user's point of view, I also would like to emphasize the users do not care what is behind. It is probably acceptable for heavy (advanced) users to wait a while during mass data reconciliation in OpenRefine. But, auto-suggest is another story. (Non-techie) users would expect fast response (max a couple of seconds), which is often not there in my experience. My impression is that users would leave the service, if it is tens of seconds to get the suggestion. So, ideally, 1) and 2) should show response within a similar time.

What I am working on is to use auto-suggest and SPARQL in sequence for a web app for (ordinary) end-users. Autosuggest with type is critical to narrow down the data in question, because the Wikidata entities are simply too many to choose from. If users can narrow down the scope, next SPARQL returns the final (query) results quicker. Otherwise, the users would get no results, too many results, or the worst, timeout.

So my expectation is fast response for autosuggest (with conditions). I hope this kind of use cases are taken into consideration, and the reconciliation will improve in the future. Cheers!

I think it would be great to have fast auto-suggest with type filtering, but it's not something that's up to OpenRefine. That's a feature request you could address to Wikidata directly, and then you'd be able to use their API without going through the reconciliation service (which is not designed for that) :slight_smile: