Module talk:Coordinates

Coordinates
Coordinates
Coordinates	45°11′30.0″N 67°17′0.2″W / 45.191667°N 67.283389°W
Location

Coordinates
Coordinates
Coordinates	45°11′30.0″N 67°17′0.2″W / 45.191667°N 67.283389°W
Location

Examples

https://geohack.toolforge.org/geohack.php?pagename=Module_talk:Coordinates&params=

Archives

Archive 1

Archive 2

This page has archives. Sections older than 365 days may be automatically archived by when more than 7 sections are present.

coordinsert feature broken

This edit by Izno (talk · contribs) has broken the |coordinsert feature. Go to a page like Didcot, and compare the coords link at the bottom of the infobox (inline) with the one in the indicator slot at the top of the page (title). The inline one has the query string parameter params=51.606_N_1.241_W_region:GB_type:city(26920) whereas the title one has only params=51.606_N_1.241_W_. This tells me that the |coordinsert feature is broken. It worked just fine yesterday, when both links had the same query string. --Redrose64 🌹 (talk) 10:59, 5 February 2022 (UTC)[reply]

I've reverted and can confirm that it worked yesterday (TemplateSandbox). I have no idea what's going on or why.

The revert is also because of MediaWiki talk:Vector-2022.css#Interface-protected edit request on 5 February 2022. Izno (talk) 21:10, 5 February 2022 (UTC)[reply]

Thank you --Redrose64 🌹 (talk) 00:12, 6 February 2022 (UTC)[reply]

Izno, it looks like the coordinsert does some really hacky string parsing, so I think that's why your last change didn't work.

What do you think about keeping the existing markup but also adding the indicator (e.g retain the existing function body in addition to the new code. We'd use a different ID e.g. #coordinates-indicator instead of #coordinates for the newly added code.

I think having a separate ID for the indicator version would be useful, and it could then be hidden in older skins such as Monobook if we find that there are problems displaying the indicator there.

What do you think?

An alternative approach would be to refactor that coordinsert code to be more prone to HTML change, but I've read through that a few times now and am none the wiser. Jdlrobson (talk) 22:44, 10 June 2022 (UTC)[reply]

Starting to look. Again. Izno (talk) 22:15, 26 June 2022 (UTC)[reply]

Alternatively, since there are only ideas here that have been tried before, coord2text and coordinsert could be changed so they require a single invoke, instead of two right now. That would allow them to be called prior to the indicator being made and work that way. The main issue with that I can see is that would require changing probably around a million pages from two invokes (one inside the other) to one invoke.

Another option with coordinsert is to either require display=inline or a plain=yes parameter in the inner invoke. In both cases the indicator would not be added and coordinsert would work just fine. The benefit here over the former suggestion is that it would require less edits. (anyway, I have an headache, so probably wont answer anything until monday)--Snævar (talk) 11:31, 1 July 2022 (UTC)[reply]

I have looked some this week and have some comments:

Basically, coordinsert is entirely incompatible with placing the coordinates in <indicator>, since the coordinates are inside a strip marker when the coordinserting module sees it. There is literally nothing to be done here which preserves the wikitext in various and sundry places as it exists today. The only way we can move to indicators without accepting a "loss of precision" in the title URL is to change the million or more pages using coordinsert via infobox to add the URL adjustments directly in the mainspace wikitext, essentially as Snævar suggests. The second suggestion, to warn/alert/require on use of display-only coords inside a coordinsert is something that could be done, but would not correct the issue of a mismatch between indicator and non-indicator versions, only alert editors that there is link with slightly more information about the place which probably should be displayed but isn't. And this likely results in a similar scale of edits.
Not being in the habit of favoring such mass changes, my preference is that we make the change here anyway, and choose not to care about this 'loss of precision' in the URL in title versions. Users are still directed to a Good Enough external location at the end of the day. Perhaps someone can enlighten as to the parameters' exact importance for the final maps provider. (I coincidentally have the opinion that we should move everything to Kartographer, but that's a different story and not particularly relevant here.)
Regarding the bad display, I think we just bear with "bad display" during the deployment, and caching, and etc. Just yank it all out of the relevant .css pages. But if someone would like to suggest appropriate CSS in the meantime, be my guest.

