Template talk:Infobox NRHP

Built information

As currently written, the built field is not really sufficient. Going through some of the church complexes, the built date generally is for the major structure (the church building). There is no way to clearly identify this. Likewise there is no way to list the other structures in the complex and associate a built date with them. It would be nice is there was a way to address this. Vegaswikian (talk) 06:02, 6 May 2011 (UTC)

It's called prose. One infobox does not an article make.--Dudemanfellabra (talk) 13:28, 6 May 2011 (UTC)

So, is the consensus for something like a church complex the date in the box is church (or in general the main structure for other then church complexes)? For historic districts it should be blank unless the article support dates for the first and last structures? Vegaswikian (talk) 18:16, 6 May 2011 (UTC)

What's put into the infobox's "built=" field and into the category for year of architecture by Elkman's article infobox generator is in fact the first year-date of possibly several year-dates of significance. It might not be a built date at all. For example, March Route of Rochambeau's Army: Scotland Road's built date is 1781, the first date that Rochambeau's army marched through, not the date of construction of that road. Also, in many cases NRIS provides the beginning and ending year of a construction period range, e.g. for a building constructed during 1920-1923 the significance dates of 1920 and 1923 will be given. Out of 30,000 infoboxes built using Elkman's system, there will be some hundreds of factual errors, due to the sometimes incorrect assumption that first date given is a built date. Vegaswikian, i think you are one editor who goes around systematically removing the date from categories for the historic district articles, is that not right? Someone, anyhow, has removed the category date and/or the infobox built= field from many/most of the articles on NRHP-listed historic districts.

I suggest the infobox should be revised to include a dates of significance field. The built= field can be kept in the infobox, to receive dates that are verified to be construction dates or date-ranges. Elkman would need to be interested into updating his article/infobox generator to use the significance date field and to provide all the available dates in that (currently Elkman's system just provides the first date). Then, although this is at least debatable, I think we should have a bot run to convert all NRHP articles to move possibly bad built= dates into the significance date field, with an edit summary and hidden comment calling for editors to restore the date to the built= field if/when it is verified. This is a lot of work to do, but is doable on a slow path, as was recently done for making a correction/update to all NRHP articles for how the NRIS reference appears, now using the template:NRISref.

For historic districts, where dates of significance are provided in NRIS, the change from puzzling "built=" presentation, to more accurate presentation as dates of significance of the district, would be especially helpful in making the articles better. --doncram 18:34, 6 May 2011 (UTC)

For a church complex case that Vegaswikian describes, the construction dates of the multiple buildings could be given as a list in the dates of significance infobox field. It would probably be confusing to use the built= field in that case. But multiple dates of significance can be briefly mentioned, appropriately in an infobox. And then in the text the significance of those dates would naturally be explained.

What to name the field, and how should it be presented? Perhaps as "|signifyear=" field, to be expanded as Significant:, in what is displayed, parallel to Built: now displayed for the built= field value. --doncram 18:44, 6 May 2011 (UTC)

Dates of significance sounds fine to me since these are commonly listed with several date ranges. Also based on the sheer number of errors in the built field, I don't think this should be filled in by a script. The creation of Category:yyyy architecture should be replaced with Category:Buildings and structures completed in yyyy since that is what the built represents. In all of the articles I have looked at, I don't recall any where the article supports any architectural significance for the building and provides a date when the building was designed. Vegaswikian (talk) 19:00, 6 May 2011 (UTC)

About what bots (scripts) could do: 1) I am suggesting that a bot could visit every already-existing NRHP article, and shift what currently appears in the built= field to a new signifdate= field, because the date might not actually be a built date. 2) It would be hypothetically possible, but I don't see how a bot could actually take new info from NRIS database and add it to each article, and don't propose creating such a bot (and there would be no regular bot-writers who would take it on, if requested, I believe). 3) For new articles going forward, created from Elkman's infobox/article generator or created from my own /draft batch generator, we would use the signifdate= field for the NRIS significance dates. So I am not suggesting anything which could possibly introduce any errors at all. In many articles the bot run I suggest would convert what is correctly presented as a built date, instead presenting it less precisely but still accurately as a date of significance, and then a human editor could move it back to the built= field if they actually know it is a built date. Hope this clarifies. --doncram 19:17, 6 May 2011 (UTC)

