Wikipedia talk:WikiProject Countries

Where is the list of participants? Sign me up! --mav

Obviously I'm in as well ;) -Scipius

There's discussion on Talk:Countries of the world/Status of the porting of Dept of State info about how to desubpage the country entries, or whether to do so; if you're still interested in getting this off the ground you should go vote about what to do. :-) --KQ

Jeronimo, why did you change the previously established layout for the headers? Using the === unnecessarily separates the title from the "main article: xxx" sub-header. Given that you had the HTML right there on the page I don't think there was a chance people would find it too difficult. -Scipius

Scipius, the main reason that I did this (maveric149 did the same for his chemical elements template) was that it was not Wiki mark-up. The current trend is to change all formatting to wiki layout; even for tables (that is being discussed on the mailing-list). Reasons are that people unfamiliar with HTML may be scared to edit such articles and (which is my personal reason) that I would prefer not to put in displaying elements in the text - that is the task of the stylesheets. In this way, we define a heading as a heading, and not a part of text as boldface size x. But of course you're free to use that format everywhere... Jeronimo 12:18 Aug 3, 2002 (PDT)

I see. I asked because I had already inadvertently changed the Netherlands Antilles headers over. Why is this the "current trend" though? Was this discussed somewhere? It does make the page look slightly more disorganised at the moment, but since "font size" doesn't seem to work properly anyway (see the Europe article, the note numbers should be -1, but aren't), I'll think I'll wait until all is sorted out. -Scipius

tags work well for footnotes. e.g. ¹ --KQ

I disagree (they create whitespace in between the entries, at least on my browser (Moz1)), but it does make the point about them being notes clearer. Let's leave it this way until font size works again. -Scipius

I think the trend is such for several reasons, but mainly to make things easier, both for us and for new editors. I had a short "discussion" with maveric on this about this (I think it's on my talk page), and I think he had one prior to that (I reacted on his changes to the headings).

Anyway, I haven't bothered to change the headings in the already existing pages yet, if only because it _does_ look nicer. But I think the WikiProject countries should focus more on how the content should be, and less on details of layout (although a uniform layout would be best, of course). Jeronimo

I've read it, thanks. You're certainly right in that there are still plenty of countries left to do first ;). -Scipius

Scipius I think we are all on the same page here in not liking the extra whitespace that the wiki headings put in by default. Instead of trying to circumvent this through HTML tricks that will turn away the HTML-phobic (which is the majority of the web) why not make a feature request to change the behavior of heading parsing? You could ask for a more WYSIWYG heading that would only have the trailing space if there is an extra space after the heading. It is counter-intuitive the way it is now;

=== Heading === Test, blah, blah, blah...

Should render as;

Heading

Test, blah, blah, blah...

With that blasted trailing whitespace! Please copy any of the above in your feature request and also include that the current behavior is leading you and many others to use HTML instead of wiki. I think the elements articles are not as nice looking as they were before but a wikipedia article that is only editable by a small group of people is not a wikipedia article. --mav

Vertical spacing after a header tag is normal in HTML. If you want it to look different and you don't want to abuse the system by not using header tags for headers (in the output from wikicode, that is), what you actually want is to have the stylesheet changed and thus the spacing reduced. --Brion VIBBER

This is what all the fuss is about: Heading vs. === Heading === --mav

Right. The former is doubly wrong (1: hard to edit/read source; 2: doesn't produce proper header tag for metaprocessing -- autoindexing, tables of contents, section numbering, summarization, proper emphasis for text or speech browsers, etc) while the latter is easy to read, easy to use, and produced correct and usable code, but some people don't think it looks nice using the default style. Ergo, fix the style. --Brion VIBBER

Brion is right here; I'm not sure however it's possible to use an HTML heading without hte whitespace. Jeronimo

Oh ye of little faith. :) Here's an example: media:temp-stylesheet-demo.html --Brion VIBBER

Cool. What might the syntax be? I do hate having the extra space but I am a bit cautious about changing all current heading behavior. --mav

