Jump to content

Module talk:Coordinates

Page contents not supported in other languages.
Coordinates: 1°N 2°W / 1°N 2°W / 1; -2
From Wikipedia, the free encyclopedia

Interface-protected edit request 27 December 2023

[edit]

Please sync from Module:Coordinates/sandbox (diff).

This adds a class and a data-gadget attribute to the span. For now, this is a no-op change. It is intended to facilitate a more performant way of loading the WikiMiniAtlas script, when coupled with the proposed changes in MediaWiki talk:Common.js#Class-triggered gadgets. – SD0001 (talk) 14:36, 27 December 2023 (UTC)[reply]

 Done * Pppery * it has begun... 16:54, 27 December 2023 (UTC)[reply]

As MediaWiki now supports category-based gadget load, we can switch to that. Please sync from Module:Coordinates/sandbox (Special:Diff/1192107975/1226463973). For now, this is a no-op as the gadget isn't actually defined. – SD0001 (talk) 20:17, 30 May 2024 (UTC)[reply]

 Done * Pppery * it has begun... 00:22, 31 May 2024 (UTC)[reply]

coordinsert problem?

[edit]

@Jonesey95 I recently found your old question on German WP. It could be because of a malformed Geohack link: "Infobox UK place" uses coordinsert which generates a broken string when "coord" got a "title" parameter: https://geohack.toolforge.org/geohack.php?pagename=Hatfield_Chase&params=53.528_N_0.893_W_&title=Tunnel+Pits_region:GB_type:city (see the splitted "params" seperated by the "title" parameter). "coordinsert" assumes "params" always as last parameter? Which isn't true when "title" is used. DB111 (talk) 09:10, 14 August 2024 (UTC)[reply]

Add a "precedence" parameter

[edit]

Hello. Can https://en.wikipedia.org/w/index.php?title=Module:Coordinates/sandbox&oldid=1319497477 be synced to Module:Coordinates please? This should add a "level" parameter that can be set to "primary" and that defaults to "secondary", matching the behavior of the GeoData extension that this module relies on.

We currently overload "display=title" to indicate that coordinates are the primary ones. Primary in this case means which coordinates get returned for the whole page in queries such as <https://en.wikipedia.org/w/api.php?action=query&prop=coordinates&titles=Cincinnati>. I'd like greater flexibility within this template and I'd like to be more explicit about the behavior by adding this "level" parameter.

Any and all code review is welcome. The name "level" isn't great. I considered doing "display=primary" initially but that seemed worse. Level or order matches what we typically call words such as primary, secondary, or tertiary. --MZMcBride (talk) 04:40, 30 October 2025 (UTC)[reply]

It's a bit unfortunate choice of the parameter name. In this context, I thought level has something to do with altitude. How about "importance level", prominence, significance, priority, relevance, precedence, or primacy? 98.15.131.172 (talk) 09:26, 30 October 2025 (UTC)[reply]
Precedence may be better, yeah. --MZMcBride (talk) 15:31, 30 October 2025 (UTC)[reply]

{{sudo}}

Based on feedback, I switched to "precedence" in <https://en.wikipedia.org/w/index.php?title=Module:Coordinates/sandbox&oldid=1319561810>. Can this be please be reviewed for acceptance? --MZMcBride (talk) 15:34, 30 October 2025 (UTC)[reply]

