Talk:Wiki/Archive 13

This page includes archived discussions. Please use Talk:Wiki to start a new discussion.

New CAPTCHA on signup page

We've switched the CAPTCHA on Special:CreateAccount from hCaptcha to Cloudflare Turnstile, which does a better job of keeping out bots. [1] Please let one of the administrators or sysadmins know if you run into any problems creating an account. – Minh Nguyễn ^💬 22:59, 5 February 2026 (UTC)

Resolved: Mateusz Konieczny (talk) 07:27, 29 March 2026 (UTC)

New tools for wiki discussions

The operations team has installed the DiscussionTools extension. [2] This extension adds a number of little features to make discussions on this wiki much more intuitive:

• Start a new topic without leaving the talk page. A live preview shows you what you're about to post. The editor automatically signs your comment for you, so there's no need to correct others' comments with {{Unsigned}} anymore.
• Reply to a comment inline without leaving the talk page. The editor automatically figures out the correct level of indentation and alerts you if someone else has replied in the meantime. Find other participants to ping by typing @.
• Subscribe for notifications when someone comments on a section of a talk page. You no longer have to put the whole talk page and its article on your watchlist just to follow a specific discussion. A signature automatically becomes a permalink to an individual comment.

All these features work in the mobile skin and with the visual editor. If you prefer to talk the old-fashioned away, you can still click "edit source" like normal. DiscussionTools manipulates ordinary wikitext, so it may fail to hook into the page in some situations. The extension also comes with some special markup for enabling or disabling the features on a specific page. For example, some talk pages are "frozen" for historical reference only, while some pages in other namespaces like Proposal: have effectively turned into talk pages.

With the introduction of DiscussionTools, we're retiring the Convenient Discussions gadget that served as a stopgap, effective immediately. Although Convenient Discussions has many more features for power users, a recent security incident had us reconsider the decision to install it globally. If you prefer Convenient Discussions, you can still install it as a personal user script.

 – Minh Nguyễn ^💬 09:03, 26 March 2026 (UTC)

Resolved: Mateusz Konieczny (talk) 04:16, 10 April 2026 (UTC)

Incomplete display

Why only office=diplomatic + diplomatic=embassy is shown on banner on https://wiki.openstreetmap.org/wiki/Tag:diplomatic%3Ddelegation ?

Template parameter has full office=diplomatic + diplomatic=embassy + embassy=delegation

Mateusz Konieczny (talk) 04:16, 10 April 2026 (UTC)

Template:Turn_into_tag_link is limited to 2 args delimited by a single plus.

It's used Template:Deprecated_feature on line 27, wrapping the three mentioned tags. I don't know how it fares with the already "converted" tag-link format, seems redundant to me.

Maybe Template:Tag could do something intelligent which the turn tag into link template can use to disable itself? That's too advanced for me now.

I've simply substituted the + with + on that page as alternative – it's different, and not matched, thus remains, and the entite argument-string is kept.

That's kind of a hack though. And I think shouldn't be used in article namespace, nor be necessary for something like this.
–cyton (talk) 06:04, 10 April 2026 (UTC)

Now, you do not need to replace the + with + anymore. – The Template:Turn_into_tag_link should be updated or replaced by a lua module that is capable of handling all of the variations. Maybe I'll give it a try. Help is welcome! -- Chris2map (talk) 22:57, 10 April 2026 (UTC)

Just created Module:Turn into tag link to lift the restrictions of only 2 tags and the need of "+". Please tell if you encounter any (new) issue. --Chris2map (talk) 17:50, 8 May 2026 (UTC)

Resolved: These pages are not broken anymore Mateusz Konieczny (talk) 06:28, 11 April 2026 (UTC)

Run script to update links from map

1. In the community forum, I learned that the keys in this wiki, which are linked from the map, are defined in the following file:

https://github.com/openstreetmap/openstreetmap-website/blob/master/config/wiki_pages.yml [3]

Last updated of wiki_pages.yml was on March 19. Update is irregular.

