Template talk:Coord/Archive 2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1 Archive 2 Archive 3 Archive 4 Archive 5

Display

If I choose the degrees (DMS) display, there is no comma between the co-ordinates, whereas there is a comma in the alternative display. (This is using Firefox.) I would prefer a comma in both - is this possible? -- roundhouse 09:53, 16 May 2007 (UTC)

Languages and page position

Using Classic skin and Win XP with MSIE7, the coordinates are up near the top right of the page. Unfortunately, so is the list of interwiki language links. If the language list is more than one line long, then the coordinates get zapped by the ---- line or by the link text itself. Can the coordinates be placed level with the page title, but on the right and below the line? (If requested, I'll upload a picture of what I'm talking about.) -- SGBailey 19:07, 18 May 2007 (UTC)

Oh yes, this also applies to {Coor} -- SGBailey 19:08, 18 May 2007 (UTC)

Here is a typical example of the problem. The "Coord" appears to be in a fixed relationship to the search box in the top right. Image:Coord clash.png -- SGBailey 08:57, 27 May 2007 (UTC)

Since it isn't just coord which is affected, it might be better to bring this up on the talk page of the relevant skin. Andy Mabbett 09:52, 27 May 2007 (UTC)
I have this problem too. I'm not aware of any other problems that affect the classic skin, therefore I assume the problem is with coord. – Tivedshambo (talk) 07:01, 30 May 2007 (UTC)
Please note the comment from SGBailey, timestamped 19:08, 18 May 2007, above. Andy Mabbett 07:50, 30 May 2007 (UTC)

Sort keys in category links?

The bottom of Template:Coord/doc contains these category links:

[[Category:Protected templates]]
[[Category:Coordinates templates]]
[[Category:Templates generating Geo]]

These category links do not contain sort keys. Compare this to Template:Coor/doc which does (it uses the {{PAGENAME}} magic word as its sort key):

<!-- ADD CATEGORIES BELOW THIS LINE -->
[[Category:Coordinates templates|{{PAGENAME}}]]

The lack of sort keys in the category links in Template:Coord/doc causes Template:Coord to sort under the letter "T" instead of "C" on category pages such as Category:Coordinates templates. This is probably undesirable, because other superseded templates appear under "C", which puts them earlier and makes them easier for people to find (and possibly use). Should we fix this by hard-coding adding a sort key in each category link, like this:

[[Category:Protected templates|{{PAGENAME}}]]
[[Category:Coordinates templates|{{PAGENAME}}]]
[[Category:Templates generating Geo|{{PAGENAME}}]]

I thought I would ask before editing in case there was a reason for omitting the sort keys. --Teratornis 12:21, 19 May 2007 (UTC)

None that I know of. Go ahead and try it!" Andy Mabbett 13:25, 19 May 2007 (UTC)
OK, done. I hope that doesn't bork anything. --Teratornis 21:07, 19 May 2007 (UTC)

Wikipedia talk:Manual of Style (dates and numbers)#Coordinates

There is an ongoing discussion at Wikipedia talk:Manual of Style (dates and numbers)#Coordinates section about which templates should be used to insert geographical coordinates into articles. -- Patleahy 23:32, 20 May 2007 (UTC)

"project" wording

The new wording:

{{coord}} will be used by tools which parse the raw Wikipedia database dumps, such as Wikipedia-World and Google Earth. The template must not be modified without reference to these projects.

is ludicrous. Nobody has to ask Google before changing anything on Wikipedia. The referral should be to the Wikipedia project which provides the database dump to Google and liaises with them. I have removed this new wording once, but it has been reverted. Andy Mabbett 21:04, 22 May 2007 (UTC)

