Talk:Wiki

Intro

This is the Wiki discussion area.

• If you have ideas for the wiki, you can generally just do them, by editing the wiki! In general we would encourage you to be bold, though it may be worth discussing big restructuring.

• If you have ideas for technical improvements to the way the wiki works, e.g. extensions we should install, you might add them here. There's a follow-up on Wiki:Requested extensions.
  For adding extensions, once discussed and consensus is present, a wiki admin should be requested to add the suggestion as an issue to openstreetmap/operations/issues/ ^GitHub.

• If you have any request that needs administrators attention, see Wiki:Requests for administrator attention.

---

Archive

Older requests can be found in archives, see yellow box on the right side.

Technical issues

Current and old issues for the wiki can be found on GitHub at openstreetmap/operations.

Signing on

For signing on on wiki with OSM account, see single sign on.

---

2025

Priority for 2025: a bot for updating data items

Unresolved

We have data items, which are extensions of articles about tags and keys. However, data items without a bot updating them are like a car without fuel.... Our, very few editors, waste time creating and updating data items manually, which is not cool and takes time they could spend on tasks the bot won't do. And the bot could easily update them very quickly.

So I would like to set the most important goal for this year: launch a bot that updates data items based on infoboxes and creates missing items based on new pages.

I tried to contact user:Yurik, operator of user:Yurikbot multiple times on 3 different channels, but I got no response, I don't even know if he read my messages.

So what can we do to push this issue forward:

1. Contact Yurik – Please have someone else try to contact Yurik and ask if he could run the bot. If not, could he share the bot's code so someone else can run it. I'm anxious to get any answer – maybe Yurik is busy with something else right now and doesn't want to return to the Wiki. But a "no" answer is better than no answer... Maybe I wrote to him on channels he doesn't read, so someone else can try through other channels or communicators.
2. If the first point fails, we can consider whether the code for Yurikbot, or a similar bot for data items is available somewhere.
3. In the worst case is the third point – to write the code of a bot that updates data items.

Such a bot wouldn't necessarily need to perform daily updates. Even a one-time or once-in-a-while update is better than none.

The categories in question:

• Category:Missing data item 2518 pages
• Category:Data item issues around 2000 pages without copied attributes

While the "Mismatched *" categories can be corrected by humans, there are many "Not copied *" categories with thousands of entries that could be emptied by a bot in one day, while it would take months for humans.

It doesn't have to be a difficult task, maybe someone will manage to contact Yurik and the matter will be solved.

I think that the lack of a bot to update data items stops our Wiki from developing. maro21 17:15, 9 January 2025 (UTC)

Hi, I'm still around - mostly on OSM-US Slack. The main issue with the data items is that it is really hard to keep data in two places when both places can be edited. I believe all information should be moved to the data items - and leave the tag cards use templates to show that data. That said, it would mean updating taginfo to also consume that information, rather than doing an error-prone wiki markup parsing. Running the bot to keep these things up to date is not really difficult - I simply lack time with all my other commitments, but I will try to find a bit of time this year. Note that if someone else wants to do it, I will be happy to teach how to run it - requires some basic python skills at most. --Yurik (talk) 17:24, 9 January 2025 (UTC)

Hi! Thanks for raising this topic. That would be quiet an improvement if we got further with the data items. I'm with Yurik regarding the use of the data items, the place for storing the info box / cards data. Double-entry bookkeeping is very ineffective here. One milestone is the switch for taginfo, to use the data items. – First of all we have to in fact copy all information from tag pages to data items. A big part of it is a bot job. I know practically nothing about Python. In the first step, I would definitely only copy what is missing, and not replace anything. And we should pay attention to what we can copy safely without having to manually revise or correct a lot of data afterwards. For example, with regard to inconsistencies between languages and outdated data. --Chris2map (talk) 14:05, 10 January 2025 (UTC)

Chris2map:

> Double-entry bookkeeping is very ineffective here

That's why I would like the running bot. Then a human edits English documentation page, and the next day the bot copies information to data items - no need to edit in two places. But let's talk only about the bot here, and about data items vs infboxes here. maro21 13:30, 11 January 2025 (UTC)

Yurik: Thanks for the quick reply:)

> that it is really hard to keep data in two places when both places can be edited

Not really hard. We have "Mismatched *" categories which we can monitor and we can easily correct. I do it everyday so these categories are usually empty.

The difficulty is to create data items manually with many properties.

As for keeping data in one place - we don't currently have community consensus to keep all data in data items, some people are in favor, some against. Let's just discuss about the bot here, and about data items vs infboxes here.

Is it enough to turn the bot on, or do you have to watch over it?

I have some knowledge in Python but I don't know if I can manage. I can't promise that I will succeed, but I want to try. You can send me the instructions and link to the code in a private message on osm.org. maro21 13:30, 11 January 2025 (UTC)

Priority for 2025: OSM logo license

Unresolved

I would like to see this issue sorted out this year. What is the license and authors of the most commonly used OSM-related image – the OSM logo?
File:Public-images-osm logo.svg
The author of this logo is known and entered, but there is still a template for the lack of a license, because this logo is a derivative work based on a previous logo, whose author cannot be determined.
File:OpenStreetMap-Logo.svg

We have several thousand derivative works based on this logo, some also with "unknown license" and some with wrong license and authors. It would be good to sort out the licensing of this logo.

This is not necessarily difficult to do, but it's important.

We can make a template where we put the author, or a blank space to enter the author, and one can add such a template to derivative works.

It's not only the license of this particular logo that is at issue, but the attribution of thousands of derivative works in which the author is not named, and authorship is attributed to people who have modified the original logo by merely inserting a different flag there, but without mentioning the original author.

I think the answer is already in the links below, so we just need to sort it out.

Previous discussions and links:

• (2009) User talk:Matt#Opencheesemap icon license?
• (2011) https://www.openstreetmap.org/user/Harry%20Wood/diary/12940
• (2021) File talk:Public-images-osm logo.svg
• (June 2022) "No urgency or concern about the copyright status of the logo"
• (June 2022) File talk:OpenStreetMap-Logo.svg
• (September 2022) Talk:Logos#History of the OpenStreetMap logo

To do:

1. determine the author of the first OSM logo
2. determine the license of the first OSM logo
3. determine the author of the current OSM logo
4. determine the license of the current OSM logo
5. determine and create a template to be added on derived works

Thank you in advance for your help. maro21 17:21, 9 January 2025 (UTC)

Also File:1000px-Logo BiH.png

Something B (talk) 10:15, 12 January 2025 (UTC)

Talk:Logos#History of the OpenStreetMap logo takes care of points 1–4. The original logo is by Matt Amos and either {{GPL}} or {{PD}} depending on whether you subscribe to the talk mailing list. [1][2] The current logo's license is definitively {{CC-BY-SA-3.0|Ken Vermette}} per the author and the OSMF. [3] – Minh Nguyễn ^💬 04:00, 21 March 2025 (UTC)

Deletion requests

Category:Labelled for deletion contains more 200 files, most without license and problematic in copyright sense, and it continues more than year. Something B (talk) 07:35, 10 January 2025 (UTC)

See also https://wiki.openstreetmap.org/wiki/Wiki:Requests_for_administrator_attention#Category:Labelled_for_deletion Mateusz Konieczny (talk) 06:53, 4 April 2025 (UTC)

The issue still actual now. Maybe we need additional administrators? Nakaner might be a good candidate. Something B (talk) 11:36, 3 November 2025 (UTC)