2. Additionally, the links for some values likely originate from:

https://github.com/JOSM/tag2link/commits/master/taginfo.json

with the last monthly update of taginfo.json on December 21.

It would be helpful to update wiki_pages.yml as well. This can be accomplished by running the script found at:

https://github.com/openstreetmap/openstreetmap-website/blob/master/script/misc/update-wiki-pages [4]

Could someone kindly run this script? 99 tabazan (talk) 09:44, 8 January 2026 (UTC)

The files were unknown to me. – For what reason or purpose? --Chris2map (talk) 13:29, 8 January 2026 (UTC)

Habi had pointed me to https://community.openstreetmap.org/t/how-to-link-a-tag-from-osm-org-to-its-wiki-page/7324 where it's explained.

People regularly contribute to this wiki and this should benefit the Map. --99 tabazan (talk) 13:35, 8 January 2026 (UTC)

This scripts may be run only by system administrators. Please contact Firefishy. Something B (talk) 13:59, 8 January 2026 (UTC)

I wasn't aware of and thought it is updating automatically like the links displayed when you edit the map (iD editor). --Chris2map (talk) 14:27, 8 January 2026 (UTC)

Thanks for the input. I sent a message to Firefishy and started checking how it looks in iD editor (wasn't aware of the use there, it's a bit different). Also, I updated 2 links above, the github I linked before might not be the one that is actually used, but the files have the same age. --99 tabazan (talk) 22:23, 8 January 2026 (UTC)

That's just plain wrong. Everyone can run the script locally, create a pull request that includes the updated yml file, and have the updated wiki_pages.yml merged into openstreetmap-website. There's really no need to bother our sysadmin with such tasks. mmd (talk) 08:37, 10 January 2026 (UTC)

I will give it a try. --99 tabazan (talk) 13:05, 10 January 2026 (UTC)

