Template talk:Infobox former country/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Constant area with changing population over time.

I don't know if this has come up before but I figure that it is going arise before too long.

When showing population and calculating pop density —is there a way to hide the stat area if the area becomes constant? For example, the area of former country X was 20,000 sq km and never changed. However, the population (and hense the pop density) grew dramatically over time. It looks like the way the template is set up now you would have to display 20,000 sq km (and its converted sq mi) for each year the the population and population density is displayed as well. It might be better to figure to a way to display a range of years for the area when needed. I don't have a specific example of this but it was just a thought. —MJCdetroit 16:00, 13 November 2006 (UTC)

This problem was taken care of when there were separate year variables for area and population. Now that there is only one year variable for both, the problem has come back. If we reintroduce these variables for year, then we lose the ability to calculate density. There has to be a way to do this. Maybe if you enter the same area for each population value, it might be possible to hide an area entry if it is the same as the previous one. - 52 Pickup 16:24, 13 November 2006 (UTC)

I think I've got it. It is still necessary to enter all area values, but now stat_area(x) will not display if it is the same as stat_area(x-1), but population density appears to work. - 52 Pickup 16:46, 13 November 2006 (UTC)

I'm not really that keen on the idea of displaying multiple values on statistics in the infobox for most entities, but I do see a value in it for states that has existed for a very long time or has undergone significant geographical changes. The idea as it is implemented at the moment is to display population density only when data on the area is provided for the same year. If there is no change in area population estimates may still be given for other years but no population density will be displayed and I believe that is what is in question here.

If it can be implemented neatly I think it should be done, but I'm more worried that a bad solution would add a whole new level of complexity that is not necessarily needed. A solution based on testing each iteration would have to take into account not only whether there is any change compared to the first value, but also successive comparisons for the rest of the values in each case.

We should not discount the fact that displaying the value for area also gives the information to the reader whether the area has changed or not. Were there are several values but not all displayed, how would the reader be able to determine when change did or did not take place? -- Domino theory 00:25, 14 November 2006 (UTC)

This is a tricky question, and different people will probably have different answers. Here's how I see it. If one sees area, population and pop. density for 1800, but then sees only population for 1900, then the absense of a new density term implies that the area has changed to some unknown amount. But if a density value is also given for 1900 with no area value for 1900, then it is implied that the area has not changed from the previously given value (something the reader can calculate themselves). Displaying the 1900 area term when it is no different to the previous value seems to be rather redundant.

Following this logic, this is why I have currently set the area to be hidden only if it is the same as the previous value, not the first one. This leaves the minimum room for error in coding and comprehension.

In most cases, we do not have multiple values for these statistics, so it is not a major problem. - 52 Pickup 10:21, 15 November 2006 (UTC)

I saw afterwards that the sollution you mention has been implemented, and I think it's good and simple. In most cases there shouldn't be multiple values for statistics, but there is a definite advantage to have the ability to add more than one figure in certain cases. -- Domino theory 13:24, 18 November 2006 (UTC)

New prototypes

I have come up with a few new possiblities for displaying the flag-navigation when the number of entries is high. The SFRY is a good example to work with and so I have three versions of that infobox here. For the moment, the templates used to make these should only be used for testing purposes.

This extended flag navigation should probably only be used if the number of entities is larger than 3 (3 is perhaps a better limit than 5, within the current design). This is why in these examples, the single preceding state is displayed at the top as per usual but the 5 successors are only at the bottom.

But, who knows? Maybe all flag navigation should be transferred to the bottom. If so, care should probably be taken with the length of link names to help keep things tidy. But one thing should be fixed: the dates should be kept where they are at the top to emphasise that this state no longer exists.

Comments? - 52 Pickup 15:08, 16 November 2006 (UTC)

I like Template C the best. One suggestion (a weak suggestion) maybe to have a "multiple successor states see below" or something similar in the date row. —MJCdetroit 17:12, 16 November 2006 (UTC)

C was my favourite out of the three too. The alignment of the flags looks the best here, but I'm still not sure about the alignment of the text: to the sides looks good only when you have a flag for each entry, so maybe it should be centered again.

I've just put up version D. This includes, as you suggested, something to indicate that the reader should look below - this is currently in the form of a down-arrow that links to the bottom of the infobox if this new section is created. The big difference between version C and D is that the separate pn/sn variables are no longer needed in version D. If only p(1-3) and/or s(1-3) are used, the flags are shown at the top as per usual (with a low number, i still like to have the flags up the top). But as soon as p4 and/or s4 are used, the bottom section is created; and the 4+ flags that would have been at the top are replaced with the down-arrow link. What do you think? - 52 Pickup 11:29, 17 November 2006 (UTC)

