This DOI doesn't work in the template. I tried several character encodings. It's in
Sea_level_rise#References. (
SEWilco 03:01, 22 May 2005 (UTC))reply
It may be a problem if the doi contains the string </nowiki>...
Paolo Liberatore (
Talk) 20:45, 29 November 2005 (UTC)reply
A DOI that is made specifically so that it doesn't work on wikipedia. That would be a sight!
Ansell 03:32, 8 April 2006 (UTC)reply
Numerous DOIs using the <,>,[ and ] characters will notwork on these templates.I am not sure how to force them to display properly. Numericla entities do not appear to work. See also
User:Circeus/Maple for two other examples.
Circeus 14:48, 25 July 2006 (UTC)reply
My problematic DOIs are 10.2179/0008-7475(2004)069<0230:SN>2.0.CO;2 and 10.1656/1092-6194(2005)012[0023:SASEOA]2.0.CO;2Circeus 14:55, 25 July 2006 (UTC)reply
It appears to be a MediaWiki bug, in that the character entity (which would be the correct way to do it) is terminating the link:
For problem URLs, you could add another variable and have one variable for the displayed value and one for the percent-encoded value. —
Omegatron 17:30, 11 August 2006 (UTC)reply
Add to template
Hi, this template is locked, so I thought I'd let someone know who has the permissions to add a bit of a "See also" section at the end:
==See also==
*[[Template:Doi-inline]]
Thanks.+
mwtoews 22:40, 22 December 2006 (UTC)reply
The documentation page is not locked. It's at
Template:Doi/doc. Feel free to edit that. It's transcluded into what you see on the
template:Doi page (add "?action=purge" to the end of the address line in your browser if it's not updated after your edit). --
Ligulem 23:47, 22 December 2006 (UTC)reply
Aha, that's cleaver. Thanks, that was new to me! Done.+
mwtoews 07:10, 24 December 2006 (UTC)reply
URL encoding
Is there a good reason why you have two separate parameters instead of just using http://dx.doi.org/{{urlencode:{{{1}}}}}? —
Omegatron 02:19, 18 February 2007 (UTC)reply
I think I tried and failed to get anything out of Whatever you did went wrong: you transcluded
Template:Urlencode instead of the magic word {{URLENCODE}}.. Besides, by now, we risk breaking too many uses of the template without real benefits.
Circeus 22:48, 19 February 2007 (UTC)reply
The problem is
bug 9031: urlencode does not treat < and > properly. --
Jitse Niesen (
talk) 10:36, 18 August 2007 (UTC)reply
This bug is fixed in newer MediaWiki versions (tried it today). In principle we could change the template. The documentation of urlencode templte states this, too:
Help:Parser_function#URLENCODE. --
Thetaphi (
talk) 19:30, 24 March 2008 (UTC)reply
haven't looked at this in a while. Can we fix it while remaining backwards-compatible? —
Omegatron 23:29, 24 March 2008 (UTC)reply
Can we have the output of the template be "DOI:" instead of "doi:" ? This is to bring this template in line with the {{
cite journal}} output. --
Rifleman 82 04:26, 22 October 2007 (UTC)reply
This is not good. DOIs should generally be treated as URIs and URIs should spell the "protocol"-part in lowercase (e.g. http: ftp: hdl: doi: urn:). This was discussed on German wikipedia, too and the spelling was changed to lowercase. I am member of one of the non-crossref DOI-supplying organizations (
http://www.std-doi.de) and we try to propse the URI notation of DOIs. Almost all publishers use doi:, examples from our field are:
doi:
10.1594/PANGAEA.55366,
doi:
10.1016/S0037-0738(99)00071-8. One example how to cite a DOI:
How to cite with DOI @ Elsevier --
Thetaphi (
talk) 13:05, 26 March 2008 (UTC)reply
By the way: {{
cite journal}} was changed to lowercase long time ago! --
Thetaphi (
talk) 13:15, 26 March 2008 (UTC)reply
Seems convincing, so I changed it back to use "doi:" . Thanks for your comment. --
Jitse Niesen (
talk) 14:22, 26 March 2008 (UTC)reply
IIRC, the offending doi displayed OK two weaks ago, I thus strongly suspect that the bug is caused by one of the recent changes to the template. Can someone revert it to the working March 26 version, and properly debug it before making further sweeping changes? —
EJ (
talk) 15:59, 14 May 2008 (UTC)reply
I have reverted. The reason id/label was implemented was that, for some reason, the #urlencode simply did not work (I think there's a bug filed for it, actually). Hence the new form made the link practically invisible.
Circeus (
talk) 21:45, 10 June 2008 (UTC)reply
Thanks. —
EmilJ.(formerly EJ) 09:23, 11 June 2008 (UTC)reply
Parameter “label”
I don't understand what the parameter “label” is good for. The version without this parameter produces exactly the same link as the one with the parameter:
{{doi
| id = 10.1175/1520-0442(2002)015%3C0487:SOCASI%3E2.0.CO;2
| label = 10.1175/1520-0442(2002)015<0487:SOCASI>2.0.CO;2
}}
{{doi
| id = 10.1175/1520-0442(2002)015%3C0487:SOCASI%3E2.0.CO;2
| label = 10.1175/1520-0442(2002)015<0487:SOCASI>2.0.CO;2
}}
Special characters (see
old version of doc) have to be replaced in the parameter “id” anyway. --
Leyo 22:11, 10 June 2008 (UTC)reply
At some points, it appears that the way urls are handled was changed at they now allow unescaped carets (I was not aware of this), which was not possible back in December/January. Any attempt to use the new format with brackets still broke the template, though, hence my revert. I'll just rewrite the current documentation to account for this.
Circeus (
talk) 23:28, 10 June 2008 (UTC)reply
Better now? Only square brackets require the id/label system.
Circeus (
talk) 23:32, 10 June 2008 (UTC)reply
Please have a look at the source code of my examples. Both types of brackets have to be replaced in the parameter “id” as shown
here. Like this, the link is working and the link text is correct, even without using the parameter “label”. --
Leyo 08:12, 11 June 2008 (UTC)reply
I looked at that and spent twenty minutes Monday fiddling and trying to figure out just what the heck was to be replaced by what in which parameters before giving up. Whatever one was supposed to do, the page was not clear enough about what it was.
Circeus (
talk) 17:25, 11 June 2008 (UTC)reply
I don't exactly understand what you mean. However, it seems that this parameter is not in use very often:
Template Tiger result. --
Leyo 19:05, 14 June 2008 (UTC)reply
However, if you follow the link below to
Template:cite doi you see two big warning signs telling you to use
Template:cite journal instead. Can this page be updated to reflect the new consensus? --
holizz (
talk) 13:39, 26 April 2015 (UTC)reply
Exactly. What's the difference? We still do know, two years later...
KDS4444 (
talk) 01:36, 13 August 2017 (UTC)reply
The template documentation given here explains how to use this template to produce a link to a DOI document without producing an error. Which is great. But it does NOT explain to an editor WHERE to use such a template, which means knowledge of correct application of the template is presumed. I have my own guesses, but it would be great if someone involved with this template provided at least a few sentences in the template documentation explaining where a person might want to use this template on Wikipedia. Thank you.
KDS4444 (
talk) 01:35, 13 August 2017 (UTC)reply
Template-protected edit request on 25 August 2017
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Please remove dx. from the template: "DOIs may be structured to use the default public DOI proxy server
https://doi.org (note that https is preferred over http, and that dx.doi.org, an earlier syntax, will remain fully supported but is no longer preferred)."
[3]Paradoctor (
talk) 21:25, 25 August 2017 (UTC)reply
A doi has two functions, right? (1) As an identifier, and (2) as a (more or less) stable link to a web page. I would question the sense of actually displaying the identifier in WP articles, as seeing the identifier has rather few uses that I can see, but it adds considerably to complexity and clutter, thereby distracting from what is really important. It is somewhat like using pi, in the sense that you can use pi in a calculation without needing to see the actual approximation being used. So, why not display doi links just as the term doi, without displaying the identifier bit? If someone really did want to see what the identifier actually is, for some reason, then they still have 3 easy options:
(1) Go into edit mode to see the doi link in full; or
(2) Use the 'Copy link address' facility on their browser; or
(3) Click on the doi link and see the full identifier on the linked web page.
Generally speaking, I would suggest that articles with lots of unnecessary identifiers showing is a bad idea.
Thoughts? Comments?
GruesomeBalls (
talk) 08:59, 3 November 2020 (UTC)reply
As with all identifiers, this would cause issues with copying text out of WP, or printing WP pages, or similar actions where having the actual DOI/ISBN/ISSN visible is helpful. –
Jonesey95 (
talk) 15:23, 3 November 2020 (UTC)reply
Same for copy-pasting the identifier into various citation tools, research tools, etc, without having to edit the page. Headbomb {
t ·
c ·
p ·
b} 16:13, 3 November 2020 (UTC)reply
@Headbomb Actually, no, the 'copy link address' facility on browsers would work fine. The only thing is that you wouldn't be able to copy the reference citation and the doi in one go. However, that would only be significant for wholesale copying. For an individual reference, it would take only a second or two longer
GruesomeBalls (
talk) 20:42, 3 November 2020 (UTC)reply
@Jonesey95 My above reply to Headbomb applies also to your comment. Printing would indeed be an issue, but I wonder how often people actually need hard copy dois? For a start, as a hard copy, the doi is *only* an identifier and not a link, so not very useful!
GruesomeBalls (
talk) 20:45, 3 November 2020 (UTC)reply
It's very useful. If I'm reading a printed document, and they mention a journal article with
A. Ali; G. Kramer (2011). "JETS and QCD: A Historical Review of the Discovery of the Quark and Gluon Jets and Its Impact on QCD". European Physical Journal H. 36 (2): 245. arXiv:1012.2288. Bibcode:2011EPJH...36..245A. doi:10.1140/epjh/e2011-10047-1. S2CID 54062126.
I'm not going to enter all of that information in a search engine. I'm going to plunk in the DOI in google (or Library search engine), and go from there. [Or arxiv, bibcode, etc.] Headbomb {
t ·
c ·
p ·
b} 02:25, 4 November 2020 (UTC)reply
You can still do that without seeing the doi! As I said, you just copy link address from a hyperlink which displays only as "doi", without seeing the identifier. My proposal makes no difference to how anyone uses a doi, only what they see.
GruesomeBalls (
talk) 03:13, 4 November 2020 (UTC)reply
Well, you're free to propose changes for this behaviour at
Help talk:CS1, but I don't think you'll find much support for the idea that
A. Ali; G. Kramer (2011). "JETS and QCD: A Historical Review of the Discovery of the Quark and Gluon Jets and Its Impact on QCD". European Physical Journal H. 36 (2): 245.
arXiv.
Bibcode.
doi.
S2CID.
I am not sure anything can be done about this but it should probably be noted that this also fails with interwikilinks, e.g.:
doi:10.1126/science. 1140516 renders the link with an underscore instead of a space. —
Uzume (
talk) 01:45, 7 December 2021 (UTC)reply
It might be better to give an example that has the possibility of linking to a valid DOI. –
Jonesey95 (
talk) 03:14, 7 December 2021 (UTC)reply
The example doi in this discussion was once a working identifier (with the space); it still works to some extent because you don't get the doi.org error page but rather you get a 404 error at science.org. I expect that that doi has been replaced with something else. Regardless, it is doubtful that the interwikilink form ([[doi:10.1126/science. 1140516]]) can ever be made to work because MediaWiki treats interwikilinks like any regular wikilink: urls are created from the wikilink syntax such that spaces (even when percent encoded) are replaced with underscores. And why is doi: an interwiki prefix anyway? The template works because it does not replace spaces with underscores. I suppose one might wander over to phabricator and propose that if non-mediawiki sites can be interwikilinked, the 'interwiki' urls created should not use underscores for spaces in the url.
I have hacked the sandbox to use {{
catalog lookup link}} so that the doi identifier can be marked as free-to-read in the same way that a free-to-read doi in a cs1|2 template can be marked: |doi-access=free. The
Template:doi/testcases failures are not really failures. The live version of this template does not trim whitespace from the doi so the leading whitespace in {{{1}}} (test 2) appears in the final rendering but {{catalog lookup link}} does trim whitespace so the whitespace is not rendered.
The sandbox version of this template supports the cs1|2 free access indicator which is accomplished by template styles so the sandbox rendering includes the necessary template styles stripmarker: