Template talk:MR

RFCs on citations templates and the flagging free-to-read sources

See

Headbomb {talk / contribs / physics / books} 17:07, 29 October 2016 (UTC)[reply]

Catalog lookup link

Though I am not in principle against the move to using {{Catalog lookup link}}, that template's use of the urlencode magic word seems to cause an issue for this template. For example: {{MR|96d:11071}} yields MR 96d:11071, failing to properly link to http://www.ams.org/mathscinet-getitem?mr=96d:11071 and instead links to https://www.ams.org/mathscinet-getitem?mr=96d%3A11071 (which fails).

@Matthiaspaul @Uzume Notice how the latter link works but the one generated from the template does not. Can we get this fixed? Thank you. 50.53.1.33 (talk) 01:45, 23 August 2017 (UTC)[reply]

@David Eppstein BTW, one might want multiple IDs when the record can be referred to by multiple IDs such as the one I put in the example section of the documentation (IDs 1333035 and 96d:11071 should both link to the same record in MSN). 50.53.1.33 (talk) 01:48, 23 August 2017 (UTC)[reply]

Those are, literally, exactly the same review, using their current format for review ids and their deprecated legacy format respectively. There is no reason to link both of them. And the legacy-format one doesn't even work, because the colon gets double-percent-encoded (turned into %3A, which would still work, but then into %253A, which doesn't) before it is sent to MathSciNet. Fortunately, the legacy id's seem to be rare — the first 20 articles I checked that use this template don't use them — so reverting your change back to a working version before fixing this bug is less urgent. A more plausible example (one I found in my checks) would be MR 0009016, MR0037277, MR0069787, MR0122834, MR0177027, MR0263581 for six different editions of the same book. I'm skeptical that that's the right way to format a sequence of these, those. —David Eppstein (talk) 02:00, 23 August 2017 (UTC)[reply]

Yes, but if you look carefully, the link only uses a single encoding. It is only once you select it that the other side seems to forward the link to the double encoded form. Methinks MathSciNet may have an issue here. You are probably right about the multiple ID example. That said, I believe the list separator could be specified to be something like |list-separator=, [[Mathematical Reviews|MR]]. I cannot try it out though due to the protection (and lack of a sandbox which I also cannot create). Which reminds me, why is this protected anyway? The last log message for protection (Special:Diff/488790453) mentions high-risk with over 100 translusions but clearly the transclusion count is in the 600+ range and not the 1000+ range. 50.53.1.33 (talk) 03:32, 23 August 2017 (UTC)[reply]

I figured out why it double percent encodes. Matthiaspaul changed it to use protocol relative URL links (which is pointless because all WMF sites now support https only so effective he has changed it to https). The urlencode in {{Catalog lookup link}} correctly does one encoding and the browser dereferences the link. Then MathSciNet pushes from https to http while doing another percent encoding. It is the second encoding that breaks the link so MathSciNet is definitely broken but we can avoid that by avoiding https (and protocol relative URL links). 50.53.1.33 (talk) 03:45, 23 August 2017 (UTC)[reply]

I reverted the protocol relative and after creating the sandbox and testcases subpages also implemented the list-separator suggestion by 50.53.1.33. Uzume (talk) 04:00, 23 August 2017 (UTC)[reply]

I didn't recognize their encoding problem as I didn't use old-style list items in my testing. Thanks for spotting this oddity! You guys probably have better connections to AMS/MathSciNet than me - will someone of you report that https bug to them so we can switch back to protocol-relative urls somewhen in the future? --Matthiaspaul (talk) 11:11, 23 August 2017 (UTC)[reply]

I agree AMS should probably fix this bug, however, I cannot agree we should move (back) to protocol relative URL links. Since all WMF projects now support only https, protocol relative links from WMF projects are effectively always rendered at https. Current consensus (though it might be a tad dated in light of MWF's move to https only) is to only use protocol relative when a target site supports both. See WP:PRURL for more information. AMS clearly does not support both for MathSciNet. 50.53.1.33 (talk) 19:14, 23 August 2017 (UTC)[reply]

Then I might have to work on the deprecated legacy format identifier tracking I mentioned below (after I get the doc and testcases updated). 50.53.1.33 (talk) 04:07, 23 August 2017 (UTC)[reply]

I will try reporting the bug to them. —David Eppstein (talk) 20:30, 23 August 2017 (UTC)[reply]

It further might be useful to add tracking for parameter values that contain the deprecated legacy format identifiers. We could then easily find and update them. 50.53.1.33 (talk) 03:49, 23 August 2017 (UTC)[reply]

Requested move 28 August 2017

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: moved. (non-admin closure) — JJMC89 (T·C) 21:12, 7 September 2017 (UTC)[reply]

Template:MathSciNet → Template:MR – Database scans show that this template is transcluded directly 182 times, whereas its redirect {{MR}} is transcluded 2467 times. {{MR}} is also more intuitive, in the same way that {{PMID}} is more intuitive than {{PubMed}} to create PMID links. Headbomb {t · c · p · b} 17:34, 28 August 2017 (UTC)[reply]

Snowy support as round-robin swap. I do support a swap, and I don't think it could be controversial, therefore I think we could snow-close this request earlier.

The only reasons why I removed the speedy deletion tag from the MR template yesterday was because the template is too old for speedy deletion and because the move can be carried out as round-robin swap without having to delete the page first. Thereby, the history will be preserved. (I can carry out the round-robin move.) --Matthiaspaul (talk) 01:14, 29 August 2017 (UTC)[reply]

Not sure what speedy deletion has to do with this, but there's nothing in the history of {{MR}} that needs to be preserved. Headbomb {t · c · p · b} 17:58, 29 August 2017 (UTC)[reply]

Uzume nominated the page for speedy deletion a couple of days ago, and I declined [1] because the page was created almost a decade ago and thus is too old for speedy. However, I was only waiting for Uzume's assuring feedback to go for the round-robin swap myself (as a WP:BOLD edit), but now that you have opened a formal move request, I hesitate to just go for it instead of waiting the 7 days - after all, the template clearly states "Don't move while the discussion is ongoing", and anyway I'm an involved editor now and closing the discussion earlier might be seen as inappropriate if there really is someone who would object the swap. ;-) So, caught by bureaucracy, should we wait or should we go for it per WP:IAR, what do you think? --Matthiaspaul (talk) 20:13, 29 August 2017 (UTC)[reply]

Really doesn't make much of a difference to me. I would have moved it myself, but I figured I'd give a change to the math people to speak up. Headbomb {t · c · p · b} 20:17, 29 August 2017 (UTC)[reply]

I don't have a strong opinion on which should be the primary name of the template and which the redirect. —David Eppstein (talk) 00:03, 30 August 2017 (UTC)[reply]

I am not sure what the age of a page (template or otherwise) has to do with speedy deletions as that was a G6 technical request. I requested the delete because there was no history worth keeping at the redirect (as is often the case). That said, whether the swap is accomplished via WP:BOLD (I did not think the move was objectionable so I went the WP:BOLD route) or WP:RM bureaucratic consensus, I believe the more appropriate name is {{MR}} based on the identifier name and not the database it links to. Uzume (talk) 16:26, 5 September 2017 (UTC)[reply]

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.