I think they are really good proposals! Alternative D is clearly the best of them. I prefer the flag alignment of C and D for succeeding entities, and D adresses also the question of displaying something for succeeding entities at the top when they've been moved. I haven't looked at the sollution just yet, but automating display features and eliminating the extra variables is clearly in the right direction. I like it. :)

In more general terms I think there are strong reasons to retain some form of navigation features at the top of the infobox. One of the reasons for this is that it enables stepping between different succeeding and preceding entities with out the need of having to scroll further down into the article. I think this is an important feature to have, if not crucial, since Wikipedia articles rather than being "read" from top to bottom, are "surveyed" by users.

From an information perspective I think that the years of existence are the most important. It is also a factor that sets it out versus the extant countries and entities. From a functionality perspective however I find that the navigation feature at the top is the hardest to be without.

There is a real problem of displaying too many flags at the top and three certainly takes less room that five, but I would be cautious of removing every navigation feature from the top as soon as a given number is exceeded. I think there is a good reason to display the main successor state, sometimes official successor, at the top even if there are several or many entities. The Soviet Union would be one example, where Russia is both the main and official successor, albeit not the only succeeding entity. The priority between different entities in such a case is not explicitly a question of importance, but rather one of relevance. -- Domino theory 13:10, 18 November 2006 (UTC)

When possible, everything should be at the top, but there has to be a limit. I chose 3 on purely aesthetic grounds. But the dates are vital and must be at the top. Listing every single entity is not normally a good idea. For example, going from the Confederation of the Rhine through to modern Germany, only the major entities have been given. Listing every single state within the infobox makes no sense and is better handled in the article text or at a subdivisional level (like what i've been workin on with the Prussian provinces). But for some cases (eg. SFRY), you need to list everything.

For the Soviet Union, the Russian Empire is the predecessor, but the CIS would be the correct successor. - 52 Pickup 21:57, 19 November 2006 (UTC)

What I am thinking of is the succession of states according to international law. Serbia, to take another example, is the sole successor state of what was once Yugoslavia. -- Domino theory 23:56, 19 November 2006 (UTC)

While that may be technically correct, I think that might be misunderstood by many readers. This is clearly a grey area. - 52 Pickup 12:08, 20 November 2006 (UTC)

Technical or not this is something that we need to relate to, but strictly adhering to it that may be another question. -- Domino theory 21:49, 20 November 2006 (UTC)

Yes. A bare minimum should be the legal successor state. Anything else has to be dealt with case-by-case. - 52 Pickup 13:18, 21 November 2006 (UTC)

With the limit of how many variable should be at the top or bottom, I'm now trying to see if there is a way to vary this amount without the use of the extra pn/sn variables (which i think we should phase out if possible). - 52 Pickup 13:18, 21 November 2006 (UTC)

Yes, good riddance get the pn/sn out. I don't think they have ever been used. -- Domino theory 21:34, 21 November 2006 (UTC)

Legislatures and constitutions

The footnotes section has virtually been the only place where there has been room to enter information about legislatures and constitutions in the infobox. An optional section for legislatures has been opened up, and currently handles three variables "legislature", "house1" and "house2". It is currently positioned under the government and leaders section in the infobox. Some more more functionality should probably be added like, automatic display labeling of upper and lower houses as well as the opportunity of changing these lables.
Constitutions are sometimes added to the events section, but it is probably appropriate to a separate variable for this. A simple "display all" variable like the one for language or currency should be suitable. These possible additions also opens up the question how to best display the entire government, leaders, legislatures and constitution segments. They are interrelated and better sollutions than the present one is likely to exist. -- Domino theory 20:45, 19 November 2006 (UTC)

Interesting. I never thought about this type of information. - 52 Pickup 12:08, 20 November 2006 (UTC)

(broken remainder text off to new section)
It's a nice idea, although only the more modern states may be the only ones who could use it. One sugesstion is the removal of the need to have something in the "legislature" field. I tried applying it to the Kingdom of Prussia, but I couldn't think of what to put there, so I added a blankspace so the other fields would show up. What do you recommend? - 52 Pickup 09:56, 21 November 2006 (UTC)

The legislature field is for the name of assembly, and there is always a name even if an article may or may nor exist. If it is a single chamber legislature, it is unlikely to have a separate distinguishing name from the legislature as such, and only the legislature variable is used. If there are two houses their respective names are used. If articles exist wikilinks can be used, and if articles are created they will become wikilinks automatically if the correct names have been entered. There are examples of legislatures with three or even four houses, but these can be added eventually as the need arises.

For Prussia the Landtag is the name of the entire legislature, while the two houses are named Herrenhaus and Abgeordnetenhaus respectively.

Southern Ireland is the first instance where the new variables were used. While we're on the topic there is also a condition that exists with the commonwealth realms, where aside from the monarch there is also a personal representative in the form of a governor-general, and a prime minister. It would be possible to add a third position as such, but I wouldn't want to see that used to add junior ministers or other miscellaneous state officials. Another option is to decide whether to list the monarch or the governor-general as leader in such a case. -- Domino theory 22:46, 21 November 2006 (UTC)

Allowing a third entry for personal representatives for commonwealth realms is an excellent idea. Perhaps this should be allowed also for colonies? Many colonies had a head of state (the monarch), an elected representative (prime minister) and the monarch's representative (governor: modern governor-generals are the successors of colonial governors). A while ago, I was experimenting with an infobox for the former version of my home state of New South Wales (please do not implement this particular infobox anywhere, it's just a test) and discovered these problems. An extra field would help. But you're right, this should only be used under the right circumstances. - 52 Pickup 07:57, 22 November 2006 (UTC)

