Module talk:Infobox military conflict/Archive 2

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

{{

! style="padding-right: 1em;" | Result
| {{{result|}}}

to:

! style="padding-right: 1em;" | {{#if:{{{status|}}}|Status|Result}}
| {{{status|}}}{{#if:{{{status}}}|{{#if:{{{result|}}}|<br />'''Result:'''}}}} {{{result|}}}

I have tested this; please see User:Boowah59/Sandbox and User:Boowah59/SandboxTemplate source. Thank you. Boowah59 (talk) 01:10, 6 January 2008 (UTC)

Not a bad idea, but your code will significantly complicate the layout of that field; there's no reason, in my view, why an article would need both a status and a result. In light of that, I've added the "status=" field as a simple alternative to the "result=" field. Kirill 01:20, 6 January 2008 (UTC)

Thanks much! Boowah59 (talk) 01:25, 6 January 2008 (UTC)

I updated the infoboxes in all of the

Can we make the ampersand in "Conflict & losses" the full word "and"? It looks neater that way. Srnec (talk) 17:30, 18 January 2008 (UTC)

I'm assuming you mean "Casulaties and losses". I agree with you, so I made the change.

Talk

19:28, 18 January 2008 (UTC)

Thanks. I didn't know how. Srnec (talk) 20:34, 18 January 2008 (UTC)

Please see the discussion at

So now we have the section titled Beligerents, but the applicable parameter in the documentation is still called Combatants. In any case, I'd like to see some clearer guidance on who gets listed in this section and in Commanders. Some articles like Napoleonic Wars and World War I are out of hand, with long lists of Emperors, Presidents, Prime Ministers, and (oh, yes) military leaders. It seems clear to me that if the state is belligerent, the head of state and the head of government are automatically engaged, so this entry should be left for the chief of staff etc.LeadSongDog (talk) 22:40, 4 February 2008 (UTC)

Changing the parameter name would require changing the templates in thousands of articles. That's doable with a bot, but not something anyone has stepped up to do. As for the others, I agree, although

WT:MILHIST would be the best place for discussing the issues you raise more generally. Askari Mark (Talk)

03:26, 5 February 2008 (UTC)

(Side comment: I'd suggest, for matters this specific, leaving a pointer on the main talk page but holding the discussion here, rather than vice versa;

WT:MILHIST is very high-traffic, so we've been trying to reduce the load a bit by branching discussions to appropriate subpages where feasible. Kirill

03:34, 5 February 2008 (UTC))

(Noted. Askari Mark (Talk) 23:14, 8 February 2008 (UTC))

In general, we've tried to avoid being too strict on the usage rules for each field; every conflict is different, and the project's general philosophy has been to allow editors the discretion to use most fields as appropriate for their particular topic.

As far as commanders are concerned, the instructions currently specify that the field should include "the commanders of the military forces involved" and that "for wars, only prominent or notable leaders should be listed"; but defining "commander" and "prominent" more precisely has intentionally been left to the subject experts for each particular topic. The end result needs to be helpful to the reader; beyond that, trying to develop a one-size-fits-all rule to things like this doesn't strike me as a particularly useful thing to do. Kirill 03:31, 5 February 2008 (UTC)

Agreed, though, for practical reasons, it might not be a bad idea to give a recommended "upper-limit" to the amount of commanders. Beyond about seven it, IMO, tends to lend itself more to a "List of X commanders in the Y conflict". Oberiko (talk) 14:21, 8 February 2008 (UTC)

Really, about 5-6 per side at most would seem reasonable to me, unless perhaps it was a very long war with many changes of leading commanders. Askari Mark (Talk) 23:14, 8 February 2008 (UTC)

Can anyone create a new type of infobox?--

In theory, yes. In practice, new infoboxes are generally created only for topics which have no possibly usable existing infobox; otherwise, the preferred method is to use optional fields to minimize maintenance overhead. Overlapping infoboxes and infoboxes with vague usage scopes are generally discouraged.

A more specific question would probably get a more specific answer. ;-) Kirill 13:29, 8 February 2008 (UTC)

{{

Nope, that's just how that particular article was set up, I think. Kirill 14:58, 19 February 2008 (UTC)

Surprisingly possibility for the fourth combatant is needed. There the fourth column is needed for the Ottoman desant, which was not an ally of other sides.--Üñţïf̣ļëŗ (see also:ә? Ә!) 18:11, 25 February 2008 (UTC)

There's no really practical way to do this using the normal layout; and there are a few conflicts with even more sides, in any case. The better way to do this would be to use the single combatant1 field (as in, e.g. Italian Wars) and format things inside that as needed. Kirill 18:19, 25 February 2008 (UTC)

In the interests of standardization, I think it'd be beneficial if we had a few more guidelines and suggested practices for using the infobox. I would propose the following:

Combatant ordering

Combatants should be listed in order of importance to the conflict, be it in terms of military contribution, political clout, or a recognized chain of command. If there is no clear means of ordering using the prior criteria, then the decision is left to the editors of the particular article.

Commanders

This should be restricted to the lowest single-point-of-authority(s) who had active strategic / operational command (either de facto or de jure) for the planning, coordination and execution of their forces in a given conflict. For example, a general commanding a theatre of war is usually not warranted for a minor battle when a local commander oversaw the activities involved. This generally should not exceed seven individuals or contain sub-ordinate commanders, though exceptions to the latter can be made in cases such as participation of multiple branches of service.

Thoughts? Oberiko (talk) 20:19, 5 March 2008 (UTC)

Meh. My philosophy was to avoid adding rules merely for their own sake; article editors generally know what the best approach for their particular case is. Are either of these actually issues where lack of a guideline causes significant problems in practice?

Aside from that, the matter of subordinate commanders is not one that's easy to deal with on articles about ancient & medieval wars, since any monarch personally leading armies in battle would technically be senior to any other commanders from the same country. Personally, I'd avoid mentioning the issue moreso than it already is in the instructions. Kirill 02:13, 6 March 2008 (UTC)

I'd say it is definitely an issue. While we might not have this problems in medieval times, we do with modern articles such as Eastern Front (World War II) which lists 34 commanders on the Soviet side and nearly as many on the Axis. Basically, we're seeing the most prominent commanders, their subordinates, and their subordinates subordinates. With so many names listed, it defeats the purpose of the info-box, becoming more of an order-of-battle.

Naturally, the monarch-on-the-field is not something I'm trying to prevent, it's the issue of tracking the chain of command all the way up. For example Brécourt Manor Assault involved two companies, and thus the commanders of both are listed; what I don't need to see is the regimental commander, the divisional commander, the corps commander, the army commander, the army group commander, the theatre commander and then the heads-of-state involved. Perhaps I should rephrase it to being the most relevant commanders for any given conflict?

In terms of the rules, it's because we are all over the place. Some articles list belligerents based on alphabetical ordering, some are based on entry time, and some are based on similar criteria that I've listed. I'm pretty sure that the casual reader, when they look at the box, usually expect the most prominent belligerents to be at the top of the list and generally work its way down. Right now we can (and in several cases have) end up with situations similar to Poland being listed before the Soviet Union in the Battle of Berlin. I should clarify that this is not applicable to iffy-situations or those where sources / general consensus can't be reached; it's for those where it's not in contention who the most prominent is. Oberiko (talk) 03:40, 6 March 2008 (UTC)

I think you misunderstood my objection about the subordinate commanders. I certainly have nothing against excluding the higher chain of command, as you suggest. My concern is for cases like the War of the Third Coalition; since, say, Kutuzov is technically a subordinate of Alexander, your comment that the field should not "contain sub-ordinate commanders" would mean his exclusion—even though he was the more prominent military figure. Basically, I don't want to be forced to pick only the top commander for each country in cases where they were not of equal rank. Kirill 03:46, 6 March 2008 (UTC)

Wot3C looks fine to me. I should also clarify that I'm not against listing especially prominent commanders instead of / along with their superiors. For example in the various battles on the North African Campaign I list Rommel (de facto commander) instead of which ever Italian officer he was usually technically subordinate to (the de jure commander). I'm not an expert on the Napoleonic Wars, but from a quick glance it looks more or less like those were the most prominent, influential commanders during the war, so, no objection.

But, I think this could easily spiral. We could list the commanders of all various armies, the heads-of-state for each state involved, folks like Joachim Murat, Kellermann and other local commanders of some influence.

So, to keep it simple, what about simply recommending an upper-limit as we do with belligerents? Try to restrict the commander list to the most prominent or influential in the conflict. An upper limit of about seven is recommended.. Oberiko (talk) 12:51, 6 March 2008 (UTC)

That seems fine as a rule of thumb, I think. Kirill 13:48, 6 March 2008 (UTC)

Great. Any opinion on the combatant ordering? Oberiko (talk) 14:56, 6 March 2008 (UTC)

Just to add to the rules of thumb, a fairly good one for command and control systems is to have detailed information on your subordinate units and track one level below that. In practice, especially in fluid operations, you want to track your peer organizations and boundaries, the organization that commands you and key components such as alternate and rear command posts, and perhaps special opeations forces and other units in your area of operations, but controlled at a significantly higher level.

That suggests no more than 3-5 levels are usually appropriate. As I think about it, perhaps it is inappropriate for the infobox, but peer organizations -- significant both for gaps and fratricide -- are important. SOF are less likely to be mixed in with a general organization, and, while there might be key facilities such as intelligence sensors in your AO, they are again probably inappropriate for the infobox.

I am a great believer in simplifying command displays, especially since I had to deal with a general who, for unknown reasons, wanted a single display with every electronic emitter in a division, with red-yellow-green operational status. At any reasonable level of magnification, it was a pulsing brown blob. Howard C. Berkowitz (talk) 17:06, 6 March 2008 (UTC)

Sorry, I'm not quite following. Is that in relation to the number of commanders to display? Oberiko (talk) 18:42, 6 March 2008 (UTC)

I appreciate the concerns which led to this subject being broached, but I quickly see two problems with it. Firstly, there are cases where the ordering of combatants is highly contested, and neither a policy of "most important" nor simply leaving it up to the editors of that article is going to work. I don't personally care much what order things are listed in, but some people - particularly, for example, some of those with a pro-China, pro-Korea, or pro-Japan attitude - get into massive arguments over this kind of stuff. ... I suppose for those cases, we can just go by a rule/guideline of alphabetical order, though that still doesn't address the nonsense arguments behind whether the PRC should be listed before Japan and Korea for "C for China", or after that for "P for People's Republic".

Anyway, such contentious things aside, I'd also like to say that as for the commanders guideline, there are cases where a commander is particularly famous for his contributions to that battle, even though he was not the top-ranking officer present. The

4th battle of Kawanakajima (1561) comes to mind - though Takeda Shingen, the top-most warlord of the entire force, was present, his subordinates Kōsaka Masanobu and Yamamoto Kansuke

are particularly famous for their tactical/strategic efforts in this battle. Again, there is always the possibility of having a guideline and simply allowing there to be exceptions for those cases where appropriate, but...

All in all, I'm afraid it seems like more often than not, guidelines/policies conceived with 20th century conflicts in mind don't really apply to pre-modern cases very well, and vice versa. LordAmeth (talk) 00:16, 7 March 2008 (UTC)

I don't think either of those two go against the grain of my proposals. For the first, it's only a guideline where there is no dispute as to prominence. If one party has clear predominance over another (more forces, higher on the chain-of-command, more political clout etc.), then they should be listed higher; if there are means or metrics where one could plausibly argue that another belligerent is potentially more prominent, then the guideline doesn't apply and the editors have to sort it out themselves.

For the second, your example is still listing well under seven commanders and there are valid reasons for the subordinates to be there since they have clearly demonstrated prominence in determining the outcome of the battle. Oberiko (talk) 01:54, 7 March 2008 (UTC)

Ah. Well, in that case, sounds good to me. LordAmeth (talk) 23:47, 7 March 2008 (UTC)

One possibility to reduce overcrowding in the "Commanders" field is to create a "Political leaders" field, to be used especially for kings, heads of state, etc., in wars. The guidelines should perhaps discourage the use of this for battles, where only the relevant field commanders should be listed. —

Hmm, I think those waters are a bit to muddy, regardless of era. Plenty of policital leaders played active roles in the military strategies and campaigns of their states. It'd be tough to distinguish them. Oberiko (talk) 18:04, 7 March 2008 (UTC)

A Political Leaders field might be nice for wars, but not battles. Though, even then I wonder if it wouldn't be too messy, as many wars stretched out over multiple reigns/presidencies/etc. LordAmeth (talk) 23:47, 7 March 2008 (UTC)

So, before I go ahead, any objection to the following:

Commanders

Commanders should be restricted to the most prominent or influential in the conflict. An upper limit of about seven per belligerent(s) column is recommended.

Combatant ordering

Combatants should be listed in order of importance to the conflict, be it in terms of military contribution, political clout, or a recognized chain of command. If differing metrics can support alternative lists, then ordering is left to the editors of the particular article.

Oberiko (talk) 14:59, 8 March 2008 (UTC)

Sounds good to me. LordAmeth (talk) 00:41, 9 March 2008 (UTC)

Combatant ordering

Combatants should be listed in order of importance to the conflict, be it in terms of military contribution, political clout, or a recognized chain of command. If differing metrics can support alternative lists, then ordering is left to the editors of the particular article.

This can be very problematic in some cases, and leaving something for editors of the particular article must have been written by someone who has not seen how ridiculously prolonged arguments over very minor issues can get in wikipedia. Chronological order by entry to war, or even simple alphabetical order, should be also options if measuring contribution gets problematical.--Staberinde (talk) 17:55, 7 May 2010 (UTC)

Well, sure. If there's no clear ordering, the editors can certainly decide to list things in any order, be it alphabetical, chronological, or any other. Kirill ^{[talk] [prof]} 16:39, 9 May 2010 (UTC)

Who are cobmatant1 and combatant2?

I am wondering if any rule exist which side should be listed as a combatant1 and which as a combatant2?--Paul Siebert (talk) 15:52, 9 May 2010 (UTC)

There's no real rule; it's pretty arbitrary which side is listed in which slot. Kirill ^{[talk] [prof]}.

Victors should always be first

In all resolved two-party conflicts, we have always listed the victor on the left when there is a victory. For inconclusive, it hardly seems to matter. For ongoing battles, it would make a lot more sense for two-party conflicts to list the longer-standing, longer-dominant force on the left. In the case of any sort of rebellion, that would mean the established government. This would include civil war. This would include one nation fighting two separate rebel forces. The problem with "who started the fighting" is that one could always argue taht the rebels almost always start the fighting but the usually lose. This logic will make a lot more sense. Those are the qualities that much such a force "more important", but after that "more important" becomes a matter of bias for those who takes sides because then their side is always more important. A problem putting rebels on the left in an ongoing conflict is that it appears biased in favor of the rebels. In the very rare cases where there is no other basis for a well-match conflict involving three groups of belligerents (where, as in inconclusive battles, order hardly matters), then we can fall back to the "order in which combatants entered the battle" as a tiebreaker. That is not NPOV. The only time we should have to switch the columns is when there is a true revolution at which time you can put the rebels on the left.--189.41.26.213 (talk) 04:34, 21 March 2011 (UTC)

For our longer campaigns / wars, should strength represent "total committed" or "at-peak" forces? They can be pretty widely different, for example, in WWII Soviet military manpower was 26.4 million mobilized in total, but only 11 million at peak due to significant losses.

I'm thinking that we might want to either add an additional field for the maximum number of forces commanded at any one point or just recommend that it be placed in brackets as shown below:

Strength
26.4 million men (11 million peak)

Thoughts? Oberiko (talk) 19:57, 31 March 2008 (UTC)

I think the parenthesized version is a more viable approach in the long term; there are a number of different data points that may be of interest in terms of representing strength, and having a separate field for each of them will quickly become unmaintainable. Better, I think, to simply allow the main fields to be free-form. Kirill 01:47, 1 April 2008 (UTC)

Hi everyone, Kirill as much as I respect you for all the work you do for MiliHist, I feel (in hindsight) the change to "belligerant" was a bad idea. It was done in attempt appease warring sides on the Iran-Iraq War article, unsuprisingly they're still warring lol. On a more serious note, it is wrong to change a template that is shown on loads of articles, because of an edit war occuring on just one article. The problem is with the Iran-Iraq war crowd, not the template.

Why does this matter? Well this "POV push" idea of adding countries who supported other countries to infoboxes is starting to spread. The sources for these are often opinions in themselves and the criteria for "support" is so extensive that pretty much every country could appear on the list on both sides! These infoboxes were made to summarise data for quick reading, not to argue over the finer points of conflcit, that's what the article is for (you can't sum up a complex situation as "support" with just a flag symbol). Ryan4314 (talk) 18:16, 4 April 2008 (UTC)

Please take the question up at

WT:MILHIST if you'd like the terminology changed again; the previous discussion on the matter came up with reasons for the switch beyond the particular I-I War situation, so it's not really limited to that. Kirill

04:19, 5 April 2008 (UTC)

Frankly, I agree with Ryan4314: "Belligerant" reeks too much of press-release jargon and adolescent DUBYADUBYATOO gaming sites. Albrecht (talk) 16:34, 7 August 2008 (UTC)

It is not simply about the Iran-Iraq War article, it’s also about correct nomenclature: a “combatant” is a “soldier”; a nation is a “belligerent”. These definitions aren’t arbitrary, but are based on the definitions contained in the

Geneva Convention. See this archived WP:MILHIST discussion for further discussion. Askari Mark (Talk)

18:49, 7 August 2008 (UTC)

You're only cheerleading for systemic modern bias at its worst. Albrecht (talk) 20:56, 12 August 2008 (UTC)

Might it not be a better idea to use "participants"? For example, the infobox on the Sri Lankan Civil War lists the Indian peacekeeping force as a "belligerent", which I think is a little POV, as they were asked to intercede, as opposed to invading. Moreover, a "belligerent" is a term used by one group to describe all the other people they are fighting against, and is generally not used as a self-identifier. MSJapan (talk) 14:05, 19 May 2009 (UTC)

Please, let's not start using current events as the examples for history articles. It only confuses matters. Albrecht's observation is correct, the use of Belligerent makes little sense in discussion of events older than or beyond the scope of the laws of war that drew that fine distinction. Yet Combatant is ambiguous (between states and soldiers). Perhaps "Combatant state" or "State at war" might be sufficiently general for the purpose.LeadSongDog come howl 14:46, 19 May 2009 (UTC)

That doesn't work for non-state belligerents (whether modern or ancient), unfortunately. Kirill ^[talk] [pf] 01:05, 20 May 2009 (UTC)

"Paricipants" or "Parties" seems like a good neutral usage. Blueboar (talk) 00:43, 22 May 2009 (UTC)

The term belligerent and insurgent have specific meanings under the laws of war. An insurgent can not by definition be a belligerent. I looked into this is detail for the start of the

:"A 'combatant' is a 'soldier'; a nation is a 'belligerent'. These definitions aren’t arbitrary, but are based on the definitions contained in the Geneva Convention" - well put, Askari Mark. Changing "belligerent" back to "combatant" will not only be a distortion of its correct meaning, it risks opening up the conflict info boxes of numerous articles to endless POV warring. Also, having additional fields will need very careful thought about what unwanted side-effects could be created (the flag issue alone will be a pov minefield). Meowy 15:58, 22 May 2009 (UTC)

"A 'combatant' is a 'soldier'; a nation is a 'belligerent'". I am not sure where you are getting that distinction from. In the Geneva conventions there is a distinction made between "belligerent power" for example Article 4.B.2 mentions "The persons belonging to one of the categories enumerated in the present Article, who have been received by neutral or non-belligerent Powers on their territory and whom these Powers are required to intern under international law.." and a "belligerent person" article 5 states "Should any doubt arise as to whether persons, having committed a belligerent act and having fallen into the hands of the enemy, ...". Similar wording exists in the earlier Hague Conventions of 1907 See for example Hague IV says Art. 2. "The inhabitants of a territory which has not been occupied, who, on the approach of the enemy, spontaneously take up arms to resist the invading troops without having had time to organize themselves in accordance with Article 1, shall be regarded as belligerents if they carry arms openly and if they respect the laws and customs of war." yet Article 3 says "The armed forces of the belligerent parties may consist of combatants and non-combatants." So a medic in an army is a soldier and an non-combatant. --

talk

) 18:37, 22 May 2009 (UTC)

Oh, my, this contentious issue has raised its hoary head again. Gentle editors, you need to please keep in mind that what was posted here in 2008 is merely a postscript from an extensive discussion carried on in several places, but mainly on

WT:MILHIST

and some of what has been written here previously was written with that context “understood”; it does not necessarily stand on its own and should not be so taken.

Yes, I am (and was) aware of the Geneva Convention’s concept of a “belligerent person”, but it was irrelevant to the issue regarding the infobox, which is about parties, not individuals. The reason for the change from “Combatant” was because that word had proved exceedingly vague (for the purpose of determining infobox content); it allowed – and was being used to justify – POV-pushing in the infobox as to who was a “Combatant”. “Participant” is even more vague. (This had even begun to include nations that had supplied arms, intelligence or even political support to any warring party.) This was, in turn, beginning to drive a need for more complex infobox designs to permit numerous “sides”. Infoboxes are supposed to provide brief overviews as to the composition and leading commanders of the warring sides. The term “Belligerent” was chosen because it clarified the intent, was less subjectable to POV warring, and is clear to modern readers. While it is true that applying the Geneva convention to ancient tribes or insurgents would be anachronistic, I would argue that applying the dictdef term for “belligerent” is understandable and clear to a modern reader – the only kind we have. In short, “belligerent” was chosen because modern technical and colloquial meanings both fit the intent of what is to go into the infobox.

Having several options is possible, but it has two drawbacks: it makes the code complex and it allows the POV camel’s nose back under the tent. I should also point out that no one has complained about being unable to understand the term, and it has indeed been successful in suppressing much of the edit-warring that led to it in the first place. In any case, if there’s a good reason to revisit the consensus (besides

WT:MILHIST, not here – but please do read through the archives first. Cheers, Askari Mark (Talk)

23:36, 24 May 2009 (UTC)

By definition in an

talk

) 16:55, 9 June 2009 (UTC)

Sardanaphalus (talk) 13:19, 8 August 2008 (UTC)

These styles are actually controlled from {{WPMILHIST Infobox style}}, which probably styles a number of other templates as well. You'd need to get a consensus to change the styles there: try Template talk:WPMILHIST Infobox style. Happy‑melon 15:47, 8 August 2008 (UTC)

• Understood. Have transferred request. Sardanaphalus (talk) 17:15, 8 August 2008 (UTC)

For conflicts which have a specific location, this template should have an optional "coordinates" property, with a label "

It'd be pretty trivial to add a dedicated coordinate field, but I see no reason why it would need a separate label; from a reader perspective, both coordinate and general location descriptors should be shown under the existing location field.

Or did you mean something other than a visible label? Kirill ^(prof) 06:35, 31 August 2008 (UTC)

I meant a visible label; it's pretty common to have one where coordinates are included in an infobox; but no problem not to, if the consensus is that it would be inappropriate in this case. Andy Mabbett | Talk to Andy Mabbett 09:31, 31 August 2008 (UTC)

Okay, fair enough. I've added a "coordinates" field that should display just under the existing location; let me know if you see any problems with it. Kirill ^(prof) 17:40, 31 August 2008 (UTC)

Thank you. That seems fine; I've used it at Battle of Blenheim. Andy Mabbett | Talk to Andy Mabbett 17:47, 31 August 2008 (UTC)

This box is being used for massacres and acts of genocide such as the Convincing Ground massacre of aboriginal Gunditjmara people in 1833. While I agree that acts surrounding the colonisation of the Australian continent constituted military aggression akin to a civil war, the use of this infobox seems inappropriate. For example, in the "Result" box it is noted "European victory, a massacre", and the categories of this infobox seem more suited to military conflicts involving uniformed and hierarchical military crew. What is your opinion about the purpose of this infobox?Sumthingweird (talk) 13:03, 1 September 2008 (UTC)

Can we get a section added to notes about using unknown for casualty counts? Geoff Plourde (talk) 19:38, 15 September 2008 (UTC)

I can't see any objections where this has been brought up, so I've added a note. Feel free to improve it. —Michael Z. 2008-09-16 17:51 z

Can (or should) known equipment losses such as aircraft or ships be cited in the "casualties" section of the template, or is that intended for human casualties? --71.112.145.102 (talk) 23:03, 20 September 2008 (UTC)

Adding equipment losses is generally fine, especially for air and naval battles where these are the most common way of reporting casualties.

talk

) 23:31, 20 September 2008 (UTC)

Indeed. If I recall correctly, that's why the label on that field was changed to "Casualties and losses" recently. Kirill ^(prof) 02:11, 21 September 2008 (UTC)

All right, thanks.--71.112.145.102 (talk) 23:33, 21 September 2008 (UTC)

{{

Please add an hCalendar microformat, by changing:

<code>
{| {{WPMILHIST Infobox style|main_box}}
|- 
! {{#if:{{{combatant3|}}} | colspan="3" | colspan="2" }} {{WPMILHIST Infobox style|header_bar}} | {{{conflict|{{PAGENAME}}}}}
</code>

to:

<code>
{| {{WPMILHIST Infobox style|main_box|vevent}}
|- 
! {{#if:{{{combatant3|}}} | class="summary" colspan="3" | class="summary" colspan="2" }} {{WPMILHIST Infobox style|header_bar}} | {{{conflict|{{PAGENAME}}}}}
</code>

Thank you. I will then ask for a bot to apply {{Start date}}. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:40, 24 October 2008 (UTC)

Done. Kirill ^(prof) 00:15, 25 October 2008 (UTC)

Would it be possible to change the infobox to allow a location map? Chamal ^talk 01:23, 27 January 2009 (UTC)

Should be easy enough; I'll implement this when I have a bit of free time. (If it's not done in a week or so, please feel free to remind me!) Kirill 03:58, 27 January 2009 (UTC)

Okay, I've added the needed passthrough parameters for a location map; please try it out and let me know whether everything works as expected. Kirill 01:51, 28 January 2009 (UTC)

Thanks, Kirill. But the location is a bit off. See Battle of Mullaitivu (2009), where I added it but commented out because it showed an incorrect location (Mullaitivu is on the northeast coast, but this map shows a location somewhere in the middle of the country). Template:Location map shows it ok though, so I'm assuming the problem is with the infobox. Chamal ^talk 11:42, 30 January 2009 (UTC)

Oh wait, I used the wrong format for the coordinates. Works now. Nice work, Kirill. Chamal ^talk 12:14, 30 January 2009 (UTC)

{{

Please add the "location" property to this template's existing hCalendar microformat, by changing:

{{{place|}}}

to:

<span class="location">{{{place|}}}</span>

Thank you. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:30, 11 February 2009 (UTC)

 Done — Andrwsc (talk · contribs) 17:00, 11 February 2009 (UTC)

Tested and working. Many thanks. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:17, 11 February 2009 (UTC)

{{

<span class="location">{{{place|}}}</span>

to:

<span {{#if:{{{placename|}}}||class="location"}}>

Thanks. -J JMesserly (talk) 23:25, 18 February 2009 (UTC)

The template doesn't take a placename parameter, so I'm a bit confused about what this is going to actually do; what's the purpose of the conditional here? Kirill ^[pf] 01:51, 19 February 2009 (UTC)

It's just a flag and is not displayed. The default behavior behaves as pigsonwing requested, activating the class since the placename flag is not set. However, for people that don't want the location class behavior, they can shut it off. Name it however you like. I just need an optional shut off on this latest change. -J JMesserly (talk) 04:10, 19 February 2009 (UTC)

Ah, ok. I've added it as no-location-property with an explicit check that the value is "yes"; please test it out and let me know if that does what you want. Kirill ^[pf] 04:26, 19 February 2009 (UTC)

Yes, the passed location text is no longer garbled after the change you made to \doc. You can't see what you fixed unless you install some junk- easy to do if you are interested. Спасибо -J JMesserly (talk) 04:38, 19 February 2009 (UTC)

{{

Please reverse that "no-location-property" edit. As can be seen on Falklands War, the hCalendar microformat now emits an hCalendar metadata "location" property of "Falkland Islands," (note extraneous comma also) and not the correct and intended value of "Falkland Islands, South Georgia and surrounding sea and airspace". Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:36, 19 February 2009 (UTC)

Editprotected is for non controversial changes. Taking a NPOV on the microformats style questions, we should allow contributors to use the location class or not to. Their option. I don't understand why we need to dictate to contributors how they must use this template. -J JMesserly (talk) 19:07, 19 February 2009 (UTC)

Somewhat more to the point, that's a problem with {{address}}, not the infobox; that template should either (a) be invoked differently in that instance, or (b) not generate its own property tags. In either case, the infobox is working exactly as it should (although, once the issue with {{address}} is resolved, you may or may not want to turn off the no-location-property field in that instance). Kirill ^[pf] 00:50, 20 February 2009 (UTC)

Eh? {{coord}} is used in this template (see docs for coordinates template) as part of the same table row. It uses a class on a span (see {{Coord/link}}). It is permitted to be outside this span using class="location". Yet address is not permitted this? Do you propose that coord is also in error on how they are using classes on spans? I propose that the reason for this contradiction is that you are mistaken in your notions about "properties", and the notion that subtemplates used inside infoboxes should not employ them. -J JMesserly (talk) 03:20, 20 February 2009 (UTC)

(undent) Due to the delay, I presume you are mulling this. I'm not sure you are familiar with the background on the mechanics. Microformat parsers recognize their tokens by looking for class values on spans and divs. What is happening is that Pigsonthewing requested placement of a "location" class on the parameter whose value sometimes includes a template that also employs the location class- just not on the entire span. When both are on, then parsers understandably get confused because they see a nested location. There is nothing wrong with Pigsonthewing's request, so long as this automatic behavior can be turned off for those who are doing it a different way. What are the benefits? Well for one, if you have Operator installed, you can see a thousand foot view of a battle site using google or Yahoo maps. step by step instructions for seeing the map function here It's pretty cool. -J JMesserly (talk) 05:56, 20 February 2009 (UTC)

The problem is that the behavior has actually changed between the two instances. When we have:

|place= A, B, and C

the resulting location property is parsed out as "A, B, and C". When we have:

|place= {{address|A}}, B, and C |no-location-property= yes

the resulting location property is parsed out as "A", with "B" and "C" being entirely omitted, since neither the inner template nor the infobox put them in an element with class="location". So either {{address}} needs to be adjusted to take multiple locations as input, or each of the locations needs to be passed into a separate instance of {{address}}; but, in either case, every distinct location labeled as such using one method should be labeled as such using the other. Kirill ^[pf] 13:24, 20 February 2009 (UTC)

There is no question that the behavior has changed. That is by design. According to spec,

A named LOCATION (potentially with an address and/or geo) in iCalendar MAY be represented by a nested hCard in hCalendar. Similarly, an address LOCATION MAY be represented by an adr, and a geo (latitude and longitude) LOCATION may be represented by a geo. (source)

String information emitted by the infobox's current default behavior emits location data whose structure is only implicitly indicated in a single string. The "1000 foot" functionality described earlier for activating Google and Yahoo maps requires further encoding. That is what placename/adress template does. These applications recognize adr data in its own vcard. You were not concrete with your example, so I am unsure what you stating are omissions. Consider

Battle of Fort Hindman. The location string emitted is Arkansas County, Arkansas. This string description of place could longer or shorter- up to the editor to decide. For brevity, they omitted the detail that the location was near Arkansas Post. Anyway, that's parameter 1, and it gets assigned to class "fn" rather than class "location". Where is it? Well, a person could figure out the coord data and put that in, or they could put |locality1=Arkansas Post|locality2=Arkansas county|state=Arkansas. Now the location property is structured. The map applications know what to do with an adr property in the location. They know how to plug properties locality and region into their search engine to deliver meaningful results. So I am not at all clear what you mean by missing B's and C's. In most cases the string description will be less verbose than the structured description. That is the case with wikilinks of the form [[disambiguated article long name|display text name]]. Now, as a technical point, it is entirely possible that placename template could simply emit the adr and for the purposes of talking to a calendar application, we'd be done. However, note from the description that it is permissible to represent location in a nested hcard. That is what gets us the google/yahoo map functionality which by the way, is far more relevant to wikipedia users than sticking battle events from the 16th century into their personal calendars. OK. Maybe military history buffs might, but 99% of the folks would rather see the fancy satellite map. Did you try the Operator example? -J JMesserly (talk

) 17:36, 20 February 2009 (UTC)

Sure; but the point is that the single place field may contain more than one distinct location. In other words, if the place is "England, France, and Spain", then we need to emit either a single location string with all three places, or three location strings, one for each place. It's not correct to emit only "England" as a location string and leave off the other two, as has been done on Falklands War. Kirill ^[pf] 18:20, 21 February 2009 (UTC)

If you want to emit 3 locations, There is nothing stopping you from using 3 instances of placename. You would get map items for each location specified. In the context of usage of the Military conflict infobox such as {{

Battle of Fort Hindman. Regarding the Falklands conflict, there is nothing wrong with placing both locations in {{placename}}[1]

. This delivers the map functionality and displays the location in a calendar application using the data

dtstart=1982-04-02
dtend=1982-06-15
location=Falkland Islands, South Georgia, UK
summary=Falklands War

You have expressed an interest in the data emitted. Did you do some of the mapping examples yet? It brings into sharp focus why this is very relevant to military history articles. -J JMesserly (talk) 01:07, 22 February 2009 (UTC)

In the example given, an hCalendar location value of "England, France, and Spain" would be perfectly acceptable. There is no need for any additional mark-up within that; and it could be achieved without this ill-conceived "no-location-property" edit. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:55, 7 March 2009 (UTC)

(undent) Unsupported assertion: Why is the no location property ill concieved? -J JMesserly (talk) 17:12, 7 March 2009 (UTC)

Why are we still arguing about this, anyways? The no-location-property tag is optional; if you don't want to turn off the property, then you can simply not use it, and the template will behave exactly as it did before the edit. Kirill ^[pf] 17:15, 7 March 2009 (UTC)

I always thought these boxes were confusing, since it's unclear as to whether the leaders were civilian or commanded the armed forces themselves. My proposed solution: italicize civilian leaders, and bold the "top" leader. So for example, for the Union side of the American Civil War, the leaders section would appear as thus:

• Abraham Lincoln
• Simon Cameron (1861-1862)
• Edwin Stanton (1862-1865)
• Gideon Welles
• George McClellan
• Ulysses S. Grant
• David Farragut
• George Meade
• etc.

Lincoln is both bolded and italicized because he was a civilian leader and the top authority in the war. However, for say the Battle of Gettysburg, it would appear as thus:

• George Meade
• Winfield Scott Hancock
• John F. Reynolds
• John Buford
• etc.

-- LightSpectra (talk) 18:05, 15 August 2009 (UTC)

IMHO, allowing an example like "Decisive X victory" in the "result" parameter usage instructions encourages editors to add other adjectives like pyrric, strategic, and tactical. I would contend the use of any adjective in this parameter unfairly colors the infobox with an arguable and non-neutral parameter. I believe such modifiers just beg for repeated and unnecessary discussion on page talk. Such conversation, consisting of much sound and fury, is currently ongoing at Talk:Battle of Gettysburg and doesn't improve pagespace. I'd rather see the page directions be changed for the result parameter on this template. My suggestion: "result – optional – this parameter may use one of several standard terms: "X victory" or "Inconclusive". The choice of term should reflect what the sources say. The use of adjectives describing the outcome is deprecated. In cases where the standard terms do not accurately describe the outcome, the preferred method is to enter a link to the section of the article where the result is discussed in detail (such as "See the 'Aftermath' section")." BusterD (talk) 22:30, 29 August 2009 (UTC)

As one of the people involved in the Gettysburg discussion mentioned above, I'd like to chime in. Personally, I like the use of terms such as "decisive", "strategic", and "pyrrhic ". However, these terms need to be well-defined and applicable to ANY war (not just the ACW). Note, in some conflicts, all of these terms need not be used (e.g., I'm not aware of any "pyrrhic" victories in the ACW, although there might be one or two).

Yet, the way it is right now, there are a few ACW battle articles which use the term "decisive" in the summary box. This encourages editors to apply that term to other battles, which results in endless discussions and, therefore, this is simply unacceptable to me. Until battle results are well-defined (in a separate Wiki article), I think it is best to use simple Union/Confederate victory or inconclusive/draw. Eventually, however, terms such as "decisive", etc. should be implemented. Bill the Cat 7 (talk) 23:06, 29 August 2009 (UTC)

The article itself should spell out the results, with any disagreements in "victory/inconc/whatever" dealt with between sources in the main body or aftermath sections. Also any lead should have an overview this info as well, using something like "Most historians state that... " if there are glaring differences of opinion. And I think the lead is right next to those boxes, right? Then I have to ask, why include it in the box at all?

A while back it was determined to use the NPS results. Is this no longer the consensus? While the optional choice works, I believe that if there is enough sourcing to require anything besides a clear-cut victory or draw result, then we automatically do the reader a great disservice by applying more adjectives and then footnoting them to explain why we're using the terms, all in the @*#&? infobox! Bottom line as I see it: if we use the line, keep it very, very simple; if not, then maybe readers will read the entire article and make up their own minds. Maybe then "decisive" or "strategic" might have to go—deprecated is a good term—and "pyrrhic" can be argued so many ways it is quite useless to include it at all. Kresock (talk) 03:20, 30 August 2009 (UTC)

Listen, like Bill the Cat 7, I enjoy adding those terms (Strategic, Tactical, Decisive, Pyrric, etc...) in articles. What I've seen happen here is that what started as a discussion for just the Battle of Gettysburg as turned out to be a discussion for every war article. Personally, I don't care what you put on any other article, I am arguing only for the term to be used on the BOG article.

Now, onto my argument, if you look at the definition of Decisive victory on the Wikipedia article of the same name, you see that Gettysburg matches nearly every definition that it states.Red Slayer 15:24, 30 August 2009 (UTC)

Here's another discussion in which an ip (in this case) has made a run inserting this contentious material in infoboxes. I'm not interested in discussing the merits of any individual entry; I'm more focused on demonstrating the negative effect of the insertion of any such superfluous modifier. Better to have one central discussion about usage instructions than to have 5,000 recurring talk page debates on the merits of individual cases. BusterD (talk

) 15:35, 30 August 2009 (UTC)

This is a recent discussion on this same subject. The definition of terms seems to have never made it into this template space. BusterD (talk) 15:46, 30 August 2009 (UTC)

The imperative to amend the template rather evaporated in the light of the absense of consensus here.  Roger Davies ^talk 16:27, 30 August 2009 (UTC)

All right then, if the real discussion is about the usage of the terms and whether or not we should use them or not, then here's what I have to say: If you guys want them, then why are we discussing this? If you don't want them, then why did you even put it in the first place?Red Slayer 16:41, 30 August 2009 (UTC) —Preceding unsigned comment added by Valkyrie Red (talk • contribs)

VR has made an excellent point. Bill the Cat 7 (talk) 07:48, 31 August 2009 (UTC)

{{

• Use of CSS instead of deprecated HTML tags.
• Putting rows inside #if tags to avoid duplicate rows (an |- above another |-).

There is no

 Done —TheDJ (talk • contribs) 19:54, 30 August 2009 (UTC)

{{

Please reverse this edit, which is no longer required. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:30, 18 September 2009 (UTC)

Done. Kirill ^[talk] [pf] 04:40, 19 September 2009 (UTC)

This last edit has left extra "}}" in the "location" field. Could someone please remove them? Thanks. Constantine ✍ 07:22, 19 September 2009 (UTC)

I've re-enabled {{editprotected}}. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:49, 19 September 2009 (UTC)

Wow, that was stupid of me. Fixed now. Kirill ^[talk] [pf] 12:56, 19 September 2009 (UTC)

Thank you. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:49, 19 September 2009 (UTC)

Can we increase the header text size and remove the colored bars (at the top at least)? It looks very bad, especially since it doesn't line up with the images below it. Martin Raybourne (talk) 21:12, 22 September 2009 (UTC)

The style is universal across all military-related templates—see {{WPMILHIST Infobox style}} and {{military navigation}}—so any change would need to be implemented across the entire range of templates, not only this one.

In any case, I'm not quite sure what you mean by "doesn't line up"; that seems like a technical problem of some sort, which can presumably be fixed if you can point us to an example of it being broken. Certainly, the colored bars themselves are a somewhat subjective matter; you don't think they look good, apparently, but other editors do. ;-) Kirill ^[talk] [pf] 00:31, 23 September 2009 (UTC)

There's a debate/argument just started at Talk:Battle of Britain#Canadian participation about which nations' contributions qualify for inclusion in the infobox. It may be of wider interest and there may be a definitive answer that we are ignorant of. All welcome to the melee. Folks at 137 (talk) 08:56, 11 October 2009 (UTC)

I need help creating this box. I've gotten this far, but don't know how to go further. Auntieruth55 (talk) 21:36, 5 January 2010 (UTC)

I've created the campaignbox at {{Campaignbox German Peasants' War}}; is that what you were looking for? Please let me know if there's anything else I can do to help. Kirill ^{[talk] [prof]} 05:15, 6 January 2010 (UTC)

Yes, that's what I was looking for. Thanks! Auntieruth55 (talk) 18:52, 6 January 2010 (UTC)

Does one currently exist? The issue here is

Is the problem just the label on the field? If that's the case, then it would be very easy to make that label modifiable on a per-article basis. Kirill ^{[talk] [prof]} 05:58, 7 January 2010 (UTC)

It should definitely be made modifiable . The term currently used is causing too many NPOV conflicts. Marokwitz (talk) 21:56, 31 May 2010 (UTC)

I don't see a field for "alt = text for a description of the image" in the template. This is important to sight-impaired people who use readers, and many other infobox templates which accept images include this. Or perhaps I missed that there is some other method I can use to insert this? Thanks. • Astynax ^talk 19:36, 21 January 2010 (UTC)

The template accepts a full image link in the "image" field, not just a filename; so you can pass in something like [[File:Example.jpg|alt=Alt text]]. Kirill ^{[talk] [prof]} 02:10, 22 January 2010 (UTC)

Thank you, that works. An alt= in the template itself would bring it in line with most others I've used, so perhaps that could be added in future update. Since putting it in the image link doesn't seem to be mentioned anywhere on the doc page or its examples, I'll go over and add it. Thanks again. • Astynax ^talk 06:17, 22 January 2010 (UTC)

Hello.

I was reading some pages in which the template is used and noticed that the caption font is very small, for me almost unreadable. Is it possible to make it a little larger? Would it be a problem to make it as large as the other text in the template?

--TakenakaN (talk) 10:54, 10 February 2010 (UTC)

Hello, I have added icons for belligerents in one battle of Genpei war: [2]. If it is all right, then it can be added to other battles. --Snek01 (talk) 19:25, 18 March 2010 (UTC)

Well, our general stance on icons is

WP:MILMOS#FLAGS; beyond that, it's really up to each article's editors to determine whether icons are useful to that article's readers. Kirill ^{[talk] [prof]}

00:15, 20 March 2010 (UTC)

The middle column in the infobox here is not centered. Anyone know how to fix it? ܥܝܪܐܩ (talk) 02:51, 20 April 2010 (UTC)

Why is the "cause of the conflict" section deleted? Qajar (talk) 01:40, 3 May 2010 (UTC)

There's an RfC at

Hi, my watchlist appears to full of comments from one source at the moment and most of it stems from this template. User:Blablaaa has concerns about the strengths section being used to list formations involved. I can see where he's coming from, even if I don't agree with his argument. Would it be possible to change the template by adding a Units involved section or other suitable wording. We could then display it as

Forgive the highly impressive tables but I think you will get the idea. --Jim Sweeney (talk) 09:21, 19 July 2010 (UTC)

This should be easy enough to implement; I'll do it when I get back from travel tomorrow if nobody objects before then. Kirill ^{[talk] [prof]} 21:51, 19 July 2010 (UTC)

Okay, I've added a set of fields (units1/units2/units3) to display the names of the units separately from the strength. Please test the change out and let me know if anything doesn't work as expected. Kirill ^{[talk] [prof]} 01:25, 23 July 2010 (UTC)

The "Commanders" section is proving problematic as editors insist on listing prime ministers, who are not military commanders, within this section (see

Easy enough; I've changed the label on that field to "Commanders and leaders", which should cover all the things it's usually used for. Kirill ^{[talk] [prof]} 23:53, 16 August 2010 (UTC)

That's great. Thank you. --

MIESIANIACAL

03:54, 17 August 2010 (UTC)

Hello, I am proposing a new field for "civilian casualties" since these are supposed to be separate from "actors" in a civil war. This section could go just below casualties as a single section. Thanks. --Amnesico29 (talk) 06:19, 30 October 2010 (UTC)

The usual convention is to list non-differentiated civilian casualties in the "casualties3" field; if only two sides are present, this field will automatically align itself where you suggest. I don't think we need to add an entirely separate set of fields, given the circumstances. Kirill ^{[talk] [prof]} 18:13, 30 October 2010 (UTC)

I tried to use that but, it looks terrible. It makes civilians look like "belligerents". --Amnesico29 (talk) 23:18, 31 October 2010 (UTC)

How is that? The label on that field shouldn't have "belligerents" in it, unless I'm very much mistaken. If there's any confusion, then the contents of the field can be explicitly labeled (e.g. "25,000 civilian casualties") to make it clearer what the numbers refer to. Kirill ^{[talk] [prof]} 23:32, 31 October 2010 (UTC)

I don't know if this has been mentioned before, but shouldn't the infobox include a

There used to be one a long time ago, actually. It wound up being removed because, as you say, wars are waged for complex reasons, and nobody could agree on whether the field should contain the official pretext cited for the war, the real reason for it, or some combination of the two. Kirill ^{[talk] [prof]} 14:10, 31 October 2010 (UTC)

{{

Generally speaking, colors have absolutely no effect on computer usage; modern computers require exactly the same processing and power consumption to display white as they do any other color. Kirill ^{[talk] [prof]} 07:08, 18 December 2010 (UTC)

The current colour scheme looks good to me. An all-white template would be boring. Nick-D (talk) 07:13, 18 December 2010 (UTC)

IMO it looks fine the way it is currently. Anotherclown (talk) 08:35, 18 December 2010 (UTC)

{{

Done. Kirill ^{[talk] [prof]} 02:17, 4 January 2011 (UTC)

Has anyone else noticed a reduction in the font size of the date, location and result fields? Is this the result of a deliberate change or a bug? Thanks, -- Black Falcon ^(talk) 02:21, 1 March 2011 (UTC)

It was caused by this edit to the main CSS configuration; because this infobox invokes class="infobox" twice, the 88% font size was also being applied twice. I've now removed the nested class, which should fix the problem. Kirill ^{[talk] [prof]} 03:15, 1 March 2011 (UTC)

Yes, that did it! Thank you for the quick response, -- Black Falcon ^(talk) 18:08, 1 March 2011 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

I would like to propose a minor change to this template to allow for the inclusion of campaignboxes in a way that allows both this box and the trailing campaignbox to act as a single floating unit. As most editors probably know, if you have two infoboxes (or other right floating elements) in sequence, and then try to add a left floating element, the left floating element cannot float any higher than the last right floating element. An example of this can be found here, notice how the left floating image is pushed down, and if you resize the browser window, it changes the location of the left floating image. The traditional fix has been to wrap both infoboxes in template:stack begin/stack end or use template:fix bunching. This is a bit messy, and frequently editors mistakenly remove either the "begin" or "end" of the stack (or fix bunching). I am proposing to move this code into this template using a |campaignbox= parameter, and this template would then add the necessary stuff needed to make this infobox and the trailing campaign box float as a single element. The code that makes this happen can be found in this version of the sandbox. A demonstration showing how it works can be found in this version, which is a simplification of this version, which uses the "fix bunching" template or of this version, which uses the "stack begin" template. Essentially what has been done is to move the code for "stack begin" or "fix bunching" into this template, so that editors do not need to add these templates, and this template takes care of adding the necessary code to wrap the elements. Please post any comments, questions, suggestions, objections here. If there are no problems, I will make a formal edit request. Thank you. Frietjes (talk) 16:09, 5 May 2011 (UTC)

Having done some testing, I don't see any problems with the new implementation. Kirill ^{[talk] [prof]} 23:48, 5 May 2011 (UTC)

Great. I will make a request. Please update the template to match this version of the sandbox, and I will update the documentation. Thank you. Frietjes (talk) 15:23, 6 May 2011 (UTC)

Done. Plastikspork _―Œ^(talk) 15:55, 7 May 2011 (UTC)

I'm posting here in the hope that we can get some clearer guidelines on what goes in the Commanders parameter of the infobox. There have been several instances of disagreement on this topic, with one user adding the leaders of national forces regardless of their importance in the order of battle. For instance, here, he added Albert of Saxony as a commander at the Battle of Königgrätz, while here he adds the Prince of Orange as a commander at Waterloo. The latter edit led to a discussion on the talk page, in which a clear consensus was to include only the most senior commanders. I believe that consensus fits with previous discussion on this page, where a desire to see only the leaders with senior control of battlefield forces included.

Unfortunately, a user (he denies being the same one) has returned to re-add Albert, despite his only being a corps commander - one of eight present in the Austrian force. Various back-and-forth arguments are getting nowhere, so I'm coming here so that the wider community can have a say.

I think my position is clear. The commanders listed should only list the senior commanders of the individual forces present. That's simple in the cases of battles like Gettysburg (Meade vs Lee), more complex in cases like Königgrätz, where the Prussian force took the form of three separate armies with one Field Marshall in charge, and even more so with something like the First Battle of the Marne, where ten or so different armies took part. What we should not be doing is including corps or division commanders purely because they were made up of different nationalities, as it would lead to huge lists of commanders in, for instance, the Napoleonic Wars or similar conflicts.

Please let's get some guidance on this one way or the other. rpeh •T•C•E• 13:18, 26 May 2011 (UTC)

I expressed my opinion on the issue in length on the Talk:Battle of Königgrätz#Austrian Commander, but I'd sum up my position in these points:

1. Template documentation says: "[...] the commanders of the military forces involved. For battles, this should include military commanders (and other officers as necessary)." - (there's even a possibility of including other officers than commanders (!) - certainly not any limitation on the Commanders of the army only. I certainly believe that a senior commander of the national contingent (as I've already made known to rpeh
   , Albert was comanding the Saxon Army Corps, not one of Austrian Corps) falls under the category "commander of the forces involved", even though not being the Commander-in-Chief of the forces involved.
2. I also believe my position is backed by the current practice when the subordinate commanders of different nationalities are quite commonly listed in the infobox - e.g. Lepanto; Lützen; Trafalgar; Dürenstein; Albuera Battle of Britain - (Corso-Fougier's command was subordinated to Kesselring's Luftflotte 2); Stalingrad; Okinawa Battle of the Ch'ongch'on River etc.
3. It's potentionally confusing for a reader when there's a national flag in the "Combatant" line of infobox, but there's no commander listed under such flag - which is perhaps OK, if the force was completely integrated into a formation of an other nation, but not quite good when the force retained its distinct identity within the command.
4. In general - I support (at least) the inclusion of a commander of an Allied force in the infobox when they had been commanding a notable portion of the force involved in the battle (typically not a GOC commanding a single brigade in an army), and had been directly under the Commander-in-Chief in the chain of command, to give to a general reader a quick reference on notable commanders involved. And let it for discussion on the individual talk pages if the question of individual commanders importance is not completely clear-cut. (And perhaps to include even subordinate commanders of the same nationality, given their performance was for some reasons notable in the battle - e.g.
   Siege of Toulon
   .) Which I believe was not a point of dispute, prior to rpeh's edits.
5. I would also suggest adding a footnote explaining what command the respective national subordinate commander held, when necessary, so as to prevent any possible confusion regarding the chain of command.
6. I do not surely want to overcrowd the infobox with commanders of every conceivable national contingent present in the battle, regardless of their importance in the chain of command, just to fairly represent commanders of notable national contingents in the battle.
7. Purported necessity of adding other Austrian Corps commanders too is clearly a false dilemma on rpeh's part, as these other commanders fail to meet the same criteria as Albert, who is notable as a commander of the Saxon Army contingent in the battle. I do not believe the question stands "either every single commander OR not one".

And of course I denied being identical with the IP rpeh accuses me to be. Because I am not. And do not get personal rpeh, please. Tom soldier (talk) 15:28, 26 May 2011 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Could you possibly add the parameters combatant4 and combatant5 please? Otherwise the infobox on Browser wars won't work (there's too many layout engines). Island Monkey ^{talk the talk} 07:19, 8 June 2011 (UTC) Island Monkey ^{talk the talk} 07:19, 8 June 2011 (UTC)

Don't think that's a military conflict! In any case, the documentation says "When there is a large number of participants, it may be better to list only the three or four major groups on each side of the conflict, and to describe the rest in the body of the article." I'm declining this request for now, please reactivate if you get a consensus for the change. — Martin (MSGJ · talk) 08:20, 8 June 2011 (UTC)

As Martin points out, this template is designed for actual military conflicts, not metaphorical ones; I'm fairly certain that no real-world war has had more than three simultaneous "sides" at any single point in time.

In practical terms, having five columns would reduce each column's width to the point where the text would become essentially unreadable. Kirill ^{[talk] [prof]} 10:44, 8 June 2011 (UTC)

I agree with Kirill: there's no military conflict that I'm aware of that involved more than three factions (not many involve more than two) and changing the infobox so that it can be used in an article which it's not suited to doesn't seem justified. Nick-D (talk) 11:12, 8 June 2011 (UTC)

Use of either this template or {{Use dmy dates}} will not add extra space (newline) to an article, but their use together (the dmy tag on top) will. See Bosnian War for example; the only tags in use are this and the dmy tag, and there is an obvious extra newline. The problem will not be triggered if the dmy tag is after this infobox. Int21h (talk)

I couldn't come up with a simple fix, but I was able to fix it by switch the template to use raw html, which is more robust in terms of whitespace (and is used by {{infobox}}). I will do some testing in the sandbox, and check a dozen articles or so. If it works, I will sync my changes with the live template. Thanks! Plastikspork _―Œ^(talk) 21:34, 11 September 2011 (UTC)

Could we add a parameter that lets us change the size of the red dot (or 'mark') on the map? Template:Location map has this option. I think the current marksize is too big, especially for marking the locations of small battles. ~Asarlaí 03:45, 17 December 2011 (UTC)

I've added the parameter as |map_marksize=; please try it out and let me know whether it works as expected. Kirill ^{[talk] [prof]} 21:46, 17 December 2011 (UTC)

It seems to be working fine. Thank you. ~Asarlaí 13:13, 18 December 2011 (UTC)