True, Google doesn't need to be asked before changing anything on Wikipedia, but Wikipedia itself, the community, does need to be asked. It so happens that the community is also interested of having Google continue using the Wikipedia data. Instructions to use database dumps are irrelevant in template instructions, all parsing is done by Google and it's now correctly referred. You seem to listen to User:Gmaxwell, so here's a reference related to Google Earth and the importance of machine readability. You can not just go editing individual templates and articles and break that feature for everyone. --Para 21:29, 22 May 2007 (UTC)
None of your irrelevant rant addresses the inappropriateness of the quoted wording. People do not need to make reference "to Google Earth" and the links you give will not take them anywhere useful for the purpose described. Please either provide more suitable wording and more suitable links, or reverse your edit. Andy Mabbett 21:38, 22 May 2007 (UTC)
Please be aware of WP:CIVIL and WP:NPA - it is possible to respectfully disagree with a contributor's suggestions or comments. Orderinchaos 21:06, 30 May 2007 (UTC)
Thank you, but I was civil; there were no attacks; and my response was tempered and measured. Andy Mabbett 21:08, 30 May 2007 (UTC)

Caution template

The caution template add edit this documentation, with the edit summary "(re-add warning, people need to know the consequences of using a non-supported template" is overkill. The template is "supported" by Wikipedia, and is used on tens of thousands of articles. Andy Mabbett 20:34, 30 May 2007 (UTC)

With all due respect, there are still issues that prevent it from becoming an official standard, as detailed by Para above. Once those issues are resolved, I think the path's pretty clear for it to replace coor* (although not coor itself, which has one or two features this one doesn't). Orderinchaos 21:03, 30 May 2007 (UTC)
WTF is an "official standard" in this context?
" one or two features this one doesn't" - such as?
Andy Mabbett 21:07, 30 May 2007 (UTC)
One of them is as raised above by myself on 11 April 2007. There was another but I have forgotten it at the present - will update when I recall it. Orderinchaos 21:11, 30 May 2007 (UTC)
I see that, even though the circumstances have changed, this hysterical warning has been restored, by reversion, yet again. Andy Mabbett 22:24, 6 June 2007 (UTC)

Addition to template doc

I added a row to the doc table to show that the user can enter a decimal-to-dms conversion without having to enter N/S or E/W. ●DanMSTalk 00:42, 1 June 2007 (UTC)

Display problem with title

You may already be aware of this, but I thought I would point it out just in case: Coord displayed as title in the upper right-hand corner is buried beneath all the interwiki language links when there a lot of other languages. Take a look at Chicago to see. This problem shows up at least in the Classic skin, which I use. I have not tried other skins. ●DanMSTalk 00:48, 1 June 2007 (UTC)

  • P.S. I use Firefox. Perhaps this displays differently in other browsers. ●DanMSTalk 00:49, 1 June 2007 (UTC)
  • I tried the other skins. It looks like Classic is the only skin that has the aforementioned problem. ●DanMSTalk 01:01, 1 June 2007 (UTC)
This has already been reported (see Languages and page position above). It's not a fault with the browser, as it also affects IE6, so I imagine it's the interface between coord template and the skin css. I don't know if anyone has looked at fixing it yet. – Tivedshambo (talk) 04:46, 1 June 2007 (UTC)
As explained in the section you cite, it's not specific to coord. Andy Mabbett 08:02, 1 June 2007 (UTC)
I think it is coord specific - I don't know of any other templates that try to put links above the start of the article. – Tivedshambo (talk) 08:36, 1 June 2007 (UTC)
It is not. I refer you, not for the first time, to the comment from SGBailey, timestamped 19:08, 18 May 2007, in the section you cite, above. Andy Mabbett 09:15, 1 June 2007 (UTC)
I don't understand what you're referring to. The only comment SG Bailey made at that time is to that same section where he reports faults with the co-ordinate system. – Tivedshambo (talk) 09:43, 1 June 2007 (UTC)
[1]. Andy Mabbett 10:06, 1 June 2007 (UTC)
That's just nit-picking. The fault lies with the co-ordinate class coding, whether it's called from {{coor}}, {{coord}} or any other similar template. – Tivedshambo (talk) 10:15, 1 June 2007 (UTC)
"That's just nit-picking" - no, it's an utter refutation of your beliefs and claims that "problem is with coord" and "it is coord specific". Andy Mabbett 10:26, 1 June 2007 (UTC)

(rm indent) I stand by my claim. There is undeniably a fault, and I believe the fault lies with the coord template (which includes the CSS coding it calls). The fact that another similar template uses the same method is irrelevant. Rather than being pedantic, could you look at fixing it please. – Tivedshambo (talk) 10:43, 1 June 2007 (UTC)

