Template talk:Building address

From Wikimedia Commons, the free media repository
Jump to: navigation, search
Evolution-tasks.png Pending tasks for Building address: edit this list - add to watchlist - purge
  • Add formatting for other countries
  • Refine error handling
  • Integrate listed monuments templates to make the whole file description smoother ? Would require to convert them to plain html (see template:Building address/testcases)
  • Integrate coordinates (the type:landmark and the region would be automatically filled)
  • Allow lower cases parameter names for quicker typing ?
  • Add a country flag for quicker identification ?

The header "Building address" should be translated as well. This template is a good idea! -- RE rillke questions? 14:23, 10 September 2011 (UTC) +1. --Alex (talk) 23:05, 1 October 2011 (UTC)

  • I'm not sure if it's the right way to go - that is, having one format for all probable address format (one flat database format -> one flat input record format -> one template fits all). Certainly works for developed countries with stable infrastructure and naming standards (although will stumble at ambiguous names like en:Monroe, Adams County, Indiana and en:Monroe, Tippecanoe County, Indiana). One step away, and it does not look so bright. Say, if the address convention requires levels of subdivisions between "nation" and "town", which level goes into template, and what happens with the other one? Perhaps the better way would be: don't worry about perfect uniformity at data input level - allow different data format and different templates to present them. Then let the database engine blend them together. NVO (talk) 09:12, 17 October 2011 (UTC)
