Template talk:Coord/Archive 4

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

Archive 2

Archive 3

→

Moving microformat markup from articles to coord

{{editprotected}} People are adding microformat markup directly to articles such as here and all the uses of {{Hcard-geo}} to get coordinates associated with a name in the additional output format. Unfortunately writing it directly in articles makes them harder to edit and unnecessarily obfuscates the wikitext. Basically what is being done is that the coordinates are wrapped in an element marked as class="vcard", and a class="fn org" element added with the associated name put inside it. This is easy enough to implement in coord as well, and I have done so here, with a test in my sandbox. It introduces a name parameter to one of the subtemplates. Please modify Template:Coord/link with the same change. This follows the proposal at Template talk:Birth date and age#use_in_hCard_microformat to make it generate the microformat markup outside article space when the name parameter is given. --Para 19:40, 28 June 2007 (UTC)

The following templates call Template:Coord/link and also need to be edited to pass the parameter on: Template:Coord/input/d, Template:Coord/input/dm, Template:Coord/input/dms, and Template:Coord/input/dec. The edit is simply to add "|name={{{name|}}}" to the end of the call, right before the last two closing braces before the ending includeonly. They in turn are called by Template:Coord, where the same edit can be made right after "|format={{{format|}}}". Are sample diffs necessary? --Para 16:07, 29 June 2007 (UTC)

Objection:The name is not published, which violates the hCard specification, as explained previously. It also requires the editor to enter data twice, unlike {{Hcard-geo}} and the table markup cited. The table markup also allows other columns to be marked up with additional hCard properties, which this change would not facilitate. Furthermore, it breaks when CSS is disabled or unavailable, with the attending accessibility issues. Such wide-sweeping changes should be discussed *before* edit-protected requests are made. Andy Mabbett 20:15, 28 June 2007 (UTC)

Editors are already writing names multiple times in articles. Are coordinates ever published without an associated name somewhere in the article, usually very close to the coordinates? I can't think of any example where they would be by themselves. The current coordinate implementation also includes hidden data inside the hCard, namely decimal coordinates when degrees, minutes and seconds are displayed. Including coordinates in another format like that and not displaying them must be a much more severe violation of the specifications than having the exact same information included in the microformat as is visible in the text already. For the style issue I moved the name inside parentheses after the coordinates for the case when someone has disabled CSS. --Para 20:28, 28 June 2007 (UTC)

Does the table of volcanoes you cited currently have each name written more than once? The "hidden" coordinate data is an automatically-generated duplication of the published data, in a different form, and thus meets the microformat requirement not to hide data. It is also designed to degrade gracefully if CSS is not available. Your method also invites naive editors to add a duplicate name property where one is already present, such as when coord is used inside an infobox. You're also asking for a change to a template used in tens of thousands of articles, and it's clear from the mess in your sandbox that you either haven't thought it through, or haven't tested it thoroughly, or both. Andy Mabbett 20:35, 28 June 2007 (UTC)

A list is not a typical example of a Wikipedia article, and most coordinates in Wikipedia are not in lists. The name parameter is likely to be added by microformat enthusiasts only, so when the infobox template has already generated named coordinates, an enthusiast will know that the name is no longer necessary in the coord template. If the specifications (link?) allow duplication and even conversion of data that is not displayed, then there is no problem with the inclusion of the name as proposed. Also, including html microformat markup directly in articles violates the Web Content Accessibility Guidelines by its combination of content, structure, and presentation. Surely a guideline that concerns the whole of Wikipedia should be followed before something related to a fraction of articles only. --Para 20:46, 28 June 2007 (UTC)

There are many ~~lists~~ tables of coordinates on Wikipedia, already marked up with hCards, and many more with potential to be. If "name parameter is likely to be added by microformat enthusiasts only", then that's another reason not to use it - we should make it as easy as possible for "lay" authors to enter data which is converted to microformat markup by tables or templates. There very much is a problem with the name duplication as you propose; unlike the automated coordinate conversion, here is no guarantee that the hidden value will match the published value; even a simple typo , let alone malicious editing, could leave a microformat with an erroneous value, which the editor will not notice, because the correct value appears on the page. Your comment about WCAG is utterly misfounded, to the point of hilarity. Andy Mabbett 20:57, 28 June 2007 (UTC)

Exactly, we should make it as easy as possible for "lay" authors to enter data, and the markup in the list example is incomprehensible for someone who doesn't know what "vcard" or "fn org" means, while "name" is totally understandable for everyone with basic English skills. The name parameter is extra much the same way as coordinate parameters are. Most editors won't add them, but they are simple enough to understand without knowing how the templates are implemented. As was pointed out elsewhere, vandalism is vandalism, and Wikipedia has the means to combat it. Could you please share why you think combining content and presentation is hilarious? Also, what is the problem with my sandbox where all the edits have been to the point? --Para 21:05, 28 June 2007 (UTC)

I don't think that combining content and presentation is hilarious; I think your utterly ludicrous comment about it is. As to your sandbox, perhaps you intended to have a pair of empty parentheses in your output, but it looks broken to me. Andy Mabbett 21:17, 28 June 2007 (UTC)

Please elaborate, I do not see anything ludicrous in trying to follow the WCAG in Wikipedia. I also do not see any empty parentheses anywhere, but perhaps you are referring to the braces in the template view of the edited template, which is a part of coord? You can look at the original template and the proposed diff to see that default values for the parameters are not provided at that level, but elsewhere. All my template edits have been thought out and well tested before copied here. --Para 21:27, 28 June 2007 (UTC)

As long as these extra fields are not compulsory to use, I don't have a problem with them. If they became compulsory, I would strongly argue against them on an ease-of-use situation. One of the good things about this template is its simplicity of use and logical follow-on - I can simply think "coord, lat, long, format, display, done!" when coding them. Orderinchaos 23:07, 29 June 2007 (UTC)

I've disabled the editprotected request while discussion continues. Please feel free to re-enable it when consensus is reached. Cheers. --MZMcBride 04:14, 29 June 2007 (UTC)

Note: There was also a previous request for the addition of this parameter, now archived to Template talk:Coord/archive002#Request_for_a_title_argument. --Para 12:08, 29 June 2007 (UTC)

I have made several requests for the addition of this parameter and have no interest whatever in the name being displayed anywhere other than the operator toolbar in Firefox. -- roundhouse0 14:08, 29 June 2007 (UTC)

Good, that's exactly what the modification would make possible. Currently it's done with {{Hcard-geo}}, but after the edit the functionality would be in coord as well, making the hcard template redundant. --Para 16:07, 29 June 2007 (UTC)

You still don't appear to understand, or appreciate the difference between what you're proposing, and what {{Hcard-geo}} does. The latter, as intended, displays the name value; your proposal would not replicate that, sand so would not make it redundant; quite apart from the other problems with your proposal. Andy Mabbett 16:44, 29 June 2007 (UTC)

Good, that's exactly what the template is for - handling coordinates, not names. Don't add parameters for values which aren't meant to be displayed, please. Andy Mabbett 16:44, 29 June 2007 (UTC)

It appears you are here to pick a fight and not build an encyclopedia that anyone can edit. It's getting increasingly hard to ignore your behaviour. Anyhow; when you want to use semantic markup such as microformats, you need identifiers to link the data elements together. That is what the name parameter is for. "Hidden" parameters are currently used on Wikipedia with most references for example, without any problems. I have already mentioned this to you at Template talk:Birth date and age#use_in_hCard_microformat and you had nothing to say. Why bring it up again? All you seem to be worried of is displaying the name right next to the coordinates (or birth dates), without giving any thought to editor choice. Why would the name have to be right before the coordinates (or the birth date), and why wouldn't an editor be allowed to add words such as "located in", "at", "born on" etc between the two? --Para 17:19, 29 June 2007 (UTC)

It appears you are here to make ad hominem comments. I have already explained why what you are doing is bad, more than once. I see no point in either of us repeating ourselves. Your questions are straw men, and bear no relation to what I have said. Andy Mabbett 17:32, 29 June 2007 (UTC)

I have just moved Template:Hcard-geo to Template:Coord named. The syntax is however still unnecessarily complex to be used more widely, when everything could be done in coord with a single added parameter. --Para 17:45, 29 June 2007 (UTC)

I'm confused - does this named thing address the issue I raised here? Orderinchaos 23:07, 29 June 2007 (UTC)

Thankfully, no. Andy Mabbett 23:27, 29 June 2007 (UTC)

No, the moved template doesn't address any issues and is written for microformat purposes only. It will hopefully be deleted soon enough. The current proposition is to give each use of inline coordinates a name that could then be displayed in some places instead of the coordinates, such as on maps and other alternative interfaces where a compact and descriptive name is preferred to a set of numbers. In the previous discussion you were looking to have the coord template display an inline heading instead of the coordinates, with the coordinates displayed in the title. That kind of use would not be appropriate for this name parameter. So it's not supported at the moment, but it'd be entirely possible to follow the old templates and add another parameter for that purpose (something else than title, preferably). It would however also be good to have all coordinates displayed in the same style throughout the English Wikipedia, with no map service preference. There's currently discussion at Wikipedia talk:WikiProject Geographical coordinates#Inline_coordinate_display of the display format, and nobody has brought up this kind of display yet. --Para 00:21, 30 June 2007 (UTC)

