Template talk:Infobox Former Country/Archive 1

From Wikipedia, the free encyclopedia

 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.
Archive 1 Archive 2 →


Contents

Suggestions

Please send all suggestions and feedback to my talk page — 52 Pickup 15:42, 20 September 2006 (UTC)

I will send you a notice that I posted here but for continuity and for histroical reasons all suggestions and feedback should be posted on this page.

I think it looks pretty good so far. I tweaked it a little. Here's what I did:

  • Removed the {{{foot5}}} field. This is in the Template:Infobox Country to satisify a need in the France article.
  • Fixed a minor typo — kmv -> km². Looks like you forgot to press ctrl.
  • Added (optionally) pop density per sq mile. Per WP:MOSNUM and for other non-metric folks like me! :-)

Suggestion.

1.) You should have an empty syntax field either here or on the template page.

2.) The year of the area need to be displayed. In your German Empire example, the area is from 1914 but is not displayed. Also, maybe a notation stating the height of the empire, e.g.
area
 -1891 (at it's zeinth)     5,000,000 km²

Regards, MJCdetroit 16:59, 20 September 2006 (UTC)

Thanks for the comments, and for making those changes, both here and on my province template. Regarding your points
  1. Good idea - I had made some syntax notes within the template (commented), but perhaps they should be put somewhere more visible.
  2. Adding the year for the area is already there in the template (identical setup to the population fields), but I had commented it out and forgot to turn it on again. Pointing out the zenith is also a good idea.
I'll have the changes done in a day or so. — 52 Pickup 17:28, 20 September 2006 (UTC)

Known area, unknown date

Sometimes only one area value is known. If you only have one area, this can be for two reasons:

  1. The area never changed during its existance.
  2. The area did change, but it is unknown which date corresponds to this area. This makes it impossible to calculate population density.

In both cases, it makes the infobox look a little funny, having the area values below the "Area" heading, instead of directly next to it. My coding skills aren't too great (only started on Wikipedia just over a week ago), so if anyone can fix this (both here and for the Historical Province template), I would be very grateful. — 52 Pickup 11:21, 21 September 2006 (UTC)

I am not sure what you mean. Can you supply an example? Maybe place it in a sandbox like User:52 Pickup/Sandbox. It better if it can be seen. —MJCdetroit 17:20, 21 September 2006 (UTC)
I don't have a state example, but I do have a province example. The Prussian Province of Hanover did not (as far as I know) change in size during its existence. So any population density can be calculated for any date (so far i have 1939 values from the German site). But since the area did not change, it does not make much sense to give a date when supplying the area. Giving a date implies that the area did change, which can cause confusion. But without a date, the area section of the infobox looks a bit odd, with the are values below the "Area" title instead of next to it. When I was talking about "fixing this problem", I meant something like placing the area values next to the "Area" title instead of below it if only one area value is given and no accompanying date.
After thinking about it, I guess the solution for not knowing the date when giving the area is either to state that it is unknown, or to not give the area at all. — 52 Pickup 11:53, 22 September 2006 (UTC)
I see what you mean now. I'll look into it but I think it is something that you'll have to live with. —MJCdetroit 15:32, 22 September 2006 (UTC)

I think I have it. The logic now goes like this: if you give a value for "area_year1", it will fill in the area with the year as before. But if no value for "area_year1" is given but a value for "area1" IS given, it will then display the area next to the "Area" heading. If only "areami²1" is given, nothing will be displayed - coding that as well would be far too confusing.

The area for Hanover Province now sits correctly. I have made the chanes to both templates. So far, this seems to work, but there could always be a bug somewhere. — 52 Pickup 20:59, 22 September 2006 (UTC)

WikiProject Former countries

In order to clarify the connection to Wikipedia:WikiProject Former countries the template has been moved to Template:Infobox Former Country. This was done in order to preserve the edit history and the work that has been done with the template so far. -- Domino theory 06:16, 8 October 2006 (UTC)

Problems with "width"

There seems to be some form of problem with the "width" of the infobox. Without an image of 275px present it seems to collapse to the left side. -- Domino theory 22:08, 14 October 2006 (UTC)

Yes, I found that too. After trying countless things, the only way that worked for me was to have an image of 275px width. Perhaps a dummy immage is required? A matching grey image that is 1px high and 275px wide should do the trick. - 52 Pickup 07:52, 15 October 2006 (UTC)
I found one possible sollution it seems and it was to set the width of a table inside the box to 275. Since that worked I was able to reduce the width of the images when displaying a single flag or single coat of arms. It also removed the need for a mandatory blank map, which was good since the existing actual location maps only have a width of 250. -- Domino theory 06:33, 16 October 2006 (UTC)

Date navigation issue

The idea of streamlining the preceding and succeeding entries to generate the flags is a very good one, but there leaves one problem. Not a very common problem, but it still happens. If there are a lot of preceding or succeeding entities, the 1-column list of entries will look a bit silly. For example, the Province of Westphalia, which was formed from no less than 11 states. One column of 11 entries in the date navigation box would look pretty silly. At the moment, nothing has been entered in the date navigation box because I do not have the flags or coats of arms for them all. But if I did, I would want to place them in multiple columns so the appearance of the infobox remains satisfactory. For cases like this, my older infoboxes (Historical State and Historical Province) are still needed - of course with the other improvements that you have made to this infobox. Nice work with the automatic generation of categories, too. - 52 Pickup 08:04, 15 October 2006 (UTC)

I feel that the infoboxes we use are still in their formative stages and I'm trying to apply them to various articles in order to find out what is lacking and how they need to be improved.
The number of preceding and succeeding entities with the flag navigation is currently limited to five, but this is of course scaleable and it wouldn't be problem to raise that number to a dozen. That is not the problem however, as you mention it is rather a design issue: How to best display many preceding or succeding entities.
I think there are several possible ways to solve this. My ideas range from limiting the number of flags and displaying the rest elsewhere, or hiding part of the infobox. Displaying two rows would be feasable, but it would probably need some form of table structure and this would make it cumbersome to work with. Also, while this sounds like an elegant sollution designwise, I'm still a bit worried about the users perception of the second column since it will point to another flag rather than out of the box.
The category generation is quite neat and I'm really surprised over how well it works. Good work by the way with relating to the portals regarding the maps, flags and heraldry, which is really important for the project.-- Domino theory 14:49, 15 October 2006 (UTC)

Nice work!

Excellent job on cleaning up the infobox. All of these new categories will make our work a lot easier in the long run.

Did you notice that someone has placed a succession box at the base of the Allied Occupation Zones in Germany entry? Since we already have that information in the infobox, this new box isn't really necessary. - 52 Pickup 18:56, 22 October 2006 (UTC)

There were a number of objectives that I wanted to achieve with the last effort that brought the template up to the 2.0 version:
  • A more robust and clear template design
  • A simpler and more systematic syntax
  • A consistent implementation of features through out the template
  • Introduce additional fields of information to enable new features
  • Extend the automatic generation of categories
During the process I also realized and implemented a number of additional functions that hadn't been envisioned when the drive started. The most important of this is the feature that either resolves fields of information to an existing article, or leaves the entry "as is" including possible wiki-links. This enables same fields of information both to appear wiki-linked and used for the various automated features.
Wanting to finish the different points and the entire undertaking, the focused effort also became a somewhat ardeous task. I have been since been away and been busy with other things, and I haven't been able to find time to do a proper documentation of the features and how they work. It is forthcoming.
The categories generation is a work in progress, and probably will be for some time. There are so many aspects to consider and ultimately it is also a question if all the features that are possible to implement can be managed in an efficient manner. -- Domino theory 11:31, 4 November 2006 (UTC)

I've added a few more categories and a few extra fields for the status/empire section. These were needed for unusual examples such as Ducal Prussia - 52 Pickup 17:08, 4 November 2006 (UTC)

I saw the use of two variables for empire as extravagantly excessive and I was not really satisfied with that solution. Especially since it didn't solve all problems. Your fix seems to handle many of the situations, but unfortunately it has added two additional variables. I would like bring it down to a single variable again and use a more flexible solution. It's important to keep the template flexible and open for new additions, but that doesn't mean that additional variables should be added frivolously. Preferably any kind of supporting variables should be eliminated and the function automated as far as possible. I want to keep the template simple and easy to use for the editors. Making it less complicated makes it less prone for error and misapplication, which means less maintenance from the project side where it is implemented. There are already now several examples of misapplication of the template. I would like to simplify it even further for the editors while maintaining overall functionality.
Specifically regarding Ducal Prussia: Is there any reason why it should not be called the Duchy of Prussia? -- Domino theory 18:18, 11 November 2006 (UTC)
Reducing the number of variables would be good. The empire_extra_text variable seemed to be a good idea at the time when doing Ducal Prussia (the naming was not my idea - that had been long decided upon), but it can probably be dropped. But without the empire_article variable, many entries don't read so well - there really is no default value for this variable that fits so well, but I'm not sure what to do about that. There is also a problem between the usage of status and government_type which is sometimes confusing. Not sure what to do about that either. - 52 Pickup 21:20, 11 November 2006 (UTC)
Or for the empire line, how about just this: status (empire_common_name)? - 52 Pickup
Solving a problem is good, and there really was a problem worth solving. All good and well, but that should not be a limitation to better solutions.
Sometimes it may be tempting to implement a solution that fixes a specific problem, but on the whole it would be better to find a generic solution, even if this often requires an exhaustive review over all the instances where it's been implemented.
What is different with this template from many others is that it generates categories, and as such it requires variable values that are clean enough for this processing. One idea that I had was to mark these variables to make them easier to spot, but since they are also used for automated functions in the template as such they are not dedicated just for categories. On the other hand there are also variables that accepts free text with wikilinks. This means that a certain amount of discipline is required to make benefit of the automated functions, but typically even when these rules are violated the template still performs according to its basic functions.
I'm aware of the dichotomy between the status and the government_type variable. The original idea was to let suzerain entities like colonies and vassals retain a specific government type, just like other entities. The status variable should also be used to declare unions, federal states and empires as such to separate them from ordinary sovereign states. --Domino theory 10:52, 12 November 2006 (UTC)

Dates for intermediate events

There are two problems with displaying the date for event1, event2, etc.

  1. These dates have commas but the start/end dates do not. I tried to correct this but I messed up somewhere and had to revert.
  2. If you know only the year but not the date, then it will not display. If you place the year in the date_event field, then it wants to know the year, placing a blankspace in the date field doesn't work either. For example Free City of Lübeck.

Any ideas on how to fix this? We will need to sort this out before we start applying the infobox in too many areas. - 52 Pickup 17:02, 4 November 2006 (UTC)

Having separate date and year variables for intermediate events served no purpose, so I replaced them with a single date variable. Start and end years are still necessary as they are used for the template and to generate categories. If I remember correctly start and end dates can be used just like the intermediate dates. If they are not resolved they display as free text, meaning that you can write all "date" variables in the same format. I can look into this again. --Domino theory 11:00, 12 November 2006 (UTC)
No problem, I'll look for entries that still use year_event variables and phase them out. - 52 Pickup 10:30, 15 November 2006 (UTC)

Area in sq mi calculated

The area in square miles being calculated is pretty neat. However is there a way to insert commas to separate the numbers? I noticed the the calculation error it makes if a comma is inserted. I fixed it on one article. MJCdetroit 05:49, 5 November 2006 (UTC)

The people over at Metawiki just showed me how to insert commas afterwards: {{formatnum:123456}} → 123,456. This has now been implemented and so the numbers look much better now. - 52 Pickup 09:36, 10 November 2006 (UTC)
Sweet. It looks like there maybe some old fields (area1, areami², area_year1) that are not in use anymore and have not been updated in the articles with the lastest fields (i.e. area_stat1). I saw this at the Nazi Germany article. —MJCdetroit 13:28, 10 November 2006 (UTC)
I tweaked the template a little by removing the <small></small> in the conversions as it may them look a little odd. I found another oddity too, but I address that in a different new section below. —MJCdetroit 13:56, 10 November 2006 (UTC)
Nice. The template does need a bit of a clean-up. Also, since the template has become quite complex, perhaps a more detailed description of the syntax is needed - I've just put up a table to cover categories supported by the template at Template:Infobox Former Country/Categories, but I think more may be needed to explain all of the features. - 52 Pickup 20:51, 10 November 2006 (UTC)

I tried to solve the problem during implementation by not performing the calculation if the value was zero, but since it did not work as expected it was dropped. It looks really neat with the formatting! --Domino theory 11:13, 12 November 2006 (UTC)

Moved section

I moved the preceeding states etc. to the bottom, I think this looks much better. - Francis Tyers · 13:54, 9 November 2006 (UTC)

Alright. Let's try it like this for a while - maybe it will grow on me :) - 52 Pickup 14:01, 9 November 2006 (UTC)
Ok cool thanks :) - Francis Tyers · 14:16, 9 November 2006 (UTC)

