Template talk:Infobox Swiss town

From Wikipedia, the free encyclopedia

/Archive01

Contents 1 Change March 28, 2005 2 Change January 7, 2005 3 Question? 4 Size 5 Sub category for Municipalities of Switzerland 6 Version by 83.76.32.102 7 Simpler source 8 As Of Rules 9 Automated categorisation 10 Why no maps? 11 How to rename 12 How to color 13 How to add maps 14 neighboring_municipalities 15 Standardizing Geographic Coordinates 16 Section 17 Elevation 18 Photograph? 19 Semi-protected 20 Proposed new version 21 Elevation 22 Incorrect calculation for old measurements? 23 Placement of map 24 Pictures with snow in summer

[edit] Change March 28, 2005

In order to make the link to Template:Coor dm possible, I split the coordinate field in four (nd/nm/ed/em) and placed the year of the population data in a separate field. I updated the different articles where the template was used. -- User:Docu

[edit] Change January 7, 2005

With class="hiddenStructure", it's now easy to add optional fields. Thus I included some of the fields available in other languages and already added to the articles, but not displayed due to the fact the fields weren't always available. -- User:Docu

[edit] Question?

Okay, I see what you mean, if you look at a large city, you've this problem, but for a small municipality, (e.g. Seigneux) we can't see the coat of arms. I think we should have a specific place for the name and a specific place for the coat of arms. And I also think that a more wikipedian-looking would be better. Could you do this, so that you're sure that everything's gonna work. And sorry if I've disturbed ;-p

[edit] Size

Why the small type? Other info boxes are normal size. Nelson Ricardo 05:20, July 28, 2005 (UTC)

