This is technically correct. The "articles" on wikidata.org actually have these titles. An API we can use to implement a special-case for Wikidata exists: https://www.wikidata.org/wiki/Special:ApiSandbox#action=wbgetentities&format=json&ids=Q42&props=labels%7Cdescriptions&languages=de&languagefallback=1&formatversion=2.

Possible questions to ask:

• Is this really the best possible API? https://query.wikidata.org/? https://www.wikidata.org/wiki/Wikidata:REST_API?
• How to make the two APIs reliably work together? Note that one works with titles but the other with item ids. This is not the same.
• We should probably show label and description as this is how Wikibase is designed (labels are not unique, but label + description is) and what users expect.
• We should probably enable language fallbacks, right?
• Do we need to take care of redirects?
• Do we need to work around the problem that the Wikidata APIs usually have a limit of 50?
• …

In T335363#8805053, @thiemowmde wrote:

• Do we need to take care of redirects?

I think the coordinates are from the item statements, and redirects cannot have statements (which leads to an answer of “no”). Am I wrong?

In T335363#8805053, @thiemowmde wrote:

• Is this really the best possible API? https://query.wikidata.org/? https://www.wikidata.org/wiki/Wikidata:REST_API?
• How to make the two APIs reliably work together? Note that one works with titles but the other with item ids. This is not the same.

MediaWiki core has an API endpoint that returns the actually displayed title, in case it’s overridden with {{DISPLAYTITLE:}}: action=query&prop=info&inprop=displaytitle. On Wikidata, this returns the Qid. Maybe Wikibase could hook into this API endpoint (consuming a standard uselang parameter), and Kartographer could use it? This way, Kartographer would not depend directly on Wikibase, and also the entity ID/page title discrepancy would naturally be solved. Even if the Wikibase part is not implemented, switching to the display title on all wikis (if it’s not already used) would be an improvement, because if a place intentionally uses a lower-case name, we should respect that.

• We should probably show label and description as this is how Wikibase is designed (labels are not unique, but label + description is) and what users expect.

Maybe this should also be done at all wikis – more and more things (mobile search autocomplete, Vector-2022 search autocomplete, VisualEditor link inspector etc.) use the description on Wikipedia, so why not also here? Of course, some descriptions make little sense if one looks at the map (e.g. Wall Street: Street in Manhattan, New York), but others are useful (e.g. Tiergarten (Berlin): Quarter of Berlin in Germany – and not a zoo).

In T335363#8805053, @thiemowmde wrote:

This is technically correct. The "articles" on wikidata.org actually have these titles. An API we can use to implement a special-case for Wikidata exists: https://www.wikidata.org/wiki/Special:ApiSandbox#action=wbgetentities&format=json&ids=Q42&props=labels%7Cdescriptions&languages=de&languagefallback=1&formatversion=2.

Possible questions to ask:

• Is this really the best possible API? https://query.wikidata.org/? https://www.wikidata.org/wiki/Wikidata:REST_API?

I'm fairly sure that you don't want to use the query service to get the labels. Rest API, maybe but it seems to me that using the code that is used elsewhere in Wikidata to get the label for a given page name seems best. Wondering if @ItamarWMDE
has thoughts.

• How to make the two APIs reliably work together? Note that one works with titles but the other with item ids. This is not the same.
• We should probably show label and description as this is how Wikibase is designed (labels are not unique, but label + description is) and what users expect.

Is the page name a link? Then I think you could get away without the description if you're space-constraint.

• We should probably enable language fallbacks, right?

I think that'd be what people would expect, yes.

• Do we need to take care of redirects?
• Do we need to work around the problem that the Wikidata APIs usually have a limit of 50?
• …

In T335363#8811478, @Lydia_Pintscher wrote:

• We should probably show label and description as this is how Wikibase is designed (labels are not unique, but label + description is) and what users expect.

Is the page name a link? Then I think you could get away without the description if you're space-constraint.

See screenshot in the description. The page name is a link, but space constraint doesn’t seem to be an issue here (at least not when descriptions are “normal-sized”; maybe descriptions could be cut off if they exceed 3-4 lines).

Is this really the best possible API? https://query.wikidata.org/? https://www.wikidata.org/wiki/Wikidata:REST_API?

I'm fairly sure that you don't want to use the query service to get the labels. Rest API, maybe but it seems to me that using the code that is used elsewhere in Wikidata to get the label for a given page name seems best. Wondering if @ItamarWMDE has thoughts.

The query service is probably too complex, for this use case, I agree. As for the REST API, that could be an option, but you would not be able to make a request to get the labels of a batch of IDs, rather only one request per ID. Therefore, the action API endpoint you mentioned is probably best as of now.