I think that template navigation, including flag navigation, is an issue that we can discuss and how it may be solved in a better manner. However it is a central component to the function and design of the template and to this project. An alteration like this should not be made unless consensus is achieved.
Besides the navigation feature it has also disrupted a vital feature for the presentation of the entire infobox. Presenting the years of existence near the top of the infobox is one of the things that sets it out and differentiates it from extant entities. Changing this is not a good idea.
I am restoring the design and functionality. -- Domino theory 11:48, 12 November 2006 (UTC)

I disagree entirely and would dispute the use of the altered template. - Francis Tyers · 12:28, 12 November 2006 (UTC)
I will leave this for a day or so to be considered. - Francis Tyers · 12:29, 12 November 2006 (UTC)

I see that you have just moved the section to the bottom once again. The first time you did it was also without consultation or agreement with anyone else. I only let it pass the first time because I was genuinely curious to see how it would look. After a few days, I must stay with my original comments on WPFC and those of Domino theory above: the dates should be at the top since it is this section which distinguishes extinct states from current ones and it deserves a prominent location. Therefore, I agreed with the return of the box to the top. Domino was also right in that consensus is needed - something that I also said the first time before you simply went ahead and made these changes.

And now you have moved it back to the bottom, again without consensus. This is too much. Those of us who have been involved in the construction of this infobox have put a lot of work into it, and we are currently very busy with its further development. All steps that have been taken so far have been done after some level of agreement. Anyone is quite welcome to participate in the development of this infobox and its use, but to simply come along and make such major changes without some level of agreement is just not acceptable.