To get some information into the pages, I added the infobox to the many stubs we keep getting, but I feel a large infobox might be too much (compare, e.g. with most French versions (e.g. fr:Rüti bei Bern has at least an image). -- User:Docu

It would be good to go to the normal font size. As it is the labels and information in the info box is near impossible to read for people like myself, who are over 40, and not userfriendly. Would be great if we can benefit and contribute to these articles as well. For instance, I work with the de-en translations and would love to get some of the now still missing articles into the system, but with a font that small I simply cannot do this to my eyes. If there is a concern about the size of the boxes, it works for most towns in other countries. And contributors can pear down the size of the box by either providing or not providing information for some of the fields. Any thoughts? --Mmounties 18:14, 20 February 2006 (UTC)

I concur, larger font size makes it readable and doesn't really hurt, does it? —Nightstallion (?) 18:26, 20 February 2006 (UTC)

I concur too. I'm getting 41 by the end of this month :-). Honestly, I don't like these small fonts. I also find the small references on pages like AIDS a real pain mostly suboptimal. --Ligulem 18:42, 20 February 2006 (UTC)

I concur as well. I have never had a problem with the larger font of the Infobox Town DE, and I have seen it used with some rather short stubs. The large font looks just as good as the small, and is indeed easier to read. Wikipedia is used by people of all ages and abilities, so making it more accessible by enlarging the font is only increasing the potential number who can benefit from the information. --Inge-Lyubov 19:00, 20 February 2006 (UTC)

We really need not do everything as fr.wikipedia (the beauty of wiki is that they are different), but if one takes aarau as an example, french, italian, and german, and even spanish, all have tables with larger font. user-friendliness is more important than pure aesthetics (or they must at least be balanced), and making it large also has a way of suggesting that more information belongs there. there's no real reason to connect font-size with population size or article length, see these both can change incrementally! Adam Mathias 19:12, 20 February 2006 (UTC)

Yep, I agree too. Whilst I can read it at this size, it's most definitely an unnecessary strain on my eyes. Trebor27trebor 19:31, 20 February 2006 (UTC)

Yes, bigger is better. My eyes don't like small fonts either. Saint|swithin 19:42, 20 February 2006 (UTC)

I agree. Let's put it to a bigger size like most other boxes. JHMM13 (T | C) 20:50, 20 February 2006 (UTC)

Which percentage would you like to use? Infobox Countries uses 95%? I suppose 90% should do. -- User:Docu

90% would be wonderful (I believe that's what the Infobox Town DE is at as well). Thanks so much! --Mmounties 21:48, 20 February 2006 (UTC)

not that I think it is overly important but a compacter look has its advantages. For those with smaller screens it gets everything on one page. I found working with the german infobox quite easy on the eyes so I have to agree with Mmounties Agathoclea 00:59, 21 February 2006 (UTC)

Agree with Mmounties as well. Olessi 21:07, 21 February 2006 (UTC)

I guess it depends on screen resolution and font size in browser as for which size looks better; but probably making the fontof a similar size to that inmost other infoboxes would be good. Kaiser 747 09:50, 24 February 2006 (UTC)

I see that the font size was updated as a result of the above. However, the population figure itself is now 100% whilst everything else is 90%. This looks inconsistent to my eyes. Was this deliberate or just missed at the time? MarkS 21:02, 20 April 2006 (UTC)

[edit] Sub category for Municipalities of Switzerland

Category:Municipalities of Switzerland has several sub-categories, such as Category:Municipalities of the Canton of Geneva. Should pages containing the infobox and belonging to the sub-category really be automatically added to the main category as well ? Schutz 21:25, 14 September 2005 (UTC)

It's quite handy to have them all in the category. The category Municipalities of Switzerland shouldn't be added manually to articles though. Possibly we could do without a specific municipality subcategory per canton. Categories such as Category:Vaud may be sufficient. -- User:Docu

I agree it is handy, even though the category will have about 2900 entries. On the other hand, looking at Category:Vaud and Category:Municipalities of the canton of Vaud shows that anything that is not a municipality will be completely lost among the municipalities in the former category, maybe justifying the sub categories too. Anyone else has an opinion ? Schutz 15:34, 19 September 2005 (UTC)

Maybe Category:Places in the canton of Vaud would avoid loosing out on the localities that are not municipalities. -- User:Docu

[edit] Version by 83.76.32.102

It's at Template talk:Infobox Swiss town/Test. -- User:Docu

[edit] Simpler source

Hi. I would like to propose a simplification of the template source. There should be no visible changes. My proposal is at User:Ligulem/work/Infobox Swiss town/1, test inclusions are at User talk:Ligulem/work/Infobox Swiss town/1. I moved the small text size style onto the top level (diff). Have I overlooked something? --Ligulem 17:02, 5 February 2006 (UTC)

Edited into the template here (diff). --Ligulem 22:21, 10 February 2006 (UTC)

For some reason it doesn't work in Cologne Blue skin. Is there a way to fix it ? -- User:Docu

Oops. Sorry. Hmm, what's wrong with it? I switched to Cologne Blue but it looks good to me (Firefox). But it's not such an important edit, so it would be possibly best to revert. Please do so if you think it is safer for now. I can try to track down the problem in my sandbox. I will have a look at it tomorrow morning. Thanks. --Ligulem 23:26, 10 February 2006 (UTC)

It looks ok. It's just the font-size that isn't smaller in Cologne Blue. -- User:Docu

You're right. I've seen it now. Have just reverted. Sorry. Strange. --Ligulem 23:45, 10 February 2006 (UTC)

[edit] As Of Rules

According to the As of page, the As of (month) (year) is depratected and should not be used. I propose that you keep the month, but the As Of link using only the year to be compliant with this..

I've added another paramer popofyear, which if defined should solve this problem. Rich Farmbrough, 18:57 7 September 2006 (GMT).

We could use existing redirects instead. There isn't much of the a problem with using them. The additional parameter is a bit an overkill (imaging all the noise created by updating the pages). Possibly we could include/fix it when revising other (displayed) fields. --- User:Docu

One of my projects is to remove the deprecated As of (month) (year) usages. I cannot find a way to do this in Swiss Town infoboxes without deleting the month. I appreciate efforts to link just to as of (year) but will respect any suggestions made here. MKoltnow 21:56, 1 December 2006 (UTC)

Burp. I just read the example infobox at the top of this page. I'll use Rich's new parameter for popofyear. I will get back to reverting the boxes that I've modified to show months but link only to as of years. Sorry! MKoltnow 21:58, 1 December 2006 (UTC)

"As of year" seems to be superfluous, as redirects for "As of (month) (year)" are available. Consequently I removed this from the template. -- User:Docu

[edit] Automated categorisation

I see there's some resistance to my change to this template, so it's time for some discussion. All Swiss cantons have their own municipality categories, so all Swiss municipalities are in one or other of those. Articles should not be in both a category and a subcategory of that category (Wikipedia:Categorization#Some general guidelines, number 3). Using a template to automatically add articles to categories prevents one from applying the proper alphabetical order to the category, since the MediaWiki software puts accented letters (umlauts, acutes, circumflexes, etc.) after the usual alphabet, whereas they would normally sort together with the unaccented forms. In a previous discussion (above), no convincing reason could be found for keeping the double categorisation, and in fact a list would be better suited to that purpose. Anyone care to disagree? --Stemonitis 08:17, 8 August 2006 (UTC)

Some things are easier to do if there are in just one category. Just ignore the category, if you don't want to use it. Please avoid doing reverts on it. As long as the categorization is consistent, nothing prevents us from applying both.

If you care, you may want to define a specific optional sortkey to allow sorting by unaccented forms. It should be easy to add. I wouldn't mind. -- User:Docu

The policy is there for a reason. Please read it. And there is no consensus, just laziness. No-one wanted to make the change, although no-one could find a good reason not to. Please provide a convincing reason for this double categorisation. I've already sorted the accented forms once before finding the real cause of the problem. It's a large amount of work, when it could all be solved by one edit which you won't allow me to make. I've found a simple, easy, policy-consistent, sensible way of solving it; your solution is worse. Let me make it. --Stemonitis 07:52, 9 August 2006 (UTC)

You might want to read on the next page to get the full policy. A simple reason is that Special:Recentchangeslinked/Category:Municipalities_of_Switzerland wouldn't work. This way you can easy check changes to the articles you created about municipalities in several cantons. Besides, if you are not sure which canton it was in, you can easily located it. Anyways, please add an optional field for sortkeys, if you feel it's needed. -- User:Docu

I would recommend a list for that functionality. --Stemonitis 06:22, 10 August 2006 (UTC)

I personaly don't care strongly one way or the other, but if someone thinks the listing of all municipalities in one category may be handy, then I'd choose to go with the status quo. I can take care of the optional sorting field if needed. Schutz 21:50, 9 August 2006 (UTC)

I really can't understand why you wouldn't want to go for the easy option. --Stemonitis 06:22, 10 August 2006 (UTC)

What do you call the "easy option" ? Modifying a template (plus taking care of a few particular cases when there are accents involved) seems much easier to me than building a list from scratch and making sure that all the links are correct. Schutz 08:47, 10 August 2006 (UTC)

See User:Stemonitis/Swiss municipalities, created from the existing list articles, or list sections of the canton articles. No two links point to the same place except for cases where no disambiguation page exists yet. It took much less time to build than it would to re-sort all the accented ones (I know from experience). --Stemonitis 09:57, 10 August 2006 (UTC)

Personally, I don't mind about the sorting. If you want to go for a static list, how often do you plan to update it? Daily, monthly or annually? Articles get created or moved once in a while. -- User:Docu

Using the list, I am able to see that the following articles have been created today: Märstetten, Bussnang, Bürglen, Thurgau, Birwinken, etc., etc. Any page moves would also show up under "recent changes". Page creations would not show up in a category if the new article is not put into the category, which is often the case, which is therefore an advantage of the list. Incidentally, the list is only a sub-page of my user page at the moment because I wasn't sure what title to give it. Feel free to move it to a title of your choosing. Can anyone give me any reason now that we've got the list, why I shouldn't empty out the Category:Municipalities of Switzerland? I feel I've answered all your queries. --Stemonitis 11:33, 10 August 2006 (UTC)

Looks good to me. Schutz 12:26, 10 August 2006 (UTC)

It just misses the articles that are created at locations to or from other than the ones on your list. Besides, you haven't responded to the question about the update frequency. -- User:Docu

And the category method misses those that are not categorised when created. One would hope that new articles would be created according to the titles given on the list; in most cases this is certainly going to be the case (where there is no need for disambiguation). The other alternative is that someone will create a disambiguation page at a title given on the list, at which point he or she should go through the incoming links and fix them to point to the disambiguated pages. Manual updates should thus never be necessary. Since a category structure exists already, it can be used to find the mis-titled articles anyway. This is the way it works at every other large category. Any further problems? --Stemonitis 06:30, 11 August 2006 (UTC)

The list is a good thing to have, I even moved it into article namespace. Thanks for making it.

It may not lead to the correct article as apparently it still needs updating. Now the question is, are you going to do the regular updates or not? I'd prefer we'd continue to use the category on the infobox and the project page to track the changes and keep things consistent with the same category in other languages.

BTW are there any articles you created you got trouble finding if we include the category? -- User:Docu

Like I say, it should only need updating when someone creates a disambiguation page, and when someone creates a disambiguation page, he or she should make sure that all pages that had linked to it are changed to point to the correct (disambiguated) pages. This is what I did yesterday when I found that the disambiguation page Rickenbach had been created. Other kinds of updates should not be necessary. Therefore, I only need to update it when I make a new disambiguation page. I have no plans to make one at the moment, but if I should, then I'll update the list; otherwise, I won't.

I don't think I understand your question about the category. There is nothing that can be found with the big category method that can't be found in a sub-category or (alternatively) on the list, unless articles are created at entirely inappropriate titles (mis-spelled, wrongly capitalised or similar).

It may also be desirable to split the list into sections so that it loads more quickly; I did very little formatting, since that didn't seem important at the time. I'll leave it up to you how the list will look.

I don't buy the argument about interwiki consistency. Different Wikipedias have different policies, and we should not apply the policies and practices of one Wikipedia to another. In any case, the French and Swedish Wikipedias do it the way I suggest, so there's no greater consistency either way. --Stemonitis 09:07, 12 August 2006 (UTC)

Ok then you wont be updating it. Thank you for answering the question. -- User:Docu

I won't need to! Does it really make so much difference whether I personally agree to regularly update something that won't need updating? Maybe I will from time to time, but I'm hardly going to guarantee that here and now. If that's the only reason for your reversion to the double-category system, then I must say I'm disappointed. I've put some effort into improving the state of things, and you're resisting the improvements for no apparent reason. --Stemonitis 10:53, 12 August 2006 (UTC)

The category on the template automates updating. It's a simple as that. It faciliates extraction of the articles as well.

You don't need to get angry and call things "a disaster" just because you don't agree with it or you don't use a category you just discovered. If you like to improve or to contribute to WikiProject Municipalities of Switzerland, please help creating stubs for the municipalities that are still missing them. I will contribute the infobox. -- User:Docu

I don't wish to put words in Schutz' mouth, but his/her comment above ("Looks good to me") seems like support for my method, which also follows policy on categories. The only support I can see for yours comes from you yourself, and the only reasons you give are effectively nullified by the existence of the list. Consensus, such as it is, is on my side.

Often, when new users create articles, they are (understandably) not aware of the existing hierarchy of categories, and so the articles are not added to the categories correctly. If you rely on the category to discover new articles, you will miss those ones. With the list you will not. The alternative problem, that an article will be created, but at the wrong title, can be picked up through the cantonal categories whether or not the infobox fills a megacategory. If the new article is ill-titled and uncategorised, then neither method will pick up on it, anyway. You could always use the "What links here" on {{Infobox Swiss town}} to find out about (ill-titled, uncategorised) articles that use that template. This would be better than filling a category with what amounts to "Articles that use Template:Infobox Swiss town".

What do you mean by "facilitates extraction of the articles"? --Stemonitis 11:33, 12 August 2006 (UTC)

I agree with Schutz that the list is nice to have. This doesn't mean it duplicates the current category solution. Categories and lists generally complete each other.

To discover new articles, the solution of the WikiProject is much more comprehensive 1. Once created, one just needs to add the infobox to add it to the category.

"facilitates extraction of the articles", i.e. you can get all articles on Swiss municipalities from one category. -- User:Docu

Well, if you've got that list, you don't need the category at all, and you never did. Curious. --Stemonitis 12:26, 12 August 2006 (UTC)

Yes, I basically agree with your method... and I also notice that there seem to be a push at the moment to create stubs for all the Swiss municipalities; once this will be done, there should be no need to update the list anymore. Schutz 21:57, 13 August 2006 (UTC)

List of municipalities of Switzerland still seems to link to disambiguation pages, would you fix it or should we use the category? - November 22, 2006 -- User:Docu

As it's much easier to do fixes to the list as well as the articles using the infobox, I readded the category. Maybe someone else who helps fixing List of municipalities of Switzerland wants to comment? -- User:Docu

Please read the comments at Wikipedia:Categories for deletion/Log/2006 November 1#Category:Municipalities of Switzerland. The list can be fixed, whereas the mis-sorting cannot so easily be fixed. Furthermore, no-one was able to think of a good encyclopaedic reason for keeping this monster category when all its constituent articles are already in one or other subcategory. Restoring the category is clearly going against consensus. Anything which serves primarily as a tool to editors should not be in the main (Category) namespace, but should probably be on the talk pages of the articles concerned instead. --Stemonitis 11:39, 20 January 2007 (UTC)

Hmm, the main concern seems to be the missing sortkeys. I will try to fix it this week. It should be easy to do.

I don't understand why you mind that much having an additional category on articles you hardly edit, especially that it facilitates many things, e.g. Special:Recentchangeslinked/Category:Municipalities_of_Switzerland. -- User:Docu

It's not only the sort keys (although that's a big enough problem). The guidelines at WP:SUBCAT state that "In straightforward cases an article should not be in both a category and its subcategory". The reasons for this are clear; if every article in a subcategory were included in the parent category, many categories would become so large as to be unusable. If it is useful to put all Swiss municipalities in a single category and not only in cantonal categories, then by the same logic, it would be useful to have all European municipalities in a single category, or all populated places in the world. Very soon, the cateogry ceases to be useful and becomes a burden instead. Hence the guideline that an article should be sorted vertically into the most precise category, and not in any of that category's parent categories. --Stemonitis 02:13, 23 January 2007 (UTC)

I will try to find a solution as well. Don't worry, none want's to mkae alist of all European municipalities similar to list of municipalities of Switzerland. Any other issues? -- User:Docu

[edit] Why no maps?

Since user Tschubby [1] has uploaded almost every community map of Switzerland he made to Wiki Commons [2] and many articles already include the image code I don't see a reason why the maps should remain turned off. Makes no sense to me. --Cooper.ch 19:14, 13 August 2006 (UTC)

We just need to decide on which format to use and implement it consistently. Initial inclusion just used the image path, later additions the entire image name. Personally, I would use the first format, but I wouldn't use the maps with labels in German for places where it's not the local language. -- User:Docu

I agree with Docu; even though a map in German is better than no map at all, having a map that says "Frankreich" instead of "France" is likely to confuse English speakers rather than help them. It is a pity, because the maps are excellent otherwise. It would be nice if these maps were available in SVG format, and that we could just have a list of translations for all places, and a simple search/replace in the XML source could be used to translate them (although names of different lengths could ruin the layout). Schutz 21:55, 13 August 2006 (UTC).

[edit] How to rename

Supposedly, Tobias Conradi is trying to standardize names (by renaming to Template:Infobox Town CH). As it's only for municipalities, we might as well change its name to "Template:Infobox Municipality CH". There don't appear to be any others named that way though (see Special:Allpages/Infobox). Until naming is fixed, I'm moving it back to the old title (Template:Infobox Swiss town). -- User:Docu

[edit] How to color

The current yellow might not be optimal for cases where "subject_name" still includes the coat of arms. (sample). Personally, I'd favor the previous "color", but obviously, this is something that may be debated at length. -- User:Docu

Recent changes meant that the coat of arms can now be successfully displayed along with a title (sample1), or just the title if no arms exist (sample2). I agree that it looked unattractive with the coat of arms buried within a coloured box, but a much better solution would be to edit all municipality boxes that display a coat of arms to make use of the imagepath_coa field. And then we can give the title some colour, which looked a lot better than does plain white. The task is to to find all remaining municipalities that display a coat within the subject_name box. I've captured quite a few of them, but we need a method of chasing up the remainder. I can do it some time in the next week. --BillC 00:45, 1 December 2006 (UTC)

I've reverted to the colour version, promising to deal with the articles in which (don't know for what reason) the coat is not in the proper field. Bye. --Attilios 16:29, 2 December 2006 (UTC)

[edit] How to add maps

The maps available at commons mainly map the borders of the municipality as compared to the neighboring municipalities. Possibly we could include a link like "(map)" where the list of neighboring municipalities are displayed (currently in an optional table row starting with "Surrounded by"). -- User:Docu

[edit] neighboring_municipalities

Articles in the French and Italian language version include the lists of neighboring municipalities. Maybe there is an easy way to import them for "neighboring_municipalities=". -- User:Docu

I guess there isn't .. quite some work ahead then. -- User:Docu

Hopefully the import from the Italian wikipedia works. -- User:Docu

It worked fairly well. Image:Kuckucksuhr.JPG lists the few remaining pages having problems. They are all non-municipalities (Appenzell (town)) or former municipalities. The template should be adapted better for former municipalities. They can easily be filtered with "municipality_type= former". Appenzell (town) could probably be merged with Appenzell (district). -- User:Docu

So the template (which is now 340 kb long) contains the neighbouring information for all municipalities in Switzerland ?? Is it really a feature ? It seems slightly crazy to me; firstly, because this can not be good for the software's performance, and secondly, because such information should be self-contained in each article (as a parameter) rather than being in this template. Schutz 22:32, 18 June 2007 (UTC)

Some articles include the information directly. In these cases the article data is used.

For all those where it was missing, it's now in the template.

Ideally the information would really be in the individual articles and I can have the bot run through them to load it, but when doing that, I'd like to include other updates. Are there elements you would like to include? -- User:Docu

[edit] Standardizing Geographic Coordinates

The geographic coordinates here are not following the standards used by other infoboxes. This means they are also not showing up on Google Earth's new Wikipedia layer. Can we change the infobox to follow more commonly used metrics? (see Google Earth Wikipedia Layer FAQ). I'll certainly help switch the Swiss towns over to the new standard. I'd love for all these swiss cities to be seen and read about by this great program! :) thanks, Goldfishbutt 08:17, 19 February 2007 (UTC)

Which format would you use? (Nice to read on Google how to use templates we created on Wikipedia ;) ). The locator map, the coordinates in the infobox and the coordinates on the article currently depend on the settings in (nd, nm, ed, em) and there is an advantage of being able to enter the coordinates just once. -- User:Docu