Your claims are, as the evidence shows, bogus. I refer you to my post, time-stamped "09:52, 27 May 2007". Andy Mabbett 12:13, 1 June 2007 (UTC)
The whole {{coord}} episode continues... I'm sure it would be much appreciated if users could concentrate on the main issues. The fact is that there is a problem, where the problem comes from is only relevant as far as attempting to solve it goes. If this is unique to {{coord}} then highlighting this problem is not an attack on the main editors of the template and should not be considered so. When problems are reported they should be investigated and resolved, there is no need for users to go on the defensive. All this does is slow the process and further delays the implementation of {{coord}}. Adambro 12:56, 1 June 2007 (UTC)
"If this is unique to {{coord}}" - *sigh* It is not, a evidenced above, and as pointed out, more than once.
"then highlighting this problem is not an attack on the main editors of the template and should not be considered so. - indeed. Who has done so?
Andy Mabbett 13:13, 1 June 2007 (UTC)

How do you make out that "my claim is bogus"? There is not the slightest shred of evidence that there is a fault with the skin, and therefore the problem almost certainly lies with the co-ordinate CSS. Can I also point out that this is not the first time there have been problems with the interraction between co-ordinates and the classic skin - see Template talk:Infobox UK station#co-ordinates. – Tivedshambo (talk) 08:03, 4 June 2007 (UTC)

"How do you make out that "my claim is bogus"? " because the cited evidence directly contradicts it. The previous issue was quickly resolved, and has no bearing on your fallacious claim. Andy Mabbett 13:41, 4 June 2007 (UTC)
This argument is going round in circles. Your only cited evidence is that {{coor}} is also faulty. I agree with this, however as this is also a co-ordinate based template it proves nothing. Can you provide any evidence not related to the co-ordinate templates that there is a fault with the classic skin? – Tivedshambo (talk) 13:47, 4 June 2007 (UTC)
"I agree with this". Finally. Andy Mabbett 14:22, 4 June 2007 (UTC)
So could you fix it then please? – Tivedshambo (talk) 07:39, 5 June 2007 (UTC)
No. See above for advice on how to report the matter. Andy Mabbett 09:33, 5 June 2007 (UTC)
There is no point reporting it as a fault with the skin when this is not the case. As I have pointed out above, the fault is with the co-ordinate CSS. – Tivedshambo (talk) 11:10, 5 June 2007 (UTC)
What "co-ordinate CSS"? Andy Mabbett 14:51, 5 June 2007 (UTC)
See [2]. There are a number of co-ordinate related classes used here - I'll have a look at coor later and see what that uses as well. I'll do some experimenting and see if I can narrow the problem down to a specific area. – Tivedshambo (talk) 15:12, 5 June 2007 (UTC)
"classes" != "CSS". Andy Mabbett 15:14, 5 June 2007 (UTC)

I've got fed up with this discussion not going anywhere and I've had chance to look into this myself and it should now be fixed. I would appreciate if others could confirm this to be the case. The problem was with a CSS ID in MediaWiki:Standard.css which is used by the {{coord}}. I haven't looked into coor but presume this uses the same CSS ID and so will probably be working also. Adambro 17:06, 5 June 2007 (UTC)

Hmm, actually what I've done is solved one problem and created another. Because the coordinates are placed a fixed distance from the page top using CSS, pages with a different number of language etc. links to Brighton still has the problem. I'll look into finding a solution to this but at least we now know where to look. Adambro 17:12, 5 June 2007 (UTC)
Thanks for trying. I also did some trials earlier, though I don't claim to understand CSS/class/span/whatever. The problem seems to be in <span id="coordinates"> which seems to be what pushes the link to the top of the page. I don't know if this helps at all. Could it be set to push the link to a position relative to the start of the article, rather than a fixed distance from the top? – Tivedshambo (talk) 17:20, 5 June 2007 (UTC)
Have we any update on the resolution of this problem? Keith D 13:29, 21 June 2007 (UTC)

GeoNames

