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)

Good Morning

Hope you are doing well

I would love to talk to you

Please It's very important  

Please reply me  at - yuliapurro78@gmail.com

So i can explain better

I await your response

God Bless you,

Yulia Upurro111 (talk) 19:19, 22 May 2026 (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)

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)

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)

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)

It sounds like it is entirely taginfo bug and it should be handled there. Is any part buggy on Wiki side? Mateusz Konieczny (talk) 16:04, 7 June 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)

Fixed?

@Stoecker, DrMxy, and AngocA: according to https://github.com/openstreetmap/operations/issues/1344#issuecomment-4113217511 it is fixed Mateusz Konieczny (talk) 12:31, 7 June 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)

@Ika-chan!: looks fixed now Mateusz Konieczny (talk) 15:39, 7 June 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)

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)

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)

Some of the less frequently used citation templates have already been switched over to the new module. --Chris2map (talk) 19:57, 31 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)

It adds more technical load and complexity. For start, is this extension maintained? Mateusz Konieczny (talk) 12:23, 7 June 2026 (UTC)

Yes, this extension is widely used, it's in use in the English and French Wikipedia for example !

Quick quote from https://www.mediawiki.org/wiki/Help:Extension:Media_Viewer and https://www.mediawiki.org/wiki/Reading/Multimedia/Media_Viewer :

Media Viewer was developed by the Wikimedia Foundation's multimedia team from July 2013 to November 2014. It was designed in collaboration with community members, in a series of discussions held over video conferences, IRC, and face-to-face meetings. This tool was then developed and tested as a Beta Feature through April 2014, when it was gradually released worldwide, over a three-month period.

We also conducted rigorous usability studies throughout development, such as this recent usability test -- and ran extensive user surveys with over 18,000 responses in 8 different languages. Additional community suggestions were collected through this widely promoted community consultation on many large wikis around the world, as well as as our regular talk page.

Should we stop making changes to the OSM Wiki for technical reasons in order to ensure greater stability? Is that what the community wants for the wiki?

In fact, this extension is very useful because it saves you from having to open each image in a new tab, and in a project where visuals are so important for understanding what the pages are about, I think it would be a real shame to go without it... — Koreller (talk) 17:04, 11 June 2026 (UTC)

If there is not enough technical capacity to maintain existing install AND add all wanted extensions then it matters little what people want. Note that some of extension requests had testing setup and also people were not really interested in doing that Mateusz Konieczny (talk) 00:20, 12 June 2026 (UTC)

Media support from Wikimedia seems problematic.

• Do we know why it took so many weeks to fix the broken images?
• Would the broken images have been displayed correctly by this extension?

In general, it's better seek technical solutions that make OSM more open. 99 tabazan (talk) 12:29, 13 June 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)

If tagging description is inconsistent feel free to discuss it at https://community.openstreetmap.org/ or tagging mailing list or on other forum to gather info allowing to resolve it, marking it as resolved as far as this specific page is concerned as it is not place to resolve tagging inconsistencies Mateusz Konieczny (talk) 12:22, 7 June 2026 (UTC)

You are the one who commented on that aspect, but we are here merely try to sort out the details of our documentation (which should be consistent). Please go there if you want to resolve them. If you have some insight about current tagging, please add it to the documentation, not its talk page. There it's less helpful. --99 tabazan (talk) 08:34, 8 June 2026 (UTC)

Is osm wiki a good place for sniping about diets?

What you think about https://wiki.openstreetmap.org/w/index.php?title=Tag%3Adiet%3Ameat%3Dyes&oldid=prev&diff=3041736 ?

I think this should be removed on account of being

• irrelevant
• adding complexity to complex sentence
• sniping about diet choices
• offtopic

So, should it stay or not? Mateusz Konieczny (talk) 17:44, 22 May 2026 (UTC)

Oh for f—, give it a rest will you? Eating only meat is not a serious diet in the sense meant by diet:*=*. Sure, you can eat only meat, but it is not sustainable. The reason I wrote that phrase in that small explanatory section that way is to clarify that diet:meat=yes is an exceptional tag within that namespace. It also adds a little lightness to the wiki, which, really, is sorely needed on an internet dominated by corporate interests.

This is the 'offending' text:

“This tag is a bit odd, given that people don't normally restrict their diet to just meat (not if they want to live in good health as well). Whereas diet:vegan=* or diet:gluten_free=* are examples of diet tags that are defined by their avoidance of certain foodstuffs.”

The text you consider a 'snipe' is highlighted in bold here (but not on the wiki page obviously). Beyond that, I really don't give a flying fuck what people eat or not. I take care to write documentation in a manner which documents, clarifies, and helps other users. This specific tag was undocumented before I wrote that page, and because of its odd nature and organically grown usage it differs from the other tags in that prefix-group. That section explaining the nature of this tag is there to help clarify its odd nature. JeroenHoek (talk) 18:49, 22 May 2026 (UTC)

There would probably be no wiki page without @JeroenHoek at all and the change is factually correct. So even through I get were you are coming from, @Mateusz Konieczny, imho this does not need to be reverted.. -- Zimtschnecke (talk) 12:31, 23 May 2026 (UTC)