The example that is given on the Google webpage is the Template:Infobox_CityIT (used for Italian cities). Maybe we could model it after this? Here you also only have to put in coordinates once (and they will show up at the top of the page), but in the style of 'coor dms N E' rather than 'nd, nm, ed, em'. Again - I'd definitely help replace the coordinates on the individual wiki pages if we could change to this standard, (just don't know how to change the CH town infobox template myself). thanks! Goldfishbutt 12:02, 6 March 2007 (UTC)

Template:Infobox CityIT doesn't include a locator map and I don't think one could include one there without duplicating the coordinates. Maybe you might want to update the Google Earth FAQ to include infoboxes such as this one. -- User:Docu

Template:Infobox Afghan City seems to be an example of an infobox that has a locator map but also has its coordinates show up on Google Earth, so it looks as though it can be done. (see Kabul at 34.533° N, 69.166° E) Goldfishbutt 06:56, 14 March 2007 (UTC)

So would simply need to rename "nd" to "latd", "nm" to "latm", "ed" to "longd" and "em" to "longm"? Instead of "|nd=|nm=|ed=|em=", we will have "|latd=|latm=|latd=|latm=" ?-- User:Docu

Apparently this is a known problem with Google, you can solve it with the solution suggested on Wikipedia talk:WikiProject Geographical coordinates#FAQ: Google Earth Geographic Web Layer. -- User:Docu