Thank you for the "nomination". I thought a couple of days about it and decided to accept it. --Nakaner (talk) 09:51, 10 November 2025 (UTC)

Yeah, Category:Labelled for deletion went down - but only by 120 entries in 17 months, with waiting image count increasing (from looking at https://wiki.openstreetmap.org/wiki/Wiki:Requests_for_administrator_attention#Category:Labelled_for_deletion ). I am looking at this category from time to time, but there is limit how much time I can justify spending on hobbies (and deleting pages on OSM Wiki is obviously not my sole or main one). Mateusz Konieczny (talk) 07:28, 11 November 2025 (UTC)

Category:Labelled for deletion/sorted is useful if you prefer to avoid looking at pages just nominated for deletion Mateusz Konieczny (talk) 07:20, 11 November 2025 (UTC)

330 categories, 204 articles and 229 images (763 in total) were there on 14 June 2024. Now, we have 29 November 2025 and we have 57 articles and 543 images (600 in total) Mateusz Konieczny (talk) 09:36, 29 November 2025 (UTC)

Clipboard Extension

I would be nice to have an extension to copy a text to clipboard. In particular, I miss an easy way to copy a tag text to the clipboard, but it may be also usefull for other purposes.

I have had good experiences with Clipboard4wiki on my own wiki. It's stable and really small. The syntax to be included into wikicode is: <clippy>waterway=river</clippy>. It adds a clipboard icon behind "waterway=river" and, when you click it, the text will be copied to clipboard. --HeiKue (talk) 11:35, 11 January 2025 (UTC)

I support. Why not? maro21 18:37, 24 January 2025 (UTC)

One more extension that needs to be maintained, can break or break other extensions or cause other issues Mateusz Konieczny (talk) 07:29, 11 November 2025 (UTC)

 Support --Chris2map (talk) 10:08, 25 January 2025 (UTC)

"I miss an easy way to copy a tag text to the clipboard" - why not use standard methods of text copying? Mateusz Konieczny (talk) 07:29, 11 November 2025 (UTC)

Help with translating descriptions

In the category Category:Mismatched description we have now 3000 pages in different languages.
Help is needed to correct these descriptions. Instructions on how to do this can be found in the description of this category.
If your language is on the list, please help correct the tag descriptions.

Arabic 1 Catalan 28 Czech 87 Danish 43 German 1136 Greek 11 Esperanto 2 Spanish 224 Persian 22 Finnish 8 French 416

Galician 3 Hebrew 1 Hungarian 16 Indonesian 1 Italian 88 Japanese 232 Korean 47 Nepali 1 Dutch 14 1 Norwegian 1 Occitan 1

Punjabi 2 Western Punjabi 1 Portuguese 233 Russian 290 Swedish 13 Turkish 3 Ukrainian 57 Vietnamese 1 Cantonese 3 Chinese simplified 32 Chinese traditional 5

If anyone has a problem with correcting the description of deprecated tags, write here. maro21 14:47, 8 March 2025 (UTC)

This just illustrates my point that we should stop maintaining two copies of descriptions, and switch to data items entirely, whatever the objections.
I spot-checked a random page from the list, and found out that the descriptions in NL:Tag:amenity=parking and Item:Q4904 differ... by the trailing full-spot. It took me a couple of minutes to hunt down the pages and the difference. Sorry, that's is not effective use of mine (or anyone's) time. There were objections that data items are difficult to watch, but those are dwarfed by the effort of bookkeeping needed to invest in lame tasks like this. Sorry, I'm not going to take part; someone should just program a bot to move everything from infoboxes to data items, and kill the former. Duja (talk) 12:10, 12 March 2025 (UTC)

This is a consequence of the lack of a bot, which previously copied descriptions to data items, and people only edited articles. A working bot would solve this issue. Articles + data items is a system that can only work properly with a working bot. Currently, we can't do what you propose anyway (i.e., removing infoboxes and relying on data items) because users added descriptions in different places - once in data items, once in articles. Removing only one would be disrespectful of someone's work. Besides, adding a description to a data item is perfectly correct, because at the time of adding the description there may not have been an article in that language (and this happens, for example, users add descriptions in Welsh, and there is no article in that language). And then there could have been an article, and another author could have added his description without knowing about the data item. maro21 15:47, 29 March 2025 (UTC)

I've fixed all the Italian pages with mismatched descriptions; I'd like to report that there are also pages which don't have any description except for the one in the Data Item (e.g. IT:Key:organic, FR:Tag:access=designated and DE:Tag:building=bridge); these pages look normal (they don't show the red pencil icon near the description) and don't belong to any useful hidden category but could pose a problem for those tools (e.g. Taginfo) that don't parse Data Items. I think I've found an easy way to find them by analysing the Taginfo SQLite database --Marcor (talk) 08:45, 15 March 2025 (UTC)

FYI, there is such a maintenance category for the main english namepace: Category:Pages loading description from data item. --Chris2map (talk) 09:17, 15 March 2025 (UTC)

Thanks, that is interesting; would be possible to extend it to other namespaces too? --Marcor (talk) 14:11, 15 March 2025 (UTC)

That would be possible. To me, the question is, should we extend manual maintenance, or will something move in matters of automated alignment of wiki pages and data items? I support switching to data items for the infobox content. For the easy start, I would like to have a bot that copies data from page to item (if an entry there is empty) and a bot that copies data from item to page (if an entry there is empty). I have no experience with bots. Someone has to take it! --Chris2map (talk) 14:34, 15 March 2025 (UTC)

I'm still waiting for a message or reaction from Yurik, but I haven't heard back from him after that. maro21 16:06, 29 March 2025 (UTC)

Yes, it's possible, however, I don't think it's necessary. The OSM Wiki is not here to adapt to Taginfo, it's Taginfo that should adapt to the Wiki if it wants to parse it. What is currently on Taginfo - that is: showing a list of different language versions and what statuses, descriptions and more they have - was created in the days when there were no data items and it was the only way to find discrepancies between articles in different languages. Nowadays it's not needed, because we have data items and tracking categories, and Taginfo tries to pretend that data items don't exist and cannot adjust to reality. Therefore, I think that the categories "Pages loading * from data item" for other languages won't be needed. maro21 16:03, 29 March 2025 (UTC)

Thank you Marcor! Yes, there are such cases as you mentioned and they are not included in this category. maro21 16:03, 29 March 2025 (UTC)

To those waiting for a bot (me included) and other co-workers: There is still manual work to do to align descriptions and this won't be possible to do by a bot, because you have to decide wether to go with the description from the page or the one from the data item, or mix or improve them. --Chris2map (talk) 08:22, 22 March 2025 (UTC)

I've started shortening the (huge) amount of Portuguese articles in this category. I find it actually fun and serves as an opportunity to also review the articles as a whole. Metapod (talk) 01:37, 7 January 2026 (UTC)

New Extension Request: SimpleTooltip

Can we please add the SimpleTooltip extension to the OSM wiki? It would enable "basic tooltips, supporting inline text and info icons" such as the following:

—Preceding unsigned comment added by GA Kevin (talk • contribs) 02:36, 20 March 2025‎ (UTC)

This looks like a fancier version of {{Abbr}} or a w:Template:Tooltip that we could import – or the built-in <ref> footnote syntax. At a glance, I don't see a strong reason for an extension, which would have some maintenance overhead. We could pull in the same Tooltipster library using a gadget and a template that invokes it. (Feel free to prototype one as a personal user script.) More broadly, footnotes would be a lot more usable with the Popups extension or the Navigation Popups or Reference Tooltips user script. – Minh Nguyễn ^💬 03:54, 21 March 2025 (UTC)