Somewhat related to this. I think that page is in need for a rewrite. See Talk:Tag:diet:meat=yes#This entire documentation page reads like a personal diary. Mxdanger (talk) 08:00, 24 May 2026 (UTC)

Special:Translate

Hello,

On multilingual Wikimedia projects such as Wikimedia Commons, there is a “Translate This Page” feature. When clicked, it activates Special:Translate, allowing pages to be translated into many languages in a simple and efficient way.

In contrast, translating pages on the OSM Wiki still relies on a much older workflow, which can be quite time-consuming and cumbersome. If a feature similar to Special:Translate were added to the OSM Wiki, it would make translation much easier and encourage more people to contribute translations.

Additionally, the OSM Wiki is missing many useful and modern special-page extensions that are available on other MediaWiki-based projects. The platform would greatly benefit from a broader modernization effort and an update to more current tools and features. Hedda Gabler (talk) 13:41, 6 June 2026 (UTC)

OSM struggles to keep just the basics of the wiki running. Given the recent months-long incident with broken images, it appears this is also caused by the wiki software's defaults.

So rather than adding more dependency on wiki software, it would be better to reduce it and stay open for other solutions. 99 tabazan (talk) 15:45, 6 June 2026 (UTC)

but translating is very useless Hedda Gabler (talk) 16:02, 6 June 2026 (UTC)

No, it is not Mateusz Konieczny (talk) 12:06, 7 June 2026 (UTC)

) When you can easily translate pages using MediaWiki's dedicated Special:Translate feature, is it really more practical to translate them by working through text embedded in wiki markup? It's like rejecting the printing press and insisting that writing by hand is more beneficial.

Hedda Gabler (talk) 15:31, 7 June 2026 (UTC)

I was responding to general "translating is very useless" claim, not commenting on specific technical solutions supporting translating Mateusz Konieczny (talk) 15:38, 7 June 2026 (UTC)

I guess that it is duplicate of https://wiki.openstreetmap.org/wiki/Proposal:Add_Translate_extension_to_Wiki et all? Mateusz Konieczny (talk) 12:20, 7 June 2026 (UTC)

Yes, but four years is a very long time in technology. During those four years, AI and translation tools have advanced dramatically. Should we really treat a vote from four years ago as a reason to never revisit the idea?

I understand that OSM Wiki traditionally tries to avoid adding too many extensions, and that some contributors may still oppose this approach. However, should we continue using workflows that already felt outdated years ago simply because they were accepted at the time?

Personally, I would like to translate many pages into Turkish. I regularly contribute to translation platforms such as TranslateWiki and Weblate, so I am not opposed to translation work itself. The problem is that the current workflow feels cumbersome, inefficient, and discouraging. In many cases, it actually reduces my motivation to translate.

Rejecting a user-friendly, practical, and efficient system is one thing. But several years have passed since that decision was made. Some of the people who participated in that discussion may not even hold the same opinion today. I think it is reasonable to ask whether the community's view has changed and whether the proposal deserves to be reconsidered.. Hedda Gabler (talk) 15:38, 7 June 2026 (UTC)

The bottleneck anyway is in technical effort to do extension herding, existing volunteer sysadmin commented that MediaWiki is highly obnoxious and nightmare in maintenance and extensions make it worse Mateusz Konieczny (talk) 19:11, 7 June 2026 (UTC)

Do we still need that many static translations? AI translation tools have gotten much better. --99 tabazan (talk) 08:31, 8 June 2026 (UTC)

And very good translations is still better and will have extra region-specific content. Mateusz Konieczny (talk) 09:23, 8 June 2026 (UTC)

Possibly not:

• It can be a sign that the original text should be improved.
• Region-specific content that can't be found otherwise isn't helpful.

This doesn't mean that region-specific content can't be written in local language. 99 tabazan (talk) 12:32, 13 June 2026 (UTC)

• • Putting Polish-specific language advise on general page is pointless and having it on Polish language page is in fact helpful Mateusz Konieczny (talk) 05:11, 16 June 2026 (UTC)

    In French, I noticed people adding advice for France into the French version/translation and present it as the general approach. The "addr:place" pages mentioned above have some of that.

    For Polish, there may not be much of a difference in scope, but it can mean that the practice for Poland can't be found through the main version.

    How a specific type of road is called in Polish in Poland can also fit into the English version. 99 tabazan (talk) 10:11, 17 June 2026 (UTC)

Broken proposal tool

https://wiki.openstreetmap.org/wiki/Proposal_process#Creating_a_proposal proposal tool is generating pages with a bad advise embedded in comments. Any idea how to fix it? See https://community.openstreetmap.org/t/proposal-status/144408/ Mateusz Konieczny (talk) 12:04, 7 June 2026 (UTC)

@Lectrician1: if I looked into history correctly you added it Mateusz Konieczny (talk) 12:12, 7 June 2026 (UTC)

For now I did https://wiki.openstreetmap.org/w/index.php?title=Template:Proposal&diff=prev&oldid=3048016 which likely should be amended and more should be synched Mateusz Konieczny (talk) 12:14, 7 June 2026 (UTC)