About Category:yyyy architecture and/or Category:Buildings and structures completed in yyyy, I haven't previously really focused on those categories with any interest. Offhand I guess the latter should be included into articles only manually, by a human editor if they know the built date. The category could be set up but hidden in a comment by Elkman's and my systems, to be removed from comment by a human editor if/when they have actual knowledge from the NRHP nom doc or other source. --doncram 19:21, 6 May 2011 (UTC)

This is a useful discussion of the shortcomings of database entries and infoboxes. It would be helpful to add some additional date fields to the infobox -- the best choice might be to embed templates that create free-labeled date fields in which the user can specify the meaning of each date, whether it's "built", "started," "completed," "destroyed", or something else. As several other commenters here have noted, the human editors who create articles need to determine what content is relevant and appropriate, rather than depending on robotic processes. --Orlady (talk) 19:30, 6 May 2011 (UTC)

Let's keep this discussion respectful, please, and let's focus on technical matters of the infobox and about bot proposals associated with an infobox change, please. --doncram 20:09, 6 May 2011 (UTC)

About Category:yyyy architecture and/or Category:Buildings and structures completed in yyyy, I'm not sure based on what I have been seeing that either should be automatically added. Also I'll note that bridges belong in category:Bridges completed in yyyy, churches go in Category:Church buildings established in the ccth century, railway stations belong in Category:Railway stations opened in yyyy. I'm not sure what the best solution is, but the current one is generating too many bad category entries. I'll point to Linlithgo Reformed Church of Livingston as an example of a bad date. Nothing in the article referenced the church in 1814. Yet that year was used in the infobox and a category. Vegaswikian (talk) 02:08, 7 May 2011 (UTC)

Also cemeteries probably belong in Category:yyyy establishments and not in a built or architecture category. Vegaswikian (talk) 05:17, 7 May 2011 (UTC)

The Linlithgo example is a useful one. The article does include the 1814 date, which is the founding date of the cemetery, earlier than the construction date of the building. Based on the NRHP nomination document, NRIS database data entry staff would have properly recorded it in a list of dates of significance for the site; Elkman's system assumes however that the first date is the built date. The article text reflects a creating editor writing from the facts given in the NRHP nom doc, but creating editor did not override the authoritative-looking built-date in the infobox from Elkman's system. Elkman's system output needs to have appropriate qualifications put into comments, or in some other way be adjusted, IMHO. In my /draft batches done so far, I addressed the lack of clarity about these facts by including a complete series of the dates of significance into the draft text and into the built= field (i would prefer to put them into a signifdates= field, if one would be created). --doncram 13:17, 8 May 2011 (UTC)

One other consideration here should be to realize that the NRHP infobox should be about the NRHP information and that a lot of confusion can be eliminated by also including other infoboxes like {{infobox church}} or {{infobox building}} these can be repeated if there are multiple structures on the site or included in the article. They would also serve to clarity what facts are about each building and better support proper categorization of the articles. In the end this should clarify the articles. See Saints John and Paul Catholic Church (Burlington, Iowa) for an example where this would clearly help. Vegaswikian (talk) 18:07, 7 May 2011 (UTC)

That might be a good example to consider, if the article actually did include 2 infoboxes, for the cases where the NRHP nom is about 2 approximately equally important things grouped together. In that case it appears just one of the churches is NRHP listed, and there is only one infobox, the NRHP one. --doncram 13:17, 8 May 2011 (UTC)

Sorry, I've been really busy since this thread started. I agree with the idea of a "significant dates" field, but I think it can go even further. Why not include the NRHP listing date here? Or NHL designation date? Other local designation dates? Delisting dates? We could turn this into a list of dates, perhaps in its own section of the infobox. I'll try to work up something in the sandbox later, although I probably won't have much time until mid-week or later. I'll also include that |builder= field you were requesting earlier, Doncram.--Dudemanfellabra (talk) 16:22, 8 May 2011 (UTC)