Even if the name in the proposed template was hidden metadata, the specifications don't say that such data is prohibited. The microformats community failed to give a reference when Andy Mabbett requested for one, and (in his own words), "I've still seen no citation for any *prohibition* of hidden data in microformats". The single objection above is thus null and void. --Para 09:57, 9 July 2007 (UTC)

Since there has been no further opposition, I have reinstated the editprotected request. --Para 17:59, 23 July 2007 (UTC)

Oppose Hiding metadata in microformats is bad practise. The initial justification, above, is also bogus. Andy Mabbett | Talk to Andy Mabbett 19:54, 23 July 2007 (UTC)

We have been through this already. When coord is used with a name, the name will in most cases appear elsewhere in the article as well, often right next to the coordinates. Vandalism can be acted upon as usually. Even if it was hidden, the practise of implementing microformats in articles directly or doing ugly workarounds for microformat purposes only and thereby complicating article editing is much worse. Therefore, if a coordinate entry template is to create a complete named microformat entity, it must be done by using the existing templates that are used elsewhere as well. Andy, when you don't have anything new to say, repetition of the same argument is not helpful (as noted in your arbitration case for example). --Para 21:06, 23 July 2007 (UTC)

I note that you fail to justify your bogus justification. The "ugly workarounds for microformat purposes only" exist only in your imagination; and your "must" is no such thing. Andy Mabbett | Talk to Andy Mabbett 22:22, 23 July 2007 (UTC)

I am uncertain which justification you are referring to, and why it would be bogus. Please elaborate. --Para 07:33, 24 July 2007 (UTC)

Support This adds much-needed flexibility to coord. Carminis 20:21, 23 July 2007 (UTC)

I've disabled the editprotected template; discussion is still ongoing. Please place it back up when the discussion dies down, or when there is a clear consensus to make the change. --ais523 16:37, 24 July 2007 (U T C)

The discussion had only a single opposing view against all others, and then died down for close to a month. When I placed the editprotected request back after all those quiet weeks, the opposing person jumps up and manages to stall the process again without having anything new to say. How many times does this need to happen before we can decide whether to do the modification or not? Indefinitely? I'll leave reactivating the editprotected request for someone else. --Para 18:34, 24 July 2007 (UTC)

With this discussion going on can I alert people to a bot request that is intended to embed mark-up in the List of United Kingdom locations articles. Keith D 18:50, 24 July 2007 (UTC)

As done on a good many other pages - it's not the same issues as discussed here (though it is a good example of a use case which won't be satisfied by para's proposal). Andy Mabbett | Talk to Andy Mabbett 13:25, 25 July 2007 (UTC)

You don't overcome valid objections simply by asking again a while later. Andy Mabbett | Talk to Andy Mabbett 13:25, 25 July 2007 (UTC)

A single objection is insignificant when nobody agrees with it, and it doesn't become any stronger if you write it on the page in bold twice. Hopefully you will understand what consensus means through your arbitration case Wikipedia:Requests for arbitration/Pigsonthewing 2/Workshop#Consensus. --Para 13:38, 25 July 2007 (UTC)

There's now a suggestion at Template talk:GeoTemplate#GeoHack_improvements to have this and other coordinate templates give the name of the page to GeoHack (where all the map service links are), so that the name can be used as a title in some of the services. This would give inline coordinates a wrong name. Alternatively, with some further changes, it would be possible to do that and in addition to use the name parameter from the suggested modification not just as a microformat title, but as a title in the map services. I can edit it in if there's enough interest to have the titles. --Para 13:55, 27 July 2007 (UTC)

I looked into this some more, and the change needed for GeoHack is actually quite simple. There have been previous requests for such functionality [1][2], and with the name parameter it's possible: inline coordinates with a name use the name as a title, others use the name of the page. I have changed the link in the editprotected request accordingly to make this possible. The change isn't just an addition of a microformat feature anymore, but an addition of a feature that everyone clicking on Wikipedia coordinates will notice. There is now no reason not to go forward with the change. --Para 16:48, 1 August 2007 (UTC)

" There is now no reason not to go forward with the change" nothing in your recent edit has resolved the issues which caused me to object to the change in the first place. Your implementation is as broken as ever, and degrades badly when CSS is not available. Andy Mabbett | Talk to Andy Mabbett 17:17, 1 August 2007 (UTC)

Since nobody agrees with your objection, those issues are in your mind only. The Engine Arm article currently uses the hcard-geo template coord is intended to replace, and the "Engine Arm Aqueduct (52°29′52″N 1°57′59″W)" text most readers see displays without CSS as "Engine Arm Aqueduct (52°29′52″N 1°57′59″W / 52.4979, -1.9665Coordinates: 52°29′52″N 1°57′59″W / 52.4979, -1.9665)". Is this template, coincidentally one of your creations, your idea of degrading gracefully? Non-CSS display has obviously never been an issue for you, so don't try to pretend it is now just so you can oppose. Additionally showing the name in parentheses after the coordinates when someone chooses not to obey the display:none rule is graceful degradation, like it or not. You have failed to give any explanation as to why the implementation would be broken. There is no reason not to go forward with the change. --Para 18:31, 1 August 2007 (UTC)

"Since nobody agrees with your objection, those issues are in your mind only" what a pathetic attempt to defy logic. Also, please don't attempt to speak for me; you lack the insight to do so. Andy Mabbett | Talk to Andy Mabbett 19:40, 1 August 2007 (UTC)

I asked you a question. Please answer. Please also explain how you think the proposed implementation doesn't degrade gracefully. --Para 19:56, 1 August 2007 (UTC)

You asked "Is this template, coincidentally one of your creations, your idea of degrading gracefully?" Every template that I have created degrades gracefully. Your edit summary for the your last post was "please cooperate"; I'm always willing to cooperate, but I can't do so on my own. Andy Mabbett | Talk to Andy Mabbett 20:57, 1 August 2007 (UTC)

Support: I support merging microformat markup from articles to coord as well as adding the name of the page to the template. I respect the argument from Andy alias Pigsonthewing that hiding information in markup only is bad practise and that Google and other search engines ignore this markup currently. But this holds only for pages where the average user has no control over the content (and markup) which is another case in Wikis! -- Geonick 22:00, 30 July 2007 (UTC)

Article vs item issue

In the above discussion it is not clear whether what is being discussed is use of {{coord}} at the article or item level. Which usages are being discussed? Is the "visibility" related to showing the name of the article at the top of the article, display on a map, or display within the article text?

At the article level, repeating the name of the article may often be redundant but article titles may be different from common or geographical names. Disambiguation may add stuff to an article title which is not relevant to a geographical name tool. A Wikipedia city name might use a common name but the geographical tool may want the name in a certain format.
At the item level, the article name may be irrelevant. For example, in Splashdown (spacecraft landing) it would be helpful on a map to display the names of the spacecraft for each item, but there is no need to display the name of the spacecraft again within the Wikipedia table.
Whatever is being displayed, it is helpful to pass a specific name to geographic tools so repeated browsing does not build up a pile of points marked only "wikipedia" or with numerical coordinates.

(SEWilco 21:16, 3 August 2007 (UTC))

The proposed modification is to allow names for both uses: article level ("title") and item level ("inline"). If a name isn't given to the template, it will automatically use the article title as a name.

The modification is not intended to have this coordinate entry template display the name, as the name is for annotation only. It is thus free of forced redundancy and intentional discrepancy issues, unlike {{hcard-geo}}.
The idea for the name parameter came from {{hcard-geo}}, which was intended to be used with inline parameters to create a complete microformat entity, which normally isn't created with inline coordinates. Therefore the modification will be most useful on the item level, where the item is related to the article or a part of it, but not entirely the same as the article's topic. In the example, each of the spacecraft coordinates can be given a unique name different from the article's title without forcing to display the name from that template instance, and leaving editors the freedom to format the content as is best for that particular use. {{hcard-geo}} does not allow this.
Agreed. There have been a number of requests from users of various map services for Wikipedia to pass on a name for the given coordinates. With the proposed change that will finally be possible.

--Para 22:17, 3 August 2007 (UTC)

Your dissemination of FUD continues. There is no "forced redundancy and intentional discrepancy issues" in {{hcard-geo}}. It does exactly what it is intended to do, and does it well (unlike your proposal, which breaks that).

"a complete microformat entity, which normally isn't created with inline coordinates" what on Earth do you mean by that?

Andy Mabbett | Talk to Andy Mabbett 22:42, 3 August 2007 (UTC)