One version is at https://wiki.openstreetmap.org/wiki/Template:Proposal and one is at https://wiki.openstreetmap.org/wiki/Proposal_process#Proposal_page_template Mateusz Konieczny (talk) 12:15, 7 June 2026 (UTC)

And maybe RFC status was supposed to work? Mateusz Konieczny (talk) 12:16, 7 June 2026 (UTC)

Posted on https://wiki.openstreetmap.org/wiki/Template_talk:Proposal_page#RFC_status Mateusz Konieczny (talk) 12:17, 7 June 2026 (UTC)

LLM generated pages which have been discussed on the forum

After an editing dispute on forests in Germany, a user created a tagging proposal in German language. During the discussion on the German forum, multiple users came to the conclusion that was generated by an LLM (my personal opinion: the user used an LLM to troll the members of the forum because they disagreed with him on the dispute).

If it were spam, I would just add Template:Delete. However, the text is discussed on the forum, therefore it is worth to be kept.

For the time being, I added an Template:Ambox but I am open for better ideas to mark LLM slop which is worth to be preserved for longer. --Nakaner (talk) 12:04, 14 June 2026 (UTC)

It's good practice to use the assistance of AI when creating texts.

Are there are any problems with the content itself (other than you disagreeing with the proposal). 99 tabazan (talk) 12:27, 14 June 2026 (UTC)

It is also good practice to verify the output of AI when making serious proposals, something that the user has, at best, not done (when claiming that produce=timber is largely unused) and at worst actively trolled about (purposefully posted nonsense with intent of provoking a long thread of responses).

In this particular case I don't have a big problem with keeping the draft proposal page since it is not long and the forum discussion is linked (I just fixed the link now). If we get to a point where miles of generated nonsense are uploaded to a wiki page and don't need to be kept, Template:Delete should work... Jarek (talk) 01:40, 15 June 2026 (UTC)

Output should obviously be verified. The question is if the proposal is obviously flawed. That there are alternatives isn't a problem. It's even why a proposal is needed in the first place.

From my experience, discussions in that forum can be a bit strange, but this doesn't directly concern the proposal (found here).

To censure a new user merely because they argue their point badly (or well with help) while paying mappers who do it worse despite years of experience leaves a bad impression.

The proposal can be a valid way forward from a point the (German) community hasn't resolved in years. Drafting a proposal and opening an RFC is a good approach. Mixing it into discussions about issues with a mapper's edits and attempting to seek deletion of the proposal page is not.

On a side note: produce=timber seems to come largely from source=GEOBASES␣2015 on Eucalyptus trees [5]. 99 tabazan (talk) 14:00, 19 June 2026 (UTC)

"Output should obviously be verified." Great. But the reason this discussion was opened here is because the LLM output was obviously not verified (per the forum thread). If you believe that the proposal has merit, you are likely welcome to adopt it and work with the German community to bring it to a vote. Otherwise, I get the impression you're more interested in lawyering. Jarek (talk) 18:33, 19 June 2026 (UTC)

The German community does seem to need external help to sort this out and find a solution for mapping forests in Thuringia. You may call that what you want, but this thread is unlikely going to resolve a matter that seems fairly trivial.

From a general point of view, one should offer them two simple options on how to map this. 99 tabazan (talk) 22:01, 19 June 2026 (UTC)

It can be a good assistance if used properly, but in typical case it is making things worse. If something has clear LLMism it typically is making things worse and should be deleted as spam (rare exceptions may apply). Mateusz Konieczny (talk) 05:16, 16 June 2026 (UTC)

"Typically" might mean that you are using it incorrectly. I think it could have helped you and avoided your SeaMap accident. If you want more specific advice, please post a sample where would think the response is inadequate. 99 tabazan (talk) 17:23, 16 June 2026 (UTC)

By typically I mean that vast majority of LLM use is spamming, posting content that is entirely useless and not wanted in the first place. Or use of LLM in way that makes well-intentioned comments look like LLM spam. And putting any comment you post via LLM (and feeding also context) is decidedly not worth it if benefit is avoiding a mistake like this once every months. Even assuming that LLM never ever add own mistakes and use is costless in all ways. Mateusz Konieczny (talk) 08:23, 17 June 2026 (UTC)

This seems disconnected from the page we are discussing and even the community forum discussion. 99 tabazan (talk) 13:59, 19 June 2026 (UTC)

It seems you are avoiding proper concerns of the community about LLM usage in OSM discussions, which also affect the aforementioned proposal. Jimkats (talk) 21:11, 19 June 2026 (UTC)

One of the forum's moderators noted that LLM usage in forum discussions couldn't be reproduced.

What do you think it means about the accusers?

Do you find such accusations ok?

Having concerns in general does that justify raising them each time your unhappy with the points being expressed? 99 tabazan (talk) 21:57, 19 June 2026 (UTC)

Spam being discussed on forum does not make it worth preserving. Use internet archive wayback machine or other archive service if for some reason preserving spam as evidence is useful. I will not go looking for it, but IMHO it should be deleted. Mateusz Konieczny (talk) 05:16, 16 June 2026 (UTC)