Jump to content

Template talk:NRHP row

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Edit request on 25 April 2012

[edit]

Due to recent changes to Template:Dts, transclusions of this template are placing many pages in Category:ParserFunction errors. The problem is when |date= is set to Not listed or another non-date value. To fix this, I propose adding a check to make sure the value of |date= is indeed a date before calling {{dts}}. For example, replace

{{dts|{{{date|}}}}}

with

{{#iferror: {{#time:Z| {{{date|}}} }} | {{{date|}}} | {{dts|{{{date|}}}}} }}

this will first check to make sure |date= is a valid date before passing it to {{dts}}, and if not, then just display it without passing it through to {{dts}}.

Example:

  • Unknown → Unknown
  • 4 July 2010 → 4 July 2010
  • July 4, 2010 → July 4, 2010

Use "view source" to see the hidden date strings if you want to check. 129.237.222.129 (talk) 18:38, 25 April 2012 (UTC)[reply]

 Done--Dudemanfellabra (talk) 19:05, 25 April 2012 (UTC)[reply]

Edit war

[edit]

It's quite disturbing to see something of an edit war regarding this template. The template is an important part of the Wiki Loves Monuments - US (WLM-US) photo contest.

There has been an extended discussion on this at WT:NRHP and, as I read the results 7 editors of the project support the inclusion of the upload button for the one month contest period (perhaps with some tweaks) and 2 editors do not support the upload button.

I'll also say that there is broad multi-lingual support for including the upload button. WLM is running in 35 countries this year, and to the best of my knowledge all of them are including an upload button.

WLM also has strong support at the Foundation level. Sue Gardner prominently mentioned it in her plenary speech at Wikimania. The WMF Board positively mentions WLM 4 times in the 2012-13 Wikimedia Foundation Plan.

The opposition to the upload button seems to misread a "non-consensus consensus" regarding a permanent type of upload button, that was specifically limited in its application and "reached consensus" only in the broadest possible use of the phrase (See Wikipedia:Centralized discussion/Image placeholders). Frankly, I don't think that discussion has any relevance to the current situation.

I'll inform WikiProject:NRHP at WT:NRHP and a couple of the folks who are helping to organize WLM-US and we can have a nice friendly discussion. If anybody thinks we have to have a broader discussion, please do it quickly, so that the discussion does not interfere with the contest, which starts on September 1. Smallbones (talk) 22:05, 13 August 2012 (UTC)[reply]

I think this is over. Discussion was moved to Wikipedia:Village_pump_(proposals)#Image_placeholders without notice, and it appears now that Wikipedia:Image placeholders is simply not a guideline and never was. Smallbones (talk) 16:16, 14 August 2012 (UTC)[reply]

Upload photo button

[edit]

Shouldn't the upload photo button be hidden on rows that already have a photo? Otherwise it adds length to the page without adding any utility. Powers T 18:51, 30 August 2012 (UTC)[reply]

The idea is to let folks upload a photo of any site they want, but is not an encouragement to replace all the old photos - of course if a new one is clearly better ...
I'm not sure that the button will be continued after the WLM contest. There are likely a number of reasons not too. Hope this helps. Smallbones(smalltalk) 04:44, 1 September 2012 (UTC)[reply]

article title addon feature to handle footnotes

[edit]

It's come up in discussion at wt:NRHP, specifically here, that the implementation of NRHP row in the last year caused the loss of footnotes attached to article titles in some (relatively few) NRHP list-articles. For one of these, the Syracuse NY list-article, there were 27 or so footnotes in this version before the NRHP row change was made. They indicated by symbol that a given row item was included in a Multiple Property Submission.

Technically, to restore such footnote indications, I think the NRHP row template would have to be amended by addition of another field, following the "article=" field, perhaps call it "article-addon=" or "article-append=, which would allow for appending anyting to what appears in the article title column already. E.g. so that rather than just Dinnie Apartments appearing, we could have Dinnie Apartments. I suspect that this would be pretty easy to implement as a change here. Comments? --doncram 19:05, 24 October 2012 (UTC)[reply]

Did you try the "name_extra" field? It was created to solve this problem. Multichill (talk) 20:02, 24 October 2012 (UTC)[reply]
example on how to do this. This footnote system confuses the hell out of me. Did the house die? Why can't I click it? Why can't I just go over it with my mouse to get more info? Some room for improvement here :-) Multichill (talk) 20:07, 24 October 2012 (UTC)[reply]
Doh! on me, about my not noticing the "name-extra" field. That's exactly what i was looking for. Thanks for your reply. And, yes, I agree it is not satisfactory that a person can't click on that. Surely the symbol should be made clickable, so that clicking on it would bring the reader to the Key at least. I'll try fixing up the Syracuse list-article again, including making those clickable. Thanks! --doncram 20:13, 24 October 2012 (UTC)[reply]
I updated the List of RHPs in Syracuse to use the name-extra field, and for the symbols to be clickable. How could they further be made to show a mouse-over message? --doncram 03:32, 29 October 2012 (UTC)[reply]

num-extra field to footnote from the number column

[edit]

I've tried but failed in editing the {{NRHP row/sandbox}} (linked sandbox) and {{NRHP row/testcases}} (the testcases) to try to create a num-extra= field, similar to the name-extra= field. This is needed to allow footnoting to keys to explain the HD, NHL, NHLD, other color types that are possible within the leftmost, colored, number column. Such footnoting was required by Featured List reviewers of the only three FLs of related National Historic Landmark list-articles: List of NHLs in Alabama, List of NHLs in Indiana, List of NHLs in Michigan. Such footnoting was used within NRHP list-article List of RHPs in Syracuse but was lost in NRHP row conversion. To bring any NRHP list-articles to Featured List this will also be needed, i expect. I'd like to get it working in the Syracuse list-article, and then share back to NRHP editors at still-current discussion wt:NRHP#MPS info in tables or not?.

MultiChill or other editors, could someone take a look at coding in sandbox to create this num-extra feature? --doncram 03:18, 15 November 2012 (UTC)[reply]

Nolatlon

[edit]

What is the purpose of the "nolatlon" parameter? I understand it bypasses the latitude/longitude logic, but why? What does it accomplish that isn't done if the "lat" and "lon" parameters are left blank? — Ipoellet (talk) 20:53, 17 March 2013 (UTC)[reply]

The inclusion of that parameter in the documentation is outdated. The parameter is no longer supported by the template. As such, I have updated the documentation.--Dudemanfellabra (talk) 22:12, 17 March 2013 (UTC)[reply]

Edit of 25 Feb. 2014

[edit]

Dudemanfellabra's most recent edit to this template is causing big red parser-function-error messages to appear in more than 100 (at least) articles in which the template is used—mainly, but not exclusively, in tables of former NRHP listings. See Category:ParserFunction errors. (Since the template is full-protected, an admin is required to revert or emend the changes.) Deor (talk) 01:13, 26 February 2014 (UTC)[reply]

I took a quick look and don't see any errors. Can you point out a specific page that has one? Jackmcbarn (talk) 01:22, 26 February 2014 (UTC)[reply]
Never mind, now I see some. Looking... Jackmcbarn (talk) 01:23, 26 February 2014 (UTC)[reply]
Done Changes reverted for now. Jackmcbarn (talk) 01:26, 26 February 2014 (UTC)[reply]
Done Jackmcbarn it is throwing errors on pages where they are listing "former" places. I've edited through an (edit conflict) with you to just comment out the code that is causing the issue. The problem is that they are listing two dates in one |date= parameter and then trying to use #time: to #ifexpr: test if the date is after a certain date. — {{U|Technical 13}} (tec) 01:35, 26 February 2014 (UTC)[reply]
I've edited the template to check if the date is actually a date first before testing. Problem fixed.--Dudemanfellabra (talk) 01:59, 26 February 2014 (UTC)[reply]

Commonscat

[edit]

Hi, I have started to chip away at the list Wikipedia:WikiProject National Register of Historic Places/Missing commons category links and including the categories in the lists like I similaraly do that on British listed building lists or similar lists on deWiki. I just have been made aware that the parameter does not even exist, so I doublechecked and the issue was discussed in Wikipedia talk:WikiProject National Register of Historic Places/Archive 57#Commons category links. Everybody thought it was a great idea and then obviously nobody implemented it. In the meantime the bot racked up a list of 2200 categories to be matched.

In short I propose the parameter commonscat to be implemented in line with the other listed building templates. An example of it in action can be seen at Grade II* listed buildings in West Oxfordshire.

I am not a particular good template coder but I think the code would be as follows: {{#if:{{{commonscat|}}}|[[:commons:Category:{{{commonscat}}}|More images]]}}|style="vertical-align:middle;text-align:center" {{!}}}} to be inserted right after the placement of the image. Agathoclea (talk) 20:23, 5 April 2014 (UTC)[reply]

see Wikipedia talk:WikiProject National Register of Historic Places#Revisiting Commonscat already done. Agathoclea (talk) 09:33, 22 April 2014 (UTC)[reply]
[edit]

I have started a discussion that will effect this template about the broken links to the "search" feature of the NPS website. The discussion his here.--ARTEST4ECHO (talk) 16:01, 29 May 2014 (UTC)[reply]

WLM-US to WSM

[edit]

"WSM" is Wikipedia Summer of Monuments. It's basically the same thing as Wiki Loves Monuments USA but with a longer upload period and participation by Galleries, Libraries, Archives and Museums. For more information see commons:Commons:Wikipedia Summer of Monuments and meta:Grant:PEG/WM US-DC/Summer of Monuments 2014. While the upload period is July 1–September 30 instead of September 1–September 30, I will respect consensus if people do not want the campaign upload button activated for three months. Harej (talk) 00:04, 24 June 2014 (UTC)[reply]

For more, see this thread at WikiProject NRHP. Harej (talk) 02:54, 24 June 2014 (UTC)[reply]

Template-protected edit request on 7 September 2016

[edit]

The Upload Wizard campaign for missing NRHP images currently links to the Summer of Monuments campaign, an event that took place a few years ago. Wiki Loves Monuments 2016 is now live, and I'm requesting that the Upload Wizard campaign be updated to this year's event by replacing Special:UploadWizard&campaign=wsm with Special:UploadWizard&campaign=wlm-us. Thanks! ~SuperHamster Talk Contribs 06:54, 7 September 2016 (UTC)[reply]

Done — Martin (MSGJ · talk) 08:26, 7 September 2016 (UTC)[reply]

Citing coordinates

[edit]

Can we add a |coord_extra= parameter so that an editor can add a citation or {{efn}} to the coordinates for a listing, similar to the existing |name_extra= and |refnum_extra=? — Ipoellet (talk) 03:54, 8 September 2016 (UTC)[reply]

"No article" option needed, and row anchor

[edit]

For cases where no article is wanted, such as some archeological sites where no information is available or expected, we want for the NRHP row to list the site but not create a wikilink. This template needs to allow for that.

A current example, where I wish to use such a feature, is for the Martin Site on the National Register of Historic Places listings in Powell County, Kentucky list. I redirected Martin Site (Stanton, Kentucky) to the list article. The list-article should show the site name, without that being wikilinked. (Currently it shows a bluelink, but that just goes to the redirect back to the list-article.)

Also I would like to put in a row anchor, so that the redirect comes to where intended within the table (the redirect goes specifically to National Register of Historic Places listings in Powell County, Kentucky#Martin Site), but usage of 'id="Martin Site"' is needed for that to work. (One example list-article with row anchors set that way is List of named corners of the Snaefell Mountain Course.).

I suppose that an old-fashioned row could be constructed that would appear as wished, but I expect that will mess up the NationalRegisterBot which relies upon regular structure in NRHP county list-articles, or mess up something else. --doncram 02:44, 5 March 2017 (UTC)[reply]

Is there a way to do this? I wish to remove a link which is a self-redirect. I left the article field empty, but the template took the name value and wikilinked that! Jay 💬 06:42, 11 April 2023 (UTC)[reply]

Badly formatted entries in tables

[edit]

Just wanted to give a ping about commons:Commons:Monuments_database/Unknown_fields/monuments_us_(en) which tracks parameters of this template which are unrecognized during the daily harvesting used for Wiki Loves Monuments (WLM). There are a few parameters which the WLM team need to support but most of the entries are simple typos resulting from a stray | character. USing the new "Source" column these should be fairly easy to track down and fix. /André Costa (WMSE) (talk) 12:30, 27 September 2017 (UTC)[reply]

[edit]

In this edit the upload link was removed. I see no consensus for removal. The campaign it links to provided us over 30.000 free images see also Wikipedia:WikiProject National Register of Historic Places/Unused images . Wiki Loves Monuments is currently running, so please restore so people can use these links. Multichill (talk) 20:28, 26 September 2018 (UTC)[reply]

Comment requested from B. I don't really have a strong position on this, but B made a couple of good points in the edit removing them. Ideally we'd have a WT:MOS or WP:VPPR discussion about this, though, as if they're okay here they'd probably be okay in a few other places. Enterprisey (talk!) 01:21, 27 September 2018 (UTC)[reply]
Wikipedia:Image placeholders were resoundingly rejected by the community every time they were discussed. I'd be very curious about the success of it. If you take out the people who are regular Wikipedians (who, presumably, would have uploaded their images whether there was an embedded upload link or not), what number of images have been contributed? (And what proportion of uploaded images later turned out to be copyvios?) If it could be restricted to only show up when you are logged in, there would be no objection. But something that always shows a link to upload an image is unencyclopedic and an invitation to upload copyvio images. --B (talk) 01:46, 27 September 2018 (UTC)[reply]
Chucking my two cents in from Wiki Loves Monuments in the United States: we do point participants to these tables as an option to find missing photos, and also so that they can conveniently use the provided upload link. I know it's utilized, but I unfortunately don't know the rate of utilization...for our post-event survey to our 1,500+ participants (>80% of which are first-time contributors), I can add a checklist asking what discovery methods were used, and hopefully that the will provide some useful insight. Within WLM, copyright violations do happen of course, but I don't think it's a particularly notable problem as we make it a point that it is a photography contest for people to submit their own photos.
I do get the MOS sentiment, but as long as the upload links are useful for WLM, I'm keen on keeping them. As new tools are being developed to find NRHP sites with missing photos (such as WLM Maps), the importance of the upload link in the NRHP tables will go down...but currently, I think the tables are still valuable for us. WLM Maps, which runs off Wikidata, is less up-to-date on whether or not a photo is on the Commons, and also requires a bit more graphical interactivity vs. just scrolling through a simple list. Maybe a solution could be to replicate these tables in an external tool and keep them synced with Wikipedia. ~SuperHamster Talk Contribs 06:31, 27 September 2018 (UTC)[reply]
 Already done by Pharos — JJMC89(T·C) 02:52, 27 September 2018 (UTC)[reply]

I'll also note that the consensus is mostly against "a dummy image designed to draw attention to the need for an actual image", which isn't what this is. A discussion seems like a good idea, but personally I think this isn't much of a problem. We have plenty of non-encyclopaedic notes and annotations in articles all over the place and there have been no reported problems as far as I know. —TheDJ (talkcontribs) 09:44, 27 September 2018 (UTC)[reply]

Wikidata coordinates

[edit]

This change to the sandbox version allows coordinates to be fetched from Wikidata, if a Wikidata id (Q-number) is provided and coordinates are not already specified in |lat=/|long=. As requested by User:Ɱ on my talk page. I'm leaving this note here in case anyone wants to discuss; if there are no objections I'll make the edit in a couple of days - Evad37 [talk] 03:56, 11 December 2020 (UTC)[reply]

Will this account for the error message that displays inline if lat/long are not present? ɱ (talk) 16:21, 11 December 2020 (UTC)[reply]
Only if the wikidata id is specified - otherwise the error message will still appear - Evad37 [talk] 23:14, 11 December 2020 (UTC)[reply]
Tested, looks good - though I think it broke the GeoGroup template here. ɱ (talk) 18:33, 11 December 2020 (UTC)[reply]
Working for me, at the moment. by "broke", do you mean the the thumnail map just displays a world map? If so, that's probably something to do with the servers taking a long time to generate the thumbnail image - Evad37 [talk] 23:14, 11 December 2020 (UTC)[reply]
@: Reported at phab:T269984 - Evad37 [talk] 00:00, 12 December 2020 (UTC)[reply]
 Done - Evad37 [talk] 07:02, 16 December 2020 (UTC)[reply]

fix template to drop linking of refnum to any URL, which almost always poorly serves readers

[edit]
See also related Template talk:NRISref#fix template to drop linking to any URL, and to properly convey the source is an offline database

It has been well-known forever (from the very beginning of the practice) among NRHP editors that {{NRHP row}}I's linkage for any given refnum to an NPS Focus or NPS Gallery webpage poorly serves readers. I didn't participate in the discussion but recall seeing comments pointing this out, at wt:NRHP, when the programming was originally done. The main programmer involved obviously liked the feature, implemented, and did not respond to what I perceived as consensus against it (as far as I recall); I believe that programmer is no longer involved in Wikipedia, has in fact been inactive for many years. It was requested that the linkage be optional, with some switch to turn it off for a given state where it was known not to work, or for an individual instance; that was not done.

For vast numbers of the cases, e.g. for every New York State usage (see any usage within List of RHPs in NY() it fails, bringing readers to the false statement that "The PDF file for this National Register record has not yet been digitized". It fails for all of Illinois and Ohio and I think for all of certain other states. It fails I think when the relevant document is an NHL nomination document rather than an NRHP nomination document. In states where it sometimes works, it fails for many other cases, including all recently NRHP-listed sites and all sites which were included in the NPS's program of weekly featured listings. Also for many states there exists a National Archives version of NRHP document which is linkable, but this is not recognized, not served up.

The imperfect linkage did serve some purpose for a while for many NRHP places not yet having articles; when the linkage actually worked to get to an NRHP nomination document PDF and the corresponding photos PDF, it did sometimes sort of help NRHP editors developing articles. But since then most articles have been created. And in every case where an article has been created, it is better for readers to click onto the article link itself, and find their way to actual proper citation of the PDF files. Where an article has not been created, it is often / usually the case that the link is not helpful, that it links to incorrect statements. And the correct focus of editing effort should be to create missing articles and include proper referencing to NRHP or NHL nomination documents.

Can we now please eliminate many tens of thousands of errors, by dropping the linkage from NRIS reference number in this template? --Doncram (talk) 21:56, 17 December 2020 (UTC)[reply]

I've always thought that linking to NARA is a way better idea, we'd just need a parameter for the wholly-different NARA identifier. NARA actually contains the NRHP nomination forms. As the National Park Service says, "The National Archives is the permanent home of our records and everything will eventually be in the National Archives." Writing/editing NRHP articles only in New York and Ohio has been frustrating because of this disconnect! ɱ (talk) 23:53, 17 December 2020 (UTC)[reply]
As well, adding my own NARA link to NRHP infoboxes creates an error message, even though it's an improvement over the "not yet digitized" NPS Focus link. And I've been criticized over this and forced to use {{Infobox historic site}}. This error message needs to be removed, promptly. ɱ (talk) 23:59, 17 December 2020 (UTC)[reply]
I recall our discussion about this over at Cincinnati Union Terminal; sorry - I have more patience and understanding for the process and details now. Default links still do need changing, and options added to include NARA when it has more information. Eventually I'll more formally propose changes to the NRHP infobox, but that's not too relevant to this discussion here... ɱ (talk) 00:14, 18 December 2020 (UTC)[reply]
Ah, , about Cincinnati Union Terminal, congrats on developing that to earn Good Article status! Yes, I see our July 2019 discussion at Talk:Cincinnati Union Terminal#Infobox error, and I agree that refining {{infobox NRHP}} in several ways sounds like a good idea. Not sure immediately if adding a NARA link to that infobox helps, although I think in general adding some NARA document link to every NRHP article somewhere in the article would be great. Perhaps using some complicated bot run to add a NARA document version link as an alternative in regular references to NRHP documents that might currently link to the NPS version would be possible? And/or a bot run to convert zillions of separate NRHP document references typically named "nrhpdoc" into a standard NRHPdocref template call, to which a NARA parameter could be added? Hmm, about this, will open wt:NRHP#a template for standardized NRHP and NHL document references, please comment there.
But here, we are agreeing: the default links here need changing. Thanks! --Doncram (talk) 01:45, 18 December 2020 (UTC)[reply]
Awesome. A lot of ideas, will await further input. I do however strongly utilize nomination forms, even on existing articles, to expand upon stubs, look at historical imagery, and just read more details - especially these NARA files contain some excellent background information outside of the nomination form itself. I strongly encourage the nominations to be linked in the infobox, where they can be easily found and accessed. Replacing the NPS Focus link in the refnum parameter with two parameters - one for refnum and one for NARA refnum, that would together generate the NRHP refnum with a link to the NARA document - would be ideal. ɱ (talk) 02:55, 18 December 2020 (UTC)[reply]
, to clarify, about here, you agree with dropping the current linkage from the refnums toward NPS Gallery pages which were hypothesized by programmer to be useful but in fact have serious problems (fail to reach what was intended about 50 percent of time, by my estimate; when "succeed" deliver negative value to reader by diverting from better coverage available in article using sources in context; maybe possibly sort of help NRHP editors about 1 percent of time or less when articles non-existent yet the linkage reaches useful sources). But you favor linking from the refnums toward NARA document links which you would hypothesize to be successful reaching useful documents, what, 100 percent of the time? I doubt that is achievable. It's an empirical question what percent of time it would reach a document at all, much less one not used, better, in the corresponding article already. So I don't perceive that hopefully linking to NARA worthwhile, at least not yet. But pursuing initiative at wt:NRHP#a template for standardized NRHP and NHL document references could establish percentages about NARA linkages working; it would be reasonable for "secondbot" mentioned there to build a massive table of links from NRHP refnums to NARA locations, and the percentage of proper hits/matches could be established. And then the separate/new/different idea of linking to NARA from template:NRHP row could be revisited. For now, I just want to remove 60,000 or so errors dis-serving readers. --Doncram (talk) 06:03, 18 December 2020 (UTC)[reply]
@Doncram: who is this mysterious inactive programmer person you're referring to?
I see links like https://npgallery.nps.gov/AssetDetail/NRIS/87002028 as the reference that something is actually listed (and not something we made up). Maybe style it more in that way and make it less prominent? Multichill (talk) 16:58, 19 December 2020 (UTC)[reply]
Okay, sure, I that is a Massachusetts state example... the link in fact fails for all or nearly all NRHP listings in Massachusetts, because the state and probably also NARA, but not NPS, host the NRHP nomination documents. In fact i think it is truly horrible to direct readers interested in "Sankaty Head Light" to https://npgallery.nps.gov/AssetDetail/NRIS/87002028:, where they are confronted with two false statements that "The PDF file for this National Register Record has not been digitized". In fact it exists as a 7 page PDF about "Number 35: Sankaty Head Light" out of a group of Massachusetts lighthouses that were studied and then listed on the National Register. (Side comment: actually the 7-pager should be read in conjunction with the main/introductory portion of the "Lighthouses of Massachusetts Thematic Resources" study report, which also was long ago digitized, and happens to be available at https://npgallery.nps.gov/NRHP/GetAsset/NRHP/64000282_text.) I think the 7-page document about "Sankaty Head Light" is not linkable, but I just accessed it by searching within https://mhc-macris.net/ (select Nantucket, select structures), which is linked within the Sankaty Head Light article's reference to the document. (And I think it is also available also at NARA, although very slowly loading, at https://catalog.archives.gov/id/63792341....yes the 7 pages and more related pages including correspondence and further exerpts from the Lighthouses study are there.) Anyhow it is HORRIBLE HORRIBLE HORRIBLE to direct readers to go to the dead end instead. Wikipedia NRHP and/or lighthouse editors have gone to good lengths to look for sources, including chasing down that dead end already, and providing good information in the article. The link misdirecting readers needs to be eliminated, not made "less prominent".
About who put it in the linking, whom I was referring to, I thought that was "Dudemanfellabra". I haven't confirmed that directly, though I see their having edited in the edit history, after [[template;NRHP row}} was created by Multichill, actually, I see now. (Creating this and related templates to standardize NRHP list-tables, was a good thing, which I supported when Multichill proposed doing it, as I recall).
Okay, further I see now that the template in fact does allow for delinking the bad link, by use of option "|nolink=yes". At a minimum, the linking should be OFF by default. But in fact it should just be off always. If an editor goes and finds decent stuff at the location which would be linked, yet somehow that stuff is not yet in an existing article, then they should develop the existing article. (Or if there is decent info but no article then they should create the article.) It would be okay for a programmer to build a big non-mainspace list of all such links, and to suggest an editing campaign to check whether somehow some of the working ones might have not yet been used in articles. But that does not belong in mainspace. And frankly it doesn't help any of the relatively prolific NRHP article writers, who know where the documents are. How to find the documents is well enough written up in wp:NRHPHELP for everyone, by the way.
Thanks, User:Multichill, for commenting. --Doncram (talk) 22:57, 19 December 2020 (UTC)[reply]
I concur that continuing to link to NPGallery/Focus is a bad idea. Firstly because of the myriad issues raised above, and secondly because the Park Service has as much as told me that they aren't really maintaining it anymore, directing me to NARA records instead. (It contains no new records since c. 2013.)
The problem with creating links to NARA is that they involve entirely new unique identifiers, which would have to be cross-referenced to NRIS refnums, or a new field would be needed on {{infobox nrhp}} for NARA catalog id, which we could render as a link into catalog.archives.gov. Creating a map of catalog->refnum could be done programmatically, but it's not entirely trivial, and would be a necessary first step in creating a refnum->catalog mapping. (Interested programmers can read the gory details of the NARA Catalog API here.) Magic♪piano 15:40, 21 December 2020 (UTC)[reply]
@Magicpiano: I think I found, at least for Ohio, that NARA-hosted nomination forms are hosted at: "https://s3.amazonaws.com/NARAprodstorage/lz/electronic-records/rg-079/NPS_OH/09000442.pdf" (substituting the last digits for whatever NRHP reference number it is), where you don't even need the NARA ID. Some other states might be different it seems, but at least I can use it for my Ohio articles, and it may work for some others... ɱ (talk) 21:29, 22 April 2021 (UTC)[reply]

Important break

[edit]

@Magicpiano: and @Doncram: seeing as we all agree on using NARA files as long as they're linkable, I think I have a part-solution. So until/unless we find a way to consistently link to NARA across all NRHP lists, we can give users the option to provide their own links. Take a look at the first example at NRHP in Columbus, where I link directly to NARA. I had some help in template editing, and can make this option live if you support it. ɱ (talk) 23:01, 22 April 2021 (UTC)[reply]

Hi, thanks for following up, and sharing that approach to linking which you think works for many Ohio sites, as in https://s3.amazonaws.com/NARAprodstorage/lz/electronic-records/rg-079/NPS_OH/75001398.pdf for American Insurance Union Citadel (the first listing in the NRHPs in Columbus page).
Could you clarify please what you mean by "we can give users the option to provide their own links"?
Hmm, I see that the first row uses template:NRHP row/sandbox instead of template:NRHP row, and it allows for a "link=" row that is hard-coded for this document:

|link=[https://s3.amazonaws.com/NARAprodstorage/lz/electronic-records/rg-079/NPS_OH/75001398.pdf #75001398]<!-- Additional documentation with added address: 2017-03-23 -->

Yes, at least that should be possible, i.e. if a user wants to add a "link=" item, then that should be used by "NRHP row" instead of what it does use.
It remains that what NRHP row does use should be cancelled everywhere; it would be an improvement if it is changed to give no link unless a specific link is given.
But perhaps something better is possible, perhaps a NARA link that should usually work?
Are you proposing that the second url, which currently is https://npgallery.nps.gov/AssetDetail/NRIS/11000711 which fails to link to anything, be changed to https://s3.amazonaws.com/NARAprodstorage/lz/electronic-records/rg-079/NPS_OH/11000711.pdf, and similarly for all other Ohio usages of template:NRHP row? And similarly for all other NRHP row usages in all states, but try changing "NPS_OH" to "NPS_NY" for New York State ones, etc.? I certainly wonder what is the "rg-079" code.
Testing for first one in National Register of Historic Places listings in Bernalillo County, New Mexico:
It sounds like you are not confident that will work often or at all in other states. And I believe NARA does not yet have NRHP documents for all states. The status about which states are mostly covered is supposed to be shown at wp:NRHPHELPNARA.
wp:NRHPHELPNARA reports that as of 2019 all states were at least in progress, except for New Jersey and Tennessee.
  1. Try first one in Alabama: https://npgallery.nps.gov/AssetDetail/NRIS/99000150 fails, but https://s3.amazonaws.com/NARAprodstorage/lz/electronic-records/rg-079/NPS_AL/99000150.pdf does it work? Yes!
  2. Try first one in Alaska: https://npgallery.nps.gov/AssetDetail/NRIS/80000739 fails, but https://s3.amazonaws.com/NARAprodstorage/lz/electronic-records/rg-079/NPS_AK/80000739.pdf does it work? Yes!
  3. Try Arkansas: https://npgallery.nps.gov/AssetDetail/NRIS/10000783 fails, but https://s3.amazonaws.com/NARAprodstorage/lz/electronic-records/rg-079/NPS_AR/10000783.pdf does it work? _NO_
But, per User:Vami_IV's direction at current wt:NRHP discussion on NARA vs. NPS to check the document URL in the "download" arrow option at NARA's page for the site (thanks!), the link is https://catalog.archives.gov/OpaAPI/media/26141446/content/electronic-records/rg-079/NPS_AR/10000783.pdf. As for Cactus Hotel and Texas ones, that requires knowing the NARA catalog number in addition to the refnum. --Doncram (talk) 02:44, 23 April 2021 (UTC)[reply]
  1. Try California: https://npgallery.nps.gov/AssetDetail/NRIS/01000826 fails, but https://s3.amazonaws.com/NARAprodstorage/lz/electronic-records/rg-079/NPS_CA/01000826.pdf does it work? Yes!
  2. Try Colorado: https://npgallery.nps.gov/AssetDetail/NRIS/06000916 fails, but https://s3.amazonaws.com/NARAprodstorage/lz/electronic-records/rg-079/NPS_CO/06000916.pdf does it work? Yes!
  3. Try Connecticut: https://npgallery.nps.gov/AssetDetail/NRIS/10000492 fails, but https://s3.amazonaws.com/NARAprodstorage/lz/electronic-records/rg-079/NPS_CT/10000492.pdf does it work? Yes!
  4. Try Delaware: https://npgallery.nps.gov/AssetDetail/NRIS/71000220 fails, but https://s3.amazonaws.com/NARAprodstorage/lz/electronic-records/rg-079/NPS_DE/71000220.pdf does it work? Yes!
  5. Try District of Columbia: https://npgallery.nps.gov/AssetDetail/NRIS/04000625 fails, but https://s3.amazonaws.com/NARAprodstorage/lz/electronic-records/rg-079/NPS_DC/04000625.pdf does it work? Yes!
  6. Try first entry in New York: https://npgallery.nps.gov/AssetDetail/NRIS/80002577 fails, but https://s3.amazonaws.com/NARAprodstorage/lz/electronic-records/rg-079/NPS_NY/80002577.pdf does it work? Yes!
  7. Try first in Texas: https://npgallery.nps.gov/AssetDetail/NRIS/82001735 fails, but https://s3.amazonaws.com/NARAprodstorage/lz/electronic-records/rg-079/NPS_TX/82001735.pdf does it work? NO, as suggested below.
Try format of Cactus Hotel one instead: https://catalog.archives.gov/OpaAPI/media/40973597/content/electronic-records/rg-079/NPS_TX/82001735.pdf does it work? Actually it can't work, because the string needs the NARA catalog number for this site, it cannot reuse the catalog number that is for Cactus Hotel. --Doncram (talk) 02:10, 23 April 2021 (UTC)[reply]
To make a request for programming to be done at wp:BOTREQUEST, it would be nice to know more about the patterns that should work in all states, which one could possibly find out from contacting the right person/department at NARA.
Another question for a BOTREQUEST, is could the bot-run itself test whether a given NARA link works, and if it does not then don't show anything?
We still need to enable an override to use a specific link, no matter what. Thanks for making progress!
--Doncram (talk) 01:28, 23 April 2021 (UTC)[reply]
P.S. Also should allow for 2 or more links, when a listing has two or more refnums. It is a disservice sometimes to link to the first, very incomplete NRHP document when much better, more comprehensive later ones are available. --Doncram (talk) 01:50, 23 April 2021 (UTC)[reply]
Hi Doncram, yes I see you broke down what I did here. Of course the end goal is to have it work for every state. The only one I tested outside of Ohio was Cactus Hotel did not work, as it instead utilizes "https://catalog.archives.gov/OpaAPI/media/40973597/content/electronic-records/rg-079/NPS_TX/84001999.pdf". It's possible all of Texas's NARA forms are hosted on catalog.archives.gov versus amazonaws. So perhaps the template could create URLs from different hosts depending on which state it is... Regardless, I will implement the "|link=" parameter on the non-sandbox version now? ɱ (talk) 01:48, 23 April 2021 (UTC)[reply]
I'm not sure I'd consider links to Amazon AWS as necessarily durable. What happens if NARA decides to change its cloud vendor? I would consider a link to catalog.nara.gov to be somewhat more durable. It may be that the links MJ found are acceptable as a short-term alternative.
By the way, I believe the NARA catalog is live for all states and other geographies (since at least last year). WP:NRHPHELPNARA just hasn't been updated. Magic♪piano 01:49, 23 April 2021 (UTC)[reply]
Well rather than hard-coding one or more long strings that might be changed (though we can all hope that NARA has more commitment to keep URLs working), it would be better to use a very simple template for each of the choices.
So rather than

|link=[https://s3.amazonaws.com/NARAprodstorage/lz/electronic-records/rg-079/NPS_OH/75001398.pdf #75001398]<!-- Additional documentation with added address: 2017-03-23 -->

it should be a call like

|link=[{{NaraStringOH}}75001398.pdf #75001398]

where NaraStringOH returns "https://s3.amazonaws.com/NARAprodstorage/lz/electronic-records/rg-079/NPS_OH/". --Doncram (talk) 01:56, 23 April 2021 (UTC)[reply]
Sounds great. I will ask about implementing multiple links when there are multiple forms... ɱ (talk) 01:57, 23 April 2021 (UTC)[reply]
Wouldn't |link=[{{NaraStringOH}}75001398.pdf #75001398] and [{{NaraStringOH}}9999999.pdf #999999] work? (or use a comma) ɱ (talk) 01:58, 23 April 2021 (UTC)[reply]
And right now do we really not even have a way to include multiple refnums built into nrhp row? (without throwing it in the description column or manually via refnum_extra, which is poor as it forms outside the parentheses!) ɱ (talk) 02:00, 23 April 2021 (UTC)[reply]
In re "we can all hope that NARA has more commitment to keep URLs working": the durable link that NARA is presumably committed to maintaining is the one into the catalog, e.g. https://catalog.archives.gov/id/132355544 will reliably deliver you to a page with metadata (including access to the NRHP doc) for "Southbury Historic District No. 1", even if the form of the page changes, or its underlying cloud storage changes. This is why a refnum->NARA catalog id mapping is needed. I'd be surprised if they make any other commitment, such as to provide durable links that have NRIS refnums in them. I view using reverse-engineered PDF links to be at best a stop-gap measure, and also not without issues (e.g. sites with restricted access to documents will still 404). Magic♪piano 02:32, 23 April 2021 (UTC)[reply]
I wouldn't mind linking to the NARA pdfs, except for restricted sites, which could use no link, or just the NPS links (which lack the PDF icon in the link). And I don't think the NARA pdf URLs will change that often or be anything not easy to fix, especially with a template. No way to know for sure except in going for it. Regardless, for now, I am going to enable and use "|link=[{{NaraStringOH}}75001398.pdf #75001398]" forms in my NRHP lists... ɱ (talk) 03:19, 23 April 2021 (UTC)[reply]
Does anyone think they can create {{NaraString}} such that {{NaraString|OH}} would render for Ohio and {{NaraString|NY}} for instance would render for New York? Avoid 50+ potential templates? ɱ (talk) 03:22, 23 April 2021 (UTC)[reply]
I can definitely create that. I would have to know what pages it should be able to link to though. I have no idea about sourcing for NRHP articles and didn't know about NARA before working on {{NaraStringOH}} --Trialpears (talk) 13:12, 6 May 2021 (UTC)[reply]

{{NaraStringOH}} is live and functioning, and I am working with Trialpears to make it hopefully have further functionality. ɱ (talk) 03:53, 6 May 2021 (UTC)[reply]

 You are invited to join the discussion at Wikipedia:Village pump (technical) § Embedded anchors in tables. Sdkbtalk 04:30, 2 October 2024 (UTC)[reply]

Elaborating on my comment made at village pump: it is possible for multiple NRHP rows (in the same page) to have the same name, which would result in duplicate ids. I'm virtually certain such a situation exists somewhere in the several thousand NRHP list pages. (If you really care, I could probably track down the example I'm thinking of. It's basically multiple entries of the form "{name} House", at different addresses.) The article parameter is also problematic, since multiple rows may be directed to the same article.
A better candidate to use for an anchor id would be the refnum, which should be (1) nonblank, and (2) unique across all of the rows in a given page. The refnum parameter is in the form of a comma-separated list of one or more numbers; if you want a somewhat durable anchor, use just the first one. Magic♪piano 18:40, 2 October 2024 (UTC)[reply]
Memory at work: National Register of Historic Places listings in Providence County, Rhode Island has two entries for "Jenckes House". HTML source confirms identical anchors after recent edit. Magic♪piano 19:02, 2 October 2024 (UTC)[reply]
[edit]

In these edits User:Ahecht seems to have accidentally introduced File:Wikimedia-logo.svg. Please change it to File:Commons-logo.svg without a link: [[File:Commons-logo.svg|16x16px|class=noviewer|alt=|link=]] Thank you, Multichill (talk) 20:30, 26 November 2024 (UTC)[reply]

 Done * Pppery * it has begun... 21:02, 26 November 2024 (UTC)[reply]
Not sure how that happened since I just did a subst, but glad it's been fixed. --Ahecht (TALK
PAGE
)
22:05, 26 November 2024 (UTC)[reply]