One more extension that needs to be maintained, can break or break other extensions or cause other issues... Is there a strong reason to have this one? What is use/benefit of "basic tooltips, supporting inline text and info icons" in improving Wiki? Mateusz Konieczny (talk) 07:31, 11 November 2025 (UTC)

JOSM screenshots with photos

• File:AgPifoJ-screenshot.jpg
• File:5.png, File:6.png, File:7.png, File:8.png

This screenshots contains photos without licenses and unknown origin. But it possible to create simular screenshot with free photo (CC0 is compatible with any version of GPL, CC-BY(-SA) 4.0 compatible with GPL version 3), and replace this ones. Disclaimer: I am not user of JOSM. Something B (talk) 10:21, 4 April 2025 (UTC)

Wait for User_talk:Michael Buege#File:6.png. --Chris2map (talk) 18:35, 27 November 2025 (UTC)

@Michael Buege: please help! Something B (talk) 18:37, 7 May 2026 (UTC)

All the images visible in these JOSM windows are (or were) georeferenced and are incorporated into JOSM to extract information.

Back in 2008, I was not aware that these images also required a licence. They no longer exist on my storage media. However, I can guarantee that these images were also taken by me and should be used under the most free licence possible.

Taking new screenshots will be difficult, as the data on the objects shown in the images probably no longer exists in the OSM database, which means the description of the mapping party could become somewhat inconsistent.

Looking ahead: how are such picture-in-picture scenarios handled, and where can I find out more about them or see some examples? Michael Buege (talk) 08:44, 9 May 2026 (UTC)

You can replace {{No license}} with {{CC0-self}}. Something B (talk) 10:02, 9 May 2026 (UTC)

OK, thank you.

Done. Michael Buege (talk) 10:30, 9 May 2026 (UTC)

Slippy map alignment

Did something change regarding inserting a slippy map? I am almost positive that the slippy map at the top of the Denmark page until recently was right aligned and also wrapped in text. Is there a way to get that layout back? --Lostmonkey (talk) 21:48, 2 May 2025 (UTC)

@Lostmonkey: This appears to be an upstream issue in the Kartographer extension that {{Slippymap}} relies on. Per phab:T314318#8439570, the ticket to watch would be phab:T318433. However, I don't know why the same wikitext and HTML output on the English Wikipedia results in a right-aligned map. Something to do with the new parser, I guess. Wrapping {{Slippymap}} in <div style="float: right;"> seems to do the trick, but it's less than ideal. – Minh Nguyễn ^💬 22:16, 2 May 2025 (UTC)

I can't remember which side the map was on, but there was a Mediawiki software update a week ago from version 1.39.12 to 1.43.1. I'm not sure if the extensions were also updated. You might look on https://www.mediawiki.org/wiki/Help:Extension:Kartographer to see if there are any settings that could be changed to make it the way you want it. However, I see that in the code there is |alignment= right, and yet it is not on the right. maro21 22:42, 3 May 2025 (UTC)

Yes, the problem is that Kartographer sets the tright CSS class, which has been removed from the Vector (2022) skin's global stylesheet. We could pretty trivially add it back into MediaWiki:Vector.css, but I'm not sure if there will be any side effects. – Minh Nguyễn ^💬 01:06, 5 May 2025 (UTC)

You can easily check it :). This is not an irreversible action :) maro21 20:49, 10 May 2025 (UTC)

@Maro21: What specifically would be needed to be done to check it? Mateusz Konieczny (talk) 05:26, 5 October 2025 (UTC)

Could we use TemplateStyles with {{Slippymap}} an define ".tright" in a Template:Slippymap/styles.css? --Chris2map (talk) 18:18, 26 May 2025 (UTC)

Do you know the style definitions that was set with class "tright"? --Chris2map (talk) 18:28, 5 November 2025 (UTC)

File:Coastline.jpg

File:Coastline.jpg (deleted 2025-10-06 by Chris2map)

Aerial image from Google Maps (© Digital Globe), used in article about PGS. Fair use is appropriate in this case? Something B (talk) 08:48, 12 June 2025 (UTC)

That is no aerial image. Do you mean ...1/2/3: File:Coastline1.jpg, File:Coastline2.jpg, and File:Coastline3.jpg? --Chris2map (talk) 19:51, 12 June 2025 (UTC)

Pardon, of course File:Coastline1.jpg and others. Something B (talk) 21:08, 12 June 2025 (UTC)

Note that decision whether we actually allow fair use was not exactly decided. Also, fair use does not apply here as it is replaceable and we do not need to use Google Maps specifically. Yes, it would be annoying to replace it. But for example fair use is more likely to apply in case of photo of no longer existing building (as new one cannot be taken) than for an accessible building (where you can get a new photo of it) Warning: I am not a lawyer. Mateusz Konieczny (talk) 08:41, 16 June 2025 (UTC)

The images and the use in the Wiki are from 2006. I think we could remove the images without losing relevant content from today's perspective. --Chris2map (talk) 11:53, 5 July 2025 (UTC)

I don't want to delete these 3 files on my own without more votes since they are in use and no simple photos. --Chris2map (talk) 16:05, 6 October 2025 (UTC)

Should we contact uploader for such files

There are some files like File:Dscf0297_600.jpg which can be easily replaced (and are in fact replaced), miss license or attribution - is it fine to just delete it?

Or should uploader be contacted?

What if uploader has talk page spammed with pile of such contact attempts?

Per https://wiki.openstreetmap.org/wiki/Talk:Wiki#Designing_policy_for_handling_files_without_clear_license suggestion was to notify uploader and wait few months for reaction But is it useful to do also in cases like this one?

Mateusz Konieczny (talk) 13:50, 11 August 2025 (UTC)

If no reaction, further attempts to contact not makes sense. Something B (talk) 20:11, 11 August 2025 (UTC)

I plan to start deleting such files. See File:Cement_Block.jpg for another example. If anyone thinks it is wrong, please protest Mateusz Konieczny (talk) 03:00, 4 October 2025 (UTC)

@Mateusz Konieczny: I've a question: If an image file is on a page among Special:PrefixIndex/User:Mateusz_Konieczny/notify_uploaders, has the uploader then been notified? --Chris2map (talk) 14:46, 4 October 2025 (UTC)