[edit] Section

Moved to /Archive01

[edit] Elevation

On test, I added a conversation to feet for the elevation (input is in meters/metres). It's visible at Template_talk:Infobox_Swiss_town/Test.

On a few articles, the elevation field includes additional information (Avers, Ormont-Dessus, Hasliberg, Bagnes, Obersaxen, Wald, Berne). To make the conversation work there, the additional information would need to go into an additional field (e.g. "altitude_description"). -- User:Docu

Instead of doing that, please restore the hCard markup which you recently removed, with no explanation, and no justification. Andy Mabbett 23:01, 7 June 2007 (UTC)

Pigsonthewing, I think BillC explained it do you. Please comment on the issue at hand, i.e. the elevation field. -- User:Docu

Nobody has explained any such thing; and it remains the issue at hand until it is properly addressed. My name remains, Andy Mabbett 23:21, 7 June 2007 (UTC)

[edit] Photograph?

Would people here appreciate adding an optional photograph field to the template, maybe below Canton/District? It would give us a standardised way to add a representative photograph to each article, especially for the smaller municipalities whose articles don't have a photograph yet. Sandstein 16:58, 3 August 2007 (UTC)

I would appreciate it so much I was asking myself the same question yesterday... so yes for me. Schutz 17:20, 3 August 2007 (UTC)

