Page MenuHomePhabricator

Support multilingual formatter url on Wikidata
Open, Needs TriagePublic

Description

We currently use the formatter url property ( https://www.wikidata.org/wiki/Property:P1630 ) to take an identifier and make a url based on the identifier. For example on https://www.wikidata.org/wiki/Property:P650 the formatter url is https://rkd.nl/explore/artists/$1 . The property is used on https://www.wikidata.org/wiki/Q150679 (Anthony van Dyck) with contents "25230" which results in the url https://rkd.nl/explore/artists/25230 .

Some websites offer their contents in multiple languages. In the example https://rkd.nl/nl/explore/artists/25230 gives Dutch and https://rkd.nl/en/explore/artists/25230 gives English. We currently already add formatter url's for these language specific urls', see https://www.wikidata.org/wiki/Property:P650 and https://w.wiki/Yuk returns 1500+ hits.

The interface should be showing the url in my language or otherwise fall back to the default formatter url. So if I browse https://www.wikidata.org/wiki/Q150679 (Anthony van Dyck)"

For bonus points (or can be forked in a new task). Have fallback for language variant to main language, so en-us/en-ca would fallback to "en" and would get https://rkd.nl/en/explore/artists/25230 . This probably makes things (much) more complicated so I'm happy if it's left out in the first version.

Event Timeline

This would only affect the UI? How do we imagine this working in exports and APIs?

This would only affect the UI? How do we imagine this working in exports and APIs?

Is the formatter url currently used in export and APIs? If so, please explain how. Are you sure you're not mixing this up with the formatter URI (the other one) that produces the wdtn: links?

Yes I think you're right. But doesn't the same issue apply there?

Yes I think you're right. But doesn't the same issue apply there?

What issue? Export and API? AFAIK it's not used for that.

Ah so it's just about the UI on Wikidata? Ok I mixed that up. There are already other discussion to use different formatter URLs based on a regular expression to for example handle IMDB IDs better based on some criteria in the external ID. This all seems to become pretty messy because we'd then be mixing criteria based on the content with criteria based on the user consuming the content. Hmmmmm.

This affects the query service which uses the formatter URL to render the URI.

We support this issue being solved. Projekt Fredrika wrote a blog about the issue with examples: Suggestion: make Wikidata’s links to external data multilingual.

This affects the query service which uses the formatter URL to render the URI.

Are you sure about that? Are you sure your not mixing up formatter URL and formatter URI?