Simple addition to the stylesheet: h1,h2,h3,h4,h5,h6,h7,h8 { margin-bottom: 0; } If you don't include a blank line between the header and the following text, no tag is inserted, so the text immediately abuts the header. If you do include a blank line, a is inserted, which has its own top-margin (normally absorbed by the existence of the header's bottom-margin) and you get the space. Intuitive, no? --Brion VIBBER

So how do we get it to look like in that example? Has this been implemented yet? It's funny and maybe I'm an exception, but I knew next to nothing about HTML before I came to Wikipedia. I've found it relatively straightforward to use once all the options are known (e.g. see the population pyramid table in Netherlands). I don't know anything about how to edit stylesheets, but I assume there will be tutorials for that. -Scipius

No after a < / h* > is badly-formed HTML -- the markup parser should force one. Use H*+P in CSS to set top margin of Ps following H* to zero. -- Tarquin

Bad HTML to be sure, but that's what the parser does currently produce. Your suggestion is a good one, however! --Brion VIBBER

I just added a feature request for this. Please add any comments to it you see fit (on my browser you have to scroll down to get to the text -- for some reason having HTML in the title field messed up that page). -mav

I'm not sure if my comment is posting of sourceforge: This is needless complication. A heading should be a heading, no more. users who want to *see* headings differently should be given a different CSS stylesheet which displays them differently (and, yes, HTML in the title breaks that page - 2 out of 3 browsers I have tried to load it with fail on it completely -- Tarquin

I submitted another feature request this time without the HTML in the summary field. The above link has been updated. I'm not sure if you are for or against killing the trailing whitespace... --mav

I don't mind how the headers look. But asking for new markup for this is mixing content with formatting. Trailing space or lack of should be implemented through CSS not through markup -- Tarquin

Whose asking for new markup? I want the behavior of the current markup changed to be more intuitive and flexible. I have no idea what you are talking about with the CSS statement. --mav

"I would like to see a more WYSIWYG wiki heading that would only have the trailing space if there is an extra space after the heading." <-- you seem to be asking for two different class of headings - those with space after and those without. What is this for? Is it to make some level 2 headings more important that other level 2 headings? Is it so some writers can have space after headings if they wish while others can have them without space? -- Tarquin

As the one who came up with the HTML style header for the WikiProject, I can say that it was to achieve a clear notion of the section text being just a summary of the main topic articles that are linked to just under the header. Anyway, it works now as described above and I quite like it. -Scipius

The "side table" contains incorrect HTML syntax, as kindly pointed out by Fred Bauder on my talk page. LDC corrected it at China/Temp, and I saw W3's validator didn't like the other formatted pages. This should be fixed, but it is bedtime for me now. Jeronimo 14:29 Aug 4, 2002 (PDT)

I fixed all tables in WikiProject pages (and the template, of course). Jeronimo

Floating a table of this size makes some part of the main text hard to read at any browser width. -- Tarquin

I agree that the table is way too fat -- fatter even then the elements table. But I don't agree this effects all browser widths; on my home screen it looks fine (17 inch at 1200 pixels wide). But since 50+ % of the web uses the default MS Windows resolution of 800 by 600 I think this is a serious problem. The images have been the worst offenders here and need to be much smaller. Some additional wordsmithing should also be done to thin the table. It took me well over a month to develop the original elements table at Beryllium with the help nearly a dozen people. This table seems to have been rushed out the door and now issues are surfacing. --mav

Although I agree that the table could be smaller, but I checked some tables in Windows at 1024 x 768 (my usual) and 800 x 600, and it looks fine to me on both sizes. The table is maybe half the content part of the page, but that actually makes the text easier to read (newspaper effect). But, I'll keep an eye out for making the tables smaller if possible. Jeronimo 23:37 Aug 5, 2002 (PDT)

I think the simplest thing would be to unfloat the table so there is no text squeezed down the side of it -- Tarquin

