Template talk:Building address/Archive 1

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
Archive 1 Archive 2 →

September 2011

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

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

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.
Gebäude
Hauptstraße 1
12345 Musterstadt
Germany
for a german address or
Building
123 Main Street
Anywhere, CA 12345
United States of America
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

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

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:

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)

Canada

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

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"?
Category:Buildings_with_addresses_-_incorrect_country_code
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?

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)

NY for NY state, not city

In this file NY is translated as New York City, wheres it should be New York State. --Vera (talk) 14:32, 14 December 2014 (UTC)

Parameter Province

There are a few images in Category:Pages using Building address template with incorrect parameter (e.g. File:Ürümqi Lu nr. 151.jpg) that have the (undefined) parameter Province. What do we do about them? --Leyo 00:44, 18 February 2016 (UTC)

The problem is not with Province which is defined for country code CN, but with Category:Pages using Building address template with incorrect parameter error checking. Whoever added it did not checked which parameters are defined for each country. Also many of those parameters are not documented. --Jarekt (talk) 04:03, 18 February 2016 (UTC)
As you say, parameters need to be documented. This includes one parameter that you added. As you noticed there were really few (less than a dozen) errors considering that the template is transcluded in thousands of pages. --Leyo 22:50, 18 February 2016 (UTC)

This template is kind of broken

As User:Rillke mentioned at Template_talk:Building_address#Propose_new_changes this template is kind of broken. As far as I can tell 0riginally this template displayed a table, but than in 2011 User:Zolo rewrote it to rely on {{Information field}} template. The problem with {{Information field}}, which is kind of a hack using code injection, is that is only meant to be used with other_field fields used by many infoboxes to add extra fields, and nothing else. The bottom line is that {{Information field}} be used without other_field produces invalid html code. For example Category:Academiegebouw (Groningen) uses

{{Building address | Street name = Broerstraat | House number = 5 | Postal code = | City = Groningen | State = Groningen | Country = NL }} {{Object location dec|53.21927658|6.563166547|region:NL_type:landmark_scale:1500}} to produce Address

InfoField
Broerstraat 5
Groningen
Netherlands
Object location53° 13′ 09.4″ N, 6° 33′ 47.4″ E Kartographer map based on OpenStreetMap.View all coordinates using: OpenStreetMapinfo

As you can see {{Building address}} is kind of broken and even {{Location}} template does not show properly. The proper html code would be generated if we use <table class="toccolours" style="width: 100%"> {{Building address | Street name = Broerstraat | House number = 5 | Postal code = | City = Groningen | State = Groningen | Country = NL }} </table> {{Object location dec|53.21927658|6.563166547|region:NL_type:landmark_scale:1500}} to produce

Address
InfoField
Broerstraat 5
Groningen
Netherlands
Object location53° 13′ 09.4″ N, 6° 33′ 47.4″ E Kartographer map based on OpenStreetMap.View all coordinates using: OpenStreetMapinfo

Wrapping this template in <table class="toccolours" style="width: 100%">...</table>. I propose to make that change and also add an extra parameter to allow use of current style, which might be required when used with other_field. --Jarekt (talk) 03:51, 27 February 2017 (UTC)

Bug with this template

See e.g. Category:Voormalig Gymnasium Johan van Oldenbarnevelt - the code for this template overspills into the next one. Looks like there's a missing end of table, or something. Can this be fixed please? @Jarekt: maybe this is related to your comment above? Thanks. Mike Peel (talk) 23:42, 30 March 2018 (UTC)

Mike Peel, I do not think there are any easy fixes to this template, as it is attempting to do 2 different tasks which require different HTML codes:
  1. Be stand-alone infobox template. The way it is usually used in categories, like Category:Kongresshalle Gießen. In this case it is missing <Table>...<Table/> HTML tags.
  2. Use Code injection like approach to hack into {{Information}} template and other infoboxes, as shown in File:12-11-01-hallein-baudenkmal-by-RalfR-230.jpg and half-a-million similar files. The template does not produce valid HTML, but browsers manage to recover (all browsers?).