Admitted, the flag section does look a little unwieldly when there are too many entries used (even with the current limit of 5). That is something that we are currently working on - a number of major uprgrades and cleanups are currently underway. To make such major changes without agreement while we are in the middle of uprgading the template is not on - it is through things like this that major coding errors can be made which can ruin everything. Furthermore, no agreement has been made on change, so no change should be made.

And so I am moving this section back to the top. Please leave it there. Once we have finished the current round or upgrades, then we can discuss things further - and I would like everyone to have a say. But for now: it stays. - 52 Pickup 11:01, 13 November 2006 (UTC)

I will be happy to leave it there, but then you must get consensus for including it on various pages. I was happy to leave it on the pages with the compromise, but now I think it is better to leave the template off various pages. At least until its form has become more static and there is consensus on how it should look. Again, I'm trying to work with you, not against you :) - Francis Tyers · 11:04, 13 November 2006 (UTC)
In fact I have a better idea. - Francis Tyers · 11:04, 13 November 2006 (UTC)
An alternate template is now available, the same, but with the flags at the bottom {{Infobox Former Country 2}}. I don't see a problem in having two versions with different layouts -- as some pages are more appropriate with the flags at the top, and some with the flags at the bottom. Thoughts? - Francis Tyers · 11:08, 13 November 2006 (UTC)
Good compromise! With a lot of flags (eg SFRY), the flags do look better at the bottom (with the current layout) - although the dates should still be at the top. When only 1-3 flags are used on each side, they definitely look better at the top. The layout for a large number of flags has been a problem for me for some time. This has been partly addressed by limiting the number to 5 and having a space for up to 12 text entries at the bottom of the box (the pn and sn variables), but this is still not a complete solution. I think once we have fixed the presentation problem when a large number of flags are used, we can then come to a final version of the template.
It should be said that care (and a bit of common sense) should always be taken when using this feature. The purpose of the infobox is not to list every single entity that the county was or became. For example, the Confederation of the Rhine goes back to the Holy Roman Empire and forwards to the German Confederation. To display every single country involved here would be totally impractical. But sometimes, a large number of countries are required (eg. SFRY), which brings us to this layout problem. A more detailed "how to" for this template is in the works.
For now, the current developments on upgrading the template should be restricted to the original version. Upgrading two things at once is just too confusing. - 52 Pickup 12:02, 13 November 2006 (UTC)
Agree :) - Francis Tyers · 12:12, 13 November 2006 (UTC)
I'm sorry that I have to disagree with this, but opening up development of a second parallel infobox template is a really, really bad idea.
From what I understand the case is that Francis Tyers is not happy with the current design of the project infobox, which is fine since anyone is entitled to their opinion. Francis also has a suggestion of how to improve the design, which also is good since we need more ideas of how to improve the infobox.
What is bad is that the same user repeatedly has tried to enforce changes either without consulting members of the project, or expressly against being told to wait for a consensus opinion before going ahead with alterations. I believe that this is a good opportunity to say that I think we would all appreciate a little bit more of cooperation from your side.
Still, I would like to welcome you to the project and your input is likewise welcome, all providing you that understand the necessity of working with the project in a cooperative spirit.
Apart from disagreeing with how you have attempted to deal with this issue so far, I'm also trying to listen to the actual concern that you have. As I have understood it: you have an opinion regarding the placement of the flag navigation features inside the infobox, but you also particularly dislike how this is affecting certain articles at the moment. Is that a more or less correct assessment of what you are trying to put forward?
  • Regarding the placement of the flag navigation inside the infobox, you are welcome to participate in the discussion on how we might improve that feature. However the discussion will take place with-in the framework of the project and consensus is required for major changes. If you would like to try out different solutions or illustrate your suggestions you should feel free and encouraged to do so, but that is something that needs to be kept under your own user pages. This means that you need to move the version of the infobox that you created and conduct further experimenting there, and not on regular pages.
  • The instances where the infobox has been implemented so far should be viewed as tentative, since both the project and the infobox are still at their formative stages. This means that the infobox is not ready for full scale deployment and likely won't be for some time, which also means that there is plenty of time for viewpoints and suggestions to be put forward and to be considered. In the mean time, if there should be single cases where the effects of the current design of infobox is considered particularly adverse, the tentative implementation could be reverted and the article restored to its previous state in order to let additional views be heard and taken into account for the development of the infobox. Regarding SFRY, I believe that the template was introduced by a someone who is not an active member of this project and as such it has not had any significant impact towards the development of the infobox. If this particular case should be a big issue, I personally don't see any problem in returning to the infobox used before November 4. The template could be reintroduced at a later stage when it has undergone more development or is ready for full deployment.