I can't really follow, why Para's proposal should break something. Can you explain yourself? What I actually have seen in some articles were things like this: |- class="vcard" |class="fn org"|Approx. tunnel mid-point |{{coord|52.50435|-2.05932|region:GB_type:landmark}}. So, this is weird to add a span/class tag around coord 'inline'. It is way better to merge the microfirmat stuff inside coord template. That's what Para suggested if I'm right. I've implemented a similar template in my own MediaWiki instance and it works. -- Geonick 00:18, 4 August 2007 (UTC)

other problems aside, that may be true if the table (and each hCard) only contains an "fn org" column and a coordinates column; but will break is there are additional columns, with "adr" (address), "label" or "note" properties, for example. The use of the proposed modification to coord in such circumstances in untenable. Andy Mabbett | Talk to Andy Mabbett 10:13, 4 August 2007 (UTC)

I see breakage and redundancy if hcard-geo invokes the modified coord with "name=", otherwise coord uses which do not mention name would behave the same. I assume if coord adds the name parameter then hcard-geo would not be needed. (SEWilco 00:37, 4 August 2007 (UTC))

I see now. Several hcard terms have to be added to tables in order to label the components. In the long term, it would be nice if MediaWiki could be told to add such labels to columns, similar to sorting columns. Otherwise, individual coordinates have to be labeled with the geographical names for use by coordinate tools. Either hcard-geo or coord|name= would allow a name tag for coordinates. Thanks, Pigsonthewing, for showing the need and solution with hcard-geo. Just what is the difference, other than that coord is already widely used? (SEWilco 00:37, 4 August 2007 (UTC))

In the long term, it would, and I would advocate that. Indeed, I wrote the Wikipedia:WikiProject Microformats "aims", one of which is "To encourage the deployment of microformats in the Wikimedia application". The differences are that hCard-geo is for a displayed name; that it degrades gracefully when CSS is disabled, and that it can't break existing uses of coord by generating wrongly- nested hCards. Despite the fact that he admits that his proposed modification to coord does something very different to hcard-geo, Para insists that the former would make the latter redundant That's deletion-by-stealth. Andy Mabbett | Talk to Andy Mabbett 10:09, 4 August 2007 (UTC)

Incompatibility issue

There has been confusion about whether adding the "name=" option would break something.

It looks to me like adding "name=" would be invisible except when the "name=" parameter is specified.
But it came up in the above discussion that because "name=" creates an hCard phrase, the proposed feature is incompatible with existing hCard phrasing.
Am I correct that before the "name=" option could be used in a section of an article which has hCard labels that the hCard labels would have to be removed?
Could hCard phrases other than "fn org" be used along with "coord|name=", or would name= generate an impermeable wrapper which disassociates the coordinate info from other related attributes?

(SEWilco 16:32, 6 August 2007 (UTC))

Point 4 certainly appears to be true; as is 3 in at least some cases. Andy Mabbett | Talk to Andy Mabbett 16:38, 6 August 2007 (UTC)

There is an "or" in point 4. Which situation in 4 is true? (SEWilco 20:08, 6 August 2007 (UTC))

Sorry; the second part is true. Andy Mabbett | Talk to Andy Mabbett 20:13, 6 August 2007 (UTC)

Short answer: 1 yes, 2 no, 3 maybe, 4a no, 4b yes. Long answer: I am not aware of Wikipedia coordinates in microformats that use properties for anything else than naming, and so wouldn't agree that the proposal is incompatible with anything. Are there any? If some have been created, they're not used to the extent of coord. It is in editors' best interests to keep wikitext editable and reviewable to keep participation possible, but writing microformat markup directly in articles has the exact opposite effect. Data entry must not be designed solely following possible minor output format requirements, and sometimes it may not be feasible to use some functionality of the output format at all if it makes data entry too difficult using the current software. That said, if there really are cases where other properties need to be given, a parameter could be added to bypass the microformat creation for those special cases, or another to add the necessary properties inside the coord created microformat. Is such a thing needed somewhere? --Para 20:26, 6 August 2007 (UTC)

Well, because 4b is true ("name=" separates coord hCard from surrounding hCard), then 2 is true for coords within hCard? I think you said 2 is not true because coord|name= is compatible with hCard -- except in the case of a coord within an hCard. I think I saw some hCard phrases in one of the {{kml}}-using articles but there might be others. (SEWilco 23:33, 7 August 2007 (UTC))

Untangling

Several things got tangled together. Do we have them untangled yet?

coord is only a solution for individual points. Discussion is ongoing elsewhere about other geometries and collections.
I think the "coord|name=" solution is the most obvious for editors and solves the problem of labeling points.
- Pages using hCard and coord will have to be examined before adding "name=" to coord.
More thorough hCard use is awkward in Wikipedia. Perhaps a way to handle collections of hCards would be for wikitables to allow columns to be labeled with hCard tags, and then all the cells within the table would be properly labeled; that would only require a minor incantation in the top of a table. Someone want to propose that to WP:MF or VP with goal of filing an Enhancement Request? (SEWilco 23:33, 7 August 2007 (UTC))

(SEWilco 23:33, 7 August 2007 (UTC))

Agreed: Let's keep concerns separated and simple. i) coord adds point location information to an article or a paragraph. polyline and polygon are not yet covered by this discussion (fortunately). ii) the "coord|name=" proposal is a practical immediate solution. It is therefore no need for another "markup" or a wrapper like hCard-geo microformat. I would even argue that microformats usually should not be part of any article text! As explained in article Microformat, technically, they are items of semantic mark up, using just standard (X)HTML.... But special markup in Wikipedia (MediaWiki) is done by using templates (which in turn can generate HTML)! hCard deals with HTML markup for publishing contact details of people, etc. There are already templates 'wiki style' like Birthdate and Geo in Wikipedia. It's there where microformat wrappers fit best in Wikipedia. Specialists can add microformats to existing templates. So there's no need to add (non-wiki style) microformat to articles if they are already tagged with (wiki style) {{coord}}. -- Geonick 01:16, 8 August 2007 (UTC)

There are microformats other than coord's Geo. Andy Mabbett | Talk to Andy Mabbett 16:43, 8 August 2007 (UTC)

The "coord|name=" proposal is not a solution - it's broken. Your proposed table solution will not work with current WikiMedia capabilities; nor does it allow for tables where some rows are hCards and others not; or where some, but not all, of a cell's content is marked up. Discussion of wider issues would be better on the microformat project talk page, BTW. Andy Mabbett | Talk to Andy Mabbett 16:43, 8 August 2007 (UTC)

An analysis of microformat use here is close to impossible, as WP:UF have written nothing about their deployment on Wikipedia other than partial information of template use. A class search finds many results, but nobody wants to do such a dirty job to find undocumented dependencies. Wikipedia:WikiProject Microformats/hcard offers nothing useful. The creator of the microformat project in particular refuses to discuss the issue constructively. Therefore I see the following options:

Keep the status quo, kill the improvement proposal and let the soon-to-be-banned user continue damaging Wikipedia by ignoring usability and thinking of nothing else than getting all possible microformats deployed in Wikipedia at any cost, even if it means writing the markup directly in article wikitext.
Implement a parameter to coord to stop it from creating the microformat wrapper, to be used in those yet-to-be-specified cases.
Implement a parameter to coord to allow microformat element injection inside the wrapper it creates.
Go forward with the coord|name= modification as it's proposed now, and deal with possible microformat issues later if users report problems.

Both of the microformat parameter options are ugly, as most of the data will probably have nothing to do with coordinates, and won't be logical for any editor who doesn't know that it's done so for microformat purposes only. In my opinion complex microformats that can't be implemented using current MediaWiki capabilities without forcing all editors to jump through hoops to continue editing Wikipedia should wait until such time that the capabilities do allow a more user friendly implementation. Most microformats on Wikipedia are for coordinates, and we should work to improve the majority instead of trying to create hacks for minor features that nobody or very few people have shown interest in. --Para 17:53, 9 August 2007 (UTC)

"The creator of the microformat project in particular refuses to discuss the issue constructively" - Please stop lying about me.

"...thinking of nothing else than getting all possible microformats deployed in Wikipedia at any cost" - Please stop lying about me.

Andy Mabbett | Talk to Andy Mabbett 18:10, 9 August 2007 (UTC)

A week has passed with no comments. What's the next step? --Para 09:02, 16 August 2007 (UTC)

Apologise for your PAs; and withdraw your broken proposal. Andy Mabbett | Talk to Andy Mabbett 12:36, 16 August 2007 (UTC)

???? --Dschwen 14:41, 16 August 2007 (UTC)

Please summarize in what way it is broken. (SEWilco 16:05, 16 August 2007 (UTC))

As far as I can tell, microformats already combine coord with a "name" parameter in various infoboxes. Could a default "fn org" be defined as {{PAGENAME}} when "name" is missing? This should only be implemented when "display=title", to avoid list/tables of coordinates. --Qyd 02:59, 19 August 2007 (UTC)