There might be other uses of the template as well. It seems to me that both uses of the template produce invalid HTML code, which is then somehow transformed through some cleanup process to something that kind of works. See for example HTML code for File:Bibliothèque de l'Arsenal-1688283.jpeg with layers for nested <Table>s. I am afraid that any change to the table will break it on the few pages where it actually works. That is why this is one of the few infoboxes I did not touch over the years. Another issue is the use of ~20 different input parameters, some of which like Listings, Reference, Notes, Bare, etc., I do not fully understand and do not know how they are used. It seems to me the only logical thing to do would be to completely rewrite the template and it's use in the files and categories. We should probably rewrite its core in LUA and create separate outer shells (skins) for access from categories and files. I still do not understand how this template does Code injection into {{Information}}. I think it is invalid, but it works. This is much bigger job than I have time to undertake at the moment, as I am trying to work on Module:Artwork/sandbox, in between other smaller tasks. Maybe someone else can take this on. --Jarekt (talk) 13:15, 3 April 2018 (UTC)
Tidy is being replaced with RemexHtml by end-June 2018 [4]. You can see how that change will affect templates via the parsermigration-edit extension. See Category:Kongresshalle_Gie%C3%9Fen for how its rendering will change. Similarly for File:12-11-01-hallein-baudenkmal-by-RalfR-230.jpg which shows no change. SSastry (WMF) (talk) 19:01, 9 April 2018 (UTC)
It looks like that will work around this issue [5], thanks! I'll avoid bot-adding the wikidata infobox to categories using this template until that's deployed. (And it doesn't look like anything changes with the wikidata infobox [6], which is good!) Thanks. Mike Peel (talk) 19:05, 9 April 2018 (UTC)
Currently 34.000 pages have a layout problem, see also [7]. Is it possible to remove style="width:100%; on line 8 of Template:Building address/layout ? This will fix the layout problem as far as I can see, not sure about other side effects.... Thanks. Rudolphous (talk) 17:45, 11 July 2018 (UTC)

Please add Russia

{{Editprotected}}

Please add Russia:

{{#if: {{{Street name|}}} | {{{Street name|}}} {{{House number|}}} <br/>| {{#if: {{{House number|}}} | {{{House number|}}} <br/>|}}}}{{city|{{{City|}}}}, {{state|{{{State}}}}}<br/>{{Russian postal index|{{{Postal code|}}}|w=18}}<br />

Thanks in advance ℺ Gone Postal (〠 ✉ ✍ ⏿) 19:42, 23 June 2018 (UTC)

✓ Done one bracket too little ;-p -- User: Perhelion 00:51, 28 July 2018 (UTC)
@Perhelion: , thanks, but for some reason State doesn't work. Is it because there is no '|' at the end? Sorry for that. You can see the problem at File:Postoffice-bryansk241050-1.jpeg. ℺ Gone Postal (〠 ✉ ✍ ⏿) 04:48, 28 July 2018 (UTC)
@Gone Postal: We have to create {{ISO 3166-2/RU}}, s. Category:ISO 3166-2 templates. -- User: Perhelion 07:03, 28 July 2018 (UTC)
I added now Wikidata entityIds for automatic translation and linking to every supported language on Wikidata. -- User: Perhelion 17:19, 28 July 2018 (UTC)

US zip code is broken but state works

Please take a look at File:Takin it to the streets - The Postal Service is hiring!.ogv, it would appear that it completely ignores the 'Postal code' bit even though the table on the description of the template says that it uses it. On the other hand State works perfectly even though it says to ignore it. ℺ Gone Postal (〠 ✉ ✍ ⏿) 06:20, 24 August 2018 (UTC)

Czech and Slovak specifics

Czechia and Slovakia (maybe also Austria) have a dual system of house numbering. The basic system are "conscription numbers" (popisné číslo, súpisné číslo) which are complementary to the "municipal part". In some bigger cities and towns, "orientation numbers" (orientační číslo) are assigned in addition. Orientation numbers are complementary to the street or square name. However, even if the city have named streets and orientation numbers, not all buildings and not all adresses need to be assigned to any street and not all streets need to have orientation numbers for its houses. Not every settlement which have named streets have also orientation numbers. If any building is on the corner or have two sides, more entries etc., it can have more adresses. The conscription number with the name of the municipal part define the building. To reflect this system, the template should:

Many smaller Czech towns have an abandoned and unmaintained system of orientation numbers: orientation number plates are kept on older houses, but are not included in official registers, on-line maps etc. Some cities never had orientation numbering (Pardubice, Zlín, Kladno...).

Czechia has an other speciality (not such is in Slovakia). Recreational and temporary buildings are numbered in a separate series, by a "registration number" (Evidenční číslo, Wikidata:Q19376249). It can be distinguished by abbreviation ("č. ev.", "če.", "nouzová stavba", "n", "E"), by different color of the number plate (yellow, green), or historically also by added zero before the number (0359 instead 359). The ministerial ordinance supposes that "registration numbers" are not combined with "orientation numbers" but they are exceptions in reality and real registers.

In registers and on older identity cards, the numbers were used separately, with the complementary name: "Vinohrady (čp.) 2327, Sobotecká (č. or.) 9, Praha". In postal adresses and modern register outputs, the numbers are associated using a slash convention: "Sobotecká 2327/9, Praha-Vinohrady". However, some people don't follow the convention and use the opposite order "Sobotecká 9/2327" – this format is considered as less official, or even as wrong. --ŠJů (talk) 13:47, 8 September 2018 (UTC)

Edit Request, Postal code in the US

{{Edit request}}

For addesses in the US postal code is useful and can be used as parameter, but the postal code is missing in the source of the template. Please add the postal code for US addresses. Thank you. --XRay talk 11:51, 25 September 2018 (UTC)

✓ Done --Majora (talk) 23:34, 28 September 2018 (UTC)

Edit Request, Addresses in LU

{{Edit request}}

Addresses of Luxembourg (LU) are missing. Thank you for fixing. --XRay talk 12:16, 25 September 2018 (UTC)

And how exactly are Luxembourgian addresses formatted, XRay? --Majora (talk) 23:35, 28 September 2018 (UTC)
I don't know, but I'm sure, they are formatted with postal code. --XRay talk 00:21, 29 September 2018 (UTC)
 Not done Can't add something without knowing exactly what and how it needs to be added. Feel free to reopen when you have that information. --Majora (talk) 21:30, 3 October 2018 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Template_talk:Building_address/Archive_1&oldid=405386936"