Template talk:Infobox protected area/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

display=inline,title in coord template

In order to ensure Google Earth is able to pick up the articles' coordinates, display=inline,title should be used, see Template:Coord, compared to display=inline which is used for now in the template. Would anyone object to this? --Berland (talk) 21:27, 11 December 2007 (UTC)

Noone objected, so I was bold and did the change. --Berland (talk) 09:00, 5 January 2008 (UTC)

That causes duplicate coordinate displays— one in the box and one at the top right of the article. See Arches National Park for an example. --— Gadget850 (Ed) ^talk - 12:28, 5 February 2008 (UTC)

True, but that is so for many other similar infobox and geobox templates. I think it serves a purpose to have them both places, that is more important than the apparent redundancy. --Berland (talk) 16:38, 5 February 2008 (UTC)

Yes, having the coordinates duplicated within three inches is redundant. Some articles already had coordinates in the External links section as well— that now shows two sets of coordinates superimposed in the title. Ah, cleanup... --— Gadget850 (Ed) ^talk - 16:47, 5 February 2008 (UTC)

I changed back to inline only before reding the discussion, I appologise for that. The reason was not redundancy, but collision of cordinates in the title area, there are many pages that use a separate coord statement or coor title (ex: Lois Hole Centennial Provincial Park, it also collides with geolinks templates. --Qyd (talk) 17:30, 5 February 2008 (UTC)

I absolutely think those articles with the separate coord statement in addition to the infobox must be fixed. Redundancy in source code must be avoided, redundancy in display is not that important (I prefer Google Earth inclusion over avoiding display redundancy). --Berland (talk) 21:49, 5 February 2008 (UTC)

Why doesn't inline work with Google Earth? --— Gadget850 (Ed) ^talk - 22:01, 5 February 2008 (UTC)

And the answers are at Template talk:Coord and About the Google Earth Geographic Web Layer. --— Gadget850 (Ed) ^talk - 22:12, 5 February 2008 (UTC)

I would still prefer this template to use display=title,inline, but Qyd reverted my change, so I am reluctant to reverting Qyd myself. Is there any consensus here? --Berland (talk) 11:12, 16 February 2008 (UTC)

I wouldn't mind to have the template render inline and title, but in that case, all pages that have dual coord statements woudld have to be cleaned up before implementing the change. Can a smart robot be set up for the task? --Qyd (talk) 13:58, 16 February 2008 (UTC)

A compromise (and easy) solution would be to have a parameter that adds the title display (by using for example title=yes), by replacing

-->|display=inline|}}

with