Should the {{#coordinates:}} not be included if the params are |display=title|precedence=secondary ? As precedence is currently ignored if display has title, or would then never be a case with the title coord not being the primary? -- WOSlinker (talk) 18:18, 30 October 2025 (UTC)[reply]
Oh, good point. I believe this is now addressed in <https://en.wikipedia.org/w/index.php?title=Module:Coordinates/sandbox&oldid=1319669517>. --MZMcBride (talk) 05:15, 31 October 2025 (UTC)[reply]
@MZMcBride: Did a little testing and didn't seem to work all the time, so made some changes. Did the check for display=title and precedence=secondary first and also set the value to blank rather than secondary that gets passed over to #coordinates as it didn't seem to accept secondary. Can you check that it looks ok with my changes? -- WOSlinker (talk) 08:49, 31 October 2025 (UTC)[reply]
I like precedence better than level, but are we overspecifying this, making it easier to make typos and other errors? What if we just had |primary=yes for any primary coords on a page and |primary=no for all other (secondary) coordinates? – Jonesey95 (talk) 14:12, 2 November 2025 (UTC)[reply]
Yeah, this might be a lot cleaner and clearer. --MZMcBride (talk) 18:55, 3 November 2025 (UTC)[reply]
I meant to say, in case it is not implied: |primary=yes would be the default, as it essentially is now, so really only |primary=no would need to be used for secondary coordinates. We could also do |secondary=yes if that makes more logical sense. – Jonesey95 (talk) 20:41, 4 November 2025 (UTC)[reply]
We currently set coords to secondary by default and only to primary if display=title is set. I'm trying to add functionality so that we can set primary coords without needing to overload display=title. We do not want every {{coords}} on the page trying to set itself as primary by default as far as I know. --MZMcBride (talk) 01:22, 7 November 2025 (UTC)[reply]
Indeed. I either didn't know that or had forgotten. Carry on. – Jonesey95 (talk) 13:23, 7 November 2025 (UTC)[reply]

Issue with inline coords

[edit]
Moved from Template talk:Infobox settlement § Issue with coordinates...
Coordinates
Coordinates:  

So I keep coming across pages where the |coordinates={{coords|...|display=title}}. The issue with this is that the logic in the if statement sees that {{{coordinates}}} is not empty, and therefore renders the Coorindates: text. See the example at right, note I have used a nbsp to achieve the same result here so as not to throw random coords on the talk page title.

We should fix this somehow... The options I see include:

  1. Detecting if |display=title and if so, hiding the Coordinates: text.
  2. Somehow modifying Module:coordinates so that in certain circumstances you can use the coordinsert functionality to change the display from just title to title and inline, though I now realize that would still require detecting what the current value of |display= is. We don't want to run into errors because the coords are defined as inline in the infobox then at the bottom of the page there is a 2nd set of coords defined for the title...

Open to any suggestions! Zackmann (Talk to me/What I been doing) 23:04, 14 December 2025 (UTC)[reply]

@Jonesey95 and Hike395: any thoughts on this? Zackmann (Talk to me/What I been doing) 18:40, 15 December 2025 (UTC)[reply]
Looks like the coordinates module already has some helper functions that parse the display parameter value, so maybe just make sure they are exported in a namespace from which they can be reused? --Joy (talk) 19:42, 15 December 2025 (UTC)[reply]
Not sure how exactly that would look. I'm only able to picture an additional function that would return the a parsed display parameter. Zackmann (Talk to me/What I been doing) 22:33, 15 December 2025 (UTC)[reply]
Can we test the output of |coordinates= to see if it wants to display the inline portion? Alternatively, can we somehow inject display=inline into the parameter, maybe with a string replacement? – Jonesey95 (talk) 01:02, 16 December 2025 (UTC)[reply]
Exactly what I am thinking, just not really sure how to do that... Happy to dive into it though. Mainly wanted to sanity check that I wasn't missing something obvious before I went down the rabbit hole. Zackmann (Talk to me/What I been doing) 01:04, 16 December 2025 (UTC)[reply]
This is a total hack and will definitely have negative side effects (I think), but {{Str rep|1={{coords|1|1|N|3|3|E|display=title}}|2=-hidden noexcerpt|3=}} might be fun to play with. – Jonesey95 (talk) 02:18, 17 December 2025 (UTC)[reply]
Because there's no mention of 'display' or 'inline' or 'title' in the second or third parameters, nobody will remember what it does tomorrow. Let's not make it more complex and less likely to be maintained. --Joy (talk) 08:19, 17 December 2025 (UTC)[reply]
I'm referring to isInline() and similar functions, Module:Coordinates#L-633. With a few relatively small interventions, this could be brought out of the local scope and we could conceivably use it to quickly check the display value from the outside. --Joy (talk) 08:47, 16 December 2025 (UTC)[reply]
Hmm that could certainly help! I'll get into this later this week and see if I can't mock something up in the Sandbox. Zackmann (Talk to me/What I been doing) 16:46, 16 December 2025 (UTC)[reply]
@Joy and Jonesey95: moved the discussion here where I probably should have started it. I have mocked up a solution in Module:Coordinates/sandbox. See below:
So with this we could wrap {{Infobox settlement}}'s {{{coordinates}}} param in the new function as follows: {{#invoke:coordinates|forceinline|{{{coordinates}}}}}. This would ensure that it always displays inline, in addition to in the title if that is desired. Note I have done VERY LITTLE testing of this, but am looking for feedback on this as a possible solution. Zackmann (Talk to me/What I been doing) 02:58, 19 December 2025 (UTC)[reply]
@Pppery, Izno, Hike395, and Frietjes: as recent editors of this template, at your convenience, could you please review the above discussion and my attempted solution? Thanks! Zackmann (Talk to me/What I been doing) 19:13, 22 December 2025 (UTC)[reply]

Edit request 28 December 2025

[edit]

Description of suggested change: To help solve the problem described at Issue with inline coords (above) I have written a new function that can be called to force coordinates to display inline. (Note: if/when implemented I will add documentation for this).

New code: please insert at Line 765 

function coordinates.forceinline(frame)
	local text
	text = mw.ustring.gsub(frame.args[1], 'geo%-inline%-hidden', 'geo-inline')
	text = mw.ustring.gsub(text, 'style=\"display:none\"', '')
	return text
end

Zackmann (Talk to me/What I been doing) 19:46, 28 December 2025 (UTC)[reply]

@Pppery and Izno: could one of you possibly review the above request? Trying to fix a problem that is plaguing a large number of settlement pages. Zackmann (Talk to me/What I been doing) 05:40, 31 December 2025 (UTC)[reply]
I don't like the idea of this. It seems like if you specify "display=title" explicitly then you want the coordinates not to display inline and that wish should be respected. But if another admin feels differently they are welcome to deploy. * Pppery * it has begun... 16:25, 1 January 2026 (UTC)[reply]
Coordinates
Map
Interactive map of Coordinates
@Pppery: That is totally valid. To be clear, this is to be used in a VERY specific use case in an Infobox which is demonstrated at right. Note how the coordinates field is blank just showing Coordinates:. That is the problem I am trying to address. If you have a different/better solution, I genuinely would love it. This is just the best way I could think of to solve the issue... --Zackmann (Talk to me/What I been doing) 21:58, 1 January 2026 (UTC)[reply]
User:Xaosflux as the protecting admin, could you please review this request? Zackmann (Talk to me/What I been doing) 00:23, 8 January 2026 (UTC)[reply]
@Zackmann08: Couldn't this be done by adding {{#if:{{{coordinates|}}}|other stuff}} to data29 of {{Infobox settlement}}? IIUC, the coord template expands before it gets parsed there, and so it should empty by the time it reaches this if statement. — hike395 (talk) 20:56, 11 January 2026 (UTC)[reply]
@Hike395: I'm not sure I follow. The coordinates param is not empty in the usecase I'm addressing. It is just setting the coords to be in the title, not to display inline so I don't see how that would work, but maybe I'm not following... Zackmann (Talk to me/What I been doing) 22:58, 11 January 2026 (UTC)[reply]
Oops, nm, I just tested it and it doesn't work. Instead, you could detect an inline coordinate template invocation like this:
{{#if:{{#invoke:string|match|s={{{coordinates|}}}|pattern="geo-inline"|ignore_errors=true|plain=true}}|some stuff}}
This will only show "some stuff" if |coordinates= has inline coordinates. — hike395 (talk) 23:25, 11 January 2026 (UTC)[reply]
So that is an interesting solution and I'm not opposed to it. But I wonder if it is a bandaid on the larger problem? Is that a temporary fix or the actual solution here. I'm not sure... Zackmann (Talk to me/What I been doing) 23:28, 11 January 2026 (UTC)[reply]
Side note, hike395 I want to test this out, but you've got another thing going in the {{Infobox settlement/sandbox}} at the moment with the image upright stuff... Let me know when that process is concluded and I'll experiment with this? Don't want to mess you up! Zackmann (Talk to me/What I been doing) 23:31, 11 January 2026 (UTC)[reply]
I agree with Pppery that forcing inline is not the correct solution, because it overrides what editors are expressing. We can make a general template {{If inline coordinates|coordinates|if true|if false}} and that would be a general solution for use in infoboxes. 03:31, 12 January 2026 (UTC)
icon Request withdrawn Zackmann (Talk to me/What I been doing) 04:03, 12 January 2026 (UTC)[reply]

Edit request 11 January 2026

[edit]

Please copy Module:Coordinates/sandbox to Module:Coordinates. See diff for the code changes.

The function coord2text is not protected against garbage inputs. See, for example, the third-to-the-last test case for coord2text. The "expected" box is a Lua error, which happens when |type=long is applied to a junk string.

I added checks in coordinates._coord2text() to return nil if something went wrong, then checked for nil in coordinates.coord2text() and returned a blank string on failures.

The tests pass for the sandbox (except where it fixes the Lua error, above).

Thanks for your attention! — hike395 (talk) 21:04, 11 January 2026 (UTC)[reply]

Why is this necessary? Why isn't producing an error the correct behavior when given garbage input? * Pppery * it has begun... 19:31, 13 January 2026 (UTC)[reply]
@Pppery: The current module does not produce an error for any non-longitude call to coord2text() with junk arguments. It produces an obscure Lua error if junk is passed into longitude. This is not consistent. Following the principle of least astonishment, I thought it would be better if longitude were consistent with the other parameters. If you want, we can raise a preview warning in coordinates.coord2text(), but I have been previously shouted at about putting technical preview warnings into articles themselves. — hike395 (talk) 21:21, 24 January 2026 (UTC)[reply]
Later --- usage of coord2text() from templates shows that coord2text isn't generally being used to create reader-visible text, but for logic within infoboxes. We could throw hard errors in all of these cases, but it might break infoboxes and be disruptive. I think silently failing at this point is a better option. — hike395 (talk) 21:30, 24 January 2026 (UTC)[reply]
In the proposed change, callers from modules will receive nil upon error, which is the standard method --- module callers can decide how to handle the nil case, or if they haven't thought about it, will generate an error in the calling module. The proposed edit thus improves error handling in this case. — hike395 (talk) 21:30, 24 January 2026 (UTC)[reply]
 Done * Pppery * it has begun... 20:36, 25 January 2026 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Module_talk:Coordinates&oldid=1334817729"