Template talk:Infobox protected area/Archive 3

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1 Archive 2 Archive 3 Archive 4

Bug fix

{{editprotected}}This edit will fix a bug caused by a typographical error.

The sandbox version uses the necessary documentation code for this template and should be copied as is. The current diff is here. The change is non-controversial.  –droll [chat] 07:41, 7 February 2011 (UTC)

 Fixed — Martin (MSGJ · talk) 17:30, 7 February 2011 (UTC)
Thanks.  –droll [chat] 21:37, 7 February 2011 (UTC)

Another bug fix

{{editprotected}}

This is embarrassing. The last fix revealed another typo.

The code in the sandbox can be copied. The current diff is here. See the Yosemite test case. The change is non-controversial.  –droll [chat] 00:07, 8 February 2011 (UTC)

Done. Plastikspork ―Œ(talk) 01:12, 8 February 2011 (UTC)

Trivial substitution

{{editprotected}} Substitute all instances of [[World Conservation Union|IUCN]] with [[IUCN]]. The IUCN has not used "World Conservation Union" as its name since 1990, and there is currently no other entity with the same acronym. The wikicode can thus be simplified. --Cybercobra (talk) 01:18, 15 February 2011 (UTC)

I replaced it with [[International Union for Conservation of Nature|IUCN]], which is not shorter, but does resolve the redirect. Thanks! Plastikspork ―Œ(talk) 02:23, 15 February 2011 (UTC)

Proposal to provide optional labels and parameters

Two of the labels, "Established" and "Governing body", have been bothering me for a while. I think the data in the infobox should be worded as accurately as possible. I would like to introduce several alternate parameters and corresponding labels.

Re: "Established"

I propose that the template provide options for the "established" label. This discussion is rather narrow in that it only discusses areas in the U.S. I did some reading on this and it seems that, in the United States, National Parks are "established" by an act of congress. National Monuments can be "established" by a presidential proclamation while others are "authorized" and might later be "established" by congress. Some Monuments have been "authorized" by congress but have never been "established"; others are "established" may years after authorization. You can read this article about the Antiquities Act for more information. It seems that wilderness areas in the United States are "designated". I added options for "authorized", "created", "established" and "designated" in the current sandbox. "Created" might be generic enough to be useful in the general case. There are examples on the test cases page. See the Listing of National Park System Areas by State.

Re: "Governing body"

While the label "Governing body" is a appropriate for National Parks and such, there are areas where the label does not fit. I added options for "governing body", "administrator" and "owner" in the current sandbox. For example, the Bureau of Land Management and the United States Forest Service use the work "administer" in regard to wilderness areas.

The label is selected by using a corresponding parameter. So using |created= selects the "Created" label. In the sandbox version, only one of the optional labels can be used.

Any ideas you have are most welcome, especially if better label names should be available for areas in other countries. If there is some consensus I'll request an edit to the template. The change is backward compatible.  –droll [chat] 19:21, 14 February 2011 (UTC)

P.S. I also was experimenting with an additional parameter, status, which might be useful for noting that an area is affiliated with the National Park Service. In the U.S. there are National Heritage Areas, the National Wild and Scenic Rivers System, and Affiliated Areas (no article yet).  –droll [chat] 04:22, 15 February 2011 (UTC)

Looks fine to be..make it as flexible as possible.--MONGO 04:50, 15 February 2011 (UTC)

IUCN Category

Not all protected areas of the United States have IUCN Category I, II, III, IV, V or VI. The Protected Areas Database of the United States (PADUS) f.e. knows also the status 'Permanently Unassigned', see GAP Status Codes and IUCN Definitions.-- Sinuhe20 (talk) 08:31, 30 March 2011 (UTC)

The version in the sandbox is ready to go active

I've been working on a new version of this template for some time. You can see a comparison of the current and sandbox version on the test cases page. All changes are rather conservative. Most of the improvements are related to coding. There is a list of the noticeable changes:

  1. Row spacing is more uniform, solving a problem with white space above in below the Coordinates row.
  2. Images are one pixel wider so they lineup below the header better.
  3. On most maps the marker is now red. The green marker is hard to pickup visually on many maps. "US Locator Blank.svg" is not affected.
  4. The Established row has alternate names as discussed here. See the first test case here.

I've been tweaking this for a long time so there might be other minor differences that I can't think of just now. If you have any objections, please note them. If there are none I wil request an {{editprotected}}.  –droll [chat] 20:08, 3 May 2011 (UTC)