Not so much stalled as "I have lots of things I'm interested in and this one is a hack or three so it really needs some motivation and I need to gather my thoughts to boot about coordinsert since I've now looked at it". ;) Izno (talk) 06:19, 2 July 2022 (UTC)[reply]

It's nothing to do with "loss of precision" (and I don't know where that idea came from), because coordinsert does not alter the lat/long values in any way at all. It's about the mapping services that are offered - compare these two URIs:

The _region:GB_type:city in the second one is what coordinsert adds. Now try following the links - the first one has a not-very-accurate generic map in the right-hand half of the screen (which sometimes comes up as a completely blank grey rectangle), the second provides a number of useful mapping services instead. I am concerned that the intent is to force the less-useful one upon us. --Redrose64 🌹 (talk) 20:10, 2 July 2022 (UTC)[reply]

'loss of precision' referring to the added parameters. As I said, the URL in the title is more or less fine, even if less useful.

I gave my recommendation: accept the less useful title coordinate URL, and if desired, warn users for coordinsert cases that have no inline version displayed, such that at least there is one more useful URL displayed on the page somewhere. New Vector title coordinates display is broken currently and we get a complaint a week about it; I'm sure you can estimate how many complaints we'll get when New Vector goes live and title display isn't fixed by then. Izno (talk) 22:51, 2 July 2022 (UTC)[reply]

@Izno Is there a reason why you can't regenerate the <indicator> tag like what I did at Module:Sandbox/BrandonXLF/2? – BrandonXLF (talk) 23:52, 2 July 2022 (UTC)[reply]

If you think you can get that to work with any real sandbox rather than invoking the module twice, go for it. Izno (talk) 00:00, 3 July 2022 (UTC)[reply]