It may be worth doing it. The infobox would get even more lenghty though.

Some time ago, I checked the category to make sure {{commonscat}} is added where a category with the same name is available.

BTW, here is the selection used on infobox lake: Wikipedia:WikiProject Lakes/Galleries-- User:Docu

This has been done for Template:Infobox German Location and can work rather well (eg. see Cologne). But there is always the problem with people selecting images that are taller than they are wide, making the photo too long in comparison to the rest of the infobox. IMO it's a good feature, but you have to be careful with image choice. - 52 Pickup 08:23, 1 November 2007 (UTC)

[edit] Semi-protected

I have semi-d this infobox, since it is used on 2700+ articles. Rich Farmbrough, 10:58 22 September 2007 (GMT).

I'm not sure if it's worth doing it, but, if you do, you may want to protect it completely. -- User:Docu

[edit] Proposed new version

I propose a number of changes to the template. By using some of the code setup that is used by similar templates, the code can be simplified and the length of the infobox reduced.

Current version

Proposed version

Coordinates: 46°12′N, 9°01′E Bellinzona Country Switzerland Canton Ticino District Bellinzona 46°12′N, 9°01′E Population 17,363  (December 2005)   - Density Expression error: Unrecognised punctuation character "," /km² (Expression error: Unrecognised punctuation character "," /sq.mi.) Area 19.84 km² (7.7 sq mi) Elevation 238 m (781 ft) Postal code 6500 SFOS number 5002 Mayor Brenno Martignoni Localities Artore, Carasso , Daro, Ravecchia Surrounded by (view map) Arbedo-Castione, Giubiasco, Gorduno, Monte Carasso, Pianezzo, Sant'Antonio Website www.bellinzona.ch Bellinzona [zoom]