Well, the NRIS database provides a list of significant dates about the building, historic district, site or object that are more fundamental than NRHP listing which occurs on a random date 50+ years after a significant event. Significant dates are like the date-range of building or the date of a battle or other event at the site or date range of a future president living in the house, and not including the date of NRHP or NHL listing, which are less important or at least different. We have fields for the NRHP listing date and the NHL designation date and customizable date field for state/local historic designation and NRHP delisting date in the infobox already that have been working fine, for when they apply. Offhand I would not change those. I currently just see advantage of having a signifdates field to include a list of significant dates about the property that are not otherwise covered (and that would provide an implicit prompt to editors to explain those dates somehow in the text). You may be suggesting that the signifdates= list could include other significant dates esp. ones that occur after the NRHP listing; I agree that in usage editors could add additional significant dates there beyond those that might be supplied by NRIS database, consistently with the editors explaining all of the dates in the text somehow, hopefully.

Happy to see whatever you might draft. Thanks for planning to get the builder= field added, too. --doncram 17:43, 8 May 2011 (UTC)

Relatedly, a technical solution for one other problem would be to add an "architect and/or builder=" field. Elkman's generator and my batch /drafts system and any other system arguably should not put anything into an "architect=" field that is not verified to be an architect rather than a builder or a consulting engineer or other party. The NRIS database just provides a list of significant names, and the first one is usually an architect. It would be conservative and arguably good to have the systems place the names into an accurately-ambiguously-named field "architect and/or builder", implicitly suggesting to editors that they should find out the facts and then move those names to architect= or builder= fields. There are only a scattered few engineer ones associated so I don't think an infobox field is needed for that (I recall one of the Cass Gilbert-designed warehouses in New York City has an engineer who worked with the architect, and was given in the NRIS that way). This could be set up for future articles only. Or, as for the signifdates= vs. built= case, we could likewise run a bot to move names given in an architect= field to the architect and/or builder= field, calling for editors to check all past work. A decision to run a bot to address all existing articles does not need to be decided now, though; we have to focus first on setting it up proper for going forward, and would need Elkman's agreement actually for fixing forward, before considering running a bot to go back to all past articles. Testing a sample of past articles for accuracy would be relevant info for making the bot run decision. Now, I guess I would like for an "architect and/or builder=" field to be set up. --doncram 17:58, 8 May 2011 (UTC)

How much of {{infobox building}}, {{Infobox bridge}} and {{infobox church}} do you want to introduce? These templates, and several others, still should be added to the various articles. Expanding the NRSP infobox will not prevent that. So why duplicate excessive amounts of information in the various infoboxes? There is a slow moving effort to convert as many of the building related infoboxes into one to both standardize the nomenclature and to eliminate duplication. I don't see this template being included at this point, but who knows in the long run. So maybe the question is what should be eliminated that is already better addressed in other templates or that really belongs in other templates? In the case of a cemetery using {{Infobox cemetery}} in lieu of a built/completed/started/established date in the NRHP template would make sense since we would not have to decide what terms are important or different for a cemetery. Vegaswikian (talk) 18:19, 8 May 2011 (UTC)

I just ran into Bald Head Light which is an example of how two infoboxes can be combined in case anyone needs to see an example. Vegaswikian (talk) 18:43, 8 May 2011 (UTC)

Oh, you seem not to have been aware that NRHP infoboxes are routinely combined ("embedded", following instructions at template:infobox NRHP) into several types of infoboxes, including Lighthouses, Ships, and Railroad stations infoboxes. This is highly appropriate as there would otherwise be a lot of overlapping information, and the NRHP info is secondary/followon to a place being first a lighthouse or a ship or a railroad station. I am not sure how formally it is done, i.e. whether it is also done using the embedding or not, but also sometimes NRHP information is combined into church infoboxes (as I have noticed often this being done by editor Daniel Case) and buildings infoboxes. I thought you were calling for multiple completely separate infoboxes to be added to articles about a historic district or a pair of buildings, which is different. There are no doubt some articles out there where the NRHP infobox follows a Ship or other infobox, where combining/embedding would be an improvement to the article. But in some cases it is helpful to keep them separate, so that the NRHP info can be in a much later "Preservation" section of an article, much past the original statement of facts about a ship. And there's no further change needed to support embedding. --doncram 19:01, 8 May 2011 (UTC)

Yea, it is kind of easy to miss in the list of examples and not widely used. As to the embedded example, I think that the explanation is overly complex. I believe that you can always add the template right before the closing '}}' in any {{infobox}} based template. BTW, this will not work with {{infobox church}} since that is not coded in the standard infobox format. Vegaswikian (talk) 23:46, 8 May 2011 (UTC)

