Property talk:P1630

Documentation

formatter URL
web page URL; URI template from which "$1" can be automatically replaced with the effective property value on items. If the site goes offline, set it to deprecated rank. If the formatter URL changes, add a new statement with preferred rank

Description

a URL-like string, such as "http://viaf.org/viaf/$1/", from which "$1" can be automatically replaced with the effective property value on items. For errors in proposals, see Category:Invalid formatter URL.

Represents

URL (Q42253), URL format string (Q114728334)

Data type

String

Domain

According to this template: Wikidata property (Q18616576) - one of Category:Properties with string-datatype

According to statements in the property:
Wikidata property for an identifier (Q19847637), unique identifier (Q6545185), Wikimedia template (Q11266439), Wikidata property to indicate a location (Q18615777), Wikidata property with datatype string that is not an external identifier (Q21099935), query (Q3428776), markup language (Q37045), Wikidata property for linking to a representative image (Q26940804), Wikidata property to link to Commons (Q18610173) or Wikidata property related to classification schemes (Q108566342)

When possible, data should only be stored as statements

Allowed values

Usage notes

use in statements on properties to generate links for external-identifiers and string properties;

Example

Wikidata (Q2013) → https://www.wikidata.org/wiki/$1
English Wikipedia (Q328) → https://en.wikipedia.org/wiki/$1
VIAF ID (P214) → https://viaf.org/viaf/$1
IMDb ID (P345) → https://wikidata-externalid-url.toolforge.org/?p=345&url_prefix=https://www.imdb.com/&id=$1
DOI (P356) → https://dx.doi.org/$1
Internet Content Provider Registration Record ID (P7477) → http://icp.chinaz.com/$1

Format and edit filter validation

Abuse filter #73

Robot and gadget jobs

AuthorityControl.js could use this property, instead of internal settings, to format a property value on items' pages

Tracking: differences

Category:Maintenance:URL formatting differs from Wikidata (Q22162660)

Tracking: usage

Category:Pages using Wikidata property P1630 (Q98131439)

// protocol

Tracked in Phabricator
Task T54253