@Chris2map: not always - these are pages generated to review what is going on and to spot issues (for example if file is clearly OSM Carto map or red triangle then appropriate template can be added without bothering uploader - for example red triangle would get {{PD-shape}} Mateusz Konieczny (talk) 05:20, 5 October 2025 (UTC)

Wikimedia Commons has bot, which notifies uploaders when deletion is requested, so similar bot will be useful here, but doing it manually for inactive contributors is waste of time. Something B (talk) 12:19, 19 October 2025 (UTC)

I deleted File:Dscf0297_600.jpg - what about say File:Steps_bicycle_ramp.jpg and File:Steps4.jpg and File:Steps5.jpg ? User is inactive since 2018, was bothered by other files and has not responded. Is it fine to delete them or is it mandatory to contact uploader first? Files are more or less replaceable and currently unused Mateusz Konieczny (talk) 07:15, 11 November 2025 (UTC)

I think that it is fine to delete. Action from uploader isn't expected. Maybe uploader even died. Something B (talk) 08:13, 11 November 2025 (UTC)

User:Mateusz Konieczny/notify uploaders/Wulankhairunisa — user uploaded images from Mapillary without attribution or any link to track or image itself, and images not used. User isn't active. I propose to delete this image. If needed, new image can be uploaded, or images from Commons can be used instead. Something B (talk) 16:42, 12 November 2025 (UTC)

I started deletion of the files. --Chris2map (talk) 19:12, 27 November 2025 (UTC)

All files listed at User:Mateusz Konieczny/notify uploaders/Wulankhairunisa have been deleted, now. Uploader has not responded to notifications on his talk page or to previous deletions. --Chris2map (talk) 18:52, 15 January 2026 (UTC)

User:Higa4 — this user was contacted in 2022 regarding some files, did not respond (either on the talk page or actually fixing the issue) and was active in 2023. Something B (talk) 10:39, 17 November 2025 (UTC)

I guess there is agreement to delete such files? Where it can be documented? Note that when user responded before or was not asked about images they definitely should be asked! Mateusz Konieczny (talk) 23:23, 30 November 2025 (UTC)

Cnr:Map Features is broken

Cnr:Map Features is broken. "Lua error: Internal error: The interpreter has terminated with signal "24"." is displayed instead of {{Keylink}}, {{Valuelink}}, {{Tag}} and {{Icon}}. Something B (talk) 15:19, 8 September 2025 (UTC)

Some of the templates in this wiki use the {{Langcode}} template, which deduces the language from the page name if the language in the page information remains in English. In this case, Mediawiki doesn’t know about the cnr language code and the templates fail. Setting the language in the page properties to something other than English would fix this but it would have to be something other than cnr and there could be links to pages in whatever language was used. It is also possible to change {{Langcode}} to return another language code for Cnr: pages by adding |Cnr=whatever alongside |Key=en, or to adjust the templates you mentioned to catch this case. Wynndale (talk) 18:52, 8 September 2025 (UTC)

AFAIK, Module:OsmPageTitleParser can process "Cnr:". Would it be a solution to use Module:OsmPageTitleParser in Module:Langcode (or the same code, at least)? --Chris2map (talk) 16:04, 9 September 2025 (UTC)

No, {{Langcode}} working correctly, see Cnr:Sandbox. Something B (talk) 08:57, 10 September 2025 (UTC)

The issues are downstream from {{Langcode}}. Wynndale (talk) 09:04, 10 September 2025 (UTC)

{{Langcode}} returns cnr, see Cnr:Sandbox (prefix is the same), so problem is in other place. Something B (talk) 09:13, 10 September 2025 (UTC)

The page is running out of computational capacity mid-page, which can usually be eased by setting the page language correctly but Mediawiki doesn’t support Montenegrin. Also, much as the icon templates are more complicated than they need to be, any template without arguments is only evaluated once so gains are minimal. Wynndale (talk) 19:44, 10 September 2025 (UTC)

@Wynndale: "which can usually be eased by setting the page language correctly" - do you know why? Is it easier for template if some knob is tuned somewhere? Mateusz Konieczny (talk) 10:18, 29 November 2025 (UTC)

{{Langcode}} takes a shortcut if the language has been set to anything other than English in the page properties and returns that language; it parses the page title if the page properties remain set to English, which takes more work but is the only way to return a language code unknown to Mediawiki. Wynndale (talk) 21:45, 30 November 2025 (UTC)

@Wynndale: "but Mediawiki doesn’t support Montenegrin." - and I guess that issue for that sits for decades at some issue tracker already? Mateusz Konieczny (talk) 10:18, 29 November 2025 (UTC)

Mediawiki describes the process for adding language support at mw:Manual:Adding and removing languages. Wynndale (talk) 21:47, 30 November 2025 (UTC)

So, if I understood it correctly - someone would need to translate substantial part of base mediawiki interface Mateusz Konieczny (talk) 23:20, 30 November 2025 (UTC)

Seems to be a specific case of problem mentioned at Talk:Wiki#Too_complex_wiki_pages Mateusz Konieczny (talk) 10:18, 29 November 2025 (UTC)

License template for HIU image

Resolved: A fair amount of information has been added to the images and Wiki. --Chris2map (talk) 09:36, 9 May 2026 (UTC)

Please suggest license template for HIU images, such as File:Hiu basketball.png. Thanks. Something B (talk) 10:23, 23 October 2025 (UTC)

Is this from "U.S. Department of State, Humanitarian Information Unit"? https://state-hiu.github.io/ and https://d3netxer.github.io/Mapgive/ittc/ - Most of the other web addresses are no longer available. --Chris2map (talk) 12:57, 23 October 2025 (UTC)

From https://state-hiu.github.io: "Through ITTC, HIU publishes high-resolution commercial satellite imagery, licensed by the United States Government, in a web-based format that can be easily mapped by volunteers." So, this imagery not in a public domain and {{PD-USGov}} not applicable. Maybe fair use still applicable? Something B (talk) 10:04, 2 November 2025 (UTC)

@Something B: first step would be listing source of the image at its file. It is necessary no matter whether it is openly licensed, kept as fair use or in any other way Mateusz Konieczny (talk) 13:52, 3 November 2025 (UTC)

I agree, but uploader isn't active. Something B (talk) 14:54, 3 November 2025 (UTC)

In such case we may try notifying them, and if source is not found (which would enable confirming copyright status) we would need to delete it. (that is why ideally files would be uploaded to Wikimedia Commons - they have tooling and people there who would notice it short after upload) Mateusz Konieczny (talk) 15:38, 3 November 2025 (UTC)

In this case, uploader (Maning) was notified in December 2022 and still inactive. Something B (talk) 15:54, 3 November 2025 (UTC)

What I found: https://2017-2021.state.gov/filling-the-gaps-mapgive-imagery-services-enhance-humanitarian-mapping-to-assist-the-worlds-most-vulnerable-populations/ - but no license statement, reference to "open data" only, most of links and actual imagery source dead!? Probably from DigitalGlobe. --Chris2map (talk) 19:00, 12 November 2025 (UTC)

Some (if not all) images from HIU are replaceable, for example with File:Yonezawa Artificial Turf Fields.jpg. Something B (talk) 11:49, 14 November 2025 (UTC)

Hmm, I don't think it makes sense to replace the images with others, since it's about images of a specific event, or rather, the image material available at the location and time of the event (in terms of appearance and quality) for mapping. – Further research has revealed that the imagery was provided for HOT OSM under the "NextView" license from DigitalGlobe, see also Humanitarian Information Unit (HIU). --Chris2map (talk) 17:50, 14 November 2025 (UTC)

Rtfm cleanup (Deleting wiki pages about namespaced tags etc.)

I started to do some cleanup related to the contributions of permanently banned user User:Rtfm. He created lots of pages about namespaced tags and tried to forster their usage by adding them wherever they fit. Cleanup means that I created delete proposal for pages like Key:electronics:repair or Key:computer:parts. I also remove these tags if they are mentioned on other pages (example). I think that is more helpful than adding Template:Ambox to that pages and telling readers that they read disputed content.
A second great topic was tags related to tourism and motorcycles. I decided that we do not need another list of tags related to tourism and proposed its deletion.
Please let me know if you think that I remove/propose to remove too much content. --Nakaner (talk) 10:34, 3 November 2025 (UTC)

I think that tagfiddling should be reverted also in OpenStreetMap data. I hoped that DWG will have time for that but https://www.openstreetmap.org/user_blocks/18810 for now sits there with no other changes (though block itself is a great help). I am working on tool that would be able to help a bit with cleanup by detecting especially suspicious edits - let me now if anyone would want to get some to review (and potentially revert) Mateusz Konieczny (talk) 13:50, 3 November 2025 (UTC)

Is anyone interested in cleaning up OSM data? I prepared listing of likely bad edits, if anyone is interested I can share part (or entirety) of it Mateusz Konieczny (talk) 10:14, 29 November 2025 (UTC)

Did you check if your list contains edits which have been reverted by DWG yet? --Nakaner (talk) 10:41, 1 December 2025 (UTC)

During looking at his edits on the wiki and checking whether his invented tags are used by other mappers (that would a reason to keep the pages about those tags), I had the suspicion that some of his tags have been added to iD presets. This needs further investigation about the usage of these tags, the history and spatial distribution of their usage, and maybe a larger discussion of the community how to deal with those tags. This means, it will take some time. --Nakaner (talk) 10:41, 1 December 2025 (UTC)

If iD added any presets corresponding to Rtfm's writings, it would've been an ironic coincidence. None of the maintainers have been particularly fond of that user. – Minh Nguyễn ^💬 22:33, 22 January 2026 (UTC)

Files with "used with permission…" statement

File:Ago-tourism-toronto.jpg contains "used with permission" statement. So this file isn't free and cannot be used outside this wiki. License isn't clear anyway. This file should be kept? If so, how it should be attributed? Something B (talk) 13:38, 4 November 2025 (UTC)

If we knew the copyright holder of the photo I would plead to keep it with the following additions:

1. On the file page: "== {{int:license-header}} == {{Wflicence|type=problematic|icon=[[File:All rights reserved logo.svg|64px|©]]|text=All rights reserved. Tourism Toronto, The Toronto Convention and Visitors Association, https://www.destinationtoronto.com/}} <tt>Do not use this image without gaining permission from the copyright holder!<br/> This file is used in the Wiki at [[State of the Map 2015/Call for venues/Toronto, Canada]] with permission exclusively for the SotM 2015 Toronto bid.</tt>"
2. On the article page at the bottom: "© The images on this page are copyrighted and a courtesy of Tourism Toronto for the SotM 2015 Toronto bid."

Sadly it is not provided who owns the copyrights of the images on that page. It is only stated "toursim Toronto" which I don't think says much. The rights may belong to the respective photographers, or am I mistaken?

Anyway, I would not create a license template, but rather write the license box directly on the page, as this is an absolute special case and should not lead to misuse via a template. --Chris2map (talk) 17:26, 4 November 2025 (UTC)

Tourism Toronto is the former trading name of the Toronto Convention and Visitors Association, the city’s destination marketing agency. They’ve since rebranded as Destination Toronto. – Minh Nguyễn ^💬 00:17, 5 November 2025 (UTC)

Can we assume that the copyright belongs to them (Tourism Toronto, The Toronto Convention and Visitors Association)? --Chris2map (talk) 11:22, 8 November 2025 (UTC)

If even so, permission might be expired (SOTM Toronto has been ended), not applicable to wiki (limited to conference as such), given by person without necessary priveleges or informal ("you can use this photos, blah-blah"). So am in favor of deletion. Something B (talk) 23:06, 8 November 2025 (UTC)

I removed this image as unfree from that page in https://wiki.openstreetmap.org/w/index.php?title=State_of_the_Map_2015/Call_for_venues/Toronto,_Canada&diff=prev&oldid=2917556 Mateusz Konieczny (talk) 07:16, 11 November 2025 (UTC)

Asked on https://wiki.openstreetmap.org/wiki/User_talk:Rw#File%3AAgo-tourism-toronto.jpg (and deleted some files uploaded from that account where there were copyright issues) Mateusz Konieczny (talk) 10:13, 29 November 2025 (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)

Logos of routes

File:AmbergauRadwegLogo.png is complex logo, no evidence of free license, but perhaps fair use applies? Something B (talk) 08:37, 6 November 2025 (UTC)

Note we have not really decided whether we want to permit fair use images or not Mateusz Konieczny (talk) 18:27, 6 November 2025 (UTC)

This is quite a problem, and in the case of route symbols it's a real shame, as they are widely used. Removing them would be quite a clear-cut.

The similar applies to the images with permission like above from "Tourism Toronto".

I don't think "fair use" or "by permission" would be the problem in the Wiki use. We can add attribution and notice. The real issue is storing the image files and making them available to everyone. We can't rule out the possibility that someone might directly access the image files and use them in some way, rather than just viewing the wiki page where the images are being used fairly. Or am I misunderstanding something?

Or can we shift the responsibility away from the Wiki to the extent that if someone uses the image files, they alone have to take care of the license?

Would it make a difference if the images themselves contained a copyright notice? For example, the ©? --Chris2map (talk) 11:16, 8 November 2025 (UTC)

Specific permission "for OSM Wiki only" will be problem for reusing of the content, because it isn't accessible for reusers. Fair use should not be a problem, because it depends from scope and context, but if fair use really applies. Something B (talk) 13:14, 8 November 2025 (UTC)

Why would it cause any difference? Mateusz Konieczny (talk) 07:18, 11 November 2025 (UTC)

Because fair use not depends from distributor, but special permission given (as I guess) to definite project (OSM). Wikipedia not accept licenses "for Wikipedia only" for similar reasons. Something B (talk) 08:09, 11 November 2025 (UTC)

"fair use" applies in cases where material is copyrighted but it can be ignored anyway and used without any permission. "with permission" is a type of unfree licensing, typically for specific and limited, maybe time-bound purpose Mateusz Konieczny (talk) 09:24, 11 November 2025 (UTC)

@Something B: That and most of the other images on DE:Bicycle/Themenrouten und beschilderte Radrouten are clear copyright violations. (It doesn't matter whether there's a © symbol.) What's the purpose of including them on this page? Would mappers be unable to figure out which relation is which otherwise? I did a spot check and most of the images are already included in the German Wikipedia article linked from the corresponding route relation. None of them seem to be used as wiki:symbol=* images in the OSM database. [4] I'd support deleting them en masse. – Minh Nguyễn ^💬 22:31, 22 January 2026 (UTC)

Justification for fair use of these logos is weak, so mass deletion is simple and effective solution, if nobody opposes. Something B (talk) 20:41, 24 January 2026 (UTC)

Request for adminship: Nakaner

Nakaner is experienced and good faith contributor. Because current administrators don't have enough time, new administrator will not be redundant. Something B (talk) 10:03, 10 November 2025 (UTC)

Was accepted by Nakaner Mateusz Konieczny (talk) 07:37, 11 November 2025 (UTC)

@Nakaner: What actions you would take if you would be an administrator and encounter page that you nominated for deletion or you consider to be in need of deletion? How it would depend on a page contents? Mateusz Konieczny (talk) 07:37, 11 November 2025 (UTC)

@Mateusz Konieczny: If it is obviously spam, I (as a non-administrator) would replace its content by Template:Delete immediately. Otherwise I have been following the established rules for deletion: propose deletion first and wait at least one week for comments on the talk page. If nobody has disagreed on the talk page in the meantime, I remove the content from the page, and use Template:Delete. When I label a page for deletion, I remove all links pointing to it except on user pages, news collections and in meeting minutes.

If I were an administrator, I would continue to follow this two-step approach for non-spam content. I would delete pages I had labelled myself for deletion. I would not do it immediately after putting Template:Delete on them. Instead, I would wait some time (a few days to weeks) before I do final cleanup. This should give all opponents of a deletion a second chance they would loose if I would use my superior power as administrator immediately.

If I have the feeling the a deletion could be disputed, I reach out on Talk:Wiki (see the recent example about my plan to do a cleanup after User:Rtfm) or on the local forum if its seems appropriate (example).

A few minutes ago, I wrote down my motivation and a rough description how I decide about deletion vs. historic preservation. --Nakaner (talk) 13:41, 12 November 2025 (UTC)

Further support is definitely welcome, and with you (user Nakaner) we have someone who takes great care of the wiki, especially with regard to cleanup. Thanks for writing down your motivation. It helps me form an opinion on whether I should delete or not. I've followed your deletion proposals in the past, but I'm still undecided about how far I should go in pursuing them. I've found that there's a difference between requesting a deletion and carrying it out myself. At least, that's how it is for me. For example, in the images, the software pages, and the place pages. For a deletion, a community agreement should actually be there. But only a few individual users are even concerned with or interested in the topic. Perhaps we can also use this moment to further clarify what can or should be deleted and what cannot. If we had more clarity and agreement, I could and would take more action, e.g. regarding images. --Chris2map (talk) 17:52, 12 November 2025 (UTC)

I support Nakaner to be selected as an administrator on this wiki (though if deleting things nominated by myself for deletion, which is not clear case of spam/ban evasion/etc then I would rather wait weeks to months) Mateusz Konieczny (talk) 18:40, 26 November 2025 (UTC)

Modernising the citation system

It appears we now have the required extensions (Lua, TemplateStyles, etc.) to synchronise the citation templates (e.g. {{Cite web}}) with the English Wikipedia. I wish to ask who would be interested in the citation templates being synchronised with the English Wikipedia? By the way, we need to add TemplateSandbox so that we can test template changes without having to guess the impact of said changes. --ika-chan! (talk) 23:43, 18 November 2025 (UTC)

What do you mean with "TemplateSandbox"? Have a look at Template:Sandbox. --Chris2map (talk) 21:12, 19 November 2025 (UTC)

Sorry, I meant the extension that adds "Preview page with this template" when you edit the template so you can see how the changes to the template appear in any given page before actually committing the changes: to quote the description page, it "adds the ability to preview a page using sandboxed versions of templates, allowing for easy testing before making the sandbox code live". BTW the link in this section's OP has been fixed as the page is in the "Extension" namespace. --ika-chan! (talk) 08:03, 20 November 2025 (UTC)

Regarding the mw:Extension:TemplateSandbox: I would need to conduct a practical test to say how useful it is. But it can certainly be helpful.

Regarding the citation template: I think citations are far less important here in the wiki than on Wikipedia. Therefore, I wonder if we need such a large citation system. The question, of course, is what results in less maintenance in the long run: adopting everything from Wikipedia or just a small part. --Chris2map (talk) 17:36, 26 November 2025 (UTC)

@Ika-chan!: in my experience cite templates on Wikipedia are horrifically complex and add massive overhead. This may be useful when quoting complex sources, printed material or transient news pages, but none applies here. What exactly expected benefits would be? That would outweigh increased complexity and loss of readability of wikicode? Mateusz Konieczny (talk) 09:59, 29 November 2025 (UTC)

@Mateusz Konieczny: The current template cannot parse language codes (as in:

lang=el

to output "Greek", or

lang=el,en

to output "Greek and English"), and I thought that just syncing the citation templates with Wikipedia would be easier. Thankfully I ask, in case you have better ideas. --ika-chan! (talk) 18:28, 16 December 2025 (UTC)

What is benefit of that? Why it would be worth importing monumentally complex templates? If language needs to be specified you can just writ it Mateusz Konieczny (talk) 06:29, 17 December 2025 (UTC)

@Ika-chan!: Thank you for starting this discussion. The outdated citation templates have been a major annoyance for the OpenHistoricalMap project, which relies on source citations more heavily than OSM. (OHM project pages often include a bibliography of frequently cited sources.) {{Citation/core}} was broken for years until I finally figured out why amid the extremely complex template code. The Citation/CS1 modules are long and complex, but at least they're much more readable, less error-prone, and well-tested, and maintaining them can be mostly a matter of copy-pasting them from another wiki. While the English Wikipedia's Citation/CS1 modules could be a starting point, you might want to look at the Wikimedia Commons version in case it handles a multilingual wiki better than the Wikipedia version. – Minh Nguyễn ^💬 22:17, 22 January 2026 (UTC)

StyleInfo link in tag description box

Has anyone noticed the addition? Template:DescriptionLinks (Diff/2928891) – What do you think?
I have two questions, see Template_talk:Description#KeyDescription - Add the StyleInfo link.   --Chris2map (talk) 18:48, 18 December 2025 (UTC)

2026

"Upcoming events" section in mainpage

Original post on Talk: Main Page. As per Chris2map's suggestion I'm linking the discussion to this page to gather opinions on the issue. Main point is the events section is needlessly long and messes up main page's visual aspect and practicality. I suggest limiting the displayed entries either by amount or time frame. Additionaly and by implication we could think of ways to improve the https://osmcal.org/ website. Please provide your input. Metapod (talk) 01:23, 7 January 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 [5]

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 [6]

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 [7] and [8] 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 [9] probably live soon) and Overpass on 2024.05.21 [10]. 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 [11] 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)