Apart from this feel free to suggest improvements and contributing to the project. And again, welcome! -- Domino theory 23:47, 13 November 2006 (UTC)
I never said anything about development of a second infobox, only allowing the temporary existance of one until we sort out this display problem. That's why I said that all development work should be confined to the original infobox. When using too many flags (which sometimes is necessary), I'm not happy with the current layout either. It was interesting to see how it would look as Francis proposed, but that did not solve everything either. If anything, the dates must still be at the top.
So long as the use of this 2nd infobox is kept to a minimum, and used on the understanding that it is not the final solution and will not be further developed until a final infobox is ready, then I do not have any real objections. - 52 Pickup 10:29, 15 November 2006 (UTC)
I don't wish having to experience a situation where we suddenly would have ended up with a project version and a Francis Tyer version of the infobox. It's important to welcome new members, but it doesn't mean that anyone who joins is free to ignore other members, disregard consensus and employ their own agenda. We want new members who are willing to cooperate.
If testing was the question, it should have been done like with your very good example of SFRY, and we would all have welcomed new suggestions regardless of who produced them.
As it is it does only minor harm, providing its use isn't extended. It's use shouldn't be encouraged or advertised. -- 13:56, 18 November 2006 (UTC)

The use doesn't do any harm. As a note I am happy with the current infobox on SFRJ (as of "(cur) (last) 14:18, 18 November 2006 Domino theory (Talk | contribs) m (Edit temporary infobox location and readd static categories)" this edit). The positioning is just right. Thanks for your consideration :) - Francis Tyers · 17:46, 18 November 2006 (UTC)