Someone has indeed written microformats in some infoboxes, which often have the same name as the page name. This is why having another default would break those undocumented dependencies and why the proposed code change passes the pagename to GeoHack when "name" hasn't been given, but does not generate microformat markup. Practically all inline coordinates are intended to use the "name" parameter, as the page name wouldn't describe them too well. --Para 08:03, 19 August 2007 (UTC)

Please cite an example, if there is one, where the page name is used inappropriately by a template; and an example of inline coordinates doing so. Or are you just creating more FUD? Andy Mabbett | Talk to Andy Mabbett 09:38, 19 August 2007 (UTC)

It would nice, indeed, if someone took the time to document the mechanism through which the "name" parameter is passes to the microformat. Using PAGENAME as a substitute, in the given conditions (no "name" parameter, title display), would be an easy compromise, and the page title is more descriptive than a couple of numbers (again, when talking about title display, which implies that the coordinates reffer to the main article subject, not just some point mentioned in the article). I realize that, if implemented, this would only cover part of the problem. --Qyd 17:16, 19 August 2007 (UTC)

That default behaviour would be wholly in appropriate. Suppose you have an article with one, in-line coordinate pair, referring to a location not relevant to the rest of that article. The use of parameters in microformats is already documented, on the relevant articles, but - in brief - the Geo microformat used by coord has no name parameter. hCard, which can include a geo microformat, has name parameters, using classes "n", "fn" and "fn org". Then there's hCalendar, which can include a Geo, but has no use for "fn" or "fn org"... Andy Mabbett | Talk to Andy Mabbett 17:25, 19 August 2007 (UTC)

Andy, I'm only talking about title display, not in-line. I had a closer look at {{Infobox Settlement}}, and, if I read right, the fn org class is only coincidentally inherited by coord (vcard classes are defined for "official name" earlier in the template), so I'm starting to doubt that a solution can be found by tweaking {tl|coord}}. --Qyd 17:45, 19 August 2007 (UTC)

No, Not all microformats, and not even all hCard microformats, use "fn org". Andy Mabbett | Talk to Andy Mabbett 17:22, 19 August 2007 (UTC)

RfC preparation

Since we're not getting anywhere like this, I have read the whole discussion above and collected the major points below. Please edit it if I missed something. Once it summarizes the points clearly for everyone to understand, we can either ask for outsider opinion as an RfC or decide what to do ourselves. --Para 20:16, 16 August 2007 (UTC)

Since the people involved have made no further changes, I believe the points reflect the long discussion above, so I have turned this into an RfC. Please comment at the #Discussion section. --Para 10:49, 19 August 2007 (UTC)

Request for Comment

{{RFCstyle|Request for Comment|Proposal to annotate coordinates on Wikipedia for use as a title in map services and microformat readers --Para 10:49, 19 August 2007 (UTC)}}

Strong consensus achieved, thanks for the comments everyone. --Para 11:07, 3 September 2007 (UTC)

Proposal to annotate coordinates on Wikipedia for use as a title in map services and microformat readers

Problems with current method

(examples of current use can be found below)

Writing HTML directly in articles mixes content with presentation
Writing HTML directly in articles makes them harder to edit because of the presentation level markup
Microformat keywords are not known to most editors unlike the rest of wikitext markup
Coordinates should always be entered using the same template

Possible solutions

MediaWiki modification to create microformat wrappers and other HTML markup from the software
{{coord}} modification to merge the microformat functionality

People have been reluctant to participate in initiatives to work the microformat support into MediaWiki, and prefer to have it through other means now instead of having to wait months or years. Therefore a template modification has been proposed.

Proposed modification

Table row

|- class="vcard" |class="fn org"|Approx. tunnel mid-point ||{{coord|52.50435|-2.05932|region:GB_type:landmark}}

into

|-

|Approx. tunnel mid-point ||{{coord|52.50435|-2.05932|region:GB_type:landmark|name=Approx. tunnel mid-point}}

Template wrapping

{{hcard-geo|name=Battersea Power Station|coordinates={{coord|51|28|57|N|0|08|41|W|region:GB_type:landmark|display=inline}}}}

into

{{coord|51|28|57|N|0|08|41|W|region:GB_type:landmark|display=inline|name=Battersea Power Station}}

Allows for a name to be shown for inline coordinates in microformat readers and geographical information services instead of or in addition to coordinate numbers.
Allows multiple coordinates from a single Wikipedia page to be exported in bulk in a format usable for geographic information services, such as this demo link shows.

Arguments

The proposed template does not output the given name parameter to the article, which can be seen as bad practise and may lead to vandalism
- The parameter will be visible in wikitext, diffs, geographical information services and microformat readers
- Annotation identifiers are already used in Wikipedia without problems, with references for example
- Allows editor freedom to format and order the prose following the Manual of Style, instead of forcing any single format
- Because the name would be invisible to HTML viewers, vandalism would only affect people using the link (who might then repair it)
Requires the name to be written twice, once for article prose and once for annotation, which may lead to separation
- Names and other identifiers are already written multiple times in articles whenever referring to the item in question, whether it's ment to be readable for people or for machines.
Closes the microformat wrapper in a way that it can only contain the coordinates and their name, and not the additional properties "address", "label" or "note". In the future articles that (1) use {{coord}} (2) with the name parameter and (3) have data to be inserted in the additional properties will be incompatible with the proposed modification.
- Current uses without the name parameter will be unaffected by the modification
- The microformats project on Wikipedia has no design plans on microformat implementation and deployment inline, and markup of varying levels can be found "here and there" in articles. Undocumented dependencies should not be taken into account.
- A "wrapper creation bypass" parameter can be added later if the incompatibility turns out to be significant
Some believe the modification does not degrade gracefully when CSS is not available - Example:

Current inline with "{{coord|1|1}}" :

   CSS: 1, 1
no CSS: 1°N 1°E / 1, 1

Proposed change with "{{coord|2|2|name=Example}}" :

   CSS: 2, 2
no CSS: 2°N 2°E / 2, 2 (Example)

- The name in parentheses is marked up in CSS as display:none. When a user chooses not to obey CSS rules, the page displays a readable though redundant name after the coordinates.

Users involved

Support:

User:Para [3]
User:Orderinchaos [4]
- Quote form cited diff: "As long as these extra fields are not compulsory to use, I don't have a problem with them. If they became compulsory, I would strongly argue against them on an ease-of-use situation. One of the good things about this template is its simplicity of use and logical follow-on - I can simply think "coord, lat, long, format, display, done!" when coding them.".
  - This is still my opinion (and probably all I'll say on the topic). Orderinchaos 15:25, 19 August 2007 (UTC)
User:roundhouse0 [5]
User:Carminis [6]
User:Geonick [7]
User:Gmaxwell please no more geocoding tag proliferation. It's enough of a pain to decode all the types of tags we have today. We need more uniformity and simplicity. We certainly don't need to be inconveniencing our editors or our coders to help third party mapping sites, but if we can get all the functionality into one master template we should be able to meet everyone's needs.--Gmaxwell 12:06, 19 August 2007 (UTC)
- coord may well be the master template for coordinates; there may well be a need for a master template for "places"; but this proposal is not suitable for the latter, and is unnecessary for the former. Andy Mabbett | Talk to Andy Mabbett 12:15, 19 August 2007 (UTC)
User:Scotthatton [8]
User:Dschwen * I support the proposal presented above. --Dschwen 13:28, 17 August 2007 (UTC)
User:Heptazane * [9]
User:SEWilco coord works well for single points and labeling those points would be helpful.

Oppose:

User:Pigsonthewing [10][11]

Discussion

Existing uses

Typically, Para chooses skewed examples, asserts his opinions as facts and misrepresents previous debate.

Para's proposal takes no account of existing uses, with formats like:

|- class="vcard" |class="fn org"|PlaceName|class="label" |Town|class="note"|comemnt|{{coord|52.50435|-2.05932|region:GB_type:landmark}}

Although he makes no mention of it in the above RFC, Para's plan is to use the is modification to, suposedly, render {{hcard-geo}} redundant; his call to delete the latter having been defeated. His proposal to replace:

{{hcard-geo|name=Battersea Power Station|coordinates={{coord|51|28|57|N|0|08|41|W|region:GB_type:landmark|display=inline}}}}

with

{{coord|51|28|57|N|0|08|41|W|region:GB_type:landmark|display=inline|name=Battersea Power Station}}

would change the rendered content from:

{{hcard-geo|name=Battersea Power Station|coordinates={{coord|51|28|57|N|0|08|41|W|region:GB_type:landmark|display=inline}}}}

to

51°28′57″N 0°08′41″W / 51.48250°N 0.14472°W

which is clearly not the same.

Please view this {{hcard-geo}} implementation:

{{hcard-geo|name=Example|coordinates={{coord|2|2|}}}}

with CSS disabled and note that his proposal is not comparable; but would duplicate the name field as:

Example 2°N 2°E / 2, 2 (Example)

Simply garnering numerical support for this ill-thought out proposal will not fix the problems inherent in it; problems which have not been addressed, since I raised them in June.

Note also that Para is canvassing Andy Mabbett | Talk to Andy Mabbett 11:36, 19 August 2007 (UTC)

Your concerns are already noted in the #Arguments section, points 1 and 2. Please do not flood the RfC with opinions already presented. --Para 12:39, 19 August 2007 (UTC)

Your claim is untrue (not least because, as I pointed out, you failed to mention your plan to replace {{hcard-geo}}), and this section is entitled "discussion", not "discussion approved by Para". Andy Mabbett | Talk to Andy Mabbett 13:55, 19 August 2007 (UTC)

Canvassing?

How is pointing out an Rfc to a person who already showed interest in this matter canvassing?! I'll answer that myself: it is absolutely not. --Dschwen 13:49, 19 August 2007 (UTC)

Selectively contacting only those who support your position in such a way is canvassing. Andy Mabbett | Talk to Andy Mabbett 13:55, 19 August 2007 (UTC)

Uhm, you are the only one who is opposing and as far as I can see you don't need to be contacted, so I don't quite see where there was any selection... --Dschwen 15:00, 19 August 2007 (UTC)

Thank you for confirming that Para only contacted people who support his views. Andy Mabbett | Talk to Andy Mabbett 15:15, 19 August 2007 (UTC)

Well, I guess I cannot stop you from misinterpreting my posts. So thank you for confirming my point that you are the only opposer and thus no selective contacting has taken place :-) --Dschwen 15:20, 19 August 2007 (UTC)