Please do not use URLs like "//www.freebase.com". Use "https://www.freebase.com" instead. "//" is Wikimedia`s invention as I know. But this property will be used by external users too. This strange construction will confuse these users. Wikidata usage must not be thorny path. — Ivan A. Krestinin (talk) 21:09, 25 December 2014 (UTC)[reply]

Protocol relative URLs (//) are not a Wikimedia invention. They are defined in RFC 3986. --Fomafix (talk) 21:54, 25 December 2014 (UTC)[reply]

@Fomafix: Interesting standard, but a bit cryptic: it states "If a URI contains an authority component, then the path component must either be empty or begin with a slash ("/") character. If a URI does not contain an authority component, then the path cannot begin with two slash characters ("//"). In addition, a URI reference (Section 4.1) may be a relative-path reference, in which case the first path segment cannot contain a colon (":") character." This does not suggests that relative paths may begin with two slashes; other sections about relative references (section 5.1) also do not show a path starting with two slashes either. Can you quote a piece of that text clarifying such syntax? -- LaddΩ chat ;) 22:50, 25 December 2014 (UTC)[reply]

Section 4.2:

relative-ref  = relative-part [ "?" query ] [ "#" fragment ]
relative-part = "//" authority path-abempty

--Fomafix (talk) 07:40, 26 December 2014 (UTC)[reply]

@Ivan A. Krestinin: Why should protocol relative URLs not used? They are well standardized and supported. --Fomafix (talk) 22:42, 29 December 2014 (UTC)[reply]

You are right, this syntax is standardized. Some difficult cases: for example I have pages:

file://my_server/my_page.html
ftp://my_server/my_page.html

Links like '//www.freebase.com' will resolved to 'file://www.freebase.com' and 'ftp://www.freebase.com'. — Ivan A. Krestinin (talk) 06:45, 2 January 2015 (UTC)[reply]

Wikidata is only accessible via HTTP and HTTPs. Protocol relative links only reference these two protocols. Where do you see this problem? --Fomafix (talk) 10:28, 2 January 2015 (UTC)[reply]

Wikidata is open project. Data can be accessible using any protocol via third-party data clients. — Ivan A. Krestinin (talk) 10:35, 2 January 2015 (UTC)[reply]

Is this a real problem or a theoretical problem? The values from P1630 are not usable directly. They have to converted with the value of the wanted property. This convertation can also add the wanted protocol HTTP or HTTPS. --Fomafix (talk) 11:34, 2 January 2015 (UTC)[reply]

I meet this issue for locally saved reports of my bot. Conversation can be included to processing algorithms. But it must be included to the most algorithms. E. g. increasing data model complexity causes growing processing algorithms complexity. I think data model must be as simple as it possible. This makes data usage more simple. More simple usage — more clients count. — Ivan A. Krestinin (talk) 16:38, 2 January 2015 (UTC)[reply]

Protocol relative links are simpler than handling two separate links for HTTP and HTTPS. --Fomafix (talk) 17:20, 2 January 2015 (UTC)[reply]

Is there some applications that needs HTTP link? — Ivan A. Krestinin (talk) 17:24, 2 January 2015 (UTC)[reply]

If somebody cannot use HTTPS because of firewalls then keeping the current protocol improves the accessibility. --Fomafix (talk) 17:28, 2 January 2015 (UTC)[reply]

HTTPS is used by too many Internet resources. HTTPS blocking was possible some years ago. But not now as I think. — Ivan A. Krestinin (talk) 17:42, 2 January 2015 (UTC)[reply]

Handling of qualifiers

I noticed that the properties examples given for P1900 do not show proper URL formatting and thus played around with it in the sandbox, which suggests that the formatting works fine for statements but not qualifiers. Don't know how to fix that. --Daniel Mietchen (talk) 12:00, 14 July 2015 (UTC)[reply]

$

The current format pattern doesn't allow to have $ besides $1. Is there a reason for this? And what should we do with the formatter URL's on ZVG number (P679) and HSDB ID (P2062) which have $ in the URL. --Pasleim (talk) 11:54, 28 September 2015 (UTC)[reply]

I added them to the exceptions for now. --- Jura 12:06, 3 October 2015 (UTC)[reply]

(Hijacking an old thread) Eventually one probably have to reimplement the functionality in the lines of RFC 6570 - URI Template]. -- Gymel (talk) 10:54, 2 April 2016 (UTC)[reply]

https or http

There is some discussion at Property talk:P214 about whether to use http (suggested by some users) or https (preferred by WMF). --- Jura 09:52, 13 December 2015 (UTC)[reply]

Qualifier used by (P1535) = Q22348290

For formatter URL that have special code in MediaWiki:Gadget-AuthorityControl.js, I added the above to the statements.
--- Jura 10:56, 1 February 2016 (UTC)[reply]

Dofollow links to proprietary and for-profit targets

Tracked in Phabricator
Task T175230

I discovered today that Wikidata identifier links don't respect nofollow configuration. I wonder if users knew this when they set certain IDs to link for-profit, proprietary websites. --Nemo 06:01, 7 September 2017 (UTC)[reply]

Distinct values constraint

This property has correctly the constraint "Distinct values". Recently two properties has been created with the same URL formatter: P4767 (P4767) and cinematografo.it name or company ID (P4768). This doesn't make sense for me and I think they should be merged. Indeed for the website www.cinematografo.it there is no way for representing a company and a person with the same ID, instead we can, allowing P4767 and P4768 in the same item, that it's wrong. --Rotpunkt (talk) 13:02, 23 January 2018 (UTC)[reply]

It's a nonmandatory constraint. We use nonmandatory constrains when most of the values are expected to not violate the constraint. We use mandatory constraints when we don't want any value to be entered that violates the constraint. ChristianKl ❪✉❫ 13:23, 23 January 2018 (UTC)[reply]

It's possible to have the same formatter, but it might be a sign that we should have the same property. If the identifier are in the same numbers range, I think we should have just one. @ديفيد عادل وهبة خليل 2, ValterVB, Mahir256: who participated in its creation.
--- Jura 13:39, 23 January 2018 (UTC)[reply]
Sure, I’ve no objections to merging the two. Guess we shouldn’t have overlooked the common formatter URL, but I leave to @ValterVB: if different ‘categoria’ values in itwiki’s ‘Cinematografo’ template cause the other fields within the template to be sufficiently different to warrant two Wikidata properties. Mahir256 (talk) 13:50, 23 January 2018 (UTC)[reply]

I based my request of creation of property on the content of the template page in Italian wiki that don't reflect the site, when @Rotpunkt: warned me, I thought I still had some time, but property was created this morning so it's too late. Now if none has problem we can deprecate P4767 and use only P4768 for name and company. (@ديفيد عادل وهبة خليل 2, Jura1, Mahir256:) --ValterVB (talk) 19:03, 23 January 2018 (UTC)[reply]

Using from within WDQS

A rather nice code fragment from User:Multichill for using this within a WDQS query:

?item wdt:Pnnn ?value .
  wd:Pnnn wdt:P1630 ?fmt .
  BIND(IRI(REPLACE(?value,  CONCAT('(',?value,')'), ?fmt)) AS ?url) .

Try it!

Jheald (talk) 13:10, 19 February 2018 (UTC)[reply]

Or, alternatively, a slightly more straightforward approach:

?item wdt:Pnnn ?value .
  wd:Pnnn wdt:P1630 ?fmt .
  BIND(IRI(REPLACE(?fmt, '\\$1'  , ?value)) AS ?url) .

Try it!

Jheald (talk) 13:14, 19 February 2018 (UTC)[reply]

Or, alternatively again:

?item wdt:Pnnn ?id .
  wd:Pnnn wdt:P1630 ?fmt .
  BIND(IRI(REPLACE(?id, '(^.*)', ?fmt)) AS ?url) .

Try it!

Jheald (talk) 17:23, 29 October 2019 (UTC)[reply]

Removing advice on use of wd in URLs

After a short discussion, User:Thierry Caro added the following advice to this property: "You may use 'wd' whenever some part of the URL is needed but can be randomly set without breaking the link.".

Elsewhere it's been pointed out that this is possibly harmful from a privacy POV; it in effect stamps URLs as 'from wikidata', for no obviously good reason, and frustrates the intentions of users whose user agents do not send an HTTP referer ID.

I'd like us to change the advice such that we use a more neutral string. I appreciate the whole issue is somewhat marginal, but still... --Tagishsimon (talk) 16:35, 29 April 2018 (UTC)[reply]

Does Wikidata have a policy for affiliate, tracking, or referral links? Would it be useful for companies and organizations to know users are coming from Wikidata? Should we add ?utm_source=wikidata so Google Analytics and Piwik can attribute us as the referral source? This might make organizations more willing to partner with us. —Dispenser (talk) 10:48, 2 May 2018 (UTC)[reply]

I'm sure it would be useful for companies. Would it be useful for users? I hear facebook is hiring, Dispenser. --Tagishsimon (talk) 13:16, 2 May 2018 (UTC)[reply]

No idea where this came from. I don't think that should be in there either. Removed it for now.
--- Jura 16:45, 11 July 2018 (UTC)[reply]

Varying URL

The National Academy of Sciences helpfully changes the URLs for deceased members, without leaving a redirect. E.g., Carl Woese (Q310067) is at http://www.nasonline.org/member-directory/deceased-members/8899.html, but the formatter on National Academy of Sciences member ID (P5380) goes to http://www.nasonline.org/member-directory/members/8899.html. I assume there's no way to fix it, short of changing all the identifiers to something like "deceased-members/8899"? Ghouston (talk) 05:18, 14 August 2018 (UTC)[reply]

This property was only recently added, so there aren't actually many values to change, but it wouldn't look right. Ghouston (talk) 05:23, 14 August 2018 (UTC)[reply]

I changed the formatter URL into a search on their website instead. Ghouston (talk) 01:39, 18 August 2018 (UTC)[reply]

Alternative URL's based on regex match

I noticed that in cases where a property has multiple formatter URL's based on a regex match, the selection doesn't actually work.

E.g. in ISIL (P791), the first alternative in the list is for DE-.*, and it works correctly (German Music Archive (Q27901)). But as far I can see, the other alternatives don't actually format the URL if there's a match, e.g. US-.* in Library of Congress (Q131454), JP-.* in Noboribetsushiritsu Library Anisubunkan (Q61901152) or IT-.* in Biblioteca Gaetano Badii (Q3639588). How is it supposed to work? --Alicia Fagerving (WMSE) (talk) 12:18, 27 June 2019 (UTC)[reply]

Those aren't defined in MediaWiki:Gadget-AuthorityControl.js yet. --- Jura 17:49, 27 June 2019 (UTC)[reply]

Escaping special characters

99% Invisible (Q16001236) has a Commons category (P373) of "99% Invisible", which produces this broken URL: https://commons.wikimedia.org/wiki/Category:99%%20Invisible. The correct URL is https://commons.wikimedia.org/wiki/Category:99%25%20Invisible, i.e. with % escaped to %25.

This URL would work, however: https://commons.wikimedia.org/w/index.php?action=view&title=Category:99%%20Invisible — with the exact same string as a query parameter instead of a path segment.

Should the formatter URL of commons category be changed (since it works in this particular case)? Or does formatter URL need to learn how to provide url-safe variants of $1? --jleedev (talk) 20:54, 18 September 2019 (UTC)[reply]

I'd say the % character should be escaped when converting to a URL, and this would affect other properties besides P373. Ghouston (talk) 02:46, 19 September 2019 (UTC)[reply]

Some characters are now escaped; as a result the formatter for Heritage Gateway ID (P8169) doesn't work. Peter James (talk) 21:45, 2 July 2020 (UTC)[reply]

I would suggest that maybe we should be able to define a substitution for a given use of P1630 (perhaps using regex), that way we can fix a specific URL, for example for P8966 the [+] needs to be replaced with %2b for it to work on the destination site Back ache (talk) 08:59, 4 October 2021 (UTC)[reply]

I found other cases notably for links generated from the value given to Unicode character (P487), whose specific URL pattern should validate formatter URL (P1630): these URL patterns don't work for passing compatiblity characters in the replaced value of "%1", if they have canonical decompositions (including for example almost all "CJK compatiblity characters", except 12 of them, or control characters). Actually the URL takes a value which can be either a single Unicode character (provided it is equal to its NFC form, and it is not a control or any character reserved by the URL syntax, for which case it must be URL encoded; the other problem being that it must be UTF-8 encoded even before any possible URL-encoding), or an hexadecimal value with at least 2 digits (so that we can query any valid code point, including controls and compatiblity characters).

For now it's not possible to use any preformatter for passing the value in the query where the value may be either in the resource path, or in a query string parameter, or in the domain name (which has its additional restrictions), the choice of URL encoding type is not possible: current tools just sets the UTF-8 encoded value given in Wikidata to replace "%1" in the full URL, assuming this gives a valid result (and this is not always the case when the value is not a restricted subset of ASCII, such as plain identifiers with just ASCII letters or digits or a very limited set of punctuation signs, excluding any other space, underscore, slash, question mark, hash, asterisk, percent, ampersand...).

Additionally for some domains, there must be additional parameters to pass depending on the value: we need a way to specify conditional filters (matching a regexp) to set the proper URL correctly.

In most cases, the URL encoding should be done automatically by Wikidata tools (but then some existing Wikidata will no longer work if they have already been URL-encoded using some "%" sign). And several external URLs won't accept URL-encoded values, just plain ASCII. So we must cleanup properties using P1630 and review them: these properties should not just check the value (in Wikidata) with constraints, and specify a URL pattern, they must also have additional formatting properties (the URL-encoding for querystrings of the UTF-8 value should be the default format, but there should be other options to set the formatter, such as type of URL-encoding, character set and additional constraints for the acceptable character set if it does not accept every valid code point or if it will accept only strings in some Unicode normalized form, not necessarily NFC). Verdy p (talk) 20:45, 26 April 2024 (UTC)[reply]

How to add the formatter URL if two different language versions have different url?

How to add the formatter URL If two languages have different URLs and both are the main sources. Should only one must been added to the property formatter URL. Can anyone check on this property GRY-Online company ID (P7997)-❙❚❚❙❙ JinOy ❚❙❚❙❙ ✉ 07:09, 20 March 2020 (UTC)[reply]

Same problem for the Canadian Encyclopedia : Property:P5395#P1630. Can the URL format can be automatically selected with the qualifier P407 added to a particular id? As here: Q4671432#P5395. Simon Villeneuve (talk) 12:52, 24 September 2023 (UTC)[reply]

Escaping spaces to _ instead of +

Property:P2000 was originally defined as data type String, and was recently changed to data type External identifier. With that change, the formatter URL is no longer working, because now it converts any space in the parameter $1 into a + sign instead of an underscore (or a space, %20). How can I fix this? —capmo (talk) 15:25, 23 March 2020 (UTC)[reply]

Yes, I think the '+' escape can be used in forms, but not always in URLs, where %20 is correct. I suppose it's under the control of software and needs to be raised on Phabricator. Ghouston (talk) 21:19, 23 March 2020 (UTC)[reply]

It's mentioned in phabricator:T160281. Ghouston (talk) 21:27, 23 March 2020 (UTC)[reply]

Hi, thanks for the phabricator link, and for reporting this issue there! Until we have a definitive solution, I'll resort to using the wmflabs tool wikidata-externalid-url, as suggested in that thread. —capmo (talk) 14:02, 25 March 2020 (UTC)[reply]

Phab: Replace https://tools.wmflabs.org/wikidata-externalid-url by providing improved handling for external id formatter urls (November 2016)

Tracked in Phabricator
Task T150939

See phab:T150939 --- Jura 07:49, 1 October 2020 (UTC)[reply]

Phab: URL-encoding of external-id values in Wikidata frontend breaks (some) links (March 2017)

Tracked in Phabricator
Task T160281

See phab:T160281 --- Jura 07:49, 1 October 2020 (UTC)[reply]

Phab: Allow own Wikidata ID to be used inside the Formatter URL (March 2019)

Tracked in Phabricator
Task T218749

See phab:T218749 --- Jura 07:49, 1 October 2020 (UTC)[reply]

Phab: Support multilingual formatter url on Wikidata (August 2020)

Tracked in Phabricator
Task T259801

See phab:T259801 --- Jura 07:49, 1 October 2020 (UTC)[reply]

External identifier with two parameters

Hi, could i create external identifier which has two parameters? We are created Kramerius of Moravian Library UUID (P8752), but only for one digital library. In the Czech Republic we have more digital libraries with same identifier style. Some in same url of https://www.digitalniknihovna.cz/$2, where $2 is digital library code. Some on different URLs. And result with one external identifier (with UUID of scan and code of library) will be helpfull, but i don't know how to do. Skim (talk) 15:50, 29 October 2020 (UTC)[reply]

I don't think that this is possible directly, since the link is created by passing a single statement value to the formatter, substituting $1. The Usual alternative would be to create a separate property for each digital library. There's another method which could be used in theory, which is to use a property value which combines all of the information (library id and item id), and with a url formatter which goes to a custom service on Toolforge which would redirect to the right location. Ghouston (talk) 23:03, 29 October 2020 (UTC)[reply]

"Should have search formatter URL" constraint violations

Should this really be a constraint? There are a myriad of different sites that have formatter URLs without search formatter URLs. Enforcing this as a constraint seems a bit much. Elliot321 (talk) 01:17, 10 February 2021 (UTC)[reply]

Is there a sample where it's not possible ? --- Jura 17:28, 20 February 2021 (UTC)[reply]

Qualifier for redirects

For my application I need a way to distinguish between formatter urls that only a resolve an ID using a redirect and the ones that directly link to the correct url. I therefore propose to use the qualifier:

 has characteristic (P1552) → URL redirection (Q1236807)

as in Fandom article ID. Do you have a better Idea? --Shisma (talk) 12:02, 7 March 2021 (UTC)[reply]

I think we should replace P6262 with a property that doesn't need redirects. As there may be some reluctance to use URL-datatype, maybe an external-id with https://$1 as formatter? --- Jura 14:45, 26 March 2021 (UTC)[reply]

Qualifier for archive urls

For my application I need a way to distinguish between formatter urls that only a resolve an ID to an archived version of website and a regular website. I therefore propose to use the qualifier:

 has characteristic (P1552) → archive URL (Q105809893)

as in Mixer game ID. Do you have a better Idea? --Shisma (talk) 12:02, 7 March 2021 (UTC)[reply]

Scope

This property is currently only allowed for other properties. But there are cases when an element of an external DB acts as a property value, and a key value in this base acts as a qualifier. The most obvious examples: stock exchange (P414)/ticker symbol (P249) and website account on (P553)/website username or ID (P554). In such cases, it would be much more convenient to have the formatter in the items. It definitely can be done in the property with a qualifier like applies to part (P518), but the lists of such values are potentially not limited, so this can create inconvenience. I propose to extend the scope to some classes of items: database (Q8513), trading venue (Q179076), social networking service (Q3220391), etc. —putnik 12:13, 20 March 2021 (UTC)[reply]

Formatter URL cached

Lucas Werkmeister indicated on Telegram that "IIRC the formatter URL of a property is cached for up to 24 hours, and then after that all the item pages using the property also need to be purged (or edited)".

Alternatively you can use the script https://github.com/generalist/wikidata-misc, but to use this you need to wait 24 hours after updating the formatter URL in the property. Romaine (talk) 17:49, 28 November 2021 (UTC)[reply]

Software resource for formatter URL

I'm proposing to add software resource (Q110832782) as a valid type for this property. This would allow items like Instagram post (Q84497003) to have formatter URLs like https://www.instagram.com/p/$1/. This would need to be a subclass constraint instead of an instance constraint. AntisocialRya n (Talk) 13:10, 21 April 2022 (UTC)[reply]

Name change

Should this not be called "URL formatter", as it formats the URL? If it was a formatter URL, it would be a URL itself, which it specifically isn't. Same for the other properties like search formatter URL (P4354). -wd-Ryan (Talk/Edits) 03:30, 7 December 2022 (UTC)[reply]

@Push-f: Thoughts on this? You're good at semantics -wd-Ryan (Talk/Edits) 20:21, 11 December 2022 (UTC)[reply]

Thanks for bringing this up ... I had previously also noticed the awkward wording but couldn't be bothered to start a discussion about this.

I agree with your observation that the order in "formatter URL" is wrong. However I would also argue that "formatter" doesn't belong into the label at all.

Wiktionary defines formatter as:

One who or that which formats.

formatter URL (P1630) is a property ... a property doesn't do anything: a property gets used but it does not perform any actions (like formatting) since it has no agency.

So I would suggest the property to be relabeled to "URL format string" (or probably rather "URL format" for short).

"format string" is an established term, defined by wiktionary as:

A string of text characters serving as a template for other strings, such as dd/MM/yyyy for a date.

which I think fits perfectly. (Sidenote we even have format string (Q3748135) because the Italian Wikipedia has an article about format strings).

Cheers, --Push-f (talk) 20:39, 11 December 2022 (UTC)[reply]

I agree with "URL format string" because it is similar to what we're used to. Another option would be like "URL template string".

Also, I recently made format string (Q114771387), should it be merged with format string (Q3748135)? -wd-Ryan (Talk/Edits) 20:41, 11 December 2022 (UTC)[reply]

Yes I just merged it. I think "URL format" would suffice: I don't think including the datatype in the label is necessary since we don't have any other "URL format" properties of other datatypes.

--Push-f (talk) 20:44, 11 December 2022 (UTC)[reply]

There's also this item URL format string (Q114728334). If we change the property name it should be updated as well. -wd-Ryan (Talk/Edits) 20:46, 11 December 2022 (UTC)[reply]

I just updated that item. Sidenote: I don't think that we should create a same-named item for every URL format string property we have ... I think instead we should create the items for the URLs that are the result of the string formatting, e.g:

So URL format string (Q114728334) would end up being linked to all of our URL format string properties, which I think makes the most sense.

--Push-f (talk) 21:09, 11 December 2022 (UTC)[reply]

"URL format" sounds a bit ambiguous to me, I think either "URL format string" or "URL formatter" would be best. -wd-Ryan (Talk/Edits) 20:49, 11 December 2022 (UTC)[reply]

"URL formatter" is wrong semantically as I explained.

You do however have a point that "URL format" is ambiguous ... I didn't consider that but you might be tempted to qualify url formatclean URL (Q6451799) (we don't have such a property yet but it's not unthinkable).

So yes with that in mind I agree that "URL format string" would be best.

--Push-f (talk) 20:53, 11 December 2022 (UTC)[reply]

Alright nice, we agree but its a lot to rename (Items and Properties) so I'll wait for somebody else's opinion. Thanks! -wd-Ryan (Talk/Edits) 23:51, 11 December 2022 (UTC)[reply]

Separators added

I have added applies if regular expression matches (P8460) and language of work or name (P407) as separators to the single best-value constraint, because sometimes the value of a property, as well as the language being used, can change the URL format outside the actual property value as embedded in the URL, even if only slightly. This applies in Statistics Canada Geographic code (P3012), because the length of a code does just that, and no geography type is "preferred" over any other:

Geography type	Example	P3012 value	URL (P3012 value in bold type)	Applicable P3012 regex
province or territory of Canada (Q2879)	Ontario (Q1904)	35	https://www12.statcan.gc.ca/census-recensement/2021/dp-pd/prof/details/page.cfm?Lang=E&DGUIDlist=2021A000235	^(1[0-3]\|24\|35\|4[6-8]\|59\|6[0-2])$
census division of Canada (Q18810091)	Ottawa (Q1930)	3506	https://www12.statcan.gc.ca/census-recensement/2021/dp-pd/prof/details/page.cfm?Lang=E&DGUIDlist=2021A00033506	^(1[0-3]\|24\|35\|4[6-8]\|59\|6[0-2])\d{2}$
federal electoral district of Canada (Q17202187)	Ottawa Centre (Q3357743)	35075	https://www12.statcan.gc.ca/census-recensement/2021/dp-pd/prof/details/page.cfm?Lang=E&DGUIDlist=2013A000435075	^(1[0-3]\|24\|35\|4[6-8]\|59\|6[0-2])\d{3}$
designated place of Canada (Q956318)	Chalk River (Q5068811)	350066	https://www12.statcan.gc.ca/census-recensement/2021/dp-pd/prof/details/page.cfm?Lang=E&DGUIDlist=2021A0006350066	^(1[0-3]\|24\|35\|4[6-8]\|59\|6[0-2])\d{4}$
census subdivision (Q17457753)	Ottawa (Q1930)	3506008	https://www12.statcan.gc.ca/census-recensement/2021/dp-pd/prof/details/page.cfm?Lang=E&DGUIDlist=2021A00053506008	^(1[0-3]\|24\|35\|4[6-8]\|59\|6[0-2])\d{5}$

And if a French-speaking user accesses this, then "Lang=E" in the URL would be expected to be replaced by "Lang=F", and neither language is "preferred" over the other in general. By specifying a regex and noting what language in which the user wants to access the URL, the URL format can be reliably selected. - Denelson83 (talk) 08:12, 5 January 2023 (UTC)[reply]

Two-part question for aircraft registration (P426)

Hello! For aircraft registration (P426), I updated the FAA URL as the old one no longer functions, but the update doesn't seem to be propagating. Is there something else I should be doing to make the new URL work?

As for the UK Civil Aviation Authority URL, it too no longer points to a functioning URL. The new search page is at https://www.caa.co.uk/aircraft-register/g-info/search-g-info/, but I have no idea how to determine what parameter(s) need to be passed for it to work. I was hoping someone might have a suggestion.

Thanks! — Huntster (t @ c) 23:25, 6 January 2023 (UTC)[reply]

@Huntster: applies if regular expression matches (P8460) is not recognized by the Wikidata UI so it wouldn't do anything automatically - on the other hand aircraft registration (P426) has string datatype (not external-id) so the Wikidata UI also won't automatically apply a formatter URL for it. So I don't believe this would ever have worked, unless it's with some gadget that's not part of the standard UI. ArthurPSmith (talk) 16:49, 9 January 2023 (UTC)[reply]

@ArthurPSmith: So how is it being recognized when used in items like NASA 905 (Q116082679) or N103US (Q21043167)? Regardless, it does work, so why would the URL not be updating on item pages? — Huntster (t @ c) 17:37, 9 January 2023 (UTC)[reply]

@Huntster: doesn't work for me, there's no link that I see on the P426 values. You probably have the AuthorityControl gadget enabled, which does this all with javascript somehow. I don't think it looks at P1630 values. ArthurPSmith (talk) 17:56, 9 January 2023 (UTC)[reply]

@ArthurPSmith: Thank you for explaining that. You are correct, it is AuthorityControl. It's pretty incredible the added value that that one tool adds to the user experience, so much so that I forgot what the default experience was like. I see where the problem lies now.

Any ideas on the second part of the question, by chance? — Huntster (t @ c) 21:59, 9 January 2023 (UTC)[reply]

Using Wikidata label as parameter

I guess the answer is no but, is there any way for using an element label when creating the URL? I think could be useful in cases where the only alternative in the destination website is through their web search feature. —Ismael Olea (talk) 10:39, 20 July 2023 (UTC)[reply]

Property talk:P1630

Contents

Documentation

// protocol

Handling of qualifiers

$

https or http

Qualifier used by (P1535) = Q22348290

Dofollow links to proprietary and for-profit targets

Distinct values constraint

Using from within WDQS

Removing advice on use of wd in URLs

Varying URL

Alternative URL's based on regex match

Escaping special characters

How to add the formatter URL if two different language versions have different url?

Escaping spaces to _ instead of +

Phab: Replace https://tools.wmflabs.org/wikidata-externalid-url by providing improved handling for external id formatter urls (November 2016)

Phab: URL-encoding of external-id values in Wikidata frontend breaks (some) links (March 2017)

Phab: Allow own Wikidata ID to be used inside the Formatter URL (March 2019)

Phab: Support multilingual formatter url on Wikidata (August 2020)

External identifier with two parameters

"Should have search formatter URL" constraint violations

Qualifier for redirects

Qualifier for archive urls

Scope

Formatter URL cached

Software resource for formatter URL

Name change

Separators added

Two-part question for aircraft registration (P426)

Using Wikidata label as parameter

Navigation menu

Property talk:P1630

Documentation

// protocol

Handling of qualifiers

$

https or http

Qualifier used by (P1535) = Q22348290

Dofollow links to proprietary and for-profit targets

Distinct values constraint

Using from within WDQS

Removing advice on use of wd in URLs

Varying URL

Alternative URL's based on regex match

Escaping special characters

How to add the formatter URL if two different language versions have different url?

Escaping spaces to _ instead of +

Phab: Replace https://tools.wmflabs.org/wikidata-externalid-url by providing improved handling for external id formatter urls (November 2016)

Phab: URL-encoding of external-id values in Wikidata frontend breaks (some) links (March 2017)

Phab: Allow own Wikidata ID to be used inside the Formatter URL (March 2019)

Phab: Support multilingual formatter url on Wikidata (August 2020)

External identifier with two parameters

"Should have search formatter URL" constraint violations

Qualifier for redirects

Qualifier for archive urls

Scope

Formatter URL cached

Software resource for formatter URL

Name change

Separators added

Two-part question for aircraft registration (P426)

Using Wikidata label as parameter

Navigation menu

Search