Let's not unfloat it, that makes it look hideous at larger resolutions and wouldn't be much prettier at smaller ones, except 640x480 or something like that. I also disagree the table is too wide per se. It wasn't necessarily rushed out, we already slimmed the original down. Yes, it can perhaps be trimmed further, but the problem is partly that not all tables will be the same width, as countries will require different lengths of information to be added to their individual tables. Let's see how it can be further narrowed.

On the general page width, I think we shouldn't always cater to the lowest common denominator. Sure, maybe now lots of people still use that resolution (though I'm not sure), but this will change over the coming years. With Wikipedia being a long-term project that's still pretty much unknown to the general public at large, I think we can afford to write to at least 800x600 or even better 1024x768. As pointed out, it doesn't look all that bad at 800x600, a further trick would be to use only small paragraphs in the text next to the table/map, so that when viewed at a smaller res, it won't be too much of a textblock. -Scipius

I'm not saying we should cater to people who have screens set at 640x480, but to the majority of the web that have screens set at 800x600. At that res the Netherlands table, for example, takes up well over half of the content area of the article. And this is with a maximized browser window without any browser sidebar. If the table were an image, this width would violate our Wikipedia:image use policy. I will work on an alternate table that will only take up half of the content area on 800x600 screens. Here is a link to a screenshot of the Netherlands table. This image is 395 pixels wide and was taken one for one from a screen shoot of the Netherlands article. --mav

this is not only about low-res screens. This is about good layout and good typography. My desktop is 1152x900, but there is no way I can read all of that page comfortably without resizing my browser window: http://c2.com/cgi/wiki?TenWordLine -- either the text alongside the table is too narrow, or the text above & below is far too wide. I suggest either unfloating the table or putting it on a seperate page, eg "Netherlands Factsheet" -- Tarquin

As an example, I reduced the width of the United States table by well over 100 pixels. Now the table is just over 250 pixels wide. Unlike images I think these tables could be up to 300 pixels wide because tables are not as distracting to me as images so the extra width isn't as important. We should still shoot for 250 though. Notice I placed the official name above the table where the useless "facts" statement was (this was needed for width issues). For non-Enlish speaking nations we can simply have he official local long form in grey right under the English long form. There is no need for an explanatory cell for these things. --mav

Looks neat, maveric, it's better now even on my high res screen. Countries with multiple names (up to 3 local names in BEL, LUX) may give problems though. Jeronimo 23:25 Aug 6, 2002 (PDT)

Thank you! Yeah those will be problematic but we can take these things one step at a time and there is no rule that each table has to be a carbon copy with different info. We can make tweaks here and there for each country in order to get everything to work right. --mav

The United States table is indeed not ideal for testing things out, since it misses several fields. I'm not too excited about the resulting extra whitespace, but I think the slimming down looks OK otherwise. However, I don't think tables need to be in the 200s, 300px (that's still less than half the screen on 800x600) seems like a good goal to reach for, with a margin of, say, some 20, 30px at the very most? We can even edit in the width in the template table and play with it if necessary. I've edited the table at France for a European example at now 315px. -Scipius

I've further edited the Netherlands table, now at 285px. That's possibly as small as it should get and has led me to believe we should indeed shoot for around 300px as the goal rather than 250px. -Scipius

Now that we have the space, it might be neat to have area and population world rankings. Here is an example from outdated off-the-top-of-my-head data for the US;

Area    |Ranked 3rd 
Land    |9,166,600 km²         
Water   |206,010 km²

and

Population |Ranked 7th
Total      |281,421,906
Density    |31/km²

I say we get rid of the ugliness the mile figures introduced, make an article named square kilometer and provide conversion factors there. This is what I have planned to do all along for the elements tables (since I use SI units almost exclusively in order to reduce table size). It would also be neat to link the actual numbers to the corresponding orders of magnitude article. That way there will be two ways people can relate the area figures. --mav

Amen! Even we merkins are taught metric in school; we can call up the conversion factors and calc.exe if we need to. --Brion VIBBER

Yes, kill the darn miles! Though after a trip to America, I'm glad that I am NOT the one that has to do the conversions :-)

As for the rankings, we should also provide a ranking article then (or at least mention a source for this) since I don't think it's in the CIA factbook (or is it?). Also, I think the total area should be mentioned somewhere, so either

Area    |Ranked 3rd 
Total   |9,372,610 km²
Land    |9,166,600 km²         
Water   |206,010 km²

or

Area    |Ranked 3rd 
Total   |9,372,610 km²
Water   |206,010 km²

would be my suggestion. Jeronimo

An almanac article with a list of rankings would be most cool. Great idea! Either of your total area modifications work for me. Vertical space is cheap but my only concern with having four entries is that the numbers begin to jumble together. But that may just be my math dyslexia. --mav

Yes, I think Total and Water only will be enough (my preference). Maybe "of which water" would be clearer, although "Total" does suggest it includes everything.

Found some possible data sources:

http://www.gazetteer.de/home.htm (Click on the first link in the body)
http://212.204.253.230/global/pop_data.php
http://www.cia.gov/cia/publications/factbook/index.html (Click on field listing, Area or Population)

The CIA book also has the land/water/total figures neatly together. Anybody looking for something to do ;-) ? Jeronimo 00:54 Aug 7, 2002 (PDT)