That is not the case, Vegaswikian. Simply adding the NRHP infobox to the bottom of the {{infobox}}-compatible template will not make the infobox appear at the bottom of it. If you would like to test this, simply use the code given for that example and move the NRHP part down to the bottom.... it won't work.

Actually, the embedding feature works better with non-meta formats, simply because this infobox is itself not meta-compatible.--Dudemanfellabra (talk) 00:25, 9 May 2011 (UTC)

Actually I did try a test case. Vegaswikian (talk) 05:04, 9 May 2011 (UTC)

Here is your test case. As you can see, you added the infobox to the very bottom of the code. Doing this, caused the "References" header to show up in the old infobox, even though there were no references in the infobox. It showed up because you put the NRHP infobox code into the |references= parameter. Also, because you didn't use the |embed=yes parameter, the NRHP infobox is not formatted correctly; it still has a border around it, and the text is smaller than normal.

In my revision, as you can see, I moved the NRHP code up to below the Architect, which is the last thing displayed in the infobox that was there before. Doing so made the "References" header disappear. I also used |embed=yes to correct the formatting. Now do you see the difference?--Dudemanfellabra (talk) 14:48, 9 May 2011 (UTC)

OK. Is your method better or is including the template with the nrhp= field better? Vegaswikian (talk) 17:08, 9 May 2011 (UTC)

They accomplish the same thing. I think the |nrhp= field was added to the church infobox (and several others) a while back when we were still trying to get embedding to work properly, and it wasn't compatible with meta-style infoboxes. Now, though, the embedding is compatible with 99.9% of infoboxes (save those that have more than two columns, and they can be tweaked to work with it), so the |nrhp= field is no longer necessary.--Dudemanfellabra (talk) 20:04, 9 May 2011 (UTC)

Sandboxed version

I have finally found the time to update the sandbox. I restored the previous meta-compatible code and moved around a bunch of stuff. One small change added several basic information fields such as |builder=, |demolished=, |restored=, and |restored_by=... all of which should be self explanatory and were discussed in an earlier thread. The big change is the fact that I have moved all of the existing date fields (including NRHP listing, NHL/NPS/other nrhp_type designations, delisting date, and local listing/delisting dates) into a new "Significant dates" subheading of the infobox. I have also added three new fields–|sigdate_label=, |sigdate2_label=, and |sigdate3_label=–along with the corresponding |sigdate=, |sigdate2=, and |sigdate3= fields, the _label fields allow a custom label (e.g. "Main building built", "Settlement began", etc.), and the sigdate fields hold the dates.

Ideally, I would like to sort these dates from earliest to latest, but I'm not quite sure how I would go about that. I'll keep looking into that, but what is in the sandbox now at least shows the basic form that I had in mind. Comments? Questions? Snide remarks? I'll try to answer as many as possible.--Dudemanfellabra (talk) 20:47, 9 May 2011 (UTC)

Also, I forgot to say that examples of the infobox in use can be seen here.--Dudemanfellabra (talk) 20:52, 9 May 2011 (UTC)

Looks fine. I noticed that the image caption is now was on a white background. Makes it stand out a bit. Also, why is built not considered a significant date? Is it because it is intended to be paired with builder? Can we add an established date for things like cemeteries? Also for compatibility should we match {{infobox building}} which uses complete and {{infobox church}} uses completed to describe when something was built. Even with my questions, I don't see why the latest version could not go live. This will make my updating easier, once I learn to spell the names of the new parameters. Vegaswikian (talk) 21:41, 9 May 2011 (UTC)

Actually the image caption was on a white background before; now it is a regular caption, more in line with other infoboxes. That can be changed back if preferred.. As to the built situation, I think built should remain in the "basic information" section of the infobox–i.e. the top part–and paired with builder. If consensus asks it, though, it can be moved to the bottom as well. As far as establsihed, completed, etc., that's what the |sigdate_label= parameters are for.. you can basically set up your own infobox fields. If you set |sigdate_label=Established and |sigdate=1776, the result will be a new line in the infobox saying Established: 1776.

I'm still looking into the idea of sorting the dates. I'll get back to you on that. I was hoping to have more comments here.--Dudemanfellabra (talk) 19:59, 10 May 2011 (UTC)