I notified all the wikiprojects related to the proposed modification and the few users who were mentioned in the above discussion but who to my knowledge are not participating in any of the related projects. Had I known of anyone else who might have an opinion on the proposal and doesn't participate in the projects, I would have written them the same notice as well. Andy was given due time to add his material to the list, but he chose not to do so. Now, anyone coming here to answer the request for comment, please do so despite the seemingly high activity. --Para 15:55, 19 August 2007 (UTC)

I support Para's proposal to extend 'coord'. My experiments here with geo-microformat and kml were positive. And I have to attest good technical and social competence to Para and Dschwen. Unfortunately I had similar problems argueing with Andy alias Pigsonthewing about the kml template (c.f. below). -- Geonick 19:40, 19 August 2007 (UTC)

I also support it primarily for the usefulness to the user of having a description in mapping sites, and for simplicity to editors as there is already a high enough bar for people to geocode their articles. -- Heptazane 18:45, 20 August 2007 (UTC)

Precedent

I point out that some of the invisible markup is similar to existing markup, such as Alt text tags on images. I think invisibility is less important than visible items and the editing interface. It's easy to invoke a documented infobox and fill in the blanks, and I don't mind if the infobox automagically includes related images and categories. (SEWilco 04:59, 20 August 2007 (UTC))

Questions

How does merging Template:Hcard-geo into Template:Coord fix any of the issues listed under "Problems with current method"? The Hcard-geo template already uses the single coord template, doesn't place HTML directly on the article page, and doesn't require the user to know microformat keywords.
Why can't the 'name' parameter just be displayed when needed? This would avoid the problems with double (and possibly differing) entries and setting microformat data on non-displayed text. Presumably this is inspired by situations where we just want the coordinates and not the name to display (such as the 'coordinates' row of an infobox), but why not just make it an optional feature to display the name or not and have the microformat tags wrapped as applicable?

I'm all for merging templates to avoid redundancy, but this change doesn't seem to retain the same functionality and thus isn't really a 'merge' per se. Basically, merging Hcard-geo into coord creates new problems and doesn't fix any of the issues listed here as the supposed reasons for doing so. So... why do it? If we DO go ahead with it... then why do it in a way that removes functionality when we don't have to? --CBD 15:05, 20 August 2007 (UTC)

Both 'hcard' and 'geo' are microformat keywords (problem 3) that do not describe the encapsulated data, but exist only for something on the presentation level (problem 1), which most editors shouldn't have to pay any attention to (problem 2). Hcard-geo annotates coordinates for microformat use only, but the proposed Coord modification generalises that and annotates coordinates for any use.
The 'name' parameter shouldn't be displayed, because the template would then force a single format and ordering to prose, instead of giving editors the freedom to write articles using their chosen wording and separate data elements, annotated or not. The templates {{Hcard-geo}}, {{Hcard-geo-title}} and {{motorway hcard}} have unfortunately been created to cover some of the possibilities in prose, similar to what {{Hcard-bday}} and {{Hcard-bday-place}} are trying to do with other templates, but the possible variations of words and other notation between coordinates and a name are endless and trying to create a template or a parameter for every possible variation is obviously the wrong approach.

What problems would combining the coordinate annotation functionality create? --Para 16:36, 20 August 2007 (UTC)

Um, you seem to be saying that {{Hcard-geo}} is "Writing HTML directly in articles" ('problems' 1 & 2) and using 'Microformat keywords' that, 'unlike wikitext markup', most editors won't be familiar with ('problem' 3). Are you saying that? If so then... that's ridiculous. 'Hcard-geo' is just the name of the template and neither HTML nor any 'special formatting' different from any other Wiki-template call... it could be called 'Template:Fred' for all the difference that would make.

You say that the proposed coord "annotates coordinates for any use". Doesn't the current coord do that... and the proposed one NOT? The proposed changes for coord would cause the name to be wrapped but not displayed. Which isn't proper microformat annotation. Correct?

Finally, you say that the name shouldn't be displayed (even optionally) because '<name> <coordinates>' is just one of the "endless" ways users could choose to display this information. Could you cite pages showing two or three of those 'endless' examples? I suppose someone could write out, '<name> is located at <coordinates>' but then the '<coordinates>' could just use the 'coord' template with the option not to display/wrap the name. Nor does that seem likely to be at all common. In 99% of cases people are going to use '<name> <coordinates>' or just '<coordinates>'. No template ever handles every possible formatting preference a user might have. That isn't their purpose... we have straight text for that. Templates exist to make it easy to reproduce formats which are used very frequently. --CBD 11:05, 21 August 2007 (UTC)

Coord is for entering and displaying coordinates and I don't see the logic in making a coordinate entry template display a name. That would be an unexpected side effect. For annotation however, having the coordinate data element equipped with a name greatly helps reuse. Forcing the template to display a name is trying to solve a problem that doesn't have a solution: prose cannot be generated with templates. Finding examples of inline use that isn't about the article's topic is hard without using the full text dump, but here's some general inline use Google found for you:

<name>'s geographic coordinates are <coordinates> (from Tabarca)
<name> lorem ipsum. Its geographic coordinates are <coordinates>. (from Cebu City)
<name> lorem ipsum. The geographical coordinates of the city are <coordinates>. (from Logroño)
<name> lorem ipsum. The coordinates of the city are approximately <coordinates>. (from Kumanovo)
The <source> locates <name> at <coordinates> (from Neffsville, Pennsylvania)
<name> was located at <coordinates> (from Petersburg, Georgia)
<name> is located at <coordinates> (from Springer Mountain)
<name> is located at coordinates <coordinates> (from Meir, Egypt)
<name> is located at <directions> at <coordinates in another system> or <coordinates> (from Wood Mountain Regional Park)
<name> is located on <location> in <general location> (<coordinates>) (from Kilometre Zero)
All tables usually have the name in a column separate from coordinates
etc...

I tried once to rename {{Hcard-geo}} to {{Coord named}}, but the creator's ownership issues made him keep the naming of all templates that exist only to generate a microformat as Template:Hcard-something. It wouldn't have been an ideal solution anyway though, with its unnecessary template wrapping. When editors surround a piece of information with something to tag it, the use of those tags (or templates in most Wikipedia cases) should be readable to all editors. Any consequential additional functionality should be implemented inside those data annotation templates so that it's transparent to editors. Templates should not be named after the element they represent on the presentation level, but following the content they're tagging. I don't see anything ridiculous in this basic design rule.

With coordinate annotation I mean giving a name to coordinates and having the possibility to display or otherwise use it somewhere. Because generating prose with templates is not practical, the possibilities do not extend to displaying the name in articles. It's just too complicated and by no means with just 1% of articles with inline coordinates. Unless you intend to modify the manual of style to say that coordinates must be given right after the name of their location, a name can not be displayed. --Para 18:41, 23 August 2007 (UTC)

In the above, "display a name" apparently refers to emitting a name in text form which shows as part of article text, not to attaching a name to a point for labeling on a map. (SEWilco 18:55, 23 August 2007 (UTC))

Right, "display" refers to the Wikipedia article context. External services that parse the wikitext dumps or GeoHack's title parameter can use the name as is best in their case, we're only making the data available. --Para 21:04, 23 August 2007 (UTC)

The examples show usage of name= inside two wrapper contexts. What would be produced by adding a name to an existing coordinate: {{coord|1.0|2.0|name=Example}}? (SEWilco 21:36, 21 August 2007 (UTC))