I got it working at Module:Coordinates/sandbox. See the example at the top of this page. {{#invoke:Coordinates/sandbox|coordinsert|{{Coord/sandbox|53.528|N|0.893|W|display=inline,title}}|region:GB|type:city}} --> 53°31′41″N 0°53′35″W / 53.528°N 0.893°W – BrandonXLF (talk) 00:42, 3 July 2022 (UTC)[reply]

Test all the way, like in Template:Infobox UK place/sandbox and arbitrary other page. Izno (talk) 00:54, 3 July 2022 (UTC)[reply]

I edited Template:Infobox UK place/sandbox and moved the infobox from Totnes to User:BrandonXLF/B and changed the call from {{coord}} to {{coord/sandbox}}. It's working as expected. – BrandonXLF (talk) 01:05, 3 July 2022 (UTC)[reply]

Way to go, that's one issue down. I think we should stick a :not(.mw-indicators) #coordinates or something in front of the current CSS definitions with the intent to remove all the skin-specific styles at a later date. It will display in a somewhat different place in old Vector, but in new Vector the indicators are on the same line as siteSub without any CSS needed. Izno (talk) 04:06, 3 July 2022 (UTC)[reply]

Thinking about this problem and this problem now. Increasingly leaves me feeling like the :not solution is better than changing what is emitted on this point. Izno (talk) 05:29, 3 July 2022 (UTC)[reply]

And also thinking about Module:Attached KML which references the ID. Izno (talk) 17:10, 7 July 2022 (UTC)[reply]

Module:Attached KML should also be updated to use an indicator to be consistent with this module.

For the first problem, #coordinates { display: none; } will still work. Even if the coordinate indicator is the only indicator, the indicator container element gets a height of 0 when the coordinate indicator is hidden and it takes up no space at all.

For the second problem, it doesn't look like the custom CSS rules add any position rules, so once the position rules are removed, the top rules will just stop working, leaving the coordinates in the default position, which is fine. – BrandonXLF (talk) 04:39, 8 July 2022 (UTC)[reply]

Outstanding problems for indicators

√ Verify the solution proposed by BrandonXLF
√ Fix Module:Attached KML see sandbox
We need to apply :not( .mw-indicator ) to the current #coordinates CSS statements of the various skins
The font size for coordinates in indicators seems pinned to 85% now. As already come with their own font-size definition, it seems this now makes them smaller than before in monobook and vector-legacy. I favour just dropping the font-size line, I think that the coord were plenty small to begin with.
√ Move skin styles into Module:Coordinates/styles.css see sandbox
- Timeless: Positioning of this is open question, as we can't easily pin to the right of it's container due to not being within a relative content container.
- Minerva: Keep hidden for now
- Monobook: Keep in same spot as original
- Vector Legacy: Keep in same spot as original
- Vector 2022: Get rid of the absolute positioning and just put it left of other indicators
Deploy Module:Attached KML/sandbox
Deploy new Module:Coordinates/styles.css
Deploy new Module:Coordinates

Did I miss anything ? —TheDJ (talk • contribs) 13:45, 28 July 2022 (UTC)[reply]

As I've suggested above, we should remove the skin CSS entirely after the job queue works through the million transclusions. I don't really think we need to preserve current looks, and if we do, there probably should be a new consensus discussion, because from what I can see, the current look is based on a discussion of "oh it looks nice" and not necessarily considering CSS expectations from today (see from 15 years ago) when we also did not have the indicator extension. This also puts it inline with e.g. Template:Sky and the other adjustments I've recently made to remove the dozen #coordinates users broadly (though I think I've said basically none were using it appropriately somewhere since they weren't coordinates). Izno (talk) 17:00, 28 July 2022 (UTC)[reply]

Shall we move all CSS styling into templatestyles first or last ? —TheDJ (talk • contribs) 18:14, 28 July 2022 (UTC)[reply]

Looked into Attached KML a bit. First of all; half the functionality is gone, because there used to be links to open the kml in bing and/or google, but neither of that works any longer. So the only thing placed in the #coordinates is really a label. And then WMA hooks into #coordinates and somehow finds the kml in the page. So i switched it to make use of indicator, but i still need the #coordinates because otherwise WMA can't hook into it. :( but that shouldn't really a blocker for us I think. At least after the skin css has been fixed as proposed. —TheDJ (talk • contribs) 19:35, 28 July 2022 (UTC)[reply]

If I understand @BrandonXLF's solution correctly, we copy the output of the title element generation and store it in an HTML comment in the generated page, so that coordinsert can then find that comment and use the same html to generate its own element right ? The comment is then stripped from the final HTML by the parser after the template expansion stage ? It's a bit wasteful in terms of generated bytes by the template (probably counts toward total template expansion limit), but since this is only once a page, i guess for now it will do. —TheDJ (talk • contribs) 19:48, 28 July 2022 (UTC)[reply]

Checked, indicators do not show in VEs preview, so we don't have to account that into the styling statements. —TheDJ (talk • contribs) 19:54, 28 July 2022 (UTC)[reply]

Have all of the technical options for this been explored, esp related to vector-2022? The general community should be able to pick what they think is best for the readers, and they won't really care how it is accomplished technically. Some people are already unhapppy about tech people pushing reader layout, especially about that go-to-another-project language control being so prominent. Ideally, I'd like to see a few options that are technically supportable that can reviewed by the community. — xaosflux ^Talk 13:28, 29 July 2022 (UTC)[reply]

I've been asked again what the progress on this is (none). My advice is that we should simply hide them altogether, until the community figures out what they want to do with coordinates. —TheDJ (talk • contribs) 15:00, 23 August 2022 (UTC)[reply]

@TheDJ: I like this checklist. (What's needed to decide on positioning in Timeless? Is that holding other things up?) @Xaosflux: this seems by far the cleanest solution + is used by other large wikipedias; the alternate solution used on eu.wp also seems to be causing them challenges).– SJ + 14:33, 29 April 2023 (UTC)[reply]

If you are referring to the suggestion to remove content that editors have specifically added to pages "...hide them altogether", I don't think that's a great idea without more input. Quite sure local editors won't be happy with that as a solution. — xaosflux ^Talk 16:20, 29 April 2023 (UTC)[reply]

@Xaosflux: certainly not! I mean the checklist that started this subsection, for tagging coords as indicators. – SJ + 02:45, 30 April 2023 (UTC)[reply]

Think I've said this before, but the main part that should get some community input is for vector-2022: where do you want to see these coordinates on a page. A couple of options with mockups should make for an easy poll. — xaosflux ^Talk 04:36, 30 April 2023 (UTC)[reply]

I'd say 'to the left of the other indicators, on the same line as the sitesub' which is what fr.wp and other Wikipedias do. I don't care particularly, just want to protect us from having overlapping geodata again. – SJ + 23:08, 30 April 2023 (UTC)[reply]

Yeah, I like how frwp does their coordinates. Galobtter (talk) 10:04, 1 May 2023 (UTC)[reply]

I revived the indicator change in the sandbox. Some changes were made to the css to ensure 100% similar positioning. CSS for original however is still in place. This means we can do the template change without making a CSS cache mess and we can postpone actual CSS rework to when this change settles. —TheDJ (talk • contribs) 09:36, 21 May 2023 (UTC)[reply]

The problem that I reported at 10:59, 5 February 2022 (UTC), which had been fixed, has returned again in the same form. --Redrose64 🌹 (talk) 19:22, 28 May 2023 (UTC)[reply]

@Redrose64 I added a new fix to the sandbox. I also added testcases to cover the issue, although they need to be checked manually. – BrandonXLF (talk) 23:59, 28 May 2023 (UTC)[reply]

Thank you The live module is now working as expected. --Redrose64 🌹 (talk) 19:40, 5 June 2023 (UTC)[reply]

Coord2text

I would like to call the function coord2text from another module. Can I make this change? — Martin (MSGJ · talk) 11:02, 22 May 2023 (UTC)[reply]

Seems like pretty straightforward change. —TheDJ (talk • contribs) 13:04, 22 May 2023 (UTC)[reply]

What purpose is there to being able to call that function in another module? Izno (talk) 21:45, 24 May 2023 (UTC)[reply]

I am using it to parse wikitext to extract coordinates which can then be imported into wikidata - want more details? — Martin (MSGJ · talk) 21:50, 24 May 2023 (UTC)[reply]

That's cool, but how is that useful onwiki? I can't see how that would be useful here. And I mean that in the sense of "what are you even doing" and not "oh, Wikidata, go away". :P Izno (talk) 22:07, 24 May 2023 (UTC)[reply]

I see I've aroused your curiosity :) I am reading a page like this and outputting a page like this which can then be pasted into QuickStatements to quickly import data into Wikidata — Martin (MSGJ · talk) 21:51, 27 May 2023 (UTC)[reply]

Protected edit request on 24 May 2023

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Please revert to the previous version, per the above "Lua errors" discussion. Something in the most recent change appears to have broken the coord template's ability to accept |display=title, at least in some circumstances, leaving big red error messages in 100+ previously working articles. Since a fix has not been forthcoming, the module change should be reverted until the problem can be fixed in the sandbox. – Jonesey95 (talk) 03:43, 24 May 2023 (UTC)[reply]

Per our discussion at #LDS temples above, I agree that something needs to happen soon to remove those problems but I would like to see that there is a reasonable way to debug the situation if the module change is reverted. I've just spent 20 minutes staring at the changes. There are several good style fixes (that is, improvements to the Lua style of arranging the code) and only a couple of significant changes which I haven't yet digested. Johnuniq (talk) 04:06, 24 May 2023 (UTC)[reply]

I don't know enough about this module and Module:Mapframe to understand what is going on. Some poking around shows that the problem (Module:Mapframe at line 384...lat_d is nil) is due to the coords parameter which function util.parseCoords receives. Instead of being coordinates that it can parse, parseCoords receives an "indicator" strip marker and a category. That's because the new function displaytitle in Module:Coordinates puts the coordinates in an indicator although I don't know how Module:Mapframe gets that as its parameter. Something like the gsub code at function coordinates.coordinsert in Module:Coordinates is needed, somewhere. Johnuniq (talk) 05:06, 24 May 2023 (UTC)[reply]

WOSlinker's amazing edit (see 06:38, 24 May 2023 above) has fixed the problems so I disabled the edit request. The current list of articles with script errors shows six titles and none of them seem related to coordinates. Johnuniq (talk) 07:34, 24 May 2023 (UTC)[reply]

Groan. Now that I look more carefully, I see there are three problems:

These need investigation. Johnuniq (talk) 07:37, 24 May 2023 (UTC)[reply]

The first one uses {{WikidataCoord}}, which sets |display=title by default. I suspect that there are more articles with errors out there, but the job queue hasn't refreshed them so that they appear in the error category. Again, I recommend reverting the most recent change until this problem is fixed. Is there a downside to going back to the previous stable version? – Jonesey95 (talk) 14:44, 24 May 2023 (UTC)[reply]

@Jon (WMF) and @TheDJ for the above.

The two changes made to this module and to Module:Attached KML help fix the issue where the other icons near the coordinates (such as featured article icon) collide with the coordinates using the Vector 2022 skin. This is detailed at T281974. Reverting this change would cause the collision again on the skin used by most readers (being the default skin). IMO the previous state was not a great look, especially on the featured article for the day I made the edits where the coordinate text collided with the featured article star and was not centred with it.

Ideally I'd like to see the remaining templates be fixed as the errors are seen, especially as this would require reverting the changes here and also to Module:Attached KML. Plus the other changes to modules to support the changes here might have to be reverted. From what I can tell the three examples are now fixed based on the page history. Dreamy Jazz ^{talk to me | my contributions} 17:30, 24 May 2023 (UTC)[reply]

Sigh. Yes, I fixed those issues. But this edit has been objected to multiple times so should still be reverted, and I find the fait accompli WOSlinker did of adding inline coordinates to thousands of articles to work around the problem inappropriate. * Pppery * _{it has begun...} 18:48, 24 May 2023 (UTC)[reply]

I've made an edit to the sandbox (Module:Coordinates/sandbox and Module:Coordinates/sandbox/styles.css) with a version that fixes the Lua errors. The only downside is that it sends some more HTML to clients, but that isn't a big concern since there's only at most one coordinate with display title per page.

Code:

{{Infobox bridge
| coordinates = {{coord|45|11|30.0|N|67|17|0.2|W|type:landmark|display=title}}
}}

Current:

Fixed:

– BrandonXLF (talk) 19:45, 24 May 2023 (UTC)[reply]

Done I've made the fix Brandon suggested. Izno (talk) 21:33, 24 May 2023 (UTC)[reply]

Thanks for doing that. Hopefully this addresses the remaining issues. If there are future issues that need fixing, please feel free to ping me. Dreamy Jazz ^{talk to me | my contributions} 21:39, 24 May 2023 (UTC)[reply]

@Izno I make a few adjustments to the sandbox code, would you be able to add them? – BrandonXLF (talk) 22:23, 24 May 2023 (UTC)[reply]

Done Izno (talk) 22:52, 24 May 2023 (UTC)[reply]

Thanks all! Jon (WMF) (talk) 04:48, 25 May 2023 (UTC)[reply]

Three more:

Johnuniq (talk) 08:57, 26 May 2023 (UTC)[reply]

These might be pre existing issues. The templates specify coordinates without making use of template coord, but also without specifying NSWE, which is a format that module:mapframe’s parseCoord does not seem to be able to handle ? —TheDJ (talk • contribs) 11:24, 26 May 2023 (UTC)[reply]

Those were GIGO problems. They should have been using {{coord}}, and two of the articles had duplicate coordinates. – Jonesey95 (talk) 13:23, 26 May 2023 (UTC)[reply]

Thanks, it's all good now. Johnuniq (talk) 00:33, 27 May 2023 (UTC)[reply]

Protected edit request on 29 May 2023

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Copy the code from Module:Coordinates/sandbox to the main module. I adjusted the code so coordinsert works properly with the indicator in the title. The only difference to the output is that inline coordinates are now wrapped in a <span class="geo-inline">...</span> tag, but I don't see anywhere where this would be an issue. I also added some manual testcases for when display=title and when display=inline title to verify the changes. The difference between the sandbox and module can be seen here. – BrandonXLF (talk) 19:41, 29 May 2023 (UTC)[reply]

Done also made the change to coord2text noted above — Martin (MSGJ · talk) 15:00, 5 June 2023 (UTC)[reply]

@BrandonXLF and MSGJ: based on timing, it appears that this change has broken page previews. For instance, hovering over Free City of Danzig shows just the coordinates, rather than the beginning of the article as it should. I haven't looked too closely to see whether this is a bug in the module or page previews, but you ought to consider reverting. Vahurzpu (talk) 03:15, 6 June 2023 (UTC)[reply]

This needs to be done, but I favor leaving it as is for a short period to allow debugging. Johnuniq (talk) 03:54, 6 June 2023 (UTC)[reply]

I'm trying to find the documentation to see what popups needs. It starts at mw:Page previews but I don't think there is anything relevant there apart from the link to the implementation at mw:Special:MyLanguage/Extension:Popups. That has a FAQ with two items reproduced below without the links.

How can I remove content from a page preview? Any element marked with the noexcerpt class will be stripped from the summary.
Where do summaries come from? These are provided by the summary REST API or the TextExtracts API in case your wiki is using the default mwApiPlain gateway.

Some investigation might show why the new coordinates code is messing up the popup preview or how it can be fixed. BrandonXLF is not active at the moment but I'm pinging to alert them. Johnuniq (talk) 03:54, 6 June 2023 (UTC)[reply]

Strangely, hovering over Tokyo shows a proper popup. A lot of other location links on that page also work. Some examples where the popup does not work (it shows the coordinates) are Australia (continent) and Regional Representative Council and United Arab Emirates, as reported at Template talk:Coord#Preview page broken. Johnuniq (talk) 05:05, 6 June 2023 (UTC)[reply]

The three listed pages have their coords templates defined outside the infobox. None of them are defined with inline accordingly.

I don't know why that matters, but that's the obvious pattern. Izno (talk) 05:32, 6 June 2023 (UTC)[reply]

This smells like phab:T334273: because the inline text is hidden via TemplateStyles, and the extracts module doesn't care about TemplateStyles, it decides the text that is being dumped out in the geo-inline is Good Enough. It doesn't have an issue with infobox things because it already yanks all of that before consideration of what it thinks the first paragraph should be.

As you can see, I've already argued that this is a flawed expectation for how TemplateStyles should interact with TextExtracts.

We can probably work around this locally by adding the noexcerpt class. Izno (talk) 05:39, 6 June 2023 (UTC)[reply]

Independently of workarounds, this looks to me like a parsing bug, so I filed T338204 to report it to the maintainers. --JCrespo (WMF) (talk) 07:44, 6 June 2023 (UTC)[reply]

Also sounds like we are prepending something instead of the safer option of appending ? —TheDJ (talk • contribs) 08:28, 6 June 2023 (UTC)[reply]

No? Izno (talk) 16:59, 6 June 2023 (UTC)[reply]

After the recent edit to Module:Coordinates and an low-substance edit on Australia (continent) the coordinates no longer appear. The REST endpoint is still picking up the empty p and newlines: extract: "\n\n"; extract_html: "<p>\n\n</p>". Yes, I think it was changing it from a div to a span that did this particular line in. I think we can fix this by changing the hidden inline back to a div and then doing a second passover looking for a div in coordinsert, or changing the regex to be a bit more greedy at the beginning by removing its dependence on the tag. Izno (talk) 17:12, 6 June 2023 (UTC)[reply]

Protected edit request on 28 September 2023

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Add a format=dec4 function to output decimal degrees rounded to four places from data entered as either DMS or higher precision DEC format. The Canadian Geographical Names Database, Geographic Names Information System, and Ordinance Survey provide location information with seven decimal degrees of precision. The dec4 format will permit the input data to be checked with the original data source while displaying the more reasonable and compact four decimal degrees of precision (+/- 10 m). Buaidh talk e-mail 21:57, 28 September 2023 (UTC)[reply]

Not done This is a repost of Module talk:Coordinates/Archive 2#Protected edit request on 14 September 2022, which was closed as needing to be sandboxed and tested. We're a year and two weeks later, and this still hasn't AFAICS been sandboxed and tested. * Pppery * _{it has begun...} 22:16, 28 September 2023 (UTC)[reply]

Interface-protected edit request 27 December 2023

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

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]

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

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?

@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]