Here are some quick comments. I wouldn't go live immediately. Thanks for setting up the builder= field etc.

About the dates section and date changes, I am not sure. Does it just change display, and not the entry of dates into the infobox, besides now allowing for additional custom fields? Do the additional custom fields allow for display of the date of significance, when it is not described yet what is the meaning? (I want that, to lay in the dates and to call implicitly for editors to identify and add meaning.)

The formatting grouping together a bunch of dates works well... in the test cases where it works well, i.e. where there a bunch of various listing dates that can be set off together, and where it looks nice. The greatest number of NRHP infoboxes, probably, have just one date, the NRHP listing date, then probably next are the two-date cases where a built date is given. If only one date is given, the insertion of a new line "Significant dates" is not an improvement. Not sure how the infobox is supposed to work with built date and with NRHP listing date. Where many dates are present, the ordering of the dates, into priority possibly but probably into chronological order, once set off into a "significant dates" section, would be pretty important to get right. Not sure how easy that would be to program, not sure it is worthwhile. Is the topic "Significant dates in registration"? Because, as the embedded Boyd Mill test case shows, the significant date of just NRHP listing, separated from other more obviously important dates of construction, doesn't look great IMO. Maybe more comments later. Hope this helps. --doncram 20:30, 10 May 2011 (UTC)

Doncram, you are correct that it just changes display. The update is entirely backwards-compatible, and no infoboxes will be broken because of it. The custom fields can be whatever you want them to be. If you set |sigdate_label=NRIS date(s) of significance and |sigdate=1900,1910,1920, then the infobox will display NRIS date(s) of significance: 1900, 1910, 1920. If you set |sigdate_label=Purple elephants and |sigdate=are awesome, the infobox will display Purple elephants: are awesome. You can literally put anything in these fields.

As far as the label popping up when only one date is given, I can look into making that stop. I agree that it's a little out of place for only one date.--Dudemanfellabra (talk) 20:03, 11 May 2011 (UTC)

I have now updated the sandbox to suppress the display of the "Significant dates" header if only one date is provided. The examples at the test cases page look better now in my opinion.--Dudemanfellabra (talk) 20:17, 11 May 2011 (UTC)

Two weeks later

So no more comments. Are we ready to go live? Vegaswikian (talk) 18:08, 25 May 2011 (UTC)

I'm fine with that, though I think we should at least drop a note at WT:NRHP to alert anyone who may care. This infobox is transcluded on tens of thousands of pages, so any change will freak someone out haha. I'll start a section there that asks for opinion and gives a tentative 2 day deadline.. so if no one objects before Friday afternoon, I don't see why it wouldn't be ok to copy the template in.--Dudemanfellabra (talk) 22:27, 25 May 2011 (UTC)

I would've liked to see compatibility with the "Designations" template (particulary when dealing with state/city level designations) and am not particular fond of the "Significant dates" header, though not overly opposed to it (could it be possible to make the header the same color as the NRHP bar). Also, could the map caption be beneath the map but not in the thumbnail, similiar to the image caption. Other than those, I am fine with the template; it's a step in the right direction. I did make some changes to the headers so they weren't as narrow. ​​​​​​​​Niagara ​​^{Don't give up the ship} 00:20, 26 May 2011 (UTC)

I agree that compatibility with the {{Designation}} template would be ideal, but I think we should hold off until a future update to implement it. That would require new parameters and a complete rewrite of the bars at the top (as well as some possible backwards compatibility issues), so something that drastic may need to wait until it can be figured out.

I saw you changed the font size of the designation bars to 110% and the header to 115%; I reverted that change because as could be seen from the test cases page, the font was just too big. I left the header at 105% and 100% for the designation bars. The now smaller size of the bars is due to the meta-compatibility. If you can find some other way to fix it besides raising font size, by all means incorporate it.

I also moved the map caption outside of the map like the image caption. Look good to you?--Dudemanfellabra (talk) 00:59, 26 May 2011 (UTC)