Bellinzona Country Switzerland Canton Ticino District Bellinzona 46°12′N 9°01′E / 46.2, 9.017Coordinates: 46°12′N 9°01′E / 46.2, 9.017 Population 17,363  (December 2005)   - Density 875 /km² (338 /sq.mi.) Area 19.84 km² (7.7 sq mi) Elevation 238 m (781 ft) Postal code 6500 SFOS number 5002 Mayor Brenno Martignoni Localities Artore, Carasso , Daro, Ravecchia Surrounded by (view map) Arbedo-Castione, Giubiasco, Gorduno, Monte Carasso, Pianezzo, Sant'Antonio Website www.bellinzona.ch Bellinzona [zoom]

Apart from the condensation of the code and the template's appearance, there are a number of other things that I have included in this new version:

• Population density: For this to work correctly, all commas have to be removed from population values. I think this can be done with a bot.
• Coordinates displayed only in the title bar, removing that annoying globe icon from the table.
• Canton flags: Given the value for "canton", the corresponding canton flag should appear in the top-right corner.

As requested above, a photo may be added to this template, but I have added that code to the template yet.

What do you think? - 52 Pickup (talk) 11:08, 18 November 2007 (UTC)

Definitely an improvement,thanks! I would greatly appreciate it if you could come up with a version that optionally incorporates a photograph in the place of the coat of arms, possibly moving the coat to a new column to the right of the "Country/Canton/District" section. Sandstein (talk) 11:22, 18 November 2007 (UTC)

Photo now added, along with optional caption field. Placing the Country/Canton/District fields next to the CoA is a very good idea and I'll give it a try. At first I tried to have the names in various languages next to the CoA image but thought that that might not be such a helpful addition.

This test template is located here. Please test it out on other entries so any bugs can be identified. - 52 Pickup (talk) 12:12, 18 November 2007 (UTC)

A copy of the proposed version is now at Template:Infobox Swiss town/sandbox to enable preview of the test cases on Template:Infobox Swiss town/testcases.

• I like the reduced horizontal spacing. Especially for neighboring muncipalities, twin towns, places this is an advantage.
• If there were a way to reduce the size of the photo, this would be helpful. Currently one has to scroll quite far to view the main data.
• Personally, I'd maintain the display of the coordinates, given that they are defined in the template.
• As the Swiss map can't be displayed next to the coat of arms, I suppose some other data could go there and save space.
• Personally, I wouldn't bold the labels on the left side of the table.
• Coat of arms of canton and country may remind some of Swiss car number plates. I wouldn't include them in the infobox, even if other boxes may do.
• The font size seems to work mainly in monobook, compare other skins: [Chick] [Classic] [Cologne Blue] [Modern] [MonoBook] [MySkin] [Nostalgia] [Simple]
• The borders around some of the fields structure the box better.

Good work. -- User:Docu

I made some changes to the template at Template:Infobox Swiss town/sandbox (results at Template:Infobox Swiss town/testcases). There is still at lot of space next to the coat of arms. Maybe SFOS and ZIP code could go there as well. -- User:Docu

Thanks for the improvements! Some proposals:

• I think the photograph looks better at the top of the box, as in User:52 Pickup/Drafts/Infobox Swiss town (compare Template:Infobox German Location).
• What's the cuckoo clock for? At 9 px, it looks like a squashed mouse... If it has a purpose, using a standard clockface icon might be advisable.
• I propose we put the geocoordinates in the title bar - most readers won't need them, and those who do, will first look for them in the usual place. However, we could put the Swiss map coordinates in the infobox (e.g., 600 000 / 200 000 for Berne), as many Swiss people will be familiar with them.
• The SFOS code is also something that very few people will be interested in. If we want to put something else to the right of the coat of arms, maybe the population count would do?