GeoNames [3] is now parsing coord (rendering the warning currently displayed in the template's documentation factually inaccurate as well as unnecessary). Andy Mabbett 16:15, 7 June 2007 (UTC)

Link? So when Google announces their support, only Wikipedia-World is left of the notable ones. --Para 16:22, 7 June 2007 (UTC)
Link in the above. Where is it stated that WW parse 'coor *' templates? Andy Mabbett 16:23, 7 June 2007 (UTC)
Link to them announcing the support I mean, or link to Wikipedia data on their site using coord. WW support was requested on Stefan Kühn's talk page. --Para 16:33, 7 June 2007 (UTC)
The news came in a private e-mail from GeoNames. Andy Mabbett 16:37, 7 June 2007 (UTC)
Excuse me for not trusting your word. Please request them to announce the support on wikitech-l. --Para 16:49, 7 June 2007 (UTC)
"Excuse me for not trusting your word." No. Andy Mabbett 16:51, 7 June 2007 (UTC)
Their XML search doesn't list the above mentioned first coord article. So, no evidence, then. --Para 19:09, 7 June 2007 (UTC)
No; just evidence that they were not doing so in early April. Andy Mabbett 19:53, 7 June 2007 (UTC)
What they were doing in April is irrelevant, as the information is in all the database dumps since the date of entry. The situation remains that no external service supports coord. Please hold your announcements until each of these services dependant on Wikipedia data make a public announcement of support. --Para 20:23, 7 June 2007 (UTC)
You're inventing, again. GeoNames is now parsing coord, as I said above. They do support it. Andy Mabbett 20:28, 7 June 2007 (UTC)
Like I said before, there is no evidence of support. The XML search above does not return Ben Bulben, even though it has been available with coord longest. --Para 20:33, 7 June 2007 (UTC)
Like I said before, I have an email from them confirming that they now parse coord. Your irrelevant test does not refute that. Andy Mabbett 20:35, 7 June 2007 (UTC)
After having been banned multiple times for disruptive behaviour, do you seriously expect anyone to take your word over data anyone can verify at any time? --Para 20:45, 7 June 2007 (UTC)
Another falsehood. I have not been "banned multiple times" for any reason. Andy Mabbett 21:01, 7 June 2007 (UTC)
Obviously, Paradisal/Para meant "blocked" not "banned". Pigsonthewing/Andy Mabbett does in fact appear to have been blocked a near-record number of times. block log, FWIW. — SMcCandlish [talk] [cont] ‹(-¿-)› 01:22, 8 June 2007 (UTC)
and that reflects on my honesty how, exactly? Andy Mabbett 08:55, 8 June 2007 (UTC)
Answered on user talk. --Para 10:49, 8 June 2007 (UTC)
As I remarked above Google Earth hasn't yet noticed coor title dms either from April - eg for instance Sterling, Ohio was tagged by the Anomebot in early April and doesn't show up (Rittman, Ohio is the nearest that shows - tagged in 2006). (Google Earth does notice coor title eventually, eg Sheffield Crucible, tagged 5 Feb 2007.) So there seems to be a considerable time lag. Geonames is nice BTW. -- roundhouse 01:01, 8 June 2007 (UTC)
Pardon my ignorance, but what does parsing coord actually mean and what effect will it have? – Tivedshambo (talk) 18:04, 7 June 2007 (UTC)
They already read and process the coor * templates. They are now going to do so for coord. What they then do with the results, I don't know. Andy Mabbett 18:34, 7 June 2007 (UTC)

The search linked above now returns Ben Bulben, and I was ready to congratulate GeoNames for being the first to support coord already, but it turns out they're not returning the coordinates from here, but those of the German Wikipedia. Can someone find another article for testing? The criteria are 1) used with coord before the latest database dump from 2007-05-27, 2) the addition of coord must be the first introduction of coordinates into the article so that we can be sure that information from the coor templates isn't being used instead, and 3) the article must not have any coordinates in other Wikipedias, which can usually be checked with the non-existence of interwiki links. Also perhaps that 4) the use of the template must be with display=title to make sure it's considered important enough to be included. Finding such a test case would allow to check all these external services for coord support. Currently it seems to still be the situation that nobody supports coord. --Para 00:22, 15 June 2007 (UTC)