Yes there are countries that require to show several levels of subdivisions, and this cannot be done with an 'administrative unit' parameter as I hoped. But I am not sure it would really help to have many templates (or rather it would help only if they have more lax structure, which may cause other problems). It sound easier to me to customize this template by country (as I tried to do in the sandbox (currently named {{tl|Buidling address/information field layout) than maintain dozen of templates. There certainly is some problems with ambiguous names. For now I think that we can write "Monroe, Adams County" or "Monroe, Tippecanoe County". I suppose the use of a wiktionary based extension or a massive bot work to expand the list of terms supported by {{city}}could help.--Zolo (talk) 09:26, 17 October 2011 (UTC)

One building with two addresses[edit]

The (rare) case that a single building has two different addresses appeared for building Category:Hermannstraße 36 (Dortmund). In text I would write something like StreetA No./StreetB No., but for the template I just used it twice. Any other suggestions? --Alex (talk) 23:05, 1 October 2011 (UTC)

I think your way is the only solution with the current template, but it it is a bit heavy and looks a bit confusing. I don't see any nice solution but maybe we could have address2, street2. It is not very nice either but I if it is not used that often I think it is okay. And I imagine it would be less machine confusing. --Zolo (talk) 08:19, 2 October 2011 (UTC)

Can some assist with cleaning of Category:Wiggerstraße 2 (Dortmund) --Jarekt (talk) 02:46, 7 October 2011 (UTC)

Done, as it seemed to be my fault. Anyway I’d keep the category for future files to be categorized. --Alex (talk) 15:47, 7 October 2011 (UTC)
Thanks, I agree that category should stay to help in the future. --Jarekt (talk) 17:09, 7 October 2011 (UTC)

New proposed version, for more internationalization[edit]

The current template uses a "state" parameter. Most countries are not subdivided into states ("provinces", "counties", "regions" etc.). I have created an alternative version in {{Building address/sandbox}}, that accomodates this problem. I have unified " country" and "state" inoto an "ISO" parameter but it could remain two separate parameters just as well. New back up templates would be needed but this is trivial and quick to do. Of course the new template could be made backward-compatible. Would that be okay ?--Zolo (talk) 08:28, 2 October 2011 (UTC)

✓ Done. I have created an "administrative unit parameter" because "state" was overly restrictive. The template can automatically detect the type of administrative unit. ISO code has to be used. The may sometimes look obscure but if we are supposed to use ISO code for country, it seems sensible to do the same for other administrative divisions. Adding more facilities for natural language use is perfectly feasible but it would make it a bit heavy.
It was suggested in the template documentation to better integrate the template with {{information}}. I agree with that but am not sure how it should look. I think that labels for "street" "Land" etc. are not nessary with this layout. It makes things look heavy, while it should be clear what the name refer to and links can provided by the template it case it is not clear (actually Wikilinks to Wikipedia for country names look like an overkill to me, but this is the only current possibility for internationalization. Would [1] be okay ? Another possibity would be to add labels in the blue margin, but every item would be separated by a thin white stripe. This could make it lengthy.--Zolo (talk) 10:24, 8 October 2011 (UTC)
I like the idea of having the label in the left blue box just as in your example. I would refer to it rather as address or something alike instead of building and maybe it could be merged with the location information. And I would show the address as apropriate in the respective country, e. g.
Hauptstraße 1
12345 Musterstadt
for a german address or
123 Main Street
Anywhere, CA 12345
United States
for one from the States. But that might be hard to implement. --Alex (talk) 16:06, 8 October 2011 (UTC)
Thanks for the input. I changed the field header to address, it is definitely better. About the address layout that you propose, it is perfectly feasible, but it takes some work. I think it works for Germany (same example as above). The most tricky case may be multilingual countries. I suppose the street number street name depends on the language rather than the country (how is it done in Switzerland ?) It could be solved by using the the user's language standards, but since the street name will not be translated, I dont think it makes sense.
One thing that may be annoying with this format is that some data are not displayed (the State in the German case). I think it could make sense to use the template inside categories as well. We could have the current, more explicit and sometimes more complete version on the category page, and the shorter, lighter version inside information templates.
I think it could make sense to integrate {{object location}} (the "type" parameter could be automatically set to landmark and the "Region" parameter to the country, so it would be fairly convenient). However I am not sure about how it should be done.--Zolo (talk) 17:37, 8 October 2011 (UTC)
I am not familiar with correct addressing in Switzerland. The french and italian guidelines by Swiss post look just like the german ones to me (p. 48; haven’t found anything for Romansh). Though I’m not sure when to name the canton as in Baden AG. But you’re right, multilanguage countries might be a problem, especially when it comes to bilingual areas. Another problem that came to my mind are countries with a non-latin alphabet. For example from en:Address_(geography) it seems to me, that address schemes in Asia differ in general. Anyway: as for the states not showing up in Germany, I think that’ll be alright. The ZIP code gives a clue about where the place is located and in general it’s quiet uncommon to name the state. --Alex (talk) 22:43, 8 October 2011 (UTC)
Ok thanks. I think the simplest and most efficient soltion is to use a "#switch:" by country and follow the guidelines of en:Address (Geography). The code will be a bit long, but simple and all kinds of format can be accomodated. About non latin alphabets, there is a "translator" extension in the MediaWiki review queue that could be useful. However it has been ready for years so deployment seems to take some time.--Zolo (talk) 07:13, 9 October 2011 (UTC)
I have implemented that. It now needs to be expanded to all countries and to special cases. I hope this works well.--Zolo (talk) 20:54, 22 October 2011 (UTC)

Move most of Template:Building address/i18n to Template:Building address/xx templates[edit]

I think it is confusing to use 2 means of internationalization, as this template does. we probably should move most of Template:Building address/i18n to Template:Building address/xx templates. This should also fix the issue of Template:Building address/layout being in Category:LangSwitch template without English version. --Jarekt (talk) 13:42, 3 February 2012 (UTC)

The /xx subtemplates are no longer used. I was hesitating to delete them in case we needed to reuse part of them, but I think they can go now. I have added an "includeonly" to remove {{Building address/layout}} from Category:LangSwitch template without English version.--Zolo (talk) 14:07, 3 February 2012 (UTC)
I did not notice that Template:Building address/xx templates are unused. Yes they should be deleted at some point. Thanks for fixing Category:LangSwitch template without English version issue. --Jarekt (talk) 16:51, 3 February 2012 (UTC)
Done. I have also copied part of it to Template:Building address/i18n in case we need some words like "street" that were translated but that the current template do not use.--Zolo (talk) 09:10, 6 February 2012 (UTC)

Propose new changes[edit]

I was pointed out that the html code of this template is incorrect, which could sometime result in an incorrect rendering. One way to solve this would be make use of the "depicted place" parameter of the new {{Photograph}} infobox to remove the {{information field}}. It could look like this: [2] or [3]

Additional advantages:

  • {{Photograph}} does not require a {{description}} parameter, which in some cases would be better, as it is just a repetition of the House name or other elements of {{Building address}} (of course it does not prevent from using {{Building address}} without {{Photograph}})
  • the current implementation can sometime break things, see the "Hello World" here
  • makes the "Bare" parameter obsolete. One caveat about the last point: "Bare" also prevents from categorizing many files transcluding {{institution}} in Category:Buildings with addresses. Can we get rid of the category altogether ? It would make things simpler and more consistent) ? --Zolo (talk) 11:05, 3 June 2012 (UTC)

At least, we must change something: #RFC: Last change of Template:Information broke the hack this template is using - what should we do? -- Rillke(q?) 10:34, 18 May 2013 (UTC)


I wrote this little piece for use in Canadian addresses.

--> |CA=<!--
-->{{#if: {{{House number|}}} | {{{House number|}}} }}{{#if: {{{Street name|}}} | {{{Street name|}}}<br />}}<!--
-->{{city|{{{City|}}}}}, {{{Province|}}} {{{Postal code|}}}<br /><!--

I think it works (I tested it in the sandbox/testcase), but I'm no expert on code, so maybe someone can tell me if it is okay before I put it in. Thanks in advance! DutchHoratius (talk) 23:33, 3 June 2012 (UTC)

Error handling[edit]

there are 2 categories for errors to end up.

Category:Buildings with addresses - country not yet supported
This category is currently filled with 1.300 images from mainly Suriname and Ghana, could somebody make these countries "supported"?
This category is filled with 3.000 RCE images (which all have "Unknown" as country code.) and 8.000 Fotothek Images (which seem to have "" empty country codes.) would it be an idea to make two seperate categories for unknown and empty codes (or let them both end up in an unknown cat). This way the Unknown countries from the RCE images (which I'm slowly sorting out) could be fixed taking some time, while the few hundred images with a real issue: the wrong country code, can be fixed because they are visible again. Could somebody fix this in the template?

Mvg, Basvb (talk) 16:04, 21 April 2013 (UTC)

I have created Category:Buildings with addresses - no country and added a sortkey for country not yet supported so that all 'Unknown' follow each other

RFC: Last change of Template:Information broke the hack this template is using - what should we do?[edit]

Please note, that the last change to Template:Information caused file description pages using the template in the description= field without | Bare = 1 looking odd. The issue is triggered by exchaning a SPAN tag with a DIV tag and HTML Tidy which runs over the HTML output of the MediaWiki parser. The test case is at User:Rillke/SandboxInfo.

The issue is that such a hack could break at any day (e.g. if HTML Tidy is updated) and it is very non-obvious that a template could use such a hack when editing the templates that contain this one (e.g. {{Artwork}} or {{Information}})

There are now 3 possibilities, I am aware of:

  1. Continue the hack and change {{Information}} (removing the DIV class="description" and migrating its class to the TD tag). This looks nice but can break any day. (✓ Done for now)
  2. Change this template so it is only displayed as one would expect (within the value-area of the description field) without messing with other tables and HTML-Tidy (Doesn't look so nice and if people used this template in other_fields [against the usage instructions], it may break there)
  3. Adding another other_fields2 field to {{Information}} that is displayed directly below the description and running a bot over all template usages.

-- Rillke(q?) 14:24, 11 May 2013 (UTC)

Can you explain the hack more. I think I understand it (not 100% sure) but others might not. From your 3 proposed fixes #3 sounds most robust in the long run. --Jarekt (talk) 04:08, 12 May 2013 (UTC)
I've updated this page, which explains the situation now more in detail. -- Rillke(q?) 10:32, 18 May 2013 (UTC)