I forgot to mention that I added parameters that allow this template to be embedded in another template and/or up to two templates to be embeded in this one. I haven't tested them yet but the functionality is documented at here.  –droll [chat]
Droll...I've done but a cursory examination of these changes and they look fine. I have been wondering about perhaps having the EXAMPLE: coordinates = {{coord|45|04|45|N|109|36|38|W|type:glacier_region:US-MT|display=inline,title}} parameter instead of the multi-line lat/lon, akin to what we have in the the infobox used in the Mountain, Glaciers and Lakes projects...I recognize this would create a massive tidy project unless we can run a bot to do it (I may be mistaken)...but it isn't that big a deal either way to me. I appreciate all your work...you may want to solicit further discussion at the Project page if you ahven't already done so as I don't think many have this template watchlisted.--MONGO 22:31, 5 May 2011 (UTC)
Hello MONGO. This template has a parameter named coords. It is a bit confusing with other templates using coordinates but it serves the same function. I can add an alias for the parameter if that would help. Actually I was thinking about adding coords as an alias in the mountain template. Thanks for the idea on leaving a note on the project talk page.  –droll [chat] 00:45, 6 May 2011 (UTC)

I am confident that the sandbox code is good. So I think its time for an update. –droll [chat] 05:17, 11 May 2011 (UTC)

 Done — Martin (MSGJ · talk) 11:55, 11 May 2011 (UTC)

Bug fix

The version in the sandbox fixes a minor bug and removes some unnecessary white space. –droll [chat] 23:23, 3 June 2011 (UTC)

Done. Plastikspork ―Œ(talk) 16:25, 4 June 2011 (UTC)

Aussie template

(opened a new section)

Has this addressed the concerns of Wikipedia:Templates_for_discussion/Log/2011_April_12#Template:Infobox_protected_area_of_Australia yet? Had I known this alternate existed or its deletion discussion, I would have argued strongly for its deletion. I don't think I see comments from the more active maintainers of this template at that discussion either. Rmhermen (talk) 18:06, 14 May 2011 (UTC)

Rmhermen I moved you question to this new section. I was not aware of the discussion but I know that the other template existed. I'm more of a mechanic than a politician and this issue might be a bit of a turf war. Generally the parameter names, when they are synonymous, are not an issue. I can modify those using WP:AWB. I need to know what new parameters need to be created. –droll [chat] 18:48, 14 May 2011 (UTC)
The problem with arguing for deletion is that the Australian template wasn't redundant to this one, as I explained and demonstrated at length, despite one person covering his eyes and ears and yelling "la la la la la I can't hear you la la la". There were 11 parameters that weren't compatible and 512 articles using x/y locator map coordinates that weren't compatible either. That's why we argued for keep. --AussieLegend (talk) 04:05, 15 May 2011 (UTC)

A new version of this template is in the sandbox. I added alternate parameters so that this template is more compatible with {{Infobox protected area of Australia}} and fixed a minor bug. There has been some discussion here. See this example. If the templates are to be merged the transition will not be simple but I would be willing to make the necessary edits. The parameters I added in the sandbox version are:

  • nearest_town
  • nearest_town/city
These are alternate parameters and can be used in place of nearest_city.
  • managing_authorities
This an alternate parameter and can be used in place of governing_body. Other alternate parameters are administrator and owner. I hope that a shorter alternative to "Managing authority" is acceptable. Letting the string line wrap is unattractive I think. If it is prevented from wrapping then the data column is forced to shrink. Would "Manager" be acceptable. –droll [chat] 04:09, 16 May 2011 (UTC)
I'm a bit time poor at the moment and haven't really had a chance to check out your version but will later. As far as "Managing authorities" wrapping is concerned though, that should be just a matter of tweaking the font size. The Australian template uses a slightly smaller font. --AussieLegend (talk) 04:05, 15 May 2011 (UTC)
I changed the sandbox so that "Managing authorities" does not wrap. Notice that the data (right column) gets squeezed. This is similar to the Aussie template. The text size in the sandbox is 90% of 1.5em and in the Aussie template is 88%. The sandbox and the Aussie template currently use a span block with white-space:nowrap.
About the incompatibility, there is none that cannot be dealt with. this template allows x,y locator map coordinates and 288px is good. I think the parameters problem can be dealt with. I'm going to work up a demonstration in my user space. –droll [chat] 19:04, 15 May 2011 (UTC)
I have abandon this effort for now. If there is renewed interest a some point I would be glad to help. –droll [chat] 06:43, 6 June 2011 (UTC)