OS OpenData StreetView

Please suggest attribution for File:OS OpenData StreetView.png. Thanks. Something B (talk) 20:09, 28 January 2026 (UTC)

Still accessible online: https://os.openstreetmap.org/#zoom=17&lat=52.294773&lon=-1.67161 choose "May 2012" - The footer says "Leaflet | Contains Ordnance Survey data © Crown copyright and database right 2012" --Chris2map (talk) 16:30, 29 January 2026 (UTC)

I cannot view recent changes

When I click on recent changes, I get the following error:

Internal error
[d6bf36eac79121d4148fac77] 2026-02-01 14:00:23: Fatal exception of type ‘TypeError’

Is this a general error or is it an error on my PC? --Jemily1 (talk) 14:05, 1 February 2026 (UTC)

No error for me, so far. Can you test it with another browser? --Chris2map (talk) 14:38, 1 February 2026 (UTC)

I am using Microsoft Edge on Windows 11. I tried logging out, and then I was able to see the recent changes. When I log back in, I can no longer see the recent changes. I tried using the Google Chrome browser and I have the same problem: I can only see recent changes in anonymous mode. --Jemily1 (talk) 14:57, 1 February 2026 (UTC)

@Jemily1: There seems to be an issue with the parameters in the URL.

1. https://wiki.openstreetmap.org/w/index.php?limit=100&days=7&enhanced=1&title=Special:RecentChanges&urlversion=2
2. https://wiki.openstreetmap.org/w/index.php?limit=100&days=7&enhanced=1&title=Special:RecentChanges
3. https://wiki.openstreetmap.org/w/index.php?title=Special:RecentChanges&limit=100&days=7&enhanced=1&urlversion=2
4. https://wiki.openstreetmap.org/w/index.php?title=Special:RecentChanges&limit=100&days=7&enhanced=1
5. https://wiki.openstreetmap.org/w/index.php?title=Special:RecentChanges&limit=100&days=7&enhanced=1&hidecategorization=1&hideWikibase=1&urlversion=2