Sandstein (talk) 20:09, 18 November 2007 (UTC)

I agree that the current formatting of the photograph isn't ideal (the line needs fixing), but unless we arrange the top of the box differently, I think we'd get too many images before getting any info.

The cuckoo clock should only appear with outdated parameters. All infoboxes displaying should be either in the article's history or need to be fixed.

Next to the coat of arms, area and population, possibly elevation would be ideal, but we would probably need to do away with the conversions.

-- User:Docu

• The problem with photo size is one that you cannot really avoid if you want to have a photo option. Even though there is the variable imagesize, many people will not use it. And, as mentioned above, a problem we have with the German Location Infobox is where people use images that are too tall. You don't want to squash the images, and it is not easy to keep watch on all articles to make sure that pictures with decent dimensions are used. In short, there is no real solution to this problem, except for not having a photo at all.
• With the coordinates returned to the table (and tweaking the CoA size), the space next to the CoA is IMO now well-filled. Not all CoAs have the same dimensions (eg. Zürich) so you don't want to jam too much in there. I've also just made some modifications to the template so that if no CoA is given, then these fields will be displayed just like the others (same alignment, etc.).
• The canton flag thing was just something I made up for this template, I don't think this is done anywhere else. The resemblance to Swiss number plates is somewhat deliberate, but the main inspiration for doing this came from the Swiss TV news where a lot of the time, the canton flag appears when discussing a certain location.
• Articles using older variables can easily be placed in a temporary maintenance category (eg. see the German maintenance category) so these articles can be rapidly identified and the fields can be updated. It is also possible to integrate multiple variable names without duplicating large slabs of code.
• Political parties (new point): since the variable mayor_party is almost always given as a party abbreviation, it is possible to use this to link directly to that party's article. This is done using {{polparty}}. This is used in the German location infobox where if you enter "SPD", then the box will display [[Social Democratic Party of Germany|SPD]]. For this to work, the Swiss parties must be fed into the polparty template, which is not difficult.
• Categorisation (another new point): At the moment, all articles using this template get placed in the "Municipalities of Switzerland" category. Wouldn't it make more sense to categorise each location by canton? This can also be easily done (although i probably don't have the canton category names correct just yet). If an unacceptable value is given for the canton, then the article can then be assigned to a maintenance category (and my version also now has a warning icon to draw attention to the error) - so then the canton value can be corrected, or the different value can be added to the switches within the template code.

52 Pickup (talk) 17:30, 19 November 2007 (UTC)