Broken relief map feature

I'm not sure when or how it happened, but the template has stopped using the relief maps when specified with "relief" parameter. For example, see Marojejy National Park. Nothing noteworthy has happened to the location map template since I added the relief map several months ago (see history), nor has anything changed in the article (see history). Any ideas as to why the article is reverting back to the default map and ignoring the "relief" parameter? – VisionHolder « talk » 06:00, 30 June 2011 (UTC)

{{Location map}} has been updated and does not pass the {{{relief}}} parameter. I have a sandbox version ready and I'll make a request for a protected edit there. –droll [chat] 08:51, 30 June 2011 (UTC)
See Template talk:Location map#Bug fix. –droll [chat] 08:59, 30 June 2011 (UTC)

Area_ref parameter not working?

Is it possible the area_ref parameter is not working properly? I believe I have used it correctly at Sauble Falls Provincial Park, but it does not seem to display a reference.--papageno (talk) 03:13, 4 July 2011 (UTC)

It must have dropped out of the template code at some point. I just checked and Sauble Falls Provincial Park is the only article in which it showed up. It really wasn't needed, IMHO, and I removed mention of it from the documentation. Also, I edited the article so that the citation shows. The coords_ref parameter is necessary when coordinates are entered using the lat_d, long_d method and the visitation_ref parameter in needed only when visitation_year is assigned a value. –droll [chat] 06:46, 4 July 2011 (UTC)
 Done Many thanks, matter is closed. --papageno (talk) 16:04, 4 July 2011 (UTC)

"Category:Protected area articles requiring maintenance" not populated

I've noticed that Category:Protected area articles requiring maintenance was previously populated by this template, but is now always empty. The template was changed to stop populating this category in October 2010 (diff; sandbox diff).

I'm not sure if this change was intentional. If it was, perhaps Category:Protected area articles requiring maintenance should be nominated for deletion? – PartTimeGnome (talk | contribs) 17:41, 14 August 2011 (UTC)

Periodically it becomes necessary to track one or more of the parameters and, if it were to be deleted, it would only have to be recreated. IMHO, it is better just to keep it around. –droll [chat] 18:06, 14 August 2011 (UTC)

Okay, fair enough. – PartTimeGnome (talk | contribs) 20:15, 14 August 2011 (UTC)

Sandbox sync

I've made some changes which increase the elegance of this code in the sandbox:

  • Rather than hacking in style overrides, the template uses | bodyclass = geography to automatically pick up on the geobox defaults.
  • The IUCN header has been significantly improved. See {{IUCN banner/sandbox}}. That code is now called three separate times to get the background styling (applied to the whole table row rather than hacked into a div), the text and the category. I'm still unsure that we should be using the latter, per WP:TEMPLATECAT, but the code in question is now isolated.

have a look at the test cases page. If there are no objections I'll sync this in a few days. Chris Cunningham (user:thumperward) - talk 12:53, 29 July 2011 (UTC)