I'm happy that we temporarily have resolved this issue, even if it was acommodated by a special sollution. I also wish to give a reminder on the opportunity to participate and give opinion regarding the general design of the infobox, which is the long term sollution. Thanks for your participation. Kindly -- Domino theory 20:23, 19 November 2006 (UTC)

Using two different references with the same stat_year

In the Nazi Germany article there are two different references for the same stat_year; one for the population and the other for the area. I managed to get both references in there. It would be nice if there was separate fields for this so that the reference for the area for that year matched and the vice versa with the population. Just an observation. —MJCdetroit 14:20, 10 November 2006 (UTC)

So far I hadn't really given much thought to referencing (i get enough of that at work...). I've added two new test fields - ref_area1 and ref_pop1 (only these two, not for year 2,3...) - and implemented them in the Nazi Germany article. It seems to work. It is best if the ref tags are not hard-coded into the template in case one wants to add multiple references. What do you think? - 52 Pickup 21:08, 10 November 2006 (UTC)

It looks good; seems to work well. I wouldn't hard-code the <ref></ref> tags into the template either. —MJCdetroit 21:34, 10 November 2006 (UTC)

I think references are good. They should be used by contributors and they should be presented in a format readily available to the reader. However I see a number of problems in utilizing this mediawiki functionality from inside the infobox. It creates double standards and make references to separate collections of footnotes. If implemented it would also create an entire score of new supporting variables, which are contrary to the effort of keeping the template simple and easy to use.
  • Footnotes used in the infobox should reference the footnote list in the infobox and the limited space for these footnotes has to be considered.
  • In detail statistics on geography and demographics has its place in the article proper, or even in their own sub articles where the regular referencing system may be used.
I guess a variable specifically for statistical reference could be added. However this would potentially open up for supporting reference variables to any kind of data, since any kind of data could be referenced. Strictly speaking, what is the compelling argument that statistics would need this kind of referencing in the infobox, but other data doesn't? -- Domino theory 12:45, 12 November 2006 (UTC)
Looking at how this is done for modern countries, there does not appear to be a standard way of doing things. Some refer to the base of the infobox with regards to population and area data, some in the references section at the bottom of the page. But wherever the location, the footnote/reference is called to from within the infobox and so we should try to do the same. The existance of separate references for the area and population is not, so far, fully supported by this infobox, leading to the highlighted problem. The creation of separate variables to mark the requirement for a footnote or reference (not sure which we should choose) is the only way to overcome this problem without compromising the functionality of the area/population calculation.
This does create more variables, but I don't see a problem with the addition of "advanced parameters" if it does not adversely affect the functionality of the infobox and if people know how to use them properly. They can be displayed separate from the main syntax. Actually, I've been thinking about preparing a "lite" version of the syntax, so new users can implement it without error. As it is at the moment, the syntax is potentially confusing to unexperienced users. - 52 Pickup 10:10, 15 November 2006 (UTC)

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)

Infobox Former Subdivision v2

Speaking of updates: over at {{Infobox Former Subdivision}}, I have now heavily upgraded it to largely match this infobox, after clearing away a lot of the old formats. A new thing: the sn/pn variables (or anything like it) are no longer in that infobox - all terms are automatically listed at the bottom of the infobox if there are more than 5 previous or succeeding states (eg. Province of Westphalia). This is from my work on the SFRY prototypes above. For this infobox, I would probably list the entries at the bottom as they currently are (centered, no images), instead of what I have in mind for the former country infobox (side-aligned, with images). The older versions of the subdivision infobox ("historical province" and "prussian province") are now no longer used by any entries and are now listed for deletion.

The subdivision infobox contains one field that this infobox does not: "today", a field where instead of listing the entities that came immediately afterwards, but what entities cover this territory today. Going further back in history, this can be useful. This field might be handy for this infobox since it has already proven useful in the subdivision infobox (eg. Province of Schleswig-Holstein). What do you think? - 52 Pickup 16:38, 27 November 2006 (UTC)