Numbers 2, 4, and 5 work for me. 1 and 3 show an error. --Chris2map (talk) 17:14, 1 February 2026 (UTC)

@Chris2map: Only option number 5 works for me.
I also cannot see recent changes by clicking on the menu on the left. If I log out, I can see recent changes normally.--Jemily1 (talk) 08:54, 2 February 2026 (UTC)

Do you have any "Saved filters" ("Filtros guardados") in use on the recent changes page? Have you tried to delete your browser cache? --Chris2map (talk) 19:01, 2 February 2026 (UTC)

@Chris2map: I have cleared my browser cache, and I have also deleted the filters I had saved in recent changes. The problem persists. This only happens with the recent changes option. All other options in the left-hand menu work normally. Email notifications for the pages on my watchlist also work normally. --Jemily1 (talk) 04:13, 4 February 2026 (UTC)

I had problems with my watchlist, After I removed Key:subject from my watchlist, it worked again. --99 tabazan (talk) 10:02, 4 February 2026 (UTC)

This now happened with another page. I can still reproduce it by readding Key:subject to the watchlist. --99 tabazan (talk) 16:03, 18 February 2026 (UTC)

@Chris2map: Right now, I'm also getting an error when I click on my watch list:

[049e1e479c7a62a4675cb933] 2026-02-05 13:59:03: Serious exception of type ‘TypeError’