I don't like to be negative, but I find all the borders between rows are just unappealing and unnecessary. I know other templates such a {{geobox}} do such things, but I have always seen it as just clutter. The width of the table is narrow in the Template:Infobox protected area/testcases#Yosemite example, causing a lot of line wrap. Cells have much more padding than I think is unnecessary and will cause additional line wrap. This template has always been an alternative to using {{geobox}}, which I believe is laudable. If people want to use geobox then they should but I don't see the merit in making them look similar. Chris, I'm sorry that I could not be more positive but I call it as see it. In a another world we could all write our own CSS, but in this world we don't. I don't see how using the style attribute is hacking. –droll [chat] 17:51, 29 July 2011 (UTC)
P.S. I kind of like the current version of {{IUCN banner}}. Transcluding the template three times and using {{switch}} three times is not more efficient (although that is probably trivial). You need to know that this template is not the only one that uses {{IUCN banner}}. –droll [chat] 18:13, 29 July 2011 (UTC)
I'm not the biggest fan of the geobox styling either, but given the choice of "follow the styling used on practically all geographical templates" or "hack up an arbitrary new styling used nowhere" I'll go for the former every time. My first instinct was simply to remove all that styling cruft as pointless, and that would definitely be my second choice over keeping the current styling. "Making them all look similar" is one of the biggest goals of moving everything to {{infobox}}. In the long run my plan is to get the geobox styling altered to be closer to the infobox defaults, and that will automatically update this template if we just use the appropriate class here.
As for {{IUCN banner}}, its template transclusions suggested that this was the only template which calls it; I see the doc refers to two other templates, but both can trivially be updated and the first one should probably be merged here anyway. And the current code is a hack - the only reason it uses a div for the background colour is that was evidently less effort than doing it properly with a table row, having the categorisation code mixed in with the rest of the switch statement makes it less clean to isolate if it needs removed for WP:TEMPLATECAT compliance, and the number of times it's transcluded isn't a serious problem (the backend is already parsing about three layers of indirection to produce the infobox as it is, so two more switch statements to roll through is nothing).
Chris Cunningham (user:thumperward) - talk 21:35, 29 July 2011 (UTC)
Chris, you asked if their were objections. I don't want to offend you but I think we just disagree. I don't think this is a matter of what is right and what is wrong. Hopefully someone else has an opinion. Maybe mentioning this discussion at Wikipedia talk:WikiProject Protected areas would generate more responses. I have spend many hours working on this template and I find your reference to a hack job offensive. I also realize that I have no proprietary rights, I know that its not "my" template. –droll [chat] 23:42, 29 July 2011 (UTC)
I don't see the {{IUCN banner}} as an issue. The reason "what links here" does not show {{Infobox protected area of Australia}} is because it is only transcluded by the template conditionally. There are no examples on the doc page and there are no testcases. Finding all such cases would be important. –droll [chat] 23:57, 29 July 2011 (UTC)
Sorry for using "hack": I meant it in the sense of "clever if inelegant solution", but I certainly didn't mean to denigrate your work. Anyway, yes, I won't push it while there are objections: if we need more eyes to move forward then so be it. The code's there to be tinkered with anyway. Chris Cunningham (user:thumperward) - talk 01:35, 30 July 2011 (UTC)

Moving forward

Can I get a succinct list of the current objections to the sandbox code? I'd like to move forward with this if possible. To start off, a couple of rebuttals to the points already raised:

  1. Inheriting the styling from CSS classes is a big win for future-proofing regardless of which style is chosen. The geobox styling is widely used in similar templates, so I opted for that one. I'm open to changing which style is inherited, but not just keeping the current custom styling (which isn't used anywhere else).
  2. Integrating the IUCN styling properly with the row code ensures that it looks right across browsers as well as being semantically cleaner. The sub-template's new code style splits what it does logically into sections for ease of maintenance: I don't consider the increased number of calls made to it to be a drawback as we needn't worry about minor perceived performance issues
  3. The other templates which call {{IUCN banner}} can be fixed without too much effort. I don't consider that a blocker to rolling out this code.

Chris Cunningham (user:thumperward) - talk 12:30, 19 August 2011 (UTC)

Questions:
  1. As you know I'm opposed to using the geobox class in infobox templates. I think it is best to move towards a consistent style using the infobox class. Which part of the custom styling would you like to remove? I think there might be some room for improvement there.
  2. I don't care about the banner template except that I don't see how your version is an improvement. Can you point out an instance where the current version looks different in different browsers and how your version provides a fix? I don't think performance is and issue. I do think that calling it three times does not improve ease of maintenance in the calling template. Can you show me how the current version is broken?
In general, I think this template provides an alternative to {{geobox}}. If people like the look and feel of that template then they should use it. I seems to me that our opinions are based mostly on our personal tastes and preferences. I've read WP:CANVAS and it would seem appropriate to notify others of this discussion by leaving a message at WP:PAREAS. –droll [chat] 17:41, 19 August 2011 (UTC)
  1. If we're both happy just using class="infobox" then so be it. There's no need for any of the custom styling: it doesn't add any demonstrable value to the template.
  2. It's not simply about verifying that it doesn't cause browser problems. There is no reason to use an inner div here other than that it leads to a simpler implementation, and implementational simplicity should not be our only goal here. We have a table, and we are presenting content in that table. The most semantically correct way of doing that it so add content and semantic attributes directly to the table cell rather than within an inner element with no additional semantic value.
  3. The template serves three separate purposes: it adds a colour (purely presentational), text (purely content) and a category (neither, and only there to help us). It would make sense to split these to three different templates entirely, but this way is just as readable and possibly easier to maintain. The last function is arguably not a good idea anyway (per WT:TEMPLATECAT), but at least if it if abstracted out of the other code a little it is easier to spot and to remove in future if that it desired/