Anomebot2 tagged many around 20 May with coord (changed from coor title during May 20) - see here. I think these all satisfy 1, 2, 4 of your criteria. -- roundhouse0 00:55, 15 June 2007 (UTC)
Netherton Tunnel Branch Canal fairly bristles with coord, since mid-April. -- roundhouse0 01:25, 15 June 2007 (UTC)
GeoNames proximity search with the title coordinates of Netherton Tunnel Branch Canal does not find the article. Not supported then, Andy must be reading emails through pink glasses. --Para 09:15, 15 June 2007 (UTC)
No, but I'm reading them, unlike you, who is simply guessing, wrongly, at what they say and mean. Andy Mabbett 20:50, 15 June 2007 (UTC)
"Currently it seems to still be the situation that nobody supports coord. Wrong. As stated, Google Earth, GeoNames and Wikipedia-World have all indicated their readiness to parse coord. Andy Mabbett 06:37, 15 June 2007 (UTC)
Google have said that they will tell us when they have their parser ready[4], and that they are planning to get it done before their next update[5] (last of which was in January-February, according to notes here). GeoNames have not communicated of the support, we only have the word of the "owner" of the template, who keeps pushing it forward despite opposition. Tests for the existence of the support fail. Wikipedia-World is working on it, but it's not ready at the moment. Currently, coord is not supported and there is no reason to pretend it is. --Para 09:15, 15 June 2007 (UTC)
Geonames do show Torside Reservoir with a wikipedia window, tagged with coor title d by Anomebot2 on 20 May. So Geonames are quite fast. -- roundhouse0 20:28, 15 June 2007 (UTC)
"Tests for the existence of the support fail." - Wrong again. You're testing for something else entirely. Your snide insinuations about ownership also prove nothing. Google Earth, WikipediaWorld and GeoNames have all indicated their readiness to parse {{coord}}. The pretence is the denial of that fact. Andy Mabbett 20:43, 15 June 2007 (UTC)

Coordinates from Netherton Tunnel Branch Canal have now appeared in the proximity search above. They're not the title coordinates, but the first coordinates mentioned in the article. This is just a GeoNames bug and should be taken up with them, but for us it means that GeoNames is now the first and only external service to show coord data. Congratulations GeoNames and Andy, it only took 10 days from the flailing arms support announcement. --Para 09:17, 17 June 2007 (UTC)

There were no "flailing arms"; refrain from such unwarranted hyperbole. As I said on 7 June, and as they told me in e-mail, GeoNames were parsing {{coord}} then. I said nothing about how long it would take for them to publish the results of that process. I note that you have still not removed your bogus and dishonest warning from the template documentation. Kindly do so immediately. Andy Mabbett 19:56, 17 June 2007 (UTC)

In answer to "what does this all mean?"

I think a clear non-technical explanation is required here, as I doubt Tivedshambo is the only one wondering what on earth we're going on about here. What we're meaning here is that independent sites like Google Earth, WW etc and undoubtedly others scan Wikipedia pages for particular formatted input in order to load data into their own systems, which they present to their own users or customers.

The process of reading a Wikipedia template and translating that into that site's own internal data format is called "parsing". So when these sites start "parsing" coord, i.e. when they fix up their systems to read ours (not much we can do to speed that up other than asking them nicely and repeatedly to do so :)) then it means that data encoded using the coord template will also (eventually) show up on those sites - in this case, satellite mapping sites and the like.

As coor has been around longer and meets some hitherto pre-agreed standards between those sites, it was recognised while this one was not, but obviously now those sites are starting to catch up. Once this has been done, as coord is a more flexible template than the old coor range and does everything the old ones could, we can say that coord has deprecated (i.e. replaced to a point where Wikipedians should use coord instead of coor on all occasions) the coor range. That is still to happen, but the point at which this will occur is probably fairly imminent (i.e. next month or two) if the information provided above is a correct reflection of what's going on. Orderinchaos 02:42, 8 June 2007 (UTC)