I think calling it governor and placing it in between leader and deputy would hopefully solve most problems relating to inappropriate use. -- Domino theory 11:23, 22 November 2006 (UTC)

In one of my test templates I have added the governor field and applied it to my New South Wales example. It works very well, as do the new legislature fields (very nice). I have not added the governor field to this template yet because I am unsure what to call it. Saying "governor" is fine by me, but it might confuse some (considering the state leaders in the USA are called Governors). Is there something else that we could use? - 52 Pickup 17:00, 22 November 2006 (UTC)

I'm still interested in including the "governor" field. At the moment, one of my test infoboxes here contains the governor fields, but I'm still not sure if the field should be named that or not. - 52 Pickup 16:42, 27 November 2006 (UTC)

I'm also for it, within the limitations that we discussed. There are basically three options: Adding in above, in the middle or below leader and deputy. I think above or in between would be the best choices and there are advantages to both. Adding it above it could be called "supreme" (supreme leader) for the head of state of the controlling empire. This would make leader and deputy correct for the entity in question while adding the possibility of additional and vital information. Adding it in between it could be called "representative" (representative leader) and this would signify that the governor is merely a representative of the highest leader. Adding it below would open up for more misunderstanding and unindented use, and this would be the least attractive option. -- Domino theory 23:28, 29 November 2006 (UTC)

I'd say middle. Many people would already understand "leader" to be the uppermost leader. Even though a "supreme" field can be useful, it might be potentially more confusing than putting this extra leader position in the middle. The other alternative is both above and in the middle, but that is perhaps too much. If we place it in the middle and mark it as optional, that should make average use pretty straightforward. Of course we can bend the rules when necessary regarding what each of the three fields is for on an individual basis. - 52 Pickup 14:20, 30 November 2006 (UTC)

Government type

(broken off from above section)
One government thing that we need to take care of is what figure out what to do when a government changes type, such as the discussed case with the Kingdom of Yugoslavia. If we don't make the presentation of this area clear enough, there will always be disagreements. For the Kingdom of Prussia article, I mentioned the change in government as an intermediate event - but that might not be enough. Until this is cleared up, I think it is better to have certain entries not fall into the right categories. Better to have something not fit than to force it to fit in a way that readers and editors do not agree with. - 52 Pickup 12:08, 20 November 2006 (UTC)

The "government_type" variable is meant to be really simple and fundamentally there are only two types of basic scenarios, either "Monarchy" or "Republic". If a monarchy stops being a monarchy it probably warrants a separate article like with the transition from the Kingdom of Prussia to the Free state of Prussia. If you are in a position where you have to add both Monarchy and Republic to the same infobox, I would say that the problem is not the infobox but the article. If an absolute monarchy changes to a constitutional monarchy and still considered the same state, it is still a monarchy and the change can be added as an event. The classifications of socialist state and communist state, were I believe introduced before the status variable, but they would likely be better suited as status values than as a government type. -- Domino theory 22:10, 20 November 2006 (UTC)

I have just made some further changes in the Instructions about this: "If a change in government takes place without the country itself changing, place the earlier government type in this field, and give the change in government as an intermediate event (eg. event1)" - how's that?

Regarding the options for government_type, we must be careful to avoid confusion. Simplicity is good for us as developers of the infobox, but may be too constrictive for infobox users, and in the end we have to cater to the user. Most editors are used to the format in the Country Infobox and I think we need to allow for more complexity in the government_type field. This means allowing for a few more government types, such as "Confederate republic", "Confederation", "Grand Duchy" (see Luxembourg), "Principality" (Monaco), and a few others. If we revert too many changes in places where we can instead improve the infobox to give more flexibility, then we will only alienate others. - 52 Pickup 09:56, 21 November 2006 (UTC)