Chris Cunningham (user:thumperward) - talk 10:47, 23 August 2011 (UTC)

I disagree. We need more input and examples. I've added some test cases to the test cases page. The second (center) proposal can be yours. I'll use the right hand templates for my proposal and then we can request comment. If this agreeable to you I will create a second sandbox. –droll [chat] 18:32, 23 August 2011 (UTC)

Sure. Feel free to notify anyone you think would have input here. Cheers! Chris Cunningham (user:thumperward) - talk 10:47, 26 August 2011 (UTC)

Senegal

This is goree in Senegal West Africa. — Preceding unsigned comment added by 82.225.101.223 (talk) 03:53, 25 November 2011 (UTC)

Geobox

I have proposed that we delete {{geobox}}. That may effect this templates. You are invited to particiapte in the Geobox deletion dicussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:52, 3 January 2012 (UTC)

Propose adding optional map parameters

 Donesandbox copied into template. —EncMstr (talk) 17:29, 22 March 2012 (UTC)

Please move the markup in {{Infobox protected area/sandbox}} to the template page. It will add two parameters, no other functionality will be effected. The change will be transparent and, I believe noncontroversial. The parameters to be added, x and y, allow the user to specify a location for the map mark that is proportional. Their values are based on an imaged 1000px in width. Since they work on a principle similar to percentage, the mark location will retain its relative position when the size of the image is changed. This is currently not the case. I'll write the documentation after this update. –droll [chat] 18:33, 21 March 2012 (UTC)

I'd take care of this myself but I'm not an administrator...anyway, concur with Droll above.MONGO 18:44, 21 March 2012 (UTC)

Are there test cases somewhere? If there is a demonstration that it works as expected, I'll make the change. —EncMstr (talk) 19:21, 21 March 2012 (UTC)
Nevermind. I found Template:Infobox protected area/testcases. The side-by-sides look fine, though the title coordinate on that page is hard to verify. :-)
Is there a test case which demonstrates the new functionality? —EncMstr (talk) 19:24, 21 March 2012 (UTC)
x and y are pretty generic parameter names. I would suggest something like locator_prop_x or locator_1000_x. --Bamyers99 (talk) 19:31, 21 March 2012 (UTC)
The parameters locator_x and locator_y already exist. IMHO there are disadvantages in their use. They specify a position from the edges of the images. Changes to the size of the map image will result in the mark shifting position. There have been circumstances where this has occurred. Obviously it is best practice to use coordinates. The values given to x and y are relative as I mentioned and so the mark will remain in its intended location if the image size changes. The names of the parameters are not important to me but in {{Infobox hot spring}} and {{Infobox glacier}} they are assigned x and y. There is a demonstration of their use in the documentation for {{Infobox glacier}} in the subsection named X,Y coordinate method. They are part of the functionality of {{infobox map}} and their use is displayed in that template's documentation in the section X,Y coordinate method.
The template {{location mark}} has similar parameters which are explained in detail (perhaps too much detail) in the documentation section The x and y parameters.
Last night I tested x and y on one of the templates on the testcases page. It worked fine. Tomorrow I will add a good example on the testcases page. It's after midnight here and I think I need some sleep.
P.S. I think that, over time, the parameters, locator_x and locator_y, will be rarely used. I will be glad to answer any more question. I know that I have not explained everything very well. –droll [chat] 08:25, 22 March 2012 (UTC)

I added new examples at the top of Template:Infobox protected area/testcases. The shift is less noticeable than I remembered. I guess I fixed most of that a long time ago. One of the nice features of using images 1000px wide is that, for SVG images, they can be downloaded directly from the image's file page. The pixel coordinates can be found using programs such as GIMP, XnView or even Windows Paint.

I have thought about the parameter names a long time. In the context of this template there is little else to which they could apply and they have simplicity in their favor.

Templates that already use these parameters include:

Readable by maps.google ?

I've used this template for a couple of articles. I've noticed that maps.google.com doesn't show those articles, although they do have coordinates specified in the infobox. One example is Rome Sand Plains. Is there a particular procedure needed to get google to read these coordinates? thanks, Easchiff (talk) 09:34, 12 June 2012 (UTC)