BTW I do note the above is a drastic oversimplification, but it explains enough to a non-technical user that they can see in broad general terms where things are at and what the current discussions actually mean. Orderinchaos 02:48, 8 June 2007 (UTC)
Thanks for the explanation. I used Google Earth last night, for the first time for ages, and noticed that there are now a number of Wikipedia globes appeared over everything, which link to the relevant article. Presumably this is what they're used for. – Tivedshambo (talk) 07:02, 8 June 2007 (UTC)
More like the next week or two. The one "oversimplification" I would comment on is that such services don't parse the published pages, but the raw page source code, which they download about once every month or two - so they're often lagging behind recent edits. Andy Mabbett 08:50, 8 June 2007 (UTC)

Conversion issues

I've just moved the section on conversion issues to /conversion; please use that page to discuss the forthcoming conversion of coor * templates (and others) to coord. Thank you. Andy Mabbett 10:58, 8 June 2007 (UTC)

Cool - I've updated the stats off AWB. Orderinchaos 11:51, 8 June 2007 (UTC)
Thank you; could you do the same for coord, please? Andy Mabbett 12:02, 8 June 2007 (UTC)
Done. Orderinchaos 12:42, 8 June 2007 (UTC)
Thank you again. Andy Mabbett 16:49, 8 June 2007 (UTC)

Classic skin - fixed!

I think I've found a solution to the problem of displaying co-ordinates in classic skin. They should now display on the top left of the display, below "Printable version". Hopefully this won't interfere with anything else. – Tivedshambo (talk) 17:41, 9 June 2007 (UTC)

Bogus warning

The re-application of a wholly fallacious warning box to this template's documentation, after Google Earth, GeoNames and Wikipedia-World have all agreed to parse {{coord}} is beginning to appear little short of vindictive. Andy Mabbett 06:40, 15 June 2007 (UTC)

Agreeing to have the parsers ready at some undefined point in the future is not the same as being ready to get the data in the new format now. What is the hurry to do the conversion now? Instead of participating in a combined effort to help bots do the conversion, you are trying to do it manually on your own. Why?? --Para 09:18, 15 June 2007 (UTC)
"this week" is not "some undefined point in the future". Who said anything about being in a hurry to do a conversion, manually or otherwise. The wording in your warning is blatantly false. I am participating in the real "combined effort". Andy Mabbett 09:40, 15 June 2007 (UTC)
The warning has just been amended, and is now not only bogus and fallacious, but PoV - and insulting to our colleagues and collaborators at GeoNames. The edit summary was "warning elaborated as requested"; yet the only request I can see is mine, for its total, and overdue, removal. Andy Mabbett 21:57, 17 June 2007 (UTC)
For the record I think the warning is fair up until the sites confirm they have processed it - it's neither "bogus (nor) fallacious" but a fair indication to people that this is not cut and dried just yet. It soon will be, but warnings (which are voluntary to follow anyway) apply to the present, not the future. Orderinchaos 23:32, 17 June 2007 (UTC)
It is bogus and fallacious because what it says is - as of more than a week ago, let alone now - not true. It is false. A lie, How much more "unfair" can it be, than that? Andy Mabbett 07:52, 18 June 2007 (UTC)

My removal of this bogus warning has again been reverted, with the dishonest edit summary "support still hasn't been announced by Google or Wikipedia-World". Andy Mabbett 13:19, 21 June 2007 (UTC)

Where have Google or Wikipedia-World (or geo names) announced support? -- roundhouse0 13:45, 21 June 2007 (UTC)
Please try to be realistic when interpreting the correspondence with the external projects. Wikipedia-World has apparently said to begin parsing the new template "this week" (the week ending on June 10), with a note a few days after that it's not ready. Google on the other hand have promised to announce the support on a public mailing list, again by the end of the week ending on June 10. No announcements have been made since, except to say that the parsing is not up-to-date yet. None of this can be interpreted as a definitive announcement of support now. Haven't we been through this enough times already? Before the most notable reusers of Wikipedia coordinate data say that their parsers now process coordinates in coord format, the warning must stay. If you wish to change the situation, feel free to follow-up and request them to announce the support on wikitech-l or here. --Para 13:55, 21 June 2007 (UTC)