• Photo size/photo placement - I'm aware that photo size can't be entirely controlled, but if you place the image in the top section of the template, even if the image isn't much longer than large, you can't see much of the data further below. Now that some information is displayed next to the coat of arms, this is somewhat improved, but it may still be preferable to place the photo after area/population data. BTW with pages like Wikipedia:WikiProject Lakes/Galleries one can review the images used in infoboxes.
• CoA layout: thank you for improving it. It looks much better now.
• Canton flag: I'm told that this is something that is liked. A solution could be the one used on the Canadian infoboxes, check, e.g. Toronto.
• Old fields: it's unlikely that you find them in the current version of articles, but if we don't include them in the current template, the page history gets somewhat unreadable. Maybe we could have the category for maintenance and some notice above the infobox mainly for displaying older versions of articles. -- User:Docu
• Political parties: ok with me (please note that there may at least two abbreviations for each party, personally I use the one in both languages.
• Categorisation: all articles are already in categories for cantons. As not everyone likes automatic categorisation, I think we should limit it to the present two categories.
• BTW, in general, it's easier to pick the correct canton if you use "iso-region". -- User:Docu

• Check for obsolete variables and absence of iso-region: [3]
• Given iso-region, this makes the "canton" variable largely obsolete. At the moment, the links under the Canton section do not always go directly to the right article: not all articles are named "Canton of..." and many links to the sections within "Districts of Switzerland" do not work properly. Even though redirects are cheap, the canton details could be easily controlled from within the template once iso-region is supplied.
• Political parties: I've just made a few Swiss additions to the polparty template. Multiple abbreviations for the same party is possible, e.g.:

{{polparty|Switzerland|SVP}}	SVP/UDC
{{polparty|Switzerland|UDC}}	SVP/UDC
{{polparty|Switzerland|SVP/UDC}}	SVP/UDC

...or the code can easily be changed so that all 3 options display "SVP/UDC". It is easy to add this template to the infobox - [4] - where only the final field is required. - 52 Pickup (talk) 16:36, 21 November 2007 (UTC)

I added a few combinations to {{polparty}}. The field for the party is not used that often. Even if the ISO region code is available, I'd still include a field for the name in text. It's easier to understand for many. Besides, links to the canton articles always worked. -- User:Docu

Well actually I would rather convert then all to a standard template and rid entirely of "Swiss town infobox". Why should Switzerland be special and have its own? ♦Blofeld of SPECTRE♦ ^$1,000,000? 19:32, 3 May 2008 (UTC)

Because Swiss municipalities have attributes such as a coat of arms, canton, district, SFOS number and postal code that are probably not well suited for display in a generic infobox. Sandstein (talk) 20:07, 3 May 2008 (UTC)

I may be wrong about this; {{Infobox Settlement}} looks rather complete. The best way to convince us would be to (a) explain what practical and substantial benefit a migration would bring, (b) produce well-looking mockups based on the standard box and (c) propose (and be ready to carry out) a practicable migration plan. Sandstein (talk) 20:21, 3 May 2008 (UTC)

Personally I find it easy to use this template's extraction by Templatetiger to do maintenance. Possibly someone has experience to share doing it with a more frequently used one. -- User:Docu

[edit] Elevation

At Template:Infobox_Swiss_town/testcases, four new fields are being tested: ( {{highest}} {{highest_m}} {{lowest}} {{lowest_m}}. The optional fields can be used to add the elevation and name of the highest point in the municipality, similar to the fields already in use for the infobox for cantons. I removed the conversion to ft as it took up too much space. -- User:Docu

[edit] Incorrect calculation for old measurements?

Can someone please check the calculations with miles? Eppenberg-Wöschnau has Population=319, Area=1.89 km², Density=169 /km² which is correct; but Population=319, Area=0.7 sq mi, Density=65 /sq.mi.. Shouldn't that be 456 /sq.mi.? -- Jeandré, 2008-04-18t11:12z

Thanks. The coefficent (1.609344²) was on the wrong side of the expression. It should be fixed now. — BillC ^talk 17:50, 18 April 2008 (UTC)

[edit] Placement of map

Blofeld tried to implement three changes:

• 1. switch the locator map from Image:Karte Schweiz.png to Image:Switzerland map blank.png
• 2. place the map at the top rather than at the bottom of the infobox. This change can be previewed at Template:Infobox Swiss town/testcases
• 3. reduce the size of the coat of arms (at least in one of the versions). This change can be previewed at Template:Infobox Swiss town/testcases

Personally, I favor point (3.): It reduces the space used and one has to scroll less to see more of the information. As for (2.): in general, I'd rather see first the other information. For (1.), the map shows adds too much space around the actual map. -- User:Docu

You do realise that having the map at the bottom is completely against the standard template where it is at the top with room for a photograph. The Swiss town infobox does neither of this and frustratingly it can't be edited and have the flexibility that a standard template has. I'm not too concerned about the map although I think a map with colour rather than greyscale is more attractive, but if we must have a seperate infobox, can the map at least be moved to the top and a new paramter added for a top photograph as 98% of other places have?? ♦Blofeld of SPECTRE♦ ^$1,000,000? 19:58, 3 May 2008 (UTC)

If you examine well over 95% of other places on wikipedia you'll see it is standard to have the map locator at the top. Photograph at the very top, map underneath and then all the data neatly underneath. The standard infobox Settlmeent ande city all use this and most countries on the planet on wikipedia have evolved this way. Only a few countries like Switzerland and Slovakia insist on having it at the bottom ♦Blofeld of SPECTRE♦ ^$1,000,000? 20:01, 3 May 2008 (UTC)

Which municipalities' templates are you comparing to?

BTW you can add a photograph with "|image_photo=", but there isn't much demand for this parameter since it was introduced. Possibly because images in infoboxes are not supported by some of the image layers based on Wikipedia articles. -- User:Docu

Well, I'm trying to use the photo parameter when I come across a town article. On the matter at hand, I agree with Docu's assessment. In a comparatively small country such as Switzerland, the geographical location is probably not the most important point of information for the international reader. Sandstein (talk) 20:14, 3 May 2008 (UTC)

Well I like to see things consistent all across wikipedia and this Swiss template is backwards. It would look much better with a photo paramter at the top too, particularly for a country as scenic as Switzerland. All templates such as even lakes and infoboxes for mountains always have a photo at the very top. For me the photograph should be at the top. This isn't to do with information importance as obviously the data is more important, but I strongly think it gives the appearance more weight this way and is an overall improvement. If the infobox could be changed so there is a photo parameter which is at the absolute top and a map this is all I ask you to think about . Regards ♦Blofeld of SPECTRE♦ ^$1,000,000? 20:37, 3 May 2008 (UTC)

Why can't you guys just use the standard? Looks much more attractive. -- —Preceding unsigned comment added by Blofeld of SPECTRE (talk • contribs)

Please add your preferred versions to Template:Infobox Swiss town/testcases rather than to live articles. This makes it easier to compare. -- User:Docu

Lausanne
Coat of arms
Lausanne Location in Switzerland
Coordinates: 46°31′N 6°38′E / 46.517, 6.633
Country	Switzerland
Cantons of Switzerland	Vaud
District	Lausanne
Government
- Mayor	Daniel Brélaz (GPS)
Area
- Total	16 sq mi (41.37 km²)
Elevation	1,624 ft (495 m)
Population (2007)
- Total	128,302
- Urban Density	8,031.6/sq mi (3,101/km²)
SFOS number 5586	1000-1018
Website: www.lausanne.ch

[edit] Pictures with snow in summer

For municipalities in the mountains, e.g. ski and summer resorts, it's a bit odd to display images with snow all year. It might be preferable to provide fields for two separate images. Depending on the month, we could display one or the other. -- User:Docu