I increased the "line-heights" a bit and shrank the map caption to match the image caption. Any chance of making the "Significant dates" header the NRHP color? Looks good otherwise ​​​​​​​​Niagara ​​^{Don't give up the ship} 01:48, 26 May 2011 (UTC)

The significant dates header now matches the NRHP bar at the top. I think before I had it that light grey because all the dates under the header are not necessarily related to the NRHP. Even with that fact, though, I think the uniformity makes the update look a lot better.--Dudemanfellabra (talk) 02:38, 26 May 2011 (UTC)

Looks like no one else cares, I say we go live!--Dudemanfellabra (talk) 16:13, 27 May 2011 (UTC)

Anyone still paying attention? Can an administrator copy over the code now?--Dudemanfellabra (talk) 17:11, 11 June 2011 (UTC)

Did not realize that was the reason for the delay. Copied over. I did nothing with the documentation. Vegaswikian (talk) 17:57, 11 June 2011 (UTC)

Infobox NRHP link useless

We have been linking to http://nrhp.focus.nps.gov/natreg/docs/All_Data.html or http://www.nps.gov/nr/ for the reference supporting the 'NRHP Reference#'. Well those links don't do that, the correct format is something like http://pdfhost.focus.nps.gov/docs/NRHP/Text/79003711.pdf, however everything is not yet digitized so another option may be needed. These should all be converted to use a format that works. Since those links could change in the future, we should have a template to generate the link where the only parameter passed is the reference number. Then we have cases like for 98000688 where entering it into the search box produces no hits! Vegaswikian (talk) 18:25, 25 May 2011 (UTC)

This is not really a problem of the infobox but of the reference used in it. No coding here will affect this issue. Maybe you should bring this up at WT:NRHP? I know we've had much discussion about the reliability and functionality of the NRIS citation. Currently the ref is controlled by the {{NRISref}} template, so half of what you want is done already. There are also templates {{NRHP Focus}}, {{NRHP nomination}}, and {{NRHP pictures}}. They point directly to the NPS Focus database, but as far as I know, no one has really liked them.--Dudemanfellabra (talk) 22:31, 25 May 2011 (UTC)

Contributing Properties in overlapping districts?

Historic Property
U.S. Historic district Contributing property
Location	Middle of nowhere
Built	Before 1961
Part of	Somewheretown Historic District (#12345678) Elsewhereville Historic District (#87654321)
Designated CP	July 2, 2011 (Somewheretown) July 3, 2011 (Elswhereville)

I have run into a curious issue: in a few places, the boundaries of two historic districts overlap (confirmed by both the maps and the descriptions), as such at least a few properties are contributing to two districts (and without regard to being individually listed), however, the current format appears to only make allowance for one. As it is, at least one article I've found is such a property. Might it be possible to have a "partof2" and "partof_refnum2" or the likes for these situations? Thanks. Morgan Riley (talk) 02:23, 3 July 2011 (UTC)

I would think because of the undoubtedly small number of notable properties to which this would apply, they could be handled by using line breaks in the |partof= parameter. Something like

| partof = Somewheretown Historic District (#12345678)<br /> Elsewhereville Historic District (#87654321)

An example of this is shown to the right.--Dudemanfellabra (talk) 02:48, 3 July 2011 (UTC)

Thank you, I was unaware of that function! Morgan Riley (talk) 03:34, 3 July 2011 (UTC)

I am having trouble at

Sighting the Enemy because the info box does not allow me to put the sculptor as the sculptor. When I got there the sculptor Edward Clark Potter, was listed as the Architect. It turns out that the architect was Hunt & Hunt, so I have all that info crammed into the Architect slot. This is not just an isolated thing, it likely will show up on all statues on the NRHP. The Statue of Liberty, for example lists Bertoldi as the architect, and he is not, the name that belongs there is What's His Name Hunt. Richard Morris Hunt that is. Can we get a Sculptor slot on the template? I'm off to mess with that Liberty Statue now. Einar aka Carptrash (talk) 02:56, 12 July 2011 (UTC)

There is a |builder= paramater that shows up as "Built by: ___". Will that suffice? This template is set up to handle the vast majority of NRHP listings, most of which are buildings or districts. To my knowledge, there aren't that many sculptures or statues on the register. I think moving Potter and Bertoldi to the builder parameter (and possibly leaving the "sculptor" parenthetical) would work fine for both of these articles.--Dudemanfellabra (talk) 03:18, 12 July 2011 (UTC)

Tough call, for me anyway. I think for now I will just keep sticking the sculptor in with the architect, since to my way of thinking, that's closer to being correct than Builder. Both architect and builder nean something else, but I can see why we might not want a category that is only used in 0.003% of the listings. However I do suspect that I have not stumbled onto the only two examples. There will be more. Lincoln Memorial, for example. Carptrash (talk) 04:01, 12 July 2011 (UTC) The Jefferson Memorial has two sculptors, neither listed in the box. Carptrash (talk) 04:10, 12 July 2011 (UTC) The United States Capitol has two or three sculptors who should (opinion) be included in the infobox Carptrash (talk) 04:34, 12 July 2011 (UTC) Gutzon Borglum in not even mentioned at the Mount Rushmore infobox. Carptrash (talk) 04:36, 12 July 2011 (UTC) Also in Washington DC one can find the National Archives and Records Administration building, the United States Supreme Court Building, the National Building Museum and more, All with sculptors whose work can be found on the exterior of the building. This sculptor thing is not as rare as one might suspect. I'm off to bed now, to think of many more NRHP buildings to add here at a later date. Carptrash (talk) 04:42, 12 July 2011 (UTC)

A |sculptor= parameter has been added.--Dudemanfellabra (talk) 04:44, 12 July 2011 (UTC)

Life is good. Carptrash (talk) 04:48, 12 July 2011 (UTC)

Contributing property to an NHL?

A new article on the Fort Pitt Blockhouse seems to have stumbled upon the rare occurrence of a contributing building to a National Historic Landmark (the Forks of the Ohio, which is apparently not a district nor a site). Are there any recommendations for how this should be handled and should a new designation for a landmark contributing property value be added to the template? CrazyPaco (talk) 05:42, 16 July 2011 (UTC)

I would leave a |nrhp_type=nhl on the blockhouse article. The "National Historic Landmark Nomination: 66000643" (PDF).

puts a pretty high importance on the blockhouse. Usually when there are several articles about the same NHL, they all get an NHL infobox.--Dudemanfellabra (talk) 15:42, 16 July 2011 (UTC)

Ok. As of now, the original author had two infoboxes inserted in the article: the building infobox and another NRHP infobox. I was thinking about merging them into one by using the NHRP template, and will proceed by using the NHL designation parameter, but the title in the infobox will be "Fort Pitt blockhouse" to match the article, not the actual registered "Forks of the Ohio"? Just to check, does that makes sense and that has precedent in the project? Or should it be left as is with two infoboxes used in the article? CrazyPaco (talk) 19:13, 16 July 2011 (UTC)

Embedding the NRHP infobox into the building one should be fine. I think the title of the NRHP infobox (which is still displayed even if it's embedded) should still say "Forks of the Ohio", since that is the name of the NHL. It is in our style guide to always favor the official name.--Dudemanfellabra (talk) 19:19, 16 July 2011 (UTC)

Ok, thanks, I actually didn't think to embed it (I was thinking just using one NRHP infobox combining the info). That makes a lot more sense. Thanks for your answers! CrazyPaco (talk) 21:08, 16 July 2011 (UTC)

Designated_other_textcolor?

I'll send this up for a suggestion again, to see if gets any more feedback or interest this time around.

Can we add a simple parameter so that one can designate text color for the local "other designations"? This way colors schemes for local historic designations can stay consistent with other projects, such as those in the Historic Sites Wikiproject (e.g. New York City's local designation infobox bar color scheme has a red background with white text). This would be easy to adding <span style="color:{{{designated_other1_textcolor}}}> in a couple of places, with obviously in this example, setting the parameter "designated_other1_textcolor =" to whatever color value you want in the infobox. CrazyPaco (talk) 21:50, 16 July 2011 (UTC)

I would support adding this parameter. On a related note, there have been several requests to add in full blown support for Template:Designation, which is what the HSITES project uses for its designations. In other words, an editor could simply type something like |designated_other1=NYC Landmark, and the bar–background color, text color, link, and all–would show up with that single parameter. While I am in favor of adding support for the Designation template in theory, it is a little harder to accomplish than adding a few lines of code here. Sure, adding the template as is would combine the |designated_other1_name=, |designated_other1_color=, and |designated_other1_link= parameters, but in order for complete compatibility, we would need to include an entirely new section in Template:Designation for abbreviations (e.g. "Los Angeles Historic-Cultural Monument" = "LAHCM"), which in the NRHP infobox are supplied by |designated_other1_abbr=. While this wouldn't be too much of a change for that template, I think we would have to bring something up over at WT:HSITES before something like this was done.

Of course, adding support for Template:Designation would not necessarily eliminate these parameters (although if a full move to the Designation template was proposed, I would support it), so the |designated_other1_textcolor= parameter and its other2 and other3 counterparts would still need to be added now. My question is why stop there?--Dudemanfellabra (talk) 04:14, 18 July 2011 (UTC)

I think that adding the Template:Designation can go down the wrong road. First, it may result in the insertion of designation abbreviations for literally 100s, if not 1000s of possible state, county, and municipality historic designations. You're probably aware that in my area of interest alone, Pittsburgh and Pennsylvania, there are Pennsylvania Historic Marker designations, City of Pittsburgh designations for districts, objects, sites and structures; and Pittsburgh History and Landmark Foundation Historic Landmark designations. I know many other towns and counties in Pennsylvania, both large and small, that have their own designations as well. For a template whose code is locked for administrative editing, that creates a unnecessary gateway to an editor wishing to display state and local designations, as well an unnecessary burden to administrators that would be needed to add each requested historic designation. Further, it can lead to unnecessary, and I believe for Wikipedia's sake, unconstructive semantical debates over the meaning of "historical designation". I don't oppose adding Template:Designation in theory, as it could simplify the process for the more widely used local designations although I believe it could prove unwieldy to fairly manage, but I do oppose any subsequent removal of customizable fields for the inclusion of local designations for the above reasons.

But I guess the first question really is, if you agree it is beneficial, should a request be submitted for the insertion of the textcolor code parameter? CrazyPaco (talk) 19:01, 20 July 2011 (UTC)

As I said, adding support here for Template:Designation would not replace all the other previously established parameters but rather work alongside them. Custom designations/abbreviations/colors, etc. could still be added to the NRHP infobox, even without adding them to the Designation template. Any designation that doesn't meet the requirements to be in the Designation template would not be allowed in simply to be used here. I see it as more expanding the use of the Designation template than limiting the NRHP infobox; it in fact makes using the local designations in the NRHP infobox much more user friendly.

As far as administrator involvement is concerned, only a single editprotected request would be needed to add support for abbreviations of already supported designations there, and then later each individual designation would be added, just as is done now.

I do agree, for now, that adding support for the text color parameter would be beneficial. I do think, however, that we should bring up this proposal at WT:HSITES to see what they think about it.--Dudemanfellabra (talk) 19:24, 20 July 2011 (UTC)

I see what you are saying. Athough I don't particularly see a substantial need for it if customization is in place, I have no problem with it as long as it doesn't replace customization (and thus stall or block the ability to signify designations as with what happened to the PA Historic Sites previously). If you think it is a good idea to discuss textcolor over there first, I'll defer that to you, and thank you in advance for your help. CrazyPaco (talk) 00:47, 21 July 2011 (UTC)

There isn't really a need for the Designation template, per se, but incorporating it directly into this infobox will make it much easier for editors to add some of the more widely known designations like NYC landmarks. I've opened up a thread at Wikipedia talk:WikiProject Historic sites#Adding abbreviations to Template:Designation asking for comments. If they're fine with it, We can get the text color parameter and designation support in one fell swoop instead of having two (or more) different editprotected requests here. Comment there if you feel it appropriate.--Dudemanfellabra (talk) 21:35, 21 July 2011 (UTC)

Dudemanfellabra knows I support the increased use of the Designation template in the infobox, but keep the customization of the infobox available in case a situation calls for it. Adding text color is also logical—you can custom the color of the bar and the abbreviation, why not the font color as well. ​​​​​​​​Niagara ​​^{Don't give up the ship} 00:46, 22 July 2011 (UTC)

Edit request

Can an admin change all instances of "Washington (U.S. state)" to "Washington (state)" for proper categorization? E.g., Category:Historic districts in Washington (U.S. state) > Category:Historic districts in Washington (state) Thanks! ^Avic_ennasis @ 12:53, 24 Tamuz 5771 / 26 July 2011 (UTC)