Thanks for the links - I'll look at them later. How about this;

Area                |Ranked 3rd 
Total               |9,372,610 km²
Water (% of total)  |206,010 km² (2.2)

I tried this with a preview of the US article and it did not add any extra width. --mav

Better idea; only mention the percent of water (a calculation already has to be made for the land figure.

Area                |Ranked 3rd 
Total               |9,372,610 km²
Percent water       |2.2%

--mav

Yes, the latter proposal gives a better impression of the amount of water. Note that for some countries listed at the CIA, the water area is zero. This may be true for some of the small 1 sq km islands, but not for countries as Afghanistan or Algeria, no matter how dry the land may be. So we should include "unknown" there. Jeronimo

Unkown is a bit ambiguous. How about simply "none" or "none significant" or something like that? --mav

I found a link with the population ranking data already in it. I will make an Almanac article with the data and then look for a similar ranking list for area and maybe population density. --mav

http://futuresedge.org/World_Population_Issues/2001_population_ranking.html

I like the idea of rankings, but one problem will be that adding up-to-date stats could mean countries would have data from different years. How would this affect the rankings? Should we just use whatever year is available for a country in the ranking or only use figures from one fixed year available for all? Also, I've indented the text a little in the Netherlands table, shall we add all this to the template table already or wait some more? -Scipius

I have introduced a proposal for a WikiProject protected areas. When you have the time could you guys have a look at it? I?m especially interested in what you think about the "Protected areas in [country name]" articles (see paragraph "Formatting of level 2 articles"), since there are points of contact with the country articles. Thanks! ? Guy

I listed a contact for this on your talk page. --mav

On the dafult table i dont particualry like the term "capital city" i much just prefer capital: - fonzy

I tend to agree -- the spelling and context is more than enough for a native English speaker to know what the term means. Let's hear from some non-native speakers before we change the template though. --mav

The field labeled "Flag:" below the images of the flag and coat of arms is rather unclear. After further inspection of Netherlands and France it appears to be the name of the person who drew the particular image used (rather than my first two assumptions, the original designer of the flag or some bizarre nickname for the flag itself) and a reference to the web site from which it was taken. --Brion VIBBER

Flags from FOTW can be used freely as long as there is a reference to the site. What Wikipedia really needs is its own flags of course, homemade and under the proper license. Anybody wanna start the discussion on what sizes they should be? Oops, I think I just did...;) -Scipius

We can't be certain we'll have cited them properly, as anyone could come in and remove it.