I'm not sure what you mean. The microformat wrappers in the examples exist only to link the coordinates with a name. Creating a microformat wrapper wouldn't be necessary after the modification anymore, because the template creates one when the name parameter is given. The coord template with a name parameter will then fit in tables and in prose without needing any extra wrappers visible to wikitext editors. --Para 17:24, 23 August 2007 (UTC)

So List of Minnesota State Parks with entries such as {{coord|45.123|-91.234}} can use {{coord|45.123|-91.234|name=Lake Itasca State Park}} with no visible effect on the Wikipedia text, but the geocoding will attach the name to the coordinate for use by mapping programs? (SEWilco 18:55, 23 August 2007 (UTC))

Yes, exactly. --Para 21:04, 23 August 2007 (UTC)

The desired alteration should be provided for our review and for the person who performs the edit. (SEWilco 16:49, 22 August 2007 (UTC))

The necessary modifications are mentioned in my first two posts to this topic: Template talk:Coord#Moving microformat markup from articles to coord. The meat of the modification is shown here. To summarise:

All uses of this template will pass the article's name to GeoHack, where it can be used by geographical information services for annotation or for further processing of the article. (See Template:GeoTemplate/doc#Miscellaneous)
When the 'name' parameter is given, this template will:
- Pass the name to GeoHack, where it can be used by geographical information services for annotation
- Place the coordinates in a microformat wrapper for annotation:  and  ({{{name|}}})

Perhaps someone can prepare a better editprotected request if mine was unclear? --Para 17:25, 23 August 2007 (UTC)

Could you build (in your sandbox maybe) a full working template (not just the "/link" part) that we could test run? That would eliminate the guessing game. Thanks. --Qyd 17:49, 23 August 2007 (UTC)