Yes, the coordinate must have a title attribute so it appears at the top right of the article, at the same level as the article title (using most skins). This is caused by {{coord|45.678|-123.456|type:landmark_region:US-OR_source:gnis-234567|display=inline,title}}. See User:EncMstr/Coord#Google_extraction for links. To do this with this template, forego the lat_d, lat_m, lat_s, long_d, ... and use the coords = {{...|display=inline,title}} form, or—if using lat_d...—use the display=inline,title option. The documentation says that is the default, so if there is a display=inline, just deleting it should work. —EncMstr (talk) 16:50, 12 June 2012 (UTC)
Thanks for your help. The articles already had |display=title by default, and the coordinates appeared in the correct place. I'll experiment with a direct call to coord. The instructions for this template suggest that it might prevent the little red dot from appearing on the locater map, which is why I hadn't tried it before. cheers, Easchiff (talk) 04:10, 13 June 2012 (UTC)

Edit request to add default_map_width parameter

{{Location map+}} now supports the use of a default_width parameter, and {{Infobox map}} has been updated to accept default_map_width and pass it to {{Location map+}}. The code in the sandbox replaces 

| map_width      = {{least|{{{map_width|}}}|284}}

with 

| map_width      = {{#if:{{{map_width|}}}|{{least|{{{map_width|}}}|284}}}}
| default_map_width = 284

This change will allow vertically oriented maps to be modified by a preset value given in the location map scheme in order to avoid overly large maps. --Paul_012 (talk) 10:48, 12 December 2012 (UTC)

I took this opportunity to modify the <noinclude> code to test whether it is on a subpage or not. If on a subpage, it shows the {{template sandbox notice}}, otherwise it shows the {{documentation}}. The code looks odd, because it was designed by User:Wikid77 to minimize expansion depth and avoid errors. This should not affect template behavior, just the appearance of the sandbox.
Closing admin --- please copy the whole sandbox to the main template. Thanks! —hike395 (talk) 14:10, 12 December 2012 (UTC)
I don't see why it is necessary to test whether it is on a subpage or not; {{documentation}} already does this, and if it detects a sandbox, displays {{template sandbox notice}} in addition to the documentation. See for example Template:Infobox Manchester Metrolink station/sandbox. --Redrose64 (talk) 15:24, 12 December 2012 (UTC)
I reverted the changes to {{Infobox map}} that supported default_map_width. The changes were not well thought out and I am fairly sure some pages where broken. Currently this template imposes a default and maximum width of 284px. {{Least}} returns the value assigned its second parameter if the first parameter value is exceeds 284 (in this instance) or if the value is undefined or invalid (non numeric). So there is already a default value. –droll [chat] 19:12, 12 December 2012 (UTC)
Sorry. This might work fine but I'd like some time to think about it. –droll [chat] 20:46, 12 December 2012 (UTC)

I think the markup in the sandbox is good to go. I changed the parameter name used here in at {{Infobox map}}. Also I fixed a bug which prevented alt text for the photo to be handled correctly. I think the {{Template sandbox notice}} modification should not interfere with the going active with the new functionality and so I did not include it in the current sandbox version. –droll [chat] 00:46, 13 December 2012 (UTC)

I added two more optional parameters (x% and y%) that are handled by {{Infobox map}}. I've tested them many times and they are reliable. See this testcases page. Most other templates that I have worked on use the parameter name embedded. I modified the version in the sandbox so that either embedded1 (the current parameter name) or embedded are recognized. These two modifications will be transparent and should not be conversational. –droll [chat] 05:52, 14 December 2012 (UTC)
Done. Please come back here (or go to my talk page) if you decide that it needs to be reverted, whether because the code is behaving wrongly or I made a mistake. Nyttend (talk) 13:45, 18 December 2012 (UTC)

Additional alternative parameters

I've added two additional alternative parameters to the version in the sandbox:

operator as an alternative to governing_body, etc.
nearest_town as an alternative to nearest_city. For some areas there is no city within 100 or more miles.

I have tested the change and I am confident that the modification will not be noticed in existing infoboxes. I don't believe the changes will be controversial. –droll [chat] 07:41, 29 December 2012 (UTC)

Done — Mr. Stradivarius (have a chat) 13:25, 29 December 2012 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Infobox_protected_area/Archive_3&oldid=1130254822"