Very good! I think we should try to have the same kinds of functionality in both templates and they should be alike as much as possible. This doesn't mean that they should be identical, because there is a very good reason to keep countries and subnational entities separate. This is also one of the problems that we have to solve for the HRE and Germany: Entities in transition from being vassal states to the emperor over sovereignty into subnational entities. The today field seems like a good idea and I think it should be implemented. The might also be a case where there is a value in displaying related contemporary entities in the infobox. There is a link between East and West Germany even though they are themselves separate, just like there is for the Duchy of Prussia and Royal Prussia. I'm not sure how to best solve that. What is your opinion? -- Domino theory 23:18, 29 November 2006 (UTC)
This second infobox may go a long way towards solving some of these transition problems. But we should not rely on the infoboxes to solve all of these problems. For states that were members of the HRE, then the German Confederation, then of the German Empire, I don't see (at the moment) how all of that can be handled by the infobox. For that, the navbars do a better job of explaining this. As a test, I have converted the Free State of Prussia entry from Former Country to Former Subdivision and it seems to work quite well. I have just copied over the "today" field into this infobox, it might need a bit of tweaking - at the moment, this field is filled in simply by listing all entries, separating them with line breaks. This field should only be filled in if the previous/succeeding states do not adequately explain the present situation. As for links between parallel states, I don't think the infobox is the right place for handling this - to introduce such a feature may lead to confusion, even misuse. In many cases, parallel states are better explained by the "History of" templates (eg. Template:History of the Low Countries and Template:History of China). - 52 Pickup 14:49, 30 November 2006 (UTC)

Nazi Germany government_type

It's currently Dictatorship, previously Totalitarian Dictatorship, but both are saying it does not comply. Can one of those be added to government_type? MeekSaffron 05:47, 12 December 2006 (UTC)

We're still working on supported government_types - it will be fixed soon. - 52 Pickup 08:35, 12 December 2006 (UTC)

Major update

I have just made a major update to the template. It covers a number of things that have been discussed above:

  1. The pn/sn variables have now been eliminated - if there are any pages which used these fields (and i don't think there were any), they will be phased out. Now you just enter the p1,s1,... fields as normal. If more than 4 of any one type are used, the side that has more than 4 entries will not be displayed in the date bar at the top, while everything will be displayed at the bottom of the infobox. This is very similar to prototype D that I used for the SFRY example above (plus a few tweaks). If the limit of 4 does not agree with many, it can be changed. (eg. Austria-Hungary)
  2. A third government office field has been added between the "leader" and "deputy" fields. This is the governor position discussed above, used for representative leaders of a country (eg. colonial governors). This field has been named "representative". For an example of its usage, see Orange River Sovereignty. The standard usage of this is for representative leaders and will not have a use everywhere and should only be used in particular cases, although the availability of a third political office can also help in clarifying special situations (eg. Nazi Germany).

This has all been tested, but there might still be faults. Please let us know if you find any. - 52 Pickup 12:31, 12 December 2006 (UTC)

Update needed

I need an urgent update to set the size of the map. Thanks! =Nichalp «Talk»= 04:55, 16 December 2006 (UTC)

If can be done, but it would be best to not have such parameters. For which entry are you having trouble with the size of the map? - 52 Pickup 14:06, 17 December 2006 (UTC)

Problem with automatic wikilinking (it works, but causes a problem)

Hi! I work on disambiguating links to dab pages. I think the feature of this template that automatically creates wikilinks is very clever, but it created a problem for me at Federation of Rhodesia and Nyasaland. This template was used on that page, and the language was set to "English," resulting in a link to English, which is a dab page. When I edited the article to find the link, it wasn't visible (only the plain text "English" was visible), so I didn't know how to fix it. I just got some help at WP:VPT -- the solution was to replace the plain text with [[English language|English]], so the template wouldn't create the link itself -- but that wasn't obvious at all. Is there anything that can be done with the template to alleviate this problem, or alternatively, can the solution be documented in a readily accessible place? Thanks. --Tkynerd 15:29, 26 December 2006 (UTC)

If only one language were to be entered here, it would be no problem to automate the creation of the correct links. But with more than 1 (which is very common) it doesn't work. As requested, I have made a note of this at Template:Infobox Former Country/Instructions. Thanks. - 52 Pickup 21:58, 27 December 2006 (UTC)
The automated link generation for one language now works. If you now enter a single language, the template will first search for the entry "{{{common_languages}}} language". So if you enter simply "English", the infobox will now show [[English language|English]]. This only works of just ONE language is used. - 52 Pickup 08:19, 4 January 2007 (UTC)

Handling of date parameters breaks user preferences

The example has

|year_start   = 1871
|year_end     = 1918
|date_start   = January 18
|date_end     = November 9

It seems useless and irritating to separate year from date. A unified parameter would have the following advantages:

  • Dates could be displayed the way registered users have set in their preferences. See Wikipedia:Manual of Style (dates and numbers)#Dates containing a month and a day.
  • People would be less restricted. What's wrong with leaving it to editors to choose between entering “[[31 December]] [[2007]]”, “[[December 31]], [[2007]]”, “[[2007-12-31]]”, “[[2007]]-[[12-31]]”, “December 2007”, “December [[2007]]”, “early 21st century” or “December 2007 or January 2008”?

Wikipeditor 23:19, 4 January 2007 (UTC)

It is not useless at all. It is very important to have these entries separated. The start and end year appear alone at the top of the infobox ("1871 - 1918") and these two parameters are responsible for the allocation of this article to two categories ("1871 establishments" and "1918 disestablishments"). If the year and the date are not separated, none of this would be possible. It does not matter if you enter "January 18" or "18 January" for the start and end dates - it will display the date according to the user's preferences.
For intervening events ("event1",...), the date and year are together in a single field (as "date_event1"). In these fields, the other date formats that you proposed are all valid. - 52 Pickup 07:48, 5 January 2007 (UTC)
Thank you for explaining the purpose. So how do you explain that even though I have my preferences to the 1999-12-31 format, I still see the December 31, 1999 format not only for special events, but also for "established" and "disestablished" dates (example: Second Philippine Republic)? Wikipeditor 00:27, 2 February 2007 (UTC)

Usage for Republic of Texas

Is this template generating the Cat:Short-lived states that appears on the Republic of Texas article? If so, there is a disconnect between what Cat:Short-lived states says (less than five years) and what this seems to generate. If this template is the source, is any way to change the template so as not to generate the short-lived category for a state that lasted 9 years? Thanks. — Bellhalla 22:17, 12 January 2007 (UTC)

Yes, this template is assigning the categorisation if the lifespan is less than 10 years. The error is with the category page (simply forgot to fix that earlier on), this has now been fixed. - 52 Pickup 11:54, 14 January 2007 (UTC)

Government type (2)

We need a new government type: Theocracy, see Papal States. I figured I should mention it here, rather than just trying to hack the template about. I would mention about articles ending up in both Category:Short-lived states and Category:Client states of the Great French War, but that seems complex and, frankly, unimportant  ;o) — OwenBlacker 23:19, 5 March 2007 (UTC)