There are too many templates in this coord clustertemplate to make a working copy. If someone else thinks it's necessary and wants to help, please go ahead. I did it once to test the modification on my local wiki, and it's not worth the trouble. As mentioned in the original editprotected request, in addition to the changes to the link template demonstrated to work in my sandbox, the edit is simple: all the clustertemplate parts that take and handle editor parameters (there's five of them) need to be modified to pass the new parameter on. --Para 18:17, 23 August 2007 (UTC)

Google doubt

Does anyone know whether these proposed changes will break Google Earth's automated parsing of {{coord}} templates? --ais523 16:39, 30 August 2007 (U T C)

Unlikely. The template already supports optional parameters and all parsers need to take their absence or presence into account. Until a week ago, the format parameter wasn't even documented, but the article The Blakehay Theatre, Weston-super-Mare for example is still visible on Google Earth. Adding another optional parameter should therefore not be a problem. --Para 17:37, 30 August 2007 (UTC)

Google's technology began with automated pattern matching. It is likely that it presently is ignoring the multiple optional parameters and will initially ignore additional parameters (it might learn the new data or might have to be told about it). That's if Google is parsing the article source; if Google is parsing the HTML then the microformat change may get picked up by existing microformat patterns. (SEWilco 21:44, 30 August 2007 (UTC))

The goal of these changes is to associate a name to each set of coordinates which can be picked up by external applications... which is worthwhile. To that end they set an '&title=' parameter in the URL and wrap vcard & fn org classes around the name and coordinates. The &title seems to be recognized by Google and other sites for single coordinates while the microformat classes are used for labels on groups of coordinates passed via Kml. Where I think it runs into trouble is in setting the 'fn org' wrapped name to a 'display:none' style. This won't work on all browsers and screen readers, and thus this name will be displayed/spoken for some users and not for others. In addition to this accessibility issue, microformats are generally used to wrap visible data rather than hidden meta-data like this. Is there some other way to assign a label to each set of coordinates? For instance, a class name could be defined and have a value set equal to the name - similar to the current; . Just add a 'name="Whatever"' option which the tool that exports the Kml data could recognize. Removes the accessibility problem. Alternatively, or in addition, an option to have the contents of the 'name' parameter display in a format like '<name> <coordinates>', likely the most common presentation, would be beneficial... that could then be wrapped as a microformat on the visible data, essentially doing just what Template:Hcard-geo does now.

On a side issue, I'm not sure that the various {{#if:{{{name|}}}| conditions in the logic are needed. {{#if:{{{name|}}}|&title={{urlencode:{{{name}}}}}}} could be changed to something like; &title={{urlencode:{{{name|{{PAGENAME}}}}}}} to always set a 'title' attribute and default it to the pagename if nothing else is set. Likewise, the vcard class could always be set... no need to make it conditional. We probably wouldn't want to default the value of the 'fn org' class to PAGENAME as that would result in all the elements being given the same label, but it could be set to default to blank and thus remove that conditional as well. --CBD 19:43, 1 September 2007 (UTC)

With a 10:1 consensus to go forward with the change, it seems pointless to raise issues that have already been discussed, but I guess we'll have to since the RFC request is still open up there and everyone can't be expected to read the whole repetitive discussion. Briefly, none of these concerns pose any problems, but to go through them in detail:

Google does not recognize '&title', '&pagename' or 'name='. All they do at the moment is use the wikitext dumps and read one title coordinate per article, naming them following the article name. The misconception here is probably a result of Google Maps being able to show external lists of coordinates, and some Wikipedia pages linking a Wikimedia created annotated coordinate list to their service. Parsing for Google Earth and our own parsing for the dynamic coordinate list service are two separate things.
Microformat readers have no trouble using 'display:none' text. This template for example already uses microformats on 'display:none' text with all coordinates that have been entered in dms format: they are converted to decimal, by default hidden from readers and used for microformat purposes only.
Most screen readers do not process text marked as 'display:none' [12], as is expected in the design of this template change.
A name for coordinates is not hidden meta-data; all examples here have had a visible name in the proximity of the coordinates, but in a way that can't be generated from a single template instance.
Wikipedia should not start inventing new attributes for HTML elements, but use the same subset that is supported everywhere else. Luckily there are no accessibility problems with the change and standard HTML is used.
Having a coordinate entry template display a name in the article text is not logical; an article that begins with "{{coord|...|name=Title}}" would make no sense to most editors. It would be an unexpected side effect.
GeoHack already falls back to using the pagename as a title if no title has been given, as the documentation explains. Having the '&title' parameter conditional avoids putting redundant data to links, where in most cases the title and the pagename would be the same. The microformat markup can't be generated by default, because this template is used in infoboxes and the like that already generate a similar microformat wrapper, and nested microformats are invalid.

I hope this clears up some of the misunderstandings. --Para 00:22, 2 September 2007 (UTC)

"Google does not recognize '&title', '&pagename' or 'name='."

No, Google doesn't recognize those parameter names, but they are included in a URL format which Google does recognize. Or, rather... they were until today. Yesterday, this http://tools.wikimedia.de/~magnus/geo/geohack.php?title=Some+Park&params=44.8624675_N_-92.7835367_E_ produced a GeoHack page where if the first map link (to Google) was clicked the 'title' parameter was shown as a label atop the coordinates pop-up box... today it doesn't. However, the second map link on that GeoHack page, to Mapquest, does still show the title parameter value ("Some Park") in the upper left-hand corner. The change seems to be the result of this edit of yours. The edit summary says that you changed it because Google can't handle parens in the title, but http://maps.google.com/maps?ll=44.862468,-92.783537&spn=0.3,0.3&q=44.862468,-92.783537+(Some%20Park) seems to work just fine. And display the label. Without any need of 'display:none'.

"Microformat readers have no trouble using 'display:none' text."

Didn't say they did. I said they are intended to be used with text which IS displayed.

"Most screen readers do not process text marked as 'display:none'"

I'm aware of that, but most != all. There is a reason Wikipedia discourages use of 'display:none'. Given that there are ways to do this which don't violate accessibility standards and which would work correctly for all users, why should we use this kludgey method instead?

"A name for coordinates is not hidden meta-data"

Meta-data: data which is intended to be machine-read and which is not displayed to the reader. A name is not hidden meta-data... until you hide it. Which this proposal does.

"Wikipedia should not start inventing new attributes for HTML elements"

No one said it should. I suggested that we define a class in an HTML span... just as Wikipedia does in dozens of other cases, including (as cited above) the current version of this template.

"With a 10:1 consensus to go forward with the change, it seems pointless to raise issues that have already been discussed"

Everyone agrees that putting labels on coordinate data passed to various mapping sites is a good thing. I'm just not sure why you are set on doing it in a way that won't work for everyone when better options are available. --CBD 20:23, 2 September 2007 (UTC)

You are trying to find problems where there are none. The whole microformat functionality of this template in its current form is based on 'display:none'; dms coordinates couldn't be used otherwise (see all the 'geo-nondefault' classes). It was shown above that the proposed change degrades gracefully when CSS isn't available, at least to the same level as the equally hidden decimal coordinates. If there is a solution to get rid of all 'display:none' in a generally supported way, then by all means let's implement that, but any partial hypocrisy is pointless. Forcing the template output the name to the article text just so that the microformat can be generated using visible text from the same template instance will ignore all editor freedom and make the naming unusable for all the inline cases that were mentioned above. As for the other proposition, having a name in an HTML class is something that isn't used anywhere else on Wikipedia or on the whole internet even, making it an ugly kludge that surely no one will want to write a parser for. This last minute proposal of yours would create more problems than it's worth. --Para 23:28, 2 September 2007 (UTC)

I wasn't aware of the display:none kludge to set a default display preference. I can't imagine how that can be described as being something which 'degrades gracefully'. Does anyone even use it? I checked the .css pages of a half dozen users active in coordinates discussions and did a search with Google and couldn't find anyone who has this 'default setting' logic configured. If it were really needed it would be built into the user preferences like defaults for dates. Doing it this way for the few people (if any) who have it set up seems like an exceedingly bad idea to me. You didn't answer my questions and points about the 'title' attribute and your dismissal of using HTML classes as something, "no one will want to write a parser for" is unfortunate given your edit-warring to make certain the parser used is your own. Again, why are you so set on using 'display:none'? Why couldn't the parser pick up an '&title' attribute or a HTML class with the name? Why should some users be forced to endure something like, 'Some Park (44°51′44.89″ N, 92°47′0.73″ W) 44.8624675 N, -92.7835367 E (Some Park)' instead of the 'Some Park (44°51′44.89″ N, 92°47′0.73″ W)' intended? On every set of coordinates. --CBD 00:14, 3 September 2007 (UTC)

It is not just for coordinate display preference; even users without a display preference get all dms coordinates with 'coord' in decimal format within a 'display:none' element. Yes it would be cleaner if they didn't, but currently there's no way in Wikipedia to do that while preserving the microformat functionality, and you are the first one concerned about it despite it having been widely used for a long time already. The proposed change uses 'display:none' because microformats need something to wrap around on, which unfortunately with templates has to be something right next to the other generated data. Since there are many cases where the coordinates and the name are not right next to each other, the microformat wraps around the 'display:none' name instead, preserving all editor freedom and keeping the wikitext readable and editable for everyone. If some minority of users choose not to obey 'display:none', that's their choice, and we have done our best to produce a readable output for them as well. All recognised parsers of Wikipedia data use the wikitext, not link parameters or overloaded HTML classes crafted for a single purpose. I don't know where this edit warring accusation is coming from, you must be referring to me having fulfilled feature requests for a disgruntled disruptive editor? The '&title' parameter isn't problematic for this template, but only at a later stage, so I started a discussion for it at Template talk:GeoTemplate#Named coordinates. Anyhow, all current coordinate templates, their poor microformat implementation and other support structures are temporary solutions until the functionality is in MediaWiki itself. We can't do it perfectly with templates now because of all the limitations, but we can do something that's ok in most cases, and meanwhile work on the software support. At that later stage it will be much easier when all the data has been kept separate: prose, marked data elements, annotation. --Para 01:04, 3 September 2007 (UTC)

Requested changes

{{editprotected}} Rippling Para's change through the template hierarchy; note the edits should be done from the bottom up so they can not be invoked until the deeper levels are ready (editor can test each level in a sandbox before edit)... (SEWilco 19:13, 26 August 2007 (UTC))

I compared the changes with my own test diffs and they're ok. --Para 20:24, 26 August 2007 (UTC)

Editprotected 1/6:

The top level has Template:coord

<includeonly>{{Coord/display/{{{display|inline}}}|1={{Coord/input/{{#ifeq:{{{4|}}}||dec|{{#if:{{#switch:{{{4}}}{{{8}}}|NE|NW|SE|SW=y}}|dms|{{#if:{{#switch:{{{3}}}{{{6}}}|NE|NW|SE|SW=y}}|dm|{{#if:{{#switch:{{{2}}}{{{4}}}|NE|NW|SE|SW=y}}|d|ERROR}}}}}}}}|1={{{1|}}}|2={{{2|}}}|3={{{3|}}}|4={{{4|}}}|5={{{5|}}}|6={{{6|}}}|7={{{7|}}}|8={{{8|}}}|9={{{9|}}}|format={{{format|}}}}}}}</includeonly><noinclude>{{template doc}}</noinclude>

change to:

<includeonly>{{Coord/display/{{{display|inline}}}|1={{Coord/input/{{#ifeq:{{{4|}}}||dec|{{#if:{{#switch:{{{4}}}{{{8}}}|NE|NW|SE|SW=y}}|dms|{{#if:{{#switch:{{{3}}}{{{6}}}|NE|NW|SE|SW=y}}|dm|{{#if:{{#switch:{{{2}}}{{{4}}}|NE|NW|SE|SW=y}}|d|ERROR}}}}}}}}|1={{{1|}}}|2={{{2|}}}|3={{{3|}}}|4={{{4|}}}|5={{{5|}}}|6={{{6|}}}|7={{{7|}}}|8={{{8|}}}|9={{{9|}}}|format={{{format|}}}|name={{{name|}}}}}}}</includeonly><noinclude>{{template doc}}</noinclude>

Editprotected 2/6:: sometimes calls Template:Coord/input/dec

<includeonly>{{Coord/link|dms-lat={{coord/dec2dms|{{{1}}}|N|S|{{coord/prec dec|{{{1}}}|{{{2}}}}}}}|dms-long={{coord/dec2dms|{{{2}}}|E|W|{{coord/prec dec|{{{1}}}|{{{2}}}}}}}|dec-lat={{{1}}}|dec-long={{{2}}}|param={{{1}}}_N_{{{2}}}_E_{{{3|}}}|default={{#if:{{{format|}}}|{{{format}}}|dec}}
}}</includeonly><noinclude>{{template doc|Template:Coord/sub doc}}</noinclude>

change to:

<includeonly>{{Coord/link|dms-lat={{coord/dec2dms|{{{1}}}|N|S|{{coord/prec dec|{{{1}}}|{{{2}}}}}}}|dms-long={{coord/dec2dms|{{{2}}}|E|W|{{coord/prec dec|{{{1}}}|{{{2}}}}}}}|dec-lat={{{1}}}|dec-long={{{2}}}|param={{{1}}}_N_{{{2}}}_E_{{{3|}}}|default={{#if:{{{format|}}}|{{{format}}}|dec}}|name={{{name|}}}
}}</includeonly><noinclude>{{template doc|Template:Coord/sub doc}}</noinclude>

Editprotected 3/6:: sometimes calls Template:Coord/input/dms

<includeonly>{{Coord/link|dms-lat={{{1}}}°{{{2}}}′{{{3}}}″{{{4}}}|dms-long={{{5}}}°{{{6}}}′{{{7}}}″{{{8}}}|dec-lat={{coord2dec|{{{4}}}|{{{1}}}|{{{2}}}|{{{3}}}}}|dec-long={{coord2dec|{{{8}}}|{{{5}}}|{{{6}}}|{{{7}}}}}|param={{{1}}}_{{{2}}}_{{{3}}}_{{{4}}}_{{{5}}}_{{{6}}}_{{{7}}}_{{{8}}}_{{{9|}}}|default={{#if:{{{format|}}}|{{{format}}}|dms}}}}</includeonly><noinclude>{{template doc|Template:Coord/sub doc}}</noinclude>

change to:

<includeonly>{{Coord/link|dms-lat={{{1}}}°{{{2}}}′{{{3}}}″{{{4}}}|dms-long={{{5}}}°{{{6}}}′{{{7}}}″{{{8}}}|dec-lat={{coord2dec|{{{4}}}|{{{1}}}|{{{2}}}|{{{3}}}}}|dec-long={{coord2dec|{{{8}}}|{{{5}}}|{{{6}}}|{{{7}}}}}|param={{{1}}}_{{{2}}}_{{{3}}}_{{{4}}}_{{{5}}}_{{{6}}}_{{{7}}}_{{{8}}}_{{{9|}}}|default={{#if:{{{format|}}}|{{{format}}}|dms}}|name={{{name|}}}}}</includeonly><noinclude>{{template doc|Template:Coord/sub doc}}</noinclude>

Editprotected 4/6:: sometimes calls Template:Coord/input/dm

<includeonly>{{Coord/link|dms-lat={{{1}}}°{{{2}}}′{{{3}}}|dms-long={{{4}}}°{{{5}}}′{{{6}}}|dec-lat={{coord2dec|{{{3}}}|{{{1}}}|{{{2}}}}}|dec-long={{coord2dec|{{{6}}}|{{{4}}}|{{{5}}}}}|param={{{1}}}_{{{2}}}_{{{3}}}_{{{4}}}_{{{5}}}_{{{6}}}_{{{7|}}}|default={{#if:{{{format|}}}|{{{format}}}|dms}}}}</includeonly><noinclude>{{template doc|Template:Coord/sub doc}}</noinclude>

change to:

<includeonly>{{Coord/link|dms-lat={{{1}}}°{{{2}}}′{{{3}}}|dms-long={{{4}}}°{{{5}}}′{{{6}}}|dec-lat={{coord2dec|{{{3}}}|{{{1}}}|{{{2}}}}}|dec-long={{coord2dec|{{{6}}}|{{{4}}}|{{{5}}}}}|param={{{1}}}_{{{2}}}_{{{3}}}_{{{4}}}_{{{5}}}_{{{6}}}_{{{7|}}}|default={{#if:{{{format|}}}|{{{format}}}|dms}}|name={{{name|}}}}}</includeonly><noinclude>{{template doc|Template:Coord/sub doc}}</noinclude>

Editprotected 5/6:: sometimes calls Template:Coord/input/d

<includeonly>{{Coord/link|dms-lat={{coord/dec2dms|{{{1}}}|{{{2}}}|{{#ifeq:{{{2}}}|N|S|N}}|{{coord/prec dec|{{{1}}}|{{{3}}}}}}}|dms-long={{coord/dec2dms|{{{3}}}|{{{4}}}|{{#ifeq:{{{4}}}|E|W|E}}|{{coord/prec dec|{{{1}}}|{{{3}}}}}}}|dec-lat={{coord/dms2dec|{{{2}}}|{{{1}}}}}|dec-long={{coord/dms2dec|{{{4}}}|{{{3}}}}}|param={{{1}}}_{{{2}}}_{{{3}}}_{{{4}}}_{{{5|}}}|default={{#if:{{{format|}}}|{{{format}}}|{{#ifeq:{{coord/prec dec|{{{1}}}|{{{3}}}}}|d|dms|dec}}}}
}}</includeonly><noinclude>{{template doc|Template:Coord/sub doc}}</noinclude>

change to:

<includeonly>{{Coord/link|dms-lat={{coord/dec2dms|{{{1}}}|{{{2}}}|{{#ifeq:{{{2}}}|N|S|N}}|{{coord/prec dec|{{{1}}}|{{{3}}}}}}}|dms-long={{coord/dec2dms|{{{3}}}|{{{4}}}|{{#ifeq:{{{4}}}|E|W|E}}|{{coord/prec dec|{{{1}}}|{{{3}}}}}}}|dec-lat={{coord/dms2dec|{{{2}}}|{{{1}}}}}|dec-long={{coord/dms2dec|{{{4}}}|{{{3}}}}}|param={{{1}}}_{{{2}}}_{{{3}}}_{{{4}}}_{{{5|}}}|default={{#if:{{{format|}}}|{{{format}}}|{{#ifeq:{{coord/prec dec|{{{1}}}|{{{3}}}}}|d|dms|dec}}}}|name={{{name|}}}
}}</includeonly><noinclude>{{template doc|Template:Coord/sub doc}}</noinclude>

Editprotected 6/6:

And for those calls to Template:Coord/link

<span class="plainlinksneverexpand">[{{Coor URL}}{{{param}}} <span class="{{#ifeq:{{{default|}}}|dec|geo-nondefault|geo-default}}"><span class="geo-dms" title="Maps, aerial photos, and other data for {{{dms-lat}}} {{{dms-long}}}"><span class="latitude">{{{dms-lat}}}</span> <span class="longitude">{{{dms-long}}}</span></span></span><span class="geo-multi-punct"> / </span><span class="{{#ifeq:{{{default|}}}|dec|geo-default|geo-nondefault}}">{{#if:{{{name|}}}|<span class="vcard">|}}<span class="geo-dec geo" title="Maps, aerial photos, and other data for {{{dec-lat}}} {{{dec-long}}}"><span class="latitude">{{{dec-lat}}}</span>, <span class="longitude">{{{dec-long}}}</span></span>]</span><noinclude>{{template doc}}</noinclude>

change to:

<span class="plainlinksneverexpand">[{{Coor URL}}{{{param}}}{{#if:{{{name|}}}|&title={{urlencode:{{{name}}}}}}} <span class="{{#ifeq:{{{default|}}}|dec|geo-nondefault|geo-default}}"><span class="geo-dms" title="Maps, aerial photos, and other data for {{{dms-lat}}} {{{dms-long}}}"><span class="latitude">{{{dms-lat}}}</span> <span class="longitude">{{{dms-long}}}</span></span></span><span class="geo-multi-punct"> / </span><span class="{{#ifeq:{{{default|}}}|dec|geo-default|geo-nondefault}}">{{#if:{{{name|}}}|<span class="vcard">|}}<span class="geo-dec geo" title="Maps, aerial photos, and other data for {{{dec-lat}}} {{{dec-long}}}"><span class="latitude">{{{dec-lat}}}</span>, <span class="longitude">{{{dec-long}}}</span></span>{{#if:{{{name|}}}|<span style="display:none"> (<span class="fn org">{{{name|}}}</span>)</span></span>|}}]</span><noinclude>{{template doc}}</noinclude>

For the benefit of an editor, these are handcrafted tests of some of the templates. Coordinates of Manhattan. May be useful for sandbox tests. (SEWilco 04:26, 28 August 2007 (UTC))

coord (dms): 40°43′42″N 73°59′39″W / 40.72833°N 73.99417°W / 40.72833; -73.99417 (Manhattan test1dms)
coord (dec): 40°43′42″N 73°59′39″W / 40.728333°N 73.994167°W / 40.728333; -73.994167 (Manhattan test1dec)
coor dms: 40°43′42″N 73°59′39″W / 40.72833°N 73.99417°W / 40.72833; -73.99417 (Manhattan test2dms)

coor dm:

{{coor dm|40|43|N|73|59|W|type:city|name=Manhattan test2dm}}

coor d:

{{coor d|40|N|73|W|type:city|name=Manhattan test2d}}

coord/link:

{{coord/link|param=40_43_42_N_73_59_39_W_type:city|dms-lat=40°43′42″N|dms-long=73°59′39″W|name=Manhattan test3}}

This page has become impossible to read and comprehend. I'm pretty sure it has to do with several independent conversations all taking place in the same area. This editprotected request has been up for a long time and the best reason I can see for that is that no one can understand what to change. If there are broad changes that need to be made to Template:Coord, place an editprotected tag in a new section with the requested changes. If a separate template (or sub-template) needs to be changed, please place the request on that template's (or sub-template's) talk page and I will gladly make the changes. Cheers. --MZMcBride 22:03, 2 September 2007 (UTC)

With all due respect, this can't get much closer to a silver platter. The reason I can see that admins aren't willing to do the edits is that their effects can't be seen until all of them have been done, and bothering to understand the changes seems to be a big effort. The talk pages of the subtemplates redirect here. Just copy each "change to" text in its entirety to the template's edit window, click on "show changes" to see the diff, and save. I added some red lines now, is that helpful enough? --Para 23:07, 2 September 2007 (UTC)

I understand the changes, but I don't like the use of 'display:none' here any more than I did when it was being pushed as a method of handling conditional logic for text (now handled by parserFunctions). Uncertainty about exactly how Google Earth is parsing the coordinates, and thus how it would handle these changes, is also a concern. --CBD 23:36, 2 September 2007 (UTC)

You are the first to complain of 'display:none', though it has been used since the creation of this template. Google Earth was shown to ignore the other optional parameter 'format', so there is no reason why 'name' wouldn't be ignored as well. --Para 23:53, 2 September 2007 (UTC)

Done. Cheers. --MZMcBride 02:31, 3 September 2007 (UTC)

Brilliant, thanks! --Para 11:07, 3 September 2007 (UTC)

List_of_Minnesota_State_Parks still doesn't show the labels on the Kml export OR, due to the recent change to GeoTemplate, single points on Google. --CBD 07:40, 3 September 2007 (UTC)

List_of_Minnesota_State_Parks does now show 71 named locations (using firefox with the Operator add-on) rather than 71 pairs of coordinates, which seems to me a great improvement. What is the kml export? Carminis 08:52, 3 September 2007 (UTC)

Fixed. Please take further discussion about the kml export functionality to its page, currently {{GeoGroupTemplate}}. For the traditional use of clicking on coordinates and choosing a map service, the discussion should go to Template talk:GeoTemplate. --Para 11:07, 3 September 2007 (UTC)

Conclusion?

I confess I'm a bit lazy and haven't dug through every last thing that has been written about this change, but from what I gather, if you want the {title} tag to have spaces in it, it is now possible to do this by using the "name" parameter in coord. For example, the following doesn't alter the name by passing underscores in place of the spaces... so far so good: "coord|47|36|33.03|N|122|10|43.8672|W|display=title|region:US_type:landmark|name=Bellevue Botanical Garden" However, this means that every coordinate in every article needs to have the name parameter specified. Is this the plan? Heptazane (talk) 18:57, 11 December 2007 (UTC)

That could be considered a bug in GeoHack, in that when the name parameter hasn't been given to the coordinate templates and GeoHack uses the url-formatted pagename as the title, it might as well make it more human readable and replace the underscores with spaces in title use. Adding the parameter to articles just to get rid of the underscores would for that purpose be a fairly pointless workaround. Some services may however have problems if characters that currently work are suddenly replaced with others; there was some discussion about the issue at Template talk:GeoTemplate#Named coordinates. --Para (talk) 19:52, 11 December 2007 (UTC)