Are the ones at e.g. The CIA site in good enough condition to use? (They're in the public domain.) --KQ 14:40 Aug 7, 2002 (PDT)

They appear to look fine (ratios and all). This could save us the trouble of making them ourselves, if they are indeed in the PD like the rest of the Factbook. The smaller size is smaller than our "small" size at the moment though, but that could of course also help in reducing table width. I've put up links to the Factbook flags (small and large) on the Netherlands page as a temporary example before we start adding them. Any comments? -Scipius

Hm, but now that you mention it, I think the text below that is what's determining the table width. Maybe one 50 pixels or so wider? I'm looking for public domain flag images.

Speaking of which, check this out: http://memory.loc.gov/frd/cs/cshome.html (Another gov't site about countries, in the public domain--and more extensive than the CIA bits).

Whoops, someone found that one already. Let me show you this round thing I invented; you can do something with it I like to call "rolling".

I'm not having any luck finding larger images of country flags which are certainly in the public domain. --KQ

It is indeed the main table text that decides the width at the moment, but there's no immediate need for finding a certain size that would fit more properly. We can probably simply take the large size flags from the Factbook now and then resize those when we decide on a good smaller size (we could even have three sizes: large, small, mini?). At least we would have a good base flag for all countries. Agreed? -Scipius

I don't have any objections. --KQ

Very well, now all that remains is the issue of format. Shall we convert the original .jpg to .png? I realise this is a no-no according to image policy, but since these are flags rather than detailed photos, could it perhaps be possible? Also, some of the flags could have their colours a little brightened, so some minor work needs to be done on them. -Scipius

Ask LDC about it; he co-created the .PNG format.

First thing to consider is that each flag has its own proper ratio so you can nto just randomly do the flag it has to be in ratio. fir example the ratio for the union flag (union jack) is 1:2. - fonzy

Well, we could move the source of the flag image to another location. Creating your own flags is fine for simple flags like the Dutch one, but more complicated ones take more time, and we might as well use other sources as well. Jeronimo 14:37 Aug 7, 2002 (PDT)

I have created and uploaded the flag of Mauritius.

Let's wait before you create any more, Fonzy. We could be adding flags for all countries very soon and the basic "small" size for use in the table still ahs to be decided. -Scipius

ok but as i ahve mention just abit before that diffrent flags have diffrent ratios teh ratio for that flag is 2:3 alot of flags are like that some liek th uk's flag is 1:2 others include 3:4 6:7, 3:5, 13:15 and more. So you cant state one default size for all flags. nto quite shore how to do it. - fonzy

I've changed the table template to the one used at Netherlands right now (slightly different from the one at United States). The table is much smaller this way. Jeronimo

I noticed that a number of prominent UK cities do not yet have entries (e.g. Newcastle upon Tyne) and I thought I would create a page listing Cities of the United Kingdom, but then I thought, perhaps this list should be included in the page on the UK, however I note that it doesn?t form part of the template. Where should a list of cities go? What do people think? Mintguy

Hi Mintguy, I think a list of the cities of a country would probably be too large for the country article, but you could place a link to a new article called "Cities of the UK" or something similar in the section on administrative divisions (counties). Note that City listing (which is a bad name, btw) already lists a number of cities in the UK. Jeronimo 09:07 Aug 9, 2002 (PDT)

i think religion should be added to the table. - fonzy

Religion is something that should be treated in the "Demography of" section, since most countries do not have an official religion. Even if they do, it's often not enough to just say "Islam", you'll probably want to say Shiite or Sunna Muslim, percentages, etc. Moreover, in my country (Netherlands), many people may have had a religious upbriging, but they're not really practising their religion. What to call them? Therefore, it's going to far for a field in the table IMO. I've been thinking that the same might be true for the language field. Jeronimo

What i mean is the main religion/sect of the country and mabey rename offical lanugae to main language.

Also i have tried something on the uk/temp and china/temp page (at the top) look and see well listen and tell me what you think.

Politics and government are not synonymous concepts, nor should be treated as such. I'm breaking up at least the US. Also, I think "demographics" is a more standard usage than "demography", which is generally reserved for the study of population characteristics/statistics, not the information itself. (E.g. on google "demographics" is an order more common than "demography".) --The Cunctator

I suggest that the template have separate rows for 'head of state' and 'head of government', rather than the current 'monarch/president' (after all, many countries have neither of those). --Matthew Woodcraft