I run the perl script .. it takes about 4 hours and generates the file. I edited that to limit the update to en (as I can't troubleshoot the others). Then I tried to upload it to github, but somehow got lost in their captchas (oddly more complicated than all the other steps). Is there another place I can save to it can be integrated? --99 tabazan (talk) 23:26, 10 January 2026 (UTC)

I have no idea what funny captchas Github has added for you (I don't see any of that here). Since there was a build failure that required code changes due to a new Turkish translation for highway=primary, I have added everything here https://github.com/openstreetmap/openstreetmap-website/pull/6696 mmd (talk) 21:24, 11 January 2026 (UTC)

Thanks. Hope we find a developer to merge.

The captcha puzzle is when creating an account (even after eventually getting a 6 of them right, it fails). Time for OSM to consider using another platform. --99 tabazan (talk) 21:44, 11 January 2026 (UTC)

The pull request was merged today, it might take some days until the next deployment of the website code. mmd (talk) 21:36, 12 January 2026 (UTC)

It's now active, thanks once more for this. Do you think we should mention it in the forum and ask people to check for any issues? --99 tabazan (talk) 09:25, 14 January 2026 (UTC)

Thanks! I think that would definitely be a good thing. Otherwise, I suspect most people won't even notice it. And that note would also emphasize that manual action is required for this. --Chris2map (talk) 07:16, 18 January 2026 (UTC)

I just noticed that my assumption above that the links on values get updated on a monthly basis was wrong. The file mentioned above [5] and [6] get updated on monthly basis with new formatter urls, but that doesn't have any effect on what's linked at the Map or on overpass (I checked some new ones in last month's update). Any idea what's needed? --99 tabazan (talk) 18:59, 22 January 2026 (UTC)

They need an update to point to the current version.

The Map is currently from 2025.7.21 (and updated yesterday [7] probably live soon) and Overpass on 2024.05.21 [8]. I asked simon04 to look into the later. --99 tabazan (talk) 21:50, 22 January 2026 (UTC)

The links on some of the values got updated yesterday. Thanks for that! --99 tabazan (talk) 21:45, 26 January 2026 (UTC)

Overpass was updated yesterday [9] and this is already live at https://tyrasd.github.io/overpass-turbo/ --99 tabazan (talk) 13:06, 29 January 2026 (UTC)

State of wiki_pages.yml: Last update 11 January 2026. (--Pablobm 26 January 2026) --Chris2map (talk) 21:23, 26 January 2026 (UTC)

Resolved: This/was mostly resolved. Thanks for the help.

• Links to this wiki were updated again this week.
• tag2link no longer updates monthly, but was updated earlier this month.
• overpass update is stuck/hasn't happened. It does have problems of another scale these weeks.

--99 tabazan (talk) 08:57, 21 May 2026 (UTC)

User template rewrite

I’ve proposed a rewrite of {{User}}, a very common template that links to the profiles of a given user on both the main site and this wiki. I’d appreciate feedback before swapping in the new implementation, as it comes with visual and functional changes that may be jarring to longtime users. – Minh Nguyễn ^💬 00:21, 5 November 2025 (UTC)

Any other opinions? --Chris2map (talk) 18:02, 8 January 2026 (UTC)

The template {{User}} has just been replaced by me with the rewrite. Please report if you have any trouble with it. --Chris2map (talk) 09:53, 22 February 2026 (UTC)

Resolved: --Chris2map (talk) 19:33, 31 May 2026 (UTC)

Standardizing thumbnail sizes

In the coming days, you may notice some minor changes to the sizes of thumbnails throughout the wiki. The Wikimedia Foundation's Product and Technology team has informed our sysadmins that they're considering blocking this wiki from their APIs due to poorly optimized use of Wikimedia Commons images. It would have the effect of disabling the vast majority of images here. To prevent this outcome, they've asked us to ensure that we only fetch thumbnails at common thumbnail sizes.

For example, Wikimedia's server was generating an image 240 pixels wide just for the infobox in "Winter sports". The page and any other feature description page now requests a more standard 250-pixel-wide image, making the infobox slightly wider. I made a similar change to {{Description}}, which appears on every key or tag description page, but you won't perceive the change because some CSS constrains the image horizontally.

While these templates account for a significant share of the images on the wiki, we have many more templates and directly embedded images to adjust. Image-heavy pages such as Map features and MUTCD/R are of particular interest. At some point, we may need someone to run a bot to fix the long tail of pages. Please keep an eye out for any broken page layouts as a result of these changes.

 – Minh Nguyễn ^💬 17:44, 4 February 2026 (UTC)

We need to look at map features templates generated from taglists for thumbnail sizes, although they aren’t as widely used as they would otherwise be because they’re generated from description pages instead of data items. There are also map features templates that were created by editing a copy of the English page instead of the recommended wrapper templates and some of them have their own odd-sized thumbnails. I’ve been fixing the ones that referred to the server-hogging {{Icon}} template by rewriting them as wrappers. Wynndale (talk) 13:21, 5 February 2026 (UTC)

Do I get it right that we should only use image sizes with following widths?

Current standard sizes in Wikimedia production: 20px, 40px, 60px, 120px, 250px, 330px, 500px, 960px, 1280px, 1920px, 3840px

So we can use all of these widths? --Chris2map (talk) 18:07, 5 February 2026 (UTC)

Taginfo / Taglist uses an image width of 100px. I suppose it is <img src="' + d.image.thumb_url_prefix + '100' + d.image.thumb_url_suffix + '"/> in https://taginfo.openstreetmap.org/js/taglists.js. How / Who can update it to 120px? --Chris2map (talk) 18:21, 5 February 2026 (UTC)

@Chris2map: Thank you for handling the map features templates. This was a top concern of Wikimedia's.

Yes, all of the standard widths are fine. To be clear, this constraint only affects images we're pulling from Wikimedia Commons. Locally uploaded images can be thumbnailed at whatever size we want. If it causes extra work generating the thumbnails, that's on us. I suspect that a nonstandard width here or there is fine (and mostly unavoidable for |upright images), but high-traffic, image-heavy pages should stick to the standard sizes to avoid a flood of images needing thumbnail generation at the same time.

I've opened a request for taginfo to update its hard-coded thumbnail size.

By the way, if anyone is suddenly seeing broken images on any page, try purging it.

 – Minh Nguyễn ^💬 20:03, 5 February 2026 (UTC)

Is there a way to find which pages are involved? Wynndale (talk) 19:14, 6 February 2026 (UTC)

@Wynndale: Not easily. Unfortunately we don't have a special page listing the pages with the most images on them. Technically a search for insource:/\|([135-9][0-9]|[24][1-9]|1[013-9][0-9]|12[1-9]|2[0-46-9][0-9]|25[1-9]|3[0-24-9][0-9]|33[0-9]|4[0-9]{2}|50[1-9]|5[1-9][0-9]|9[0-57-9][0-9]|96[0-9]|1[013-8][0-9]{2}|12[0-79][0-9]|128[1-9]|19[013-9][0-9]|192[1-9]|[24-9][0-9]{3}|3[0-79][0-9]{2}|38[0-35-9][0-9]|384[1-9])px/ would find a bunch, but it's much too complex for the search engine here. – Minh Nguyễn ^💬 03:45, 8 February 2026 (UTC)

We have updated several pages and templates now and I hope that brings an improvement. Is an effect already noticeable and reported? --Chris2map (talk) 17:24, 13 February 2026 (UTC)

@Chris2map: Yes, the WMF SREs have mentioned that the Map features changes particularly improved the situation. Unfortunately, I think we're going to keep seeing HTTP 429 errors, but that's probably a broader phenomenon beyond our wiki. – Minh Nguyễn ^💬 18:11, 24 February 2026 (UTC)

"but it's much too complex for the search engine" -> Can we not just look for span.mw-broken-media or pages containing typeof="mw:Error? I see two types of issues, one where the filename appears in red and one where it says "Error creating thumbnail". Both have a span with this class and typeof with this value. Not sure which one would be more specific to this problem Lucgm (talk) 06:44, 12 April 2026 (UTC)

If I click on an image to see a larger version, I frequently get errors. Is this the same problem? Can it be fixed or do we need to save images locally? --99 tabazan (talk) 20:15, 24 February 2026 (UTC)

MediaWiki 1.44 includes a new pair of $wgThumbnailSteps and $wgThumbnailStepsRatio settings that let you configure image widths in bucketed steps. When these settings are set to $wgThumbnailSteps = [20, 40, 60, 120, 250, 330, 500, 960, 1280, 1920, 3840]; and $wgThumbnailStepsRatio = 1; your MediaWiki should emit HTML that puts whatever width and height is appropriate on generated <img/> tags while also selecting the exact match or next largest width from the step sizes for the image requested from upload.wikimedia.org. This is what has been done for the Wikimedia project wikis to align requested thumb sizes with the newly enacted rate limits. It looks like y'all will need to upgrade MediaWiki to get that functionality, but it might be worth trying. --BryanDavis (talk) 23:19, 4 March 2026 (UTC)

Thanks for that information! That sounds quite crucial.

I have noticed today that most of the images from Commons are no longer being displayed at all, at least on my end. This is a huge disruption to the Wiki. Therefore, we need to find a solution quickly. --Chris2map (talk) 19:30, 6 March 2026 (UTC)

https://wiki.openstreetmap.org/wiki/File:Logo_rijksoverheid.svg was mirroring https://commons.wikimedia.org/wiki/File:Logo_rijksoverheid.svg from Wikimedia Commons, but this image file has now completely disappeared from our wiki. Is embedding images from Commons completely broken now, regardless of thumbnail size? JeroenvanderGun (talk) 17:35, 17 April 2026 (UTC)

Right now, there are load blocking and caching issues. The images appear and disappear intermittently. It's still a mess. I hope this will calm down after some time and adjusting the sizes and I'm still hopeful that everything will be working again before too long. -- Chris2map (talk) 17:47, 17 April 2026 (UTC)

There is a divergence between those specifications of the standard sizes from WikiMedia to that what only works: 40 and 120 px doesn't work any longer. But 30 and 100 does work! What goes wrong? For now, 10, 20, 30, 60, 100, 250 px (and maybe bigger) is working, rest is broken --Chris2map (talk) 07:31, 7 March 2026 (UTC)

Tracking these suggestions (and a potential upgrade) in the operations repository. – Minh Nguyễn ^💬 23:40, 8 March 2026 (UTC)

I suppose that (about {{User JOSM}} and similar template) we can resize the logos from 43px to 40px without stressing the Wikimedia Commons servers. This is not the best solution, but reduces the work in the Commons servers. Galessandroni (talk) 16:45, 7 March 2026 (UTC)

I'm not sure what's wrong, but images from Commons are frequently breaking on this wiki right now. Even images referenced in templates like Template:KeyDescription which I assume have been updated (example page: Key:tactile_paving), and images included with thumbnail size 330px.

Should I go back to uploading photos for OSM wiki use to this wiki, rather than to Wikimedia Commons? It kinda sucks if I can't depend on Wikimedia Commons to load in my own images. --Jarek (talk) 01:15, 8 March 2026 (UTC)

@Jarek: We can't depend on Wikimedia Commons to load images at arbitrary resolutions, but our problems with not reviewed licensing statuses are far worse. I would still recommend Wikimedia Commons Mateusz Konieczny (talk) 08:23, 8 March 2026 (UTC)

Which images are failing for you on Key:tactile_paving ? Mateusz Konieczny (talk) 08:24, 8 March 2026 (UTC)

"By the way, if anyone is suddenly seeing broken images on any page, try purging it." seems relevant here - for me few pages were broken but purging (I do it by going into edit mode, not changing anything and saving) makes it work again Mateusz Konieczny (talk) 08:32, 8 March 2026 (UTC)

Subjectively, most pages I open appear to be broken currently (maybe I only notice the erroring bits). E.g. just now I opened Tag:highway=track and DE:Tag:highway=track and both have an error message in place of their primary image in the right infobox. My cache had a version of the English page from 24 days ago where it shows everything still worked (also some images down the page), but of course upon opening any not-recently-updated page, it lazily fetches the page again and the cached version also gets broken so it's a bit hard to use as reference/diff.

I just found this Talk page and tried the suggestion of purging this page, but this breaks it slightly further: the infobox used to say under "Beschreibung" (description) "Feldweg/Waldweg (Wirtschaftsweg) PENCIL Error creating thumbnail:" with a pencil icon in place of "PENCIL". After purging, the icon is also broken and it says "Feldweg/Waldweg (Wirtschaftsweg) Error creating thumbnail: Error creating thumbnail:". Also several minutes later, or when reloading the page with Ctrl+F5, it does not seem to resolve itself.

Not sure I fully understand the thread / solution. Should we manually configure an appropriate image size for every image that's broken on the OSM wiki?

Lucgm (talk) 06:38, 12 April 2026 (UTC)

Currently, the same issues for me. Also with other pages. I don't know what WCommons is doing. Maybe our IP addresses are blocked temporarily for requesting too many thumbnails. Should be working again after "some" (more) time. -- Chris2map (talk) 06:58, 12 April 2026 (UTC)

Right now, all the images from WCommons have disappeared for me. All of them, big and small, on every page — even the ones with the standard sizes. — ? --Chris2map (talk) 09:01, 12 April 2026 (UTC)

@Chris2map: There are probably clues in phab:T414805. They're still tightening the screws further, most recently by blocking requests for thumbnails that already exist on their side if the thumbnail size is considered nonstandard. I wonder if even those blocked requests count toward some rate limit. Minh Nguyễn ^💬 16:39, 14 April 2026 (UTC)

Hi, I found phab:T402792#11792778, but I'm struggling to interpret that comment. Does it mean if any page on our wiki requests >1 non-standard thumbnail, our entire wiki will be blocked for 60 seconds? 😭 That would explain why every image on every page appears broken to me --Kylenz 11:34, 17 April 2026 (UTC)

@Kylenz: Yikes, you might be right. Then I hope [10] and phab:T423570 come through for us. Minh Nguyễn ^💬 08:07, 18 April 2026 (UTC)

If so, update to MediaWiki 1.44 is necessary, because if even all pages will be corrected, old revisions will refer to thumbnails with non-standard sizes, and someone can add (intentionally or accidentally) thumbnails with non-standard sizes. Something B (talk) 12:42, 18 April 2026 (UTC)

@Something B: That's what configuring thumbnail steps is supposed to address. It should now be the case that, even if you specify a nonstandard size in wikitext, the wiki will only request the next largest standard size. We thought we'd have to upgrade to MediaWiki 1.44 to take advantage of this feature, but it looks like they've backported it to 1.43. [11] Minh Nguyễn ^💬 19:03, 18 April 2026 (UTC)

@Mateusz Konieczny: @Firefishy suspects that purging is probably counterproductive because it bypasses our own cache for both successful and unsuccessful responses, leading to a roulette wheel effect compounded by our own long-lived cache expiry period. Minh Nguyễn ^💬 16:46, 14 April 2026 (UTC)

https://phabricator.wikimedia.org/T423570 claims that image problems should be no longer happening Mateusz Konieczny (talk) 06:44, 25 May 2026 (UTC)

Resolved: Marking as resolved Mateusz Konieczny (talk) 12:31, 7 June 2026 (UTC)

New data item properties

Resolved: Zimtschnecke (talk) 14:11, 29 March 2026 (UTC)

Hi. I proposed new wikibase properties at Talk:Data items but there was nearly no response. Should wikibase changes be proposed here instead? Zimtschnecke (talk) 10:19, 26 March 2026 (UTC)

No, though this request for comments is fine. This way anyone observing this page can take look there. But if people ignore it because they are not interested - or see no point in commenting as they agree with the current outcome and do not want to pile on, then posting it here would not help and further overload this page. Mateusz Konieczny (talk) 07:24, 29 March 2026 (UTC)

Taginfo links to country versions

With Template:ValueDescription, depending on the page language, different links to local versions for taginfo appear.

Is there a way to customize this for English? A link to the LU version may be of use even if the page is in English. Sample: Tag:addr:country=LU.

The same question arises with Template:KeyDescription --99 tabazan (talk) 19:16, 10 April 2026 (UTC)

You can specify the taginfo region links in tools section with parameter "taginfo-region", e.g. |taginfo-region = lu . -- Chris2map (talk) 21:23, 10 April 2026 (UTC)

Why it would be useful on Tag:addr:country=LU ? Mateusz Konieczny (talk) 06:29, 11 April 2026 (UTC)

In the case of addr:country=LU or similar, it's not so much about a specific country link as it is about hiding the specific English links taginfo · GB · IE (N+S) · IN · US that don't make sense here. -- Chris2map (talk) 06:57, 11 April 2026 (UTC)

Resolved: Much better now! Thanks. --99 tabazan (talk) 10:34, 11 May 2026 (UTC)

Proposal to enable multilingual default labels on data items

Moved to Talk:Data items#Multilingual default labels on data items.

Search for a relation

The wiki page Sv:Sverige/Vandringsleder/National trails mentions a pilgrimage trail Munkastigen and its parts do exist, e.g. part 1 is relation 3876477 3876477, showing that name. But when I visit the map and search for Munkastigen, it is not found. Only some streets are found that happen to have the same name. Is there another way to do this, so the pilgrimage trail can be found in search? LA2 (talk) 12:45, 20 April 2026 (UTC)

Nominatim ignores name=* in route relations because there is so much garbage in them. Wynndale (talk) 17:18, 20 April 2026 (UTC)

Thanks for the pointer to the long discussion in October 2023. You refer to "garbage" in the name tag, as does the discussion, but I don't see any examples of what that garbage looks like? If it is "name = road 17 from Berlin to Paris", I can understand that it is a problem that this gives false hits for Paris and Berlin, but this should be possible to filter out by the length of the name. In my case, the "name=Munkastigen etapp 1", which is quite minimalistic (etapp means stage). It could be reduced to "stage=1", since "name=Munkastigen" is already in the parent relation.

So how do we get back to something useful from where we are now?

For another trail name, "Bergslagsleden", a search does bring up a handful of hits, which are path segments that happen to have "name=Bergslagsleden", which should probably be removed, as this name really belongs to the relation and not to the individual segments. --LA2 (talk) 19:10, 20 April 2026 (UTC)

I had a similar concern: combining ways for a single-named street fails when assembled via a relation. A similar problem was fixed for waterways (for example, the Rhine river), which now exists as one discoverable relation.

Besides naming, there's ambiguity about which location to display a combined relation at. For the Rhine this led to debate because it was shown as located in Switzerland; it now appears located in Germany. Neither is ideal, but having the full river as a relation means we can find the entire feature without dynamically reassembling it each time.

Maintenance is also easier because multiple mappers more quickly notice and report missing segments.

From the discussion about Flüela Pass and searchable pass roads, I got the impression that the role of pass-road relations (distinct from the highest point) may not be fully understood by people implementing fixes. This gives fairly good results at other websites (see the comparison in that thread).

We probably just need a developer willing to implement the change; the necessary fixes look fairly straightforward. --99 tabazan (talk) 10:15, 23 April 2026 (UTC)

Noone is claiming this specific relation has bad name. Nominatim is not indexing relation names as overall large part of them is garbage, not because all are. BTW, public transport routes are still advised by this wiki to carry invalid fake names, so AFAIK it is hardly fixed. Mateusz Konieczny (talk) 12:25, 7 June 2026 (UTC)

I have updated wiki to stop recommending use of fake names in pages known to me. Doing it based on https://community.openstreetmap.org/t/removal-of-from-to-tags-in-routes-if-the-name-already-contains-the-values/138323/2 and other evidence of broad consensus. Hopefully noone will want me to waste time on a full blown proposal Mateusz Konieczny (talk) 12:49, 7 June 2026 (UTC)

See https://github.com/osm-search/Nominatim/issues/413 for a github issue. Once at least fake names in public transport routes are fixed it may make sense to reask for support there? Or maybe there is subset of relations that have no epidemic of bad names? Mateusz Konieczny (talk) 12:53, 7 June 2026 (UTC)

Actually, Nominatim does index some relations and that works quite well. You just need to find a useful type (likely avoid public transport) and submit the patch to add that. --99 tabazan (talk) 08:38, 8 June 2026 (UTC)

Resolved: Either way it is Nominatim-specific issue. https://github.com/osm-search/Nominatim/issues/413 is likely good thing to read if anyone is interested Mateusz Konieczny (talk) 09:21, 8 June 2026 (UTC)

Moving page Londonderry, Northern Ireland

Hello, I'm writing a request to move the page Londonderry, Northern Ireland to the empty page [[Derry]] .

Wikipedia uses the name Derry[12] when referring to the city and I believe we should observe a similar policy.

The current page is rather outdated anyway, it hasn't been updated in almost ten years and features no reference to the name Derry, not even once, despite being the name most commonly used by the locals.

The argument that Londonderry is the official name and thus there shouldn't be a move is also void, considering the page Hull exists, surely if the legal name matters more than the common name, that page should be called [[Kingston upon Hull]], which is rather ironic since that's what it's actually called on Wikipedia[13] Mooedlorre (talk) 17:46, 9 May 2026 (UTC)

Resolved: done

Something B (talk) 23:04, 9 May 2026 (UTC)