-->|display=inline{{#ifeq:{{{title|}}}|yes|,title|}}|}}

or with

-->|display=inline{{#ifeq:{{{title|}}}|no||,title}}|}}

The editors would than be able to control the rendering. Alternately (second example), the switch could be used to inhibit the title display in particular cases (useful if consensus is built towards enabling the title display by default). --Qyd (talk) 14:24, 16 February 2008 (UTC)

This can now be done by using coords= {{coord|lat|long|display=inline,title}}. If you use this variant, you can ignore the lat_degress, lat_minutes, etc. parameters. —EncMstr (talk) 21:56, 25 July 2008 (UTC)

Need the name parameter in coord

I recently added the name={{{name}}} parameter to the coord template and had it reverted. Out of curiousity, if you're just going to revert every change, then why not protect the page?

Anyhow, the reason is that the name provided there will escape the spaces properly. For example, if you go to Mount Rushmore right now and select the coordinate you'll see that Title shows Mount_Rushmore. If you then try to use a mapping service that uses the name (like MapQuest... when it's working, and Live Maps), the underscore breaks things. With the fix in there, the title will show Mount Rushmore, and everything will work fine. I guess I'll check back and see if people feel better about the change after this explanation. Heptazane (talk) 00:04, 8 March 2008 (UTC)

Apparently, it breaks the template. See testcases.- Jespinos (talk) 22:47, 13 March 2008 (UTC)

That is because the name field in the example includes the image. When the name field is reused in the coordinates, so is the image. The top image should be a separate parameter. --— Gadget850 (Ed) ^talk - 23:05, 13 March 2008 (UTC)

the "name" part is not necessary. the geo microformat is wrapped in a vcard class (the top class of the infobox), which already defines the name ("fn" class definition of the "name" element), and that is inherited automatically by the geo microformat contained in coord. Furthermore, if adding a name to coord, fn would be defined twice, which is prohibited by the microformat, and would create an error (fn is required and mus be unique, "MUST be present exactly once"). Yes, an image added to the "name" field would break that name (as parsed through the microformat), but only if that image contains a caption, otherwise it's fine. --Qyd (talk) 23:47, 13 March 2008 (UTC)

Did some more testing, turns out you Heptazane is right, the name is not present when you click the coordinates link that takes you to the geo-hack age (unless it's defined again in the coord template). It is, however, present in the geo microformat generated by the page as a whole. Question remains if a duplicate fn definitions breaks the entire microformat (according to the standard, it would, but it might work still if the statements are identical (both times "fn" is defined by the same parameter, the "name" field).--Qyd (talk) 00:18, 14 March 2008 (UTC)

Okay, so it's incorrect to have the photo in the name, and the name is required as I've been saying, so are you guys satisfied, or if I make the change again will it just get reverted? Heptazane (talk) 23:21, 14 March 2008 (UTC)

You are unaware of that your change causes problems on the numerous pages that use the template with image and map. If you think is incorrect the present way of including two images in the infobox, then you would propose an alternative way to solve this issue and fix it before making any another change. Jespinos (talk) 15:42, 15 March 2008 (UTC)

I did some more testing, and found no evidence of errors in the microformat if the name is defined in the coord statement. Images in the name field, however, break the template if name is defined in coord. If another picture field is defined and implemented (allowing for both map and picture), the change could be made, otherwise, I would not go ahead with it. --Qyd (talk) 16:02, 15 March 2008 (UTC)

I propose that images not be put in the name field because then it isn't really a "name" field, it's a "name+image" field. Not having it means that all protected areas with a space in the name will cause a poor experience when using the coordinates. My vote is for fixing the name field. Heptazane (talk) 22:21, 15 March 2008 (UTC)

Use the new coords= {{coord|lat|long|etc.}} form. —EncMstr (talk) 21:57, 25 July 2008 (UTC)

Sandbox

I created the sandbox and testcases pages. Please use these to test changes and gain consensus before making live changes. --— Gadget850 (Ed) ^talk - 02:30, 8 March 2008 (UTC)

Links?--MONGO 17:24, 11 March 2008 (UTC)

At the top of the documentation section. This is one of the neat things about using the {{Documentation}} system— as soon as you create the sandbox and testcases subpages, it automatically adds the links to the doc page. --— Gadget850 (Ed) ^talk - 17:30, 11 March 2008 (UTC)

Gotcha...thanks.--MONGO 09:00, 13 March 2008 (UTC)

Modifying zoom level for coord

Can someone who is savvy please add a field for modifying the zoom level of the co-ordinates? This is done with "type:____" in the coord template. I think this would be useful to the varying sizes of parks; for example, look at the difference between the title and inline coords I used at Westmeath Provincial Park. --Padraic 18:23, 1 May 2008 (UTC)

This can now be done by using coords= {{coord|lat|long|etc.}} where etc. includes the zoom level. —EncMstr (talk) 21:58, 25 July 2008 (UTC)

Awesome, thanks! --Padraic 15:05, 30 July 2008 (UTC)

Change

Sorry if i mess up the page history, but I made some changes that incorporate the world heritage template. Hopefully, it can solve the problem. —Chris! _ct 21:24, 3 May 2008 (UTC)

I had to go back and readjust it since all the infoboxes were doing was showing a year date and no further explanation. But kudos for trying. I think the problems should be resolved now. I need to ensure all the infobox versions are the same too.--MONGO 06:09, 9 July 2008 (UTC)

I just restored the version without the additional world heritage template..that template only adds more clutter to the articles. The Protected Areas infobox is more than sufficent. Maybe we can add one or two more parameters, but again, some of these article that have this template are Feature level and as such, they should consist mostly of written words.--MONGO 05:36, 12 July 2008 (UTC)

If the same info from the world heritage site template can be written somewhere, I will be ok with the removal of it. Personally, I don't think the template adds more clutter to the article. I think it actually works very well.

It is also a good idea to add more parameters because the date parameter we had now tells nothing about world heritage site to the readers.—Chris! _ct 17:51, 13 July 2008 (UTC)

Lets see if we can get more feedback..perhaps a week?--MONGO 03:49, 14 July 2008 (UTC)

Whatever changes we do make, we need to make sure we don't end up with a huge whitespace area as was left behind in this edit[1] when the heritage site infobox was added.--MONGO 03:52, 14 July 2008 (UTC)

That won't happen again. It was just an error I made on the world heritage site template.—Chris! _ct 20:51, 14 July 2008 (UTC)

(2) Proposed updates: coords and location

Optional location_* and coords_* parameter fields to:

1. Allow the {{Location map}} templates to be used either in addition to, or in place of: locator_x, locator_y map?

The {{Location map}} template would use the lat_* and long_* fields to set the corresponding lat_* and lon_* parameters to place the dot or mark.

• location_map =
• location_label =
• location_label_size = 90
• location_position = right
• location_background = none
• location_mark = Red pog.svg
• location_marksize = 8
• location_border = none
• location_caption =
• location_float = right
• location_width = 240
• location_AlternativeMap =

Typically usage would be to set the current {{Infobox Protected area}} parameter fields:

• lat_*=
• long_*=

parameter fields, and

• location_map = {country-name} {region-or-state-name}

Only if necessary, would other parameters be set, typically either:

• location_label =
• location_position =
• location_mark =

to make the corresponding dot-mark more legible.

2. To add:

• coords_parameters =
• coords_display =
• coords_format =
• coords_name =

fields which would map to the corresponding {{Coord}} template parameters.

Typical usage would be:

• coord_parameters = region:XX-YY_type:ZZZ
• coords_display = inline,title
• coords_name = map-marker-label

Where:

• XX is the 2-letter country abbreviation (ISO 3166-1 alpha 2 code, like US for United States, CA for Canada, ...)
• YY is the 2- or 3- letter province, region, or state abbreviation (typically the "local postal abbreviation code"; formally an ISO 3166-2 code)
• ZZZ is either: (country, state, adm1st, adm2nd, city, airport, mountain, isle, waterbody, forest, river, glacier, edu, pass, railwaystation, landmark, ...). The types are defined or updated in the geohack.php and mapsources.php source code and published on the WP:GEO project page.

Summary: The additional optional coords_* and location_* would not change the current (default) behavior and would allow better specification of coordinates and a more current overlay map. Such would update {{Infobox Protected area}} to be more similar to other current Geo- and Info- box templates. LeheckaG (talk) 10:59, 27 August 2008 (UTC)

Missing seconds causing error message

Unresolved

The absence of seconds in the coordinates value here is causing display problems. Andy Mabbett (aka Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 19:42, 4 September 2008 (UTC)

This might be related: Template talk:Infobox nrhp#Coord transform broken. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:53, 21 September 2008 (UTC)

I restored the template to my earlier version. Hopefully that is a simple fix for now. Alterations to embedded parameters such as {{coord}} is not really an infobox issue and I see you have discussed that with those that work on that template at Template:Coord already.--MONGO 02:01, 22 September 2008 (UTC)

Thank you, but that didn't fix it (and you also reverted other changes) so I've reverted you. The problem is not with {{coord}}, but what this template is passing to it. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:41, 22 September 2008 (UTC)

Still happening. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:41, 26 October 2008 (UTC)

Minor changes

I made a few very minor changes to the template and sub templates. If anyone notices anything that untoward please contact me ASAP. --DRoll (talk) 08:43, 7 March 2009 (UTC)

Updated version

I have finally finished an updated version of this template. I will wait a few days more before I change the current template. Editors are incouraged to take a look at the new template and its documentation which and be found in the sandbox at Template:Infobox Protected area/sandbox/doc. Test cases which compare output from the original template and the updated version can be found at Template:Infobox Protected area/testcases. The updated template is based on a meta-template {{Infobox2}}. Further discussion should probably take place at WikiProject Protected areas. If you read this I hope you can contribute to the discussion. I have spent a lot of time on this project and I think the results are very good if I do say so myself. --droll [chat] 11:24, 24 March 2009 (UTC)

Looks good, but I'm seeing a problem with the picture and caption on the testcases - the first word of the caption appears to the right of the picture instead of below it. (This might be something to do with screen width or the fact that two boxes are placed side by side, I don't know if the same thing would happen with a single box on an article page.)--Kotniski (talk) 12:24, 24 March 2009 (UTC)

Yes, looks like that problem's been fixed now:)--Kotniski (talk) 06:46, 25 March 2009 (UTC)

Updated version to be installed

If there is no objection to the updated version of {{Infobox Protected area}} that can be found at {{Infobox Protected area/sandbox}} it will be installed on Wednesday. You can compare the output of the two versions by viewing the test cases. --droll [chat] 19:05, 30 March 2009 (UTC)

It looks good to me. Thanks for setting up the test cases with the side-by-side comparisons of old version vs. sandbox, then followed by some demonstration of new functionality (which i gather is a lot about map display control). It seems pretty clearly to be working well. Also, I guess i like that it accepts latitude and longitude in either decimal or DMS format. That would be a nice functionality to have in the similar template:infobox nrhp, which has map control but will not accept decimal coords. Nice work! doncram (talk) 22:00, 30 March 2009 (UTC)

This template was updated today

If you notice anything untoward please contact me ASAP. I am committed to deal with any side effects. --droll [chat] 19:47, 31 March 2009 (UTC)

State parks

I tried to convert Lake Tahoe – Nevada State Park to this template. To do so, I'd would need an additional type field, e.g. "type". The html table in the article has a row "Designation: State park". This doesn't fit into the "iucn_category" field. -- User:Docu

So look at Lake Tahoe – Nevada State Park and let me know what you think. I stole the color form the navbar. With no color the infobox looks kind of blah. I might do something to match each states "Protected Areas" navbar. For example have a field for the states 2 letter code and have a switch figure out the the color. --droll [chat] 05:19, 3 April 2009 (UTC)

In the meantime, you changed it to {{Infobox Park}}. Apparently the IUCN code for the park would be "V". This helps skip the color issue. The new field "designation" would be fine. -- User:Docu

Do what you wish. IUCN V sounds good. I did not document the designation field yet but I will. --droll [chat] 22:23, 3 April 2009 (UTC)

coordinates slightly broken

The coordinate links contain empty source: and globe: fields. This is not valid. Either specify globe:earth or leave it out. Same goes for source: --Dschwen 19:49, 13 April 2009 (UTC)

Fixed in {{Infobox coord}}. --Dschwen 19:55, 13 April 2009 (UTC)

Conversion to Template:infobox

On the /sandbox is a suggested conversion of this template to use {{infobox}}. Please compare the testcases and let me know your troughts. The only change I can see if a slightly greater spacing between rows which would bring it into line with the style of other infoboxes. A couple of questions:

• Is the {{{designation}}} field actually used anywhere? If so, could it be put into a normal row field of the table rather than as a header?
• Are {{{native_name}}} and {{{alt_name}}} supposed to be used together? If not, which one should take precedence?

— Martin (MSGJ · talk) 10:31, 21 August 2009 (UTC)

I noticed that PC78 created Category:Use of subheaders in Infobox Protected area. You can find the data you need there. I am planning on deprecating {{{native_name}}} and I noted that on the documentation page yesterday. {{{alt_name}}} has seen considerable use especially on Asian pages. I have been spending a considerable amount of time developing a method of writing infoboxes that does not require a meta template. There are technical advantages to the new approach which I will be glad to discuss if you are interested. There is a testcases page at User:Droll/sandbox/testcases. Right now it has a bug and not much shows but you can find the code at User:Droll/sandbox/code and a linked version at User:Droll/sandbox. As I say I've spend considerable time on this and I need a little longer to finish up.

I don't think {{{designation}}} was ever used. It probably should have been removed a long time ago. It was requested an so I implemented it. I has never been documented. IMHO {{{native_name}}} implies a certain POV. I've also been spending some time updating pages that use deprecated field names of late and I hope the end is in sight.–droll [chat] 00:50, 22 August 2009 (UTC)

url parameter vs. website

Why was the website parameter changed? I think it's far better to be able to read the url in the infobox and not just have a link. Keep in mind that Wikipedia articles are not always read in a web browser so external links are not useful for all readers (e.g. when reading a paper copy of an article). —D. Monack ^talk 05:41, 24 August 2009 (UTC)

I didn't think the change would be controversial. Actually the field is still available. The problem with the website field is that some URLs are very long and are most often designed to be machine friendly and not people friendly. Placing your cursor over the link will cause the URL to display as a tooltip in Safari, Opera, Internet Explorer and Foxfire. The URL will also be display on the very bottom of the browser window in the browsers I tested except Safari. I hope this is satisfactory and that it is responsive to your question. –droll [chat] 02:57, 25 August 2009 (UTC)

That's all fine but I'm more concerned with non-browser versions of articles. Someone looking at a printout of an article will no longer see the url. Also, often a reader will want to see the url without having to click on it (for example, to see if a site is .org, .gov, or .com). I realize you can hover the cursor to see it, but that's annoying and many readers may not realize this. All this change does is put another layer between the reader and information. That's rarely a good idea. —D. Monack ^talk 23:05, 25 August 2009 (UTC)

Accessibility improvement

In reviewing the WP:ACCESSIBILITY of the featured article candidate Upper and Lower Table Rock I discovered that its infobox map lacks alt text. To fix this, I plan to have this edit installed into the {{Infobox protected area}} template, which generates that infobox; the edit will add support for alt text to that template. However, for this to work, we need to improve {{Superimpose}} somewhat. {{Infobox protected area}} uses {{Superimpose}} to create a location map:

{{Superimpose
  | base          = Oregon Locator Map.PNG
  | base_width    = 283px
  | base_caption  = Location in Oregon, in the United States
  | float         = Red_pog.svg
  | float_width   = 7px
  | float_caption = Upper and Lower Table Rock         
  | x             = 58
  | y             = 182
}}

This has accessibility issues, since the visually-impaired reader who's using a screen reader will hear something like "Upper and Lower Table Rock link Location in Oregon, in the United States link". The change to {{Infobox protected area}} will cause it to generate this call instead:

{{Superimpose
  | base          = Oregon Locator Map.PNG
  | base_width    = 283px
  | base_alt      = Upper and Lower Table Rock is located in southwest Oregon, close to California
  | base_caption  = Location in Oregon, in the United States
  | float         = Red_pog.svg
  | float_width   = 7px
  | float_link    =
  | x             = 58
  | y             = 182
}}

This generates the same visual appearance, but the screen reader will say the more-useful "Upper and Lower Table Rock is located in southwest Oregon, close to California link".

I've implemented a patch along the above lines, but to get it to work I first need a change installed into {{Superimpose}} that will allow one to specify that the floating image should not have a link or alt text, and that only the base image should have that. Once that's done, I'll propose a change to this template here. Eubulides (talk) 07:30, 17 October 2009 (UTC)

Prerequisite done so please install

{{editprotected}} The {{Superimpose}} change was installed. So, please install this edit into the {{Infobox protected area}} template, as described above. Eubulides (talk) 22:18, 17 October 2009 (UTC)

 Done —TheDJ (talk • contribs) 21:37, 19 October 2009 (UTC)

Request to modify template source.

{{Editprotected}} Please replace the code in the active template with the code in the sandbox. Test cases are here and a diff can be found here.

This change will be transparent except in the pages that apear in the tracking categories. The first change removes articles using {{{website}}} from the maintenance tracking category. There is no need that I can see to worry about this parameter being used. I wrote that code some time ago.

The second change will depopulate Category:Use of subheaders in Infobox Protected area. The motivation for tracking these parameters was to help resolve discussion about the use of more than one sub-header in Template:Infobox. The issue was resolved a long time ago.  –droll [chat] 05:39, 7 July 2010 (UTC)

 Done — Martin (MSGJ · talk) 08:49, 7 July 2010 (UTC)

Request for edit

{{editprotected}} Please replace:

{{#if: {{{native_nave|}}}{{{image|}}}{{{base_width|}}}{{{caption|}}}{{{lat_degrees|}}}{{{lat_minutes|}}}{{{lat_seconds|}}}{{{lat_direction|}}}{{{long_degrees|}}}{{{long_minutes|}}}{{{long_seconds|}}}{{{long_direction|}}} | [[Category:Protected area articles requiring maintenance|{{FULLPAGENAME}}]]}}

with

{{if both|{{is article}}|{{{native_name|}}}{{{image|}}}{{{base_width|}}}{{{caption|}}}{{{lat_degrees|}}}{{{lat_minutes|}}}{{{lat_seconds|}}}{{{lat_direction|}}}{{{long_degrees|}}}{{{long_minutes|}}}{{{long_seconds|}}}{{{long_direction|}}} | [[Category:Protected area articles requiring maintenance}}

in {{Infobox protected area}}. The code is near the bottom just before the <noinclude> block. This will reduce clutter on the category page. Also fixed a typo. –droll [chat] 17:56, 9 August 2010 (UTC)

You missed a set of square brackets. Next time, please load your changes into Template:Infobox protected area/sandbox and request sync rather than putting your code on the talk page. Thanks :) — Martin (MSGJ · talk) 08:32, 10 August 2010 (UTC)

Re-{{infobox}}ing

It looks as if this template's code was shot to bits as an unfortunate fallout of {{infobox2}}, the old base template, being deleted. I've re-implemented the template as a proper {{infobox}}; the code is in the sandbox and comparisons between old and new are available on the test cases page. Please check the code is working properly and I've not missed anything; if there are no objections I'll get this synced to the live template. Chris Cunningham (user:thumperward: not at work) - talk 09:03, 3 September 2010 (UTC)

I see that user:Droll has worked on this further; I've now synced the sandbox code to the live template. Chris Cunningham (user:thumperward: not at work) - talk 02:20, 11 October 2010 (UTC)

visitation_ref property

The visitation_ref property won't show up anywhere in the template. Should this be fixed? ›mysid (☎∆✎) 05:25, 30 September 2010 (UTC)

Hi. I tested it at Template:Infobox protected area/testcases#Ellis Island and it appears to work. Could you provide an example where it fails to function as expected. –droll [chat] 06:19, 30 September 2010 (UTC)

Thanks for the reply, I now notice that the article was using the similar template {{Geobox|Protected area}}, where there is no such property. I'll consider migrating it and others to this template. ›mysid (☎∆✎) 07:53, 30 September 2010 (UTC)

Error code on doc page

The red error code on the documentation page is caused by too many levels of transclusion. It should not effect articles. I'll fix it in the sandbox tonight or tomorrow morning. –droll [chat] 05:55, 11 October 2010 (UTC)

As it turns out, there is no way to fix the documentation problem in the template code. The documentation template adds extra levels of transclusion and that's what causes the problem on the documentation page. The old code did not use {{infobox}}, which adds two levels of transclusion. I think {{convert}} is probably responsible for most of the transclusions.

So the solution, as I see it, is to fudge the examples on the documentation page. I'll do that now. –droll [chat] 09:04, 11 October 2010 (UTC)

The other solution, is to reduce the transclusion depth of {{documentation}}. I just switched the doc back to using convert, but replaced {{documentation}} with {{documentation/core}}, and the problem went away. Plastikspork _―Œ^(talk) 14:52, 11 October 2010 (UTC)

Added map option

{{editprotected}}

This edit will allow the use of additional map resources including relief maps. The change to the code will be transparent to readers and editors. Relief maps are currently available for the USA, China and Russia.

The sandbox version uses the necessary documentation code for this template and should be copied as is. There are test cases here and the current diff is here. The change is transparent and non-controversial. I'll update the doc page after the template is update. –droll [chat] 15:53, 18 October 2010 (UTC)

Done. Thanks for the update. Nyttend (talk)

Cosmetics

This is not related to the function of the template, but I was wondering if we could consider adjusting the template to mirror the appearance of the French version, see at Parc national de Marojejy, for instance. I mostly like the display of the title, but maybe other people might like some of the other tweaks (like the use of the country flag, location of the map, etc.). – VisionHolder « talk » 15:56, 30 January 2011 (UTC)

And in support of moving the map to the bottom of the infobox, compare the Marojejy National Park with its French counterpart. (And don't worry, I'm writing the article as we speak. So please don't dive in and create edit conflicts. It should be done sometime late tonight.) Even the {{Taxobox}} template puts the range map of species at the bottom. But I realize that some parks only have a map and no photo... in which case maybe a conditional statement could put the map on top if no photo is available, or on bottom if there is a photo. – VisionHolder « talk » 16:11, 30 January 2011 (UTC)

I don't see anything wrong with it the way it is. In fact the convention is to place the map at the top underneath the photo for most articles. I'd be more concerned with the lacking state of the article rather than the layout of the infobox..♦ Dr. Blofeld 17:03, 30 January 2011 (UTC)

I agree that the lack of content is a significant and persistent problem. But that shouldn't stop us from taking a little time to make things look nice. I plan to build up the Marojejy article and take it to FAC rather quickly, and I would like the article to look as good as possible. Let's face it—readers are more likely to stop and look at the pictures and the design than they are to read every sentence in a lengthy article. Although content is critical, layout and appearance are also very important. – VisionHolder « talk » 17:14, 30 January 2011 (UTC)

Exactly. That's why the map should be at the top so readers don't have to scroll down to see where it is..♦ Dr. Blofeld 17:30, 30 January 2011 (UTC)

People wouldn't have to scroll that far (if at all) to see a map in an infobox. That's fine if you disagree, though. The location of the map was not the original point of the email. It was just one of several suggestions. What about the first idea? – VisionHolder « talk » 17:45, 30 January 2011 (UTC)

And thanks for the edit conflict on the Marojejy article. Especially since I explicitly stated above not to rush in and patch things up. – VisionHolder « talk » 17:17, 30 January 2011 (UTC)

If you don't want an edit conflict place Template:Inuse on an article.♦ Dr. Blofeld 17:25, 30 January 2011 (UTC)

The article hadn't see activity for months, and had only been edited 12 times since it was created 2 years ago. The only people likely to edit the article today would have been people reading this request. I will start using {{inuse}} from now on. If it was an honest mistake, then that's okay. If it was deliberate, then don't be a dick. – VisionHolder « talk » 17:45, 30 January 2011 (UTC)