I'm still waiting for a response. --Jemily1 (talk) 14:02, 5 February 2026 (UTC)

Try to find which page is corrupted. Maybe it's sufficient to remove just Key:subject. Otherwise, you can edit the watchlist at Special:EditWatchlist/raw. Save it somewhere than remove half of it .. if it works again, add more, if it doesn't remove more. --99 tabazan (talk) 15:05, 5 February 2026 (UTC)

I'm neither an IT pro nor a MediaWiki programmer therefore I can only suggest what may be the failure, too. – "99 tabazan" could be on a right trace. A connection between "recent changes" and "watchlist" is plausible because the "recent changes" page highlights entries (bold type) which are on your watchlist. I suggest you to try to reduce or empty your watchlist temporarily, like "99 tabazan" wrote. Copy and save your watchlist entries first. I can't tell you anything else at the moment. --Chris2map (talk) 18:00, 5 February 2026 (UTC)

@Jemily1: Are you still affected by it? --Chris2map (talk) 17:26, 13 February 2026 (UTC)

Update 1

I can reproduce the issue, now: If you remove all filters from set to default and remove all parameters from the URL and open bare https://wiki.openstreetmap.org/wiki/Special:RecentChanges then the page doesn't load, instead the error message is displayed. @Jemily1: You can refresh the page (F5) then it should load with automatically add parameters to the URL. → But: The error doesn't occur (to me) and you could load the bare URL (such as the link in the main menu) if you deactivate the following option in your user special:preferences: → Tab: "Recent changes" → Advanced options: "Show data edits in recent changes" → deselect/deactivate it and "Save" → Reload the wiki page (Ctrl+F5).
It looks to me that this option causes the issue. In addition, this option seems not work. On other wikis it adds/activates the filter "Data item edits" to the recent changes list. Here it doesn't do anything, AFAICS. @Minh Nguyen: Do you know something about the option, how it should work? I saw your MediaWiki:Wikibase-rc-show-wikidata-pref. Could we disable and remove this option from the preferences? --Chris2map (talk) 11:43, 14 February 2026 (UTC)

I have just disabled the option "Show data edits in recent changes" on the page https://wiki.openstreetmap.org/wiki/Special:Preferences#mw-prefsection-rc and for now it seems that the option on the left-hand menu "recent changes" is working again.

Thank you for everything.--Jemily1 (talk) 15:16, 14 February 2026 (UTC)

You're welcome! --Chris2map (talk) 08:56, 15 February 2026 (UTC)

@Chris2map: I had customized MediaWiki:Wikibase-rc-show-wikidata-pref and some other messages to get rid of {{WBREPONAME}} as a workaround for a poor server configuration setting, which has since been fixed. However, I kept the overridden messages because they have better capitalization than "Data Items". – Minh Nguyễn ^💬 03:48, 15 February 2026 (UTC)

@Minh Nguyen: Thanks for the info! Did you intentionally left out the word "items" in the overridden message? – And does the preference option work for you? I haven't recognized function yet. In addition, the option seems to be related to the error with Recent Changes. --Chris2map (talk) 08:56, 15 February 2026 (UTC)

@Chris2map: I inserted "item". I can also reproduce the issue unless hideWikibase=1 appears in the URL parameters, as it does by default. This parameter corresponds to the "Data item edits" filter. I have a feeling the setting in preferences only applies in the non-enhanced (no JavaScript) recent changes interface. In any case, an error like this is out of the control of the administrators. This would be a valid bug report to the operations team. – Minh Nguyễn ^💬 23:44, 17 February 2026 (UTC)

@99 tabazan: I cannot confirm an issue in relation to the watchlist and the page Key:subject. At least, there is no error for me, neither with nor without that page on my watchlist. @Minh Nguyen: I checked the fact of the non-enhanced (no JavaScript) recent changes interface: If I toggle off the JavaScript option for Recent Changes or if I have it on does make no difference for me regarding the error message from recent changes. For me it seems to be that only the setting "Show data item edits in recent changes" leads to the error, either in JavaScript mode or in non-JavaScript mode. If this option is on then error, if it is off then no error. Except there is the parameter "hideWikibase=1" in the URL; then it works regardless of the settings. – I'm going to report it to the operations team. (/operations/issues/1333) --Chris2map (talk) 17:34, 18 February 2026 (UTC)

Actually, the error goes away when I uncheck "Show data item edits in your watchlist" in preferences. --99 tabazan (talk) 19:04, 18 February 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 [12] 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. [13] 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)

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. [14] 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)

Taginfo and spaces (" ") in tags (not "_" or "␣")

There is a bug report open for a while about Taginfo applying the wiki page with " " to tags with "_".

Generally this works well, except in the few tags where the value includes a space (" "). I don't think there are any keys with a space.

Taginfo has that nice feature to display spaces as "␣".

Example:

• Tag:species=Castanea sativa (with the value in the infobox as "Castanea sativa")
• Is shown at https://taginfo.openstreetmap.org/tags/species=Castanea_sativa#overview
• And not at https://taginfo.openstreetmap.org/tags/species=Castanea%20sativa#overview

A solution still needs to be found. Maybe loading redirects could do? Example:

• Tag:species=Castanea␣sativa redirecting to Tag:species=Castanea sativa

--99 tabazan (talk) 10:12, 11 March 2026 (UTC)

Somewhat related issue: https://github.com/taginfo/taginfo/issues/483 99 tabazan (talk) 10:37, 11 May 2026 (UTC)

syntaxhighlight version, missing language wikitext, no copy button when combined with inline

The special:veraion lists the hash 0a8a293, which is from the REL1_43-branch (direct-link to commit 0a8a2933fefcca7fc4a2b3e3b8f5193bc28d2016).
Whereas the en.wikipedia.org uses 059f154, from master-branch (direct-link to commit 059f154cbadd2fbb6c5b4387bc4d560e49a0e10a).

Could that be the entire issue, that it's outdated? Could it not be updated to use master instead of the 1.43 version? I don't know what the actual difference between them, or a reason not to use master is.

For example typing <syntaxhighlight lang="wikitext">{{foo|bar=fuzz}}</syntaxhighlight> should work;

{{foo|bar=fuzz}}

But it's not colored. It even puts the page in the Category:Pages with syntax highlighting errors.

(Whether the following is another issue, or related to the version, idk.)