I have been leaning towards giving monarchies the label "Constitutional monarchies" if that had been achieved when they ended, but I think that you summized a rule that would work well.

Only allowing two different types of government might be a little bit over simplistic, and there is definately more potential to be gained from that variable. What I want to make sure is that a coherent system is built, which maintains a clear separation between what is a government type and what is a status type. Status exists partly to enable entities that retains a specific relationship to other entities to have a government type of it's own. Examples of such specific roles of relationships can be empires, colonies, client states, vassals, state unions, federations and confederations. This means that the Confederate States of America would have Confederation as its status and Republic as its government type to take an example.

During this entire process with the project there will be various kinds of problems and contradictions that turns up and that we need to solve. One current problem is the apparent contradition of having the Confederation of the Rhine being a client state (status) and a confederation (government type). This might suggest that we should allow confederation to also be a government type, but this would then break down the rule of separation and lead to more confusion. The sollution lies in that the Confederation of the Rhine is not a state, and we should not label it as such. This does not mean that we should exclude this type of entities all togeather, but there are limits to what can be said about government type when such a thing as a government might not even exist.

A kingdom is a monarchy where the monarch is a king. A sovereign grand duchy is a monarchy where the monarch is a grand duke, but grand duchy that is a vassal would be a principality. A principality is below the level of a monarchy, but a sovereign principality would be very close to the position of what a monarchy is. -- Domino theory 21:31, 21 November 2006 (UTC)

My concern about all of this is that we will soon be applying this infobox to the hundreds of states of the Holy Roman Empire. Before we start on that, we need to have some clear rules set out where functionality is preserved and where users and readers are happy. - 52 Pickup 08:01, 22 November 2006 (UTC)

My contention is that contradictions and various other problems will arise out of the complex relationships that has existed over time between the different entities in Germany and Central Europe until the end of World War I. This is the reason why I have suggested a coordinated effort on not only the HRE but also the following entities up to 1918. One of the forseeable problems is the fact that states of princes that were at one time vassals to the emperor later became sovereign states and then again reverted back to become subnational entities, all the while they as sovereign states also were members of various confederations. Beside these kind of forseable and apparent contradictions I also believe that we will see other kinds of interesting problems that we need to solve. It would be better to start with a smaller number of entities and look at the entire period, than covering all entities and limit it to the HRE. It would hopefully spare us from having to re do work more times than necessary for many entities as new problems arise. -- Domino theory 10:52, 22 November 2006 (UTC)

Good point. Small steps is better at this point. - 52 Pickup 17:43, 22 November 2006 (UTC)

Pre- and post-events

For many cases, the inclusion of events that took place outside the official life-span of the entity can help in telling the story. For example, some countries passed their constitution before the country itself was established. Also, some events after the end of a nation are important for that nation. For example, the Treaty of Saint Germain (1919) was an official dissolution of Austria-Hungary, even though the Austro-Hungarian union was itself dissolved in the previous year (and 1918 is widely considered to be the end-date for Austria-Hungary).

And so I have created two new fields pre-event1 and post-event1, each with their corresponding date fields. Filling in these fields places the event either before event_start or after event_end. They should be used sparingly, but they have their uses. It is better to have something like this than to have these events listed between event_start and event_end, leaving events displayed in non-chronological order. If necessary, more fields can be created but that can be easily done at a later date. - 52 Pickup 12:55, 21 November 2006 (UTC)

I agree that there might be cases where there may be a need to include pre- and post-events. However as a general rule I would most likely prefer using formal start and end points over informal, and this might mean that I have an even more restrictive view of how sparingly these could be used. Referring to Austria-Hungary I would say that the Treaty of Trianon (1920) virtually is just as important the Treaty of Saint Germain. -- Domino theory 23:22, 21 November 2006 (UTC)

They have their uses, but they should be used sparingly. The thing is this: people will place relevant events outside the official life-span anyway. So it's better to be prepared for it rather than revert all the time (we're pretty busy with clean-up work as it is). The Treaty of Trianon is very important: the only reason why I haven't put that in is that I only put in 1 pre/post event. Maybe I'll put in a 2nd set, but that should be all. - 52 Pickup 08:11, 22 November 2006 (UTC)

Do we really need a second? Mention them as treaties and then explain it as footnote. -- Domino theory 11:05, 22 November 2006 (UTC)

True. One is useful, but two is overdoing it. - 52 Pickup 17:39, 22 November 2006 (UTC)