Flags

I am having several problems with flags on the infoboxes.

  1. How do you get it to show a Preceding/Succeeding countries section like on Allied Occupation Zones in Germany?
  2. How do I represent preceding or succeeding countries without a flag, without the gray Image:Sin escudo.svg appearing?
  3. In the preceding/succeeding section, which flag/image fields are for what? How do I properly convince the template to link to, for example, Flag of Japan and show the proper image?
    1. In particular, I am having trouble convincing certain flag images (i.e. Image:Ryukyu Islands flag until 1875.svg) to show up at all.

Any help would be most appreciated. Thank you. LordAmeth 13:34, 12 March 2007 (UTC)

To answer your questions (a lot of this is given in Template:Infobox_Former_Country/Instructions:

  1. The Preceding/Succeeding countries section like on Allied Occupation Zones in Germany appears if more than 4 preceding or succeeding states are given.
  2. You can give a different flag to prevent the sin escudo image from appearing (using the flag_p1 field). If an image simply doesn't exist (as opposed to it being unknown or unavailable), "image_p1 = [[Image:Blank.JPG|1px]]"
  3. Instructions text for image fields: "Going further back in history, flags were less common and coats of arms were used instead. Coat of arms images are generally narrower than flag images, so if coat of arms images are displayed at the defined image size used here for flags (i.e. width=30px), they appear too big. Therefore, if you have anything other than a flag/banner image to use for a previous/following entity, fill in this field. Here you must enter all wikilinking as normally done when entering an image, but set the image width to 20px (or higher, depending on the individual image). If you know that there is no flag for this entity, but do not know what the coat of arms is, enter Image missing in the image field".

Hope this helps. - 52 Pickup 16:52, 24 March 2007 (UTC)

Absolutely. Thanks for your detailed response. I'll look into implementing those soon. Still, while I certainly don't presume to know the full history of such things as they pertain to East Asia, I'm largely certain that the Western concept of "coats of arms" for a country, much like flags or various other institutions didn't exist. No big deal, of course - I'm sure we can find substitutes, like the family crest/badge of the ruler, or the royal seal as I did on Ryukyu Kingdom. Anyway, thanks again. I'm glad to know how this preceding/succeeding flag thing works and that it's not just an error :) LordAmeth 17:08, 24 March 2007 (UTC)

Number of leaders

It seems strange to me to see 6 entries for leaders (up to leader6). What if a former kingdom had 21 kings? I am asking because someone was puzzled in Talk:Soviet_Union#Government_Leaders why they cannot see Gorbachev (who is #7).

Please clarify the usage. `'mikka 00:51, 15 March 2007 (UTC)

While there is no response from template maintenance guys, I tried to fix this for the Soviet Union. But even if my change will not be reverted, the discrete nature of the template still remains to be fixed. Cmapm 11:06, 16 March 2007 (UTC)
As it is stated in the instructions for this template, it was NEVER inteneded to list every single ruler if there are so many. If there are more than 5, only the FIRST and LAST people should be given. No more fields will be added. Therefore, for the USSR entry you should have |leader1 = [[Vladimir Lenin]] (first) and |leader2 = [[Mikhail Gorbachev]] (last)
This infobox is already big enough. Having fields for over 6 rulers would be too much. As for 21... no way. Lists of rulers should be given either in the article body or as a different article. If in a separate article, the list should be accessed by the subheading that precedes the names, as you have correctly done in the USSR article with |title_leader = [[List of leaders of the Soviet Union|''Leaders'']] - 52 Pickup 16:29, 24 March 2007 (UTC)

Terrible Changes to Template! Light blue background, yellow highlight of name

A recent edit to this template has made it look terrible! PLEASE restore the old template! —The preceding unsigned comment was added by R-41 (talk • contribs) 18:41, 10 May 2007 (UTC).

Fixed. - 52 Pickup 19:31, 10 May 2007 (UTC)

Replace the 'preceded/suceeded by' arrows with prose above...?

In the section indicating preceeding and suceeding states, has using subheadings such as "Preceded by" and "Suceeded by" (in smaller font-size) above flag/s been considered...?  Having recently passed by a couple of pages using this template and had someone ask me to confirm what the leftward and rightward arrows imply (and also that they are/can be links), I wonder if something that's more more self-explanatory and more visible as a link might be preferable...?  Meanwhile, thanks for comprehensive template!  Regards, David Kernow (talk) 21:20, 30 May 2007 (UTC)

Thanks for the kind words. Placing additional subheadings is something I had not previously considered, but it is a good idea. After I removed the default "flag unknown" image a while ago, it is probably not immediately clear what the arrows mean if there is no adjacent image. At the moment, I'm toying with how to make the infobox collapsible - if possible, I would then place that extended "Preceded/Succeeded by" section at the top and then remove it when expanded (if the number of states is small enough: <5), which should make it clear to all what the arrows mean. That's going to take a while, but your suggestion has come at just the right time! - 52 Pickup 09:20, 1 June 2007 (UTC)
Glad it has; look forward to future development!  Best wishes, David (talk) 14:20, 1 June 2007 (UTC)
Oh, I dunno, I really like the preceded / succeeded arrows as they are. — OwenBlacker 16:11, 28 July 2007 (UTC)
They'll still be there, just not when collapsed. It has occurred to me this infobox is rather big (so are the standard ones for countries and cities) and I would like to try reduce the obstructiveness of the template. So far, I'm not even sure if what I have in mind is practical or even possible - so it will be a while before any possible major changes are put forward. - 52 Pickup 14:18, 29 July 2007 (UTC)
Hmm, from a recent query over at the Village Pump, it looks like the coding required for this collapsible template is not possible - at least not at the moment. Damn. - 52 Pickup 21:10, 14 August 2007 (UTC)

status_text

Is there a way of showing the status_text without adding a status? I can't really think of an appropriate status for the Stem duchy of Lorraine… — OwenBlacker 16:11, 28 July 2007 (UTC)

For this entry, you would say "status=Vassal", "empire=Holy Roman Empire" - this is the standard way to describe HRE states (the other option is "status=City"). This automatically generates some status text, but this can be overwritten. It should be stressed that the "status" parameter is used only for the purpose of categorisation - for this reason, the options for this field are limited and this field should be used sparingly. - 52 Pickup 14:11, 29 July 2007 (UTC)

Stacked flags

Multiple previous and following flags look terrible in this template. I'l looking at Ukrainian People's Republic: I see a stack of six stripes on the left, and four on the right, and no identifiable flags. —Michael Z. 2007-08-13 14:32 Z

Yeah, I know. This problem has been bugging me for ages. Still working on it. - 52 Pickup 17:58, 14 August 2007 (UTC)
Maybe the table cell just needs a line-height taller than the flags? —Michael Z. 2007-08-14 18:40 Z
Nice idea, but each stack is within a single cell - having individual cells for each flag would be a coding nightmare. But now I think I've come up with a way to do it, by playing with font sizes and adding some line breaks. So far, it looks like its worked, but if there are any problems, please post them here. - 52 Pickup 21:05, 14 August 2007 (UTC)
Looks good in Safari 3.0.3/Mac. Thanks. —Michael Z. 2007-08-14 21:17 Z

suggestion

If this is needing constant fiddling, ...

Why not parameterize all the style characteristics as I did with width months ago?
Second, t'would be a good idea to make the standard width similar to other types of Info boxes, for cases where an article is serving currently as both a current topic/place and the former nation/state (e.g. Wittenberg and Duchy of Saxe-Wittenberg which size mismatch brought me here to check whether this had a width option.) I would recommend the much debugged and (imho, still overlarge) templates of Template:Infobox Military Conflict (edit talk links history) and the related war or campaign boxes as a max size model. (e.g. Battle of Breitenfeld (1631) (edit talk links history)). See the guts in Template:WPMILHIST Infobox style (edit talk links history) which maxes out the 315px, but a better size would be circa 22.5em which is pretty standard for big infoboxes. Best regards // FrankB 00:00, 19 October 2007 (UTC)

The problem is that there is no "standard" box size. But usages of the same box should have the same width, hence the lack of extra parameterisation: this infobox has a lot of parameters already. In the Wittenberg example, there should really be a separate article for the duchy. Having too many infoboxes on a single page is never good.
If you want to bring up the matter of box width and discuss it with other infobox designers, perhaps you could bring it up at WT:INFOWATCH - 52 Pickup 09:40, 28 October 2007 (UTC)