Another example: <syntaxhighlight lang="text" copy inline>{{foo|bar=fuzz}}</syntaxhighlight> should display a button to copy the code into clipboard; {{foo|bar=fuzz}}.
Or swap order of attributes; {{foo|bar=fuzz}} also doesn't show it.
Only without the inline;

{{foo|bar=fuzz}}

–cyton (talk) 07:56, 14 March 2026 (UTC)

Internal error for pages with PDFs

Please fix the issue on https://wiki.openstreetmap.org/wiki/Tag:natural%3Dridge - it shows [6d160809e6513773b6c77292] 2026-03-14 12:08:37: Fataler Ausnahmefehler des Typs „Error“ --Stoecker (talk) 12:10, 14 March 2026 (UTC)

Also https://wiki.openstreetmap.org/wiki/Tag:service=parking_aisle Started to happen between 06 and 12 on 2026-03-12 (software update?) --Stoecker (talk) 12:15, 14 March 2026 (UTC)

Looks like it's a problem with the wiki handling PDFs. --DrMxy (talk) 20:49, 14 March 2026 (UTC)

@Stoecker and DrMxy: Now tracking in GitHub. – Minh Nguyễn ^💬 23:40, 14 March 2026 (UTC)

Logos page is not working

It is generating an error: [4965959b0abdb5b1f1fb1798] 2026-03-20 14:32:26: Fatal exception of type "Error" AngocA (talk) 14:35, 20 March 2026 (UTC)

That's the same problem like above due to an issue with displaying PDF files. --Chris2map (talk) 14:58, 20 March 2026 (UTC)

Images not rendering

In Greece/National Roads, not only are most of the shields not rendering, but the error text is in Chinese Simplified. --ika-chan! (talk) 18:14, 22 March 2026 (UTC)

@Ika-chan!: Well that's a new one! (The error message is "创建缩略图出错：", which means "Error creating thumbnail:".) I've purged the page and it came back with some more shields and errors in English again. Then I purged it a few more times, very slowly, until the rest of the images came back. The errors are due to Wikimedia rate-limiting MediaWiki as it attempts to fetch metadata about the images on the page. The rate limit has gotten much stricter lately, affecting many wikis. The operations team is aware of the issue. – Minh Nguyễn ^💬 22:22, 22 March 2026 (UTC)

Help with Template:TagCount

Recently I've been working on improving and documenting Template:TagCount, which fetches the current usage count of the specified tag from Taginfo. For the most part, I got it working as I wanted, except for those pesky line breaks, which break the text flow when used inline. The current result can be seen at its very Template:TagCount/doc page – it produces an unwanted line break before and after. As can be seen here, using raw HTML <span class="taginfo-ajax"... </span> works fine, but the same content within {{TagCount}} somehow produces a line break and disrupts the text flow.

I've tried eliminating all breaks from the template and fiddled with <includeonly> and <onlyinclude>, to little avail. If anyone knows a magic trick to make it work as desired, it would be much appreciate. As it stands now, the template can be only used within tables, but not in the running text (where it would be most useful). Duja (talk) 11:26, 23 March 2026 (UTC)

I try to avoid the line breaks by cheating with css display:inline-table syntax, see and test Template:Sandbox. --Chris2map (talk) 17:33, 23 March 2026 (UTC)

@Duja: Have you seen and tested it? --Chris2map (talk) 16:44, 30 March 2026 (UTC)

@Chris2map: Thanks! I wish there was a less kludgy way, but that one will do for the time being. I'm busy at the moment so I don't have time for more thorough testing, but I'll try it out these days. Duja (talk) 11:53, 1 April 2026 (UTC)

Still not resolved, unfortunately. The hack works when the template is used in a bulleted list, as in Template:TagCount/doc. However, as soon as it's used in plain vanilla text, it inserts a </p> before and after, again breaking the flow. See the lead section of Relation. It seems it's a MediaWiki featurebug. Duja (talk) 10:49, 15 April 2026 (UTC)

New tools for wiki discussions

The operations team has installed the DiscussionTools extension. [15] 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)

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)

Gadget to track down specific wiki page change easily?

Do we have (or can we add) some gadget to easily find out who created/edited certain text on the wiki, without manually looking at each diff? E.g. something like WWT or similar? Commandline tool WikiBlame tool seems to work, but needs installing on each local machine and is rather cumbersome. What are other people using? mnalis (talk) 18:41, 26 March 2026 (UTC)

I have to assume you don't know of https://wikipedia.ramselehof.de/wikiblame.php?user_lang=en&lang=wiki&project=openstreetmap&tld=org

I don't know if these pre-filled values are correct.
–cyton (talk) 18:47, 26 March 2026 (UTC)

Proposal to enable multilingual default labels on data items

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

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)

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)

Proposed rewrite of citation templates

I've proposed rewriting the citation templates based on a Lua module to catch up with the functionality in Wikipedia's corresponding templates. Minh Nguyễn ^💬 23:13, 18 April 2026 (UTC)

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)

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[16] 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[17] Mooedlorre (talk) 17:46, 9 May 2026 (UTC)

Resolved: done

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

Installation of the "Extension:Media Viewer" on the wiki

Hello everyone,

Is it possible to install the Media Viewer extension on the wiki?

The Media Viewer allow to view images in larger size, with useful information about their contents, authors and related metadata. It also offers a number of tools to share, download or embed media files.

The Media Viewer extension aims to:

• improve the viewing experience for readers
• make it easier to preview and browse images
• provide a quick summary, with easy access to details
• offer features such as enlarge, download, share and embed

(see Help:Extension:Media Viewer for further information)

Thanks for your answers (see https://wiki.openstreetmap.org/wiki/Talk:Wiki/Archive_12#Installation_of_the_%22Extension:Media_Viewer%22_on_the_wiki for the previous discussion which was archived) — Koreller (talk) 19:28, 10 May 2026 (UTC)

addr:place inconsistencies

There are several inconsistencies around the key addr:place=*:

• FR:Key:addr:place suggests to use it in addition to addr:street
• Key:addr:place suggests not to use it in addition to addr:street
• Key:addr:place recommandes the use for villages without street naming.
• Is ID-editor changing "addr:street" automatically to "addr:place" if the value includes "Place" (French for urban square)?
• Some tools/reports routinely expect "addr:place" for urban squares.
• The last two don't depend on consistent street naming in a town/city.

It might just be that the various pages on this wiki are differently out-of-date. What's the best way to note this point?

Ultimately, all addr:*=*-tags appear to be mostly country-specific practices, but the general description here should be comprehensible. 9 tab (talk) 10:30, 11 May 2026 (UTC)

I am a bit bewildered why that question appears here, isn't this page about operational stuff? That said, addr:place gets used in my local area extensively in places (sic) where the streets have no names. This kind of numbering makes it very cumbersome to find a house by its address. It was standard here during the monarchy. A hundred years later lots of communes still not name their streets. So the tag is quite useful. Hungerburg (talk) 21:46, 17 May 2026 (UTC)

Most addr:*=* keys behave differently from country to country, depending on the national address format and other regional considerations. Minh Nguyễn ^💬 12:49, 18 May 2026 (UTC)

"FR:Key:addr:place suggests to use it in addition to addr:street" - feel free to start discussion in French community, maybe Wiki is wrong and there is no such practice. Or it should be rephrased that it is useful only in special cases. Ideally French community would not use it this way and follow global standards, but local peculiarities may block this. Mateusz Konieczny (talk) 05:35, 20 May 2026 (UTC)