I will revise that as I'm fixing the date display. I has been kind of dysfunctional for a while, but it will accept date as free text with wikilinks and as a back up it will also accept date and/or year given spearately. -- Domino theory 17:17, 23 November 2006 (UTC)

Handy trick for maps

Some old infoboxes (eg. the older one from Austria-Hungary) had two maps, which looked quite good. It is still possible to have multiple maps using this infobox. All you need to do is use the image_map_caption field: enter the caption for the first map (entered using image_map), then add a line-break, then the image of the second map (with full wikicoding, setting the image size to a maximum of 260px), then another line break, then the caption for this second map. So now Austria-Hungary has been modified to look a bit more like the older version. This isn't something that would be needed too often, but it does have its uses: eg Allied Occupation Zones in Germany.

This cannot be done for the flag and coat of arms images because the captions are set to be wikilinked. Maybe we should change this to allow a bit more flexibility. It can't hurt. I'll see what I can do. - 52 Pickup 16:36, 21 November 2006 (UTC) Nah, scratch that about the flag and coat of arms. Too messy. - 52 Pickup 16:49, 21 November 2006 (UTC)

This will make the infobox become even longer. Are you sure that this is a good idea? I quite like the limited length, since it limits how far down one needs to go into the page in order to find the information contained in the infobox. -- Domino theory 23:31, 21 November 2006 (UTC)

This is not a feature that will be advertised in the instructions. Some infoboxes on other-language wikis are very long. But you're right, it can make it a little awkward in terms of getting to the information at the bottom. This trick can also be done with the footnotes field so as an alternative, I've altered the Allied-occupied Germany page in this way. - 52 Pickup 08:21, 22 November 2006 (UTC)

I think it works a lot better at the bottom of the infobox. This could be done a separate free field from footnotes, but I'm a little wary over that possibility since we would have very little control over its use. It may also look quite different with flag navigation at the bottom too. -- Domino theory 11:12, 22 November 2006 (UTC)

It is probably best if we keep this as a "secret" feature instead of creating a new field - creating a separate field implies to some that it must be filled in. If flags are placed at the base of the infobox, would you prefer them above or below the footnotes? I would say above, but I thought I'd check. - 52 Pickup 17:38, 22 November 2006 (UTC)

Latest update

I did a drive to update the template and to implement a few changes. One of the most important reasons for this was to catch-up with ther error handling and reduce the number of articles placed in the maintenance category. A new feature is that the template will display warning messages if variables are not used correctly. Specifically this concerns the continent, common_name and government_type variables that will have messages displayed at the top of the template or appropriate section. As part of this drive support for a few more categories has been added including categories for federations, confederations and principalities. There is room for more development, but the new implementation works quite handy and has cut the number of articles needing attention. There is also increased incentive for editors to correct errors and read up on functionality themselves. -- Domino theory 00:35, 27 November 2006 (UTC)

Very nice. The warnings stand out, but do not take up too much space. It's good that you did not put up a similar warning for "era". Maybe the warnings could link to the instructions page? Nice work rearranging the instructions page too. - 52 Pickup 16:38, 27 November 2006 (UTC)

Just noticed that the government_type warning is in the infobox, blocking out whatever was there before. I think it might be better to have that warning at the top with the others, and display whatever government_type value was given. To those filling in the infoboxes, the warnings are important, but not to the average reader. - 52 Pickup 16:53, 27 November 2006 (UTC)

It didn't make sense to have warnings for era, however it might make it into a sort of hybrid variable/free field and I don't think that is necessarily a good idea. The basic idea about the warnings is for the editor to get it right the first time, or that some one performing maintenance will spot the error quickly. I agree that all of the warnings should link to the appropriate section on instructions page. Government_type determines the placement for a number of crucial categories, and only valid values should be allowed there. My intention is to extend the number of available options for government_type, but I'm also concerned that the system should be consistent and preferably not overlapping. It would be nice to collect all warning messages at the same location, but I don't think it warrants a double implementation of the same condition set to satisfy that. I also think that we should strive to make further updates relatively uncomplicated to perform. -- Domino theory 23:07, 29 November 2006 (UTC)

It is a shame that the current string functions only look at the whole entry, instead of picking out parts. For example, it you added any type of republic, it would be nice if you could search just for the word "Republic" within the entered text to work. This way, multiple entries in this field could then be accepted without any trouble. With the current string functions, not even footnotes are acceptable. There are some new string functions in the works over at Meta which may be helpful if they are ever installed here, so we should keep an eye on these developments. - 52 Pickup